March 04, 2011, 4:34 PM —
After watching Oracle eat away at Red Hat Enterprise Linux (RHEL) business with Oracle Enterprise Linux (OUL), Red Hat has decided to launch a competitive strategy with its RHEL source code that will make it more difficult for Oracle and other downstream RHEL-based distros to follow in RHEL's footsteps.
It's a strategy that has the community up in arms, as it follows the letter of licensing law but not necessarily the spirit.
The problem was first publicly pointed out in the middle of last month at of all places, Debian developer Raphaël Hertzog's blog, where Hertzog interviewed Maximilian Attems, a member of the Debian Project's kernel team.
In that interview, Attems highlighted the reasons behind and the achievements made in the decision to use Linux 2.6.32 for the latest release of Debian GNU/Linux ("Squeeze"). When discussing this topic, he mentioned Red Hat as a specific problem for 2.6.32 development syncing.
"The only real big bastard on the cool 2.6.32 'sync' is Red Hat," Attems said, "Red Hat Enterprise 6.0 is shipping the linux-2.6 2.6.32 in obfuscated form. They released their linux-2.6 as one big tarball clashing with the spirit of the GPL. One can only mildly guess from the changelog which patches get applied. This is in sharp contrast to any previous Red Hat release and has not yet generated the sharp and snide comments in press it deserves. Red Hat should really step back and not make such stupid management moves. Next to them even the semi-maintained Oracle 'Unbreakable' 2.6.32 branch looks better: It is git fetchable."
Attems is about to get his wish granted, because after a slow amount of build up, the rest of the community, and the tech media, is certainly taking issue now.
So what does Attems mean by "obfuscated?"
Previously, whenever a RHEL release was made, a vanilla Linux kernel was shipped along with seperate patches that would, when applied, make the kernel used by that release of RHEL unique for RHEL. Since the kernel and the patches were shipped seperately, any downstream vendor could see what was going on and releatively easily make adjustments to the kernel for their own downstream distro, such as CentOS, OUL, or Scientific Linux (which just came out with their 6.0 release based on RHEL 6.0 this week).
Now, it seems, Red Hat is releasing the source code for the kernel in one big tarball file, with all of the patches applied already. Functionally, this makes no difference for RHEL users, since the kernel is optimized for, well, RHEL. But for downstream vendors it has now become much harder to discern the exact changes Red Hat has made to its kernel and therefore make changes optimized for the downstream distribution.
Let's be completely clear: this is all perfectly on the up and up. The GNU General Public License under which RHEL is licensed requires that source code be supplied with the binaries--which is exactly what Red Hat is doing. There's nothing in the rules that says release source code in a way that is most efficient for downstream developers to use.
For its part, Red Hat is pretty much affirming what everyone figured was going on: that this was in direct response to competition from Oracle and OUL. A blog entry by Red Hat CTO and VP Worldwide Engineering Brian Stevens posted earlier today pretty much laid it out:
"When we released RHEL 6 approximately four months ago, we changed the release of the kernel package to have all our patches pre-applied. Why did we make this change? To speak bluntly, the competitive landscape has changed. Our competitors in the Enterprise Linux market have changed their commercial approach from building and competing on their own customized Linux distributions, to one where they directly approach our customers offering to support RHEL," Stevens wrote.
"Frankly, our response is to compete. Essential knowledge that our customers have relied on to support their RHEL environments will increasingly only be available under subscription. The itemization of kernel patches that correlate with articles in our knowledge base is no longer available to our competitors, but rather only to our customers who have recognized the value of RHEL and have thus indirectly funded Red Hat’s contributions to open source that will advance their business now and in the future," Stevens continued.
I give them props for not beating around the bush, that's for sure.
I am of two minds on this, The business mind says that this seems a perfectly reasonable step to compete against Oracle. After all, Oracle had no compunctions against putting the screws to Red Hat when it broke its partnership with Red Hat and started creating its own Linux distro--essentially a rebranded RHEL. Indeed, we all remember Larry Ellison gloating how open source licensing made it so easy.
But the community mind is not so happy about it.
For one thing, there are other distros downstream from RHEL that are going to get torqued around by this move--notably the aforementioned CentOS and Scientific Linux. While neither distro is specifically mentioned by Stevens, I can't help but think that Red Hat won't be too sad to see them damaged, particularly CentOS, which is a very popular free version of RHEL that's very big in the cloud.
For another, is this going to be the start of a new kind of positioning in the Linux community where we see upstream and downstream vendors deliberately withholding patch information and other key bits of knowledge just to make things more difficult? I wonder what Red Hat would do if some of its upstream software vendors decided to cut them off from such info?
And will others follow suit? Debian can get pretty touchy about Canonical, you know, so here's a complete absolutely fictional example: what if Debian just released pre-patched code to their downstream, which includes Canonical's Ubuntu?
So while Red Hat's move makes good business sense, I think it does little to improve the general health of the Linux community, and may even cause more harm than good.
For years, Red Hat has been able to complete on value and support. Have they finally decided that that alone isn't enough?