Joe, did you read the essay that prompted the comment that prompted this blog entry? I don’t deny that Red Hat has played a huge role in Linux’s success to date—indeed, I point out in the essay that they “got it” when others didn’t (most notably Caldera, which by all accounts should have been the company to succeed, since they were funded when no one else was).
I also don’t deny that self-interest is involved—Red Hat is, after all, a competitor of mine, probably one of the biggest too. However, that doesn’t mean my viewpoint is wrong or that Red Hat’s current strategy won’t be seriously damaging to the Linux ecosystem if it succeeds. I make my living in the Linux ecosystem, so I naturally don’t want it to be damaged. This kind of self-interest is called “enlightened self-interest”, and it’s a fundamental part of capitalism, in which I’m a big believer.
To the point: Yes, Red Hat does GPL everything they do; and, yes, Red Hat does employ a great many people to work on free software. This a good thing.
However, one of the central points of the essay is that software intellectual property isn’t the name of the game anymore. Yes, Red Hat’s business model is unprecedented. They realize that, in a world dominated by open source software (i.e., a commoditized software industry), software IP isn’t the route to dominance it used to be, and they have adapted accordingly, even masterfully. However masterfully they’re going about it, though, it doesn’t change the fact that they’re pursuing the same old thing, the Holy Grail of platform companies: proprietary lock-in.
Don’t believe me that they’re going after proprietary lock-in? If you’re among the large number of folks that are moving to Linux to run commercial applications such as Oracle and SAP, you have little choice but to run Red Hat Enterprise Linux. What is that if not proprietary lock-in, albeit under a different guise? (Ok, you could run SuSE, but Novell’s market position seems to be “like Red Hat but not Red Hat!”, and their financial results the past two quarters show this strategy of imitation isn’t working, as I told Chris Stone two years ago it wouldn’t.)
I’ll believe Red Hat is a good community citizen when they move beyond the lip service they pay to open standards such as LSB. As a start, I’d encourage them to join the rest of us (sans Novell) in pushing the LSB as the platform ISVs and IHVs certify to (Novell, we’d love to have you involved too!). Let’s compete in the market based on service or market/geographic specialization or anything other than making sure potential Linux users don’t have any other choice but to use our stuff. After all, freedom of choice is why all those commercial users are coming to Linux, isn’t it?
1) “If you’re among the large number of folks that are moving to Linux to run commercial applications such as Oracle and SAP, you have little choice but to run Red Hat Enterprise Linux.”
From July 2004 [ with a couple of corrections]
http://ianmurdock.com/?p=136
QUOTE
Ian, I don’t quite understand your chain of reasoning. You are claiming that it is RedHat’s relationship with third party proprietary vendors, who supply support for their closed source software, makes RedHat’s distribution proprietary.
The flaw in your reasoning is that any amalgamation of restricted licensed proprietary and open source software effectively becomes a closed source solution. Even if you did run Oracle on White Box Linux, or even Debian for that matter, you are not even free to redistribute the whole of the resulting combination. By the same twisted reasoning, Debian running Oracle makes Debian a proprietary distribution, which is absurd.
There is no terms in any of the open source or free licenses which guarantee that support for the result will be provided. Support for open source licensed products is handled by a relationship between the customer and vendor that is entirely separate from the licensing of the source code.
If Oracle, or any other vendor, demands that customers have a formal support agreement from Progeny, before providing support for Oracle products running on “componentised” Linux, That does not make the Progeny product a proprietary one.
There are plenty of open source data bases to choose from, it’s only by choosing to use only open sourced solutions that you remain free to choose from who you purchase support.
If your a Redhat’s Enterprise distribution customer, you remain free to select other vendors and other products, and still take the Redhat source code, and in the words of Fleetwood Mac, “Go your own way”. There is no proprietary lock in.
UNQUOTE
Wednesday, April 6th, 2005
http://ianmurdock.com/?p=149
The long haul: Providing long-term support for open source
In which Progeny Linux Systems is praised for providing the kind of support that Redhat should.
But does that make Progeny Linux Systems a proprietary company or Component Linux any more proprietary? No it does not.
It cost proprietary software vendors a LOT to maintain and support their software on many vendors platforms. Companies such as Oracle approach both Novell-Suse and Redhat to provide standardized platforms and support. If Progeny could provide that same service, at a per install client fee, as long at it can prove to the proprietary software vendors that it can bring along a sizable chunk of customers to the said vendors.
2) “I’ll believe Red Hat is a good community citizen when they move beyond the lip service they pay to open standards such as LSB. ”
QUOTE
# rpm -q -i redhat-lsb
Name : redhat-lsb Relocations: (not relocatable)
Version : 1.3 Vendor: Red Hat, Inc.
Release : 4 Build Date: Wed 29 Sep 2004 12:08:36 AM NZST
Install Date: Thu 14 Oct 2004 03:16:22 AM NZDT Build Host: tweety.build.redhat.com
Group : System Environment/Base Source RPM: redhat-lsb-1.3-4.src.rpm
Size : 17654 License: GPL
Signature : DSA/SHA1, Thu 30 Sep 2004 06:47:04 AM NZST, Key ID da84cbd430c9ecf8
Packager : Red Hat, Inc.
URL : http://www.linuxbase.org/
Summary : LSB support for Red Hat Linux
Description :
The Linux Standards Base (LSB) is an attempt to develop a set of
standards that will increase compatibility among Linux distributions.
The redhat-lsb package provides utilities needed for LSB Compliant
Applications. It also contains requirements that will ensure that all
components required by the LSB that are provided by Red Hat Linux are
installed on the system.
UNQUOTE
Redhat, Mandrake and even Suse provide a Linux Standard Base with their products. What none of them currently do is provide the setup to build LSB compatable applications from the outset.
It’s not that difficult for a knowledgeable person to write a few shell scripts to set the compiler/include/link defaults, but it is a major effort to port and maintain the extra libraries and frameworks APIs such as KDE and GNOME that would be needed for many of the LSB applications.
It could also be an opportunity a third party, Progeny Linux Systems for example, to step in and provide the ported development shell scripts, and added libraries which would make the LSB truly useful to many software vendors. Progeny could potentally become the LSB provider on top on Redhat, Fedora, Suse etc. The result may compete with Component Linux, but could also offer LSB bridge to it.
IBM is now offering ISV porting services for Redhat and Novell with Chiphopper …
http://www.developer.ibm.com/isv/eserver/advantage/
If you want ISVs to support the LSB, then I believe that your company ( along with others ) is going to have to step in and provide a similar service assisting ports to a third party maintained LSB on Redhat, Suse, Mandrake, Ubuntu, Xandros, Debian and Component Linux.
BTW, check out the twelfth step on “Trusted Build Agents” in …
http://itheresies.blogspot.com/2004_10_01_itheresies_archive.html
Yes, Ian, I did read your original essay. While it made some good points, both it and the blog entry I replied to struck me as unfair to Red Hat and overly optimistic about a model that I don’t think is going to work at least in the short term, which is why I commented as I did.
I wear two hats; I’ve been active in the development of GCC (these days only as a tester and steering committee member) for over a decade, and I also work for one of the largest suppliers of expensive, proprietary applications that run on GNU/Linux (an EDA company). I therefore have seen the problems with the LSB from both ends. I normally avoid discussing both at the same time because I try to keep these interests rigorously separate, but in this context it seems fairest to mention both. I speak only for myself here.
First, the GCC end. LSB 2.0’s attempt to standardize the C++ ABI was premature and worthless; they standardized on two contradictory specs: a document, and a library release that did not correctly implement that document (the one with gcc 3.3.x). They specified that certain bugs not fixed would be fixed (thus forcing the GCC team to put out 3.3.5 to comply with this), then they specified a major version number corresponding to gcc 3.3, not gcc 3.4, even though 3.4 fixed several ABI bugs. Red Hat had already moved to 3.4, SuSE/Novell was still on 3.3, but this way SuSE gets to brag about LSB compliance and Red Hat looks like the bad guy. The end result of this is that everyone should simply ignore the C++ part of LSB 2.0, because it is worthless, and a major vendor (Red Hat) correctly does not implement it. Hopefully this will be done right for LSB 3.0.
Next, from the proprietary developer point of view. Simply put, certifying to the LSB is not possible. The reason is that no system ever completely and correctly implements its spec, and the spec does not fully specify the behavior of the system. The app might use no interfaces that do not appear in the LSB, yet still pass on vendor A’s system and fail on vendor B’s system. The customer is going to want to know how the app was tested; if it was tested on Red Hat but not on Ubuntu (or vice versa), the vendor is not going to be able to take the risk of claiming that any LSB-compliant system will work. Also, the LSB does not specify many things about a system that might be relevant to whether the app works correctly.
Network effects will inevitably lead to vendors certifying their apps only with the top (or maybe the top two) OS suppliers. This does not prevent the customer from trying some other version, it’s just that the vendor is only going to certify the product on platforms where it has been tested. To do otherwise is not responsible.
Now, certainly application developers should not do foolish things like trying to detect if it’s Red Hat or not, and refusing to run if it’s not.
David,
Please reread http://ianmurdock.com/?p=136. Proprietary != closed source. In other words, I’m not saying Red Hat’s relationships with third party proprietary software vendors make RHEL closed source.
-ian
David,
Sure, Red Hat and SuSE are LSB-certified. But what does that mean anyway? That I can run any LSB-certified application on any LSB-certified distribution? That would be nice, and that was the original idea behind LSB. Trouble is, there are exactly zero LSB-certified applications today, so “LSB-certified” on a distro doesn’t really mean much.
Why haven’t any apps been LSB-certified? The main reason is that ISVs want to support exactly two Linux platforms—no more (because that’s additional cost and complexity), no less (because that gives the one too much market power). And ISVs already have two today: Red Hat and SuSE.
So, if either Red Hat or Novell were committed to actually making the LSB stronger, they could push the LSB instead of their own, um, proprietary (in the sense of “used, made, or marketed by one having the exclusive legal right”, not “closed source”) platforms. And I contend they shouldn’t just do that out of kindness either—it would be a huge competitive differentiator over the other too.
Today, though, they’re choosing not to do that, even while both talk a pretty good game when it comes to the importance of LSB and standards more generally. Lip service.
-ian
Joe,
You make very good points about the LSB’s past mistakes and inherent weaknesses. Indeed, the latter point is the reason Conectiva, Mandrakesoft, Progeny, and Turbolinux formed the Linux Core Consortium—we’re building a reference implementation of the paper standard to complement the existing LSB effort and, hopefully, make the FSG’s nascent certification efforts around LSB more effective (see http://ianmurdock.com/?p=144). Here’s what I said in a
debian-develpost last December discussing this very issue:See http://lists.debian.org/debian-devel/2004/12/msg00975.html for the complete message and links to the long, long, long thread (in which Debian’s variant of Godwin’s law eventually kicked in and the discussion became mostly about non-free firmware in the Linux kernel).
-ian
* proprietary *
Ian, you stated in http://ianmurdock.com/?p=136 “Red Hat clearly possesses exclusive legal rights to Red Hat Enterprise Linux, namely the exclusive legal right to distribute RHEL in binary form“.
The only exclusive right that RedHat asserts in its distros is the use of RedHat’s trademarks, hence the language used on the Centos website ( http://www.centos.org/ ).
As you well know, Centos, and to a lesser extent whitebox linux and taolinux, use the sources from RedHat for each build and *are* binary API clones of Redhat’s commercial products. And, since you mention the vendor, yes, there are plenty of instances of Oracle running on Cenos…
http://www.google.co.nz/search?q=Centos+Oracle
“and most importantly, the accompanying exclusive legal right to pass along the ISV certifications associated with the RHEL binary distribution. ”
What it comes down to is support. Oracle prefers that its Linux using customers have an Redhat distro using the same Redhat RPMs as the one at the support lab at Oracle, because it is easier for Oracle to provide support. Oracle also “certifies” the use of Suse for Oracle’s products in the same way.
As I have pointed out ( and you have failed to provide an counter argument for ) the relationship between Redhat and Oracle does not make Redhat’s commercial Linux distributions “proprietary”.
“Red Hat uses a legal vehicle, a cleverly crafted license it calls a subscription agreement, to enable it to possess these exclusive legal rights in a product that can continue to be marketed as open source.
As I first replied to you
http://ianmurdock.com/?p=136
The “RHN Code” mentioned in the Redhat Subscription Agreement, only refers to the individual digital key used by Redhat’s customers to access, digitally sign and interact with the Redhat services. The legal terms and conditions do not effect the terms and conditions of to the customer for any of the source code released under the GPL or any other of the open source licenses.
S. K. Goel also said:” I get replied from Red Hat that “You can install the same software on as many as machines, But Red hat will give the support on only one machine”.”
It is all about support, and as I pointed out : There is no terms in any of the open source or free licenses which guarantee that support for the result will be provided. Support for open source licensed products is handled by a relationship between the customer and vendor that is entirely separate from the licensing of the source code.
* LSB *
There has not been much support by ISVs for Linux outside of Intel/AMD X86 processor space, which is why IBM got off its collective ass and offered the Chiphopper service.
http://www.developer.ibm.com/isv/eserver/advantage/
Ian, please don’t take this the wrong way, but maybe it would be better for you to stop bitching about the lack of support for LSB, get of your sorry ass and offer a similar sevice for both open source and close source vendors : Porting and certificating applcations to the LSB.
David,
It’s not just the trademarks. Red Hat also controls how its binaries can be legally redistributed. To get access to the binaries, you sign the Subscription Agreement, which says if you redistribute the binaries, your subscription is terminated. Since the value of RHEL lies in the software updates that are only delivered to subscribers, this essentially means you can’t redistribute the binary product. More precisely, you can redistribute the binary product exactly once, because once you do it, you’ve violated the Subscription Agreement, and Red Hat will stop giving you the updates.
Binary API clones aren’t good enough for the ISV/IHV community. Oracle won’t support you if you run CentOS or White Box Linux.
(By the way, if you’re distributing RHEL updates you receive from Red Hat via a single subscription to an entire network of RHEL machines, you’d better make sure Red Hat doesn’t find out about that.)
Re getting off my sorry ass and doing something about this, I beat you to it. See http://ianmurdock.com/?p=144 etc.
-ian