Linux Today: Linux News On Internet Time.

More on LinuxToday

Editor's Note: Red Hat's Not Proprietary, But Issues Exist

Jan 14, 2005, 23:30 (30 Talkback[s])
(Other stories by Brian Proffitt)

By Brian Proffitt
Managing Editor

Red Hat, Inc. does not make proprietary software.

Red Hat Linux is open source software. That's Fedora and Red Hat Enterprise Linux, mind you.

These two statements should make it clear exactly what my perceptions of Red Hat the company and Red Hat the software are. It's a preemptive argument based on the last time I started this discussion in a public forum.

The discussion is this: if Red Hat is open source, where do all these people get off saying that Red Hat is proprietary?

It has to do with semantics and more than a little corporate politics.

The chief proponent of the idea of a "proprietary" Red Hat is, of course, Sun Microsystems. Both Jonathan Schwartz and Scott McNealy have publicly paraded this idea out to the media in a not-so-transparent attempt to downplay Red Hat and play up Solaris. And while these statements rile many in the Linux community, the fact remains that Sun's motivation is no different than any other corporate entity's: play the game and see who can take home the most marbles.

But, while I am not critiquing Sun's motivation, I am less than sanguine about their tactics. After all, anyone with half a brain can tell you that Linux is open source, and if Red Hat is using Linux according to the GPL, then they are nowhere near a proprietary company. Still, the argument persists. Why?

Because there is some truth to the argument. But when Sun uses the term "proprietary," they are really overgeneralizing the situation in an effort to distance themselves from the likes of Red Hat and (they hope) prevent some problems for themselves later on.

Here's the thing: Red Hat is not proprietary. I'm still grounded in reality. What Red Hat is doing that Sun finds so objectionable and calls "proprietary" is not the way Red Hat codes software. What Sun has issues with is not some violation of the GPL or hidden code in Red Hat Linux: it has issues with the way Red Hat does business.

Red Hat, for instance, is a big partner with Oracle. Big. Millions of dollars are wrapped up between these two companies, as they work to make Oracle fully supported on Red Hat. Oracle's status as independent software vendor for Red Hat gives it a growing market to sell to. And Red Hat gets a very popular set of high-end apps to offer to potential customers. A nice relationship, no? Yet this is exactly the kind of relationship that has Sun (and quite a few others) jumping up and down crying "foul!"

This is because, since Oracle choose to partner with Red Hat, Oracle's software is customized to optimally run on Red Hat (specifically one of the RHEL flavors). And Red Hat, all within the auspices of the GPL, can tweak its code to give Oracle products a very welcoming environment within which to work.

Okay, so what's the problem? After all, I can take the exact same RHEL source code, compile it, call it BPLinux, and run Oracle right on top of it, no sweat. This is also allowed under the GPL. In fact, someone has already done this in an excellent distro known as White Box Linux.

So yes, anyone can get the code for Red Hat Enterprise Linux and run any ISV's code right on it with nary a glitch. This means that, in the sense of open source vs. proprietary, the proprietary argument is shot screaming out of the sky.

Ah, but remember--I said the problem Sun and others had was with the business practices, not the development, distribution, or licensing of Red Hat.

Imagine that I am a corporate executive. I used to imagine this myself quite a bit, but I kept putting myself on vacation in Tahiti and my company always went bankrupt with no one at the helm. But, we'll use the argument anyway.

If I am a corporate executive and I want to run Oracle on Linux, am I going to (a) go with Red Hat, which costs more, or (b) White Box, which is just as good and is free? If I am serious about making sure my investment works in the long term, I'm going to go with (a). Why? Because along with the ISV arrangement that makes the code work all comfy-cozy, there is also a reciprocal support agreement. Which means that if my Oracle server breaks, I can call Oracle and they will fully support me until said server is fixed--if I am running Red Hat. If I am running White Box? Very likely not--even though it's the same code.

Which means, unless I have a treasure trove of Linux and Oracle gurus at my fingertips, going with White Box may be too risky from a business standpoint. Red Hat, then, has achieved what is effectively vendor lock-in with Oracle. If I want support and updates, I need to stick with a Linux that has ISV or similar support arrangements with the Linux distributor.

Red Hat is aggressive with getting ISVs in their stable. This makes sense, since in an open source arena, that's one of the best ways they can distinguish themselves from the competition. And this distinction is what Sun calls "proprietary." Not the license: the business model.

I would argue that this label is false and misleading, since calling anything "proprietary" in this community is like whacking a hornet's nest with a stick. If you want to call it something, call it vendor lock-in, because that's really what we're talking about. But Sun won't do that, and neither will any other Red Hat competitor. Why not?

Because all those competitors are working and hoping for the same kind of vendor relationships, too. How long will it be before we hear Sun making an announcement about a new ISV or golden partner? If Solaris takes off like they hope, not very long at all. Which is why Sun has to be careful what they say, so it won't come back to bite them.

If Sun cries "vendor lock-in!" the media and the community will swoop in on them and call them out when they make their ISV announcements. But, if Sun uses flamebait like "proprietary," then anyone who calls them for the same thing will be pooh-poohed aside as a wrong-headed copycat.

Are these ISV relationships Red Hat has as evil as Sun says? There, I must admit, I waffled--until this week. On the one hand, it did seem a bit skeezy. Linux should be open to all vendors, in an ideal world. Locking one Linux flavor out over others buts a damper on commercial opportunity for the other Linux distros.

But, on the other hand, Red Hat is trying to make a buck, and what they are doing is allowed under the GPL. Sure, Sun will squawk, but they have a vested interest (and perhaps partners) in seeing Linux's biggest commercial distributor go away.

Then Red Hat announced its big push to get more developer involvement from the community this week and my mind was made up. Pushing for more community involvement is all well and good, until you realize that all of the innovation that goes into Fedora/RHEL will simply be folded into Red Hat's commercial model. Red Hat gains the benefits of the innovation, which will ultimately be shared with the other distributions under the GPL, but the other distros will still be kept locked out in the commercial sense.

If you are a developer who's only interested in making great code, then this may not bother you. But from a business standpoint, this seems a bit unfair.

If you don't like Red Hat's practices, there are a couple of options.

First, there is the education option, which will take care of distros like White Box. The more people that get trained up in Linux, the more support options there are for corporate users, which would take the edge off of the ISV-support blade Red Hat is holding.

Second, there is the LSB. If Red Hat and the rest of the commercial distros actively participated in the Linux Standards Base, instead of paying it lip service, then much of the "special code" in one distro would be disseminated to the other Linux flavors. This would also have the added advantage of giving potential ISVs only one Linux target to shoot at, which might open the door for an accelerated number of new applications for all Linux flavors.

Is Red Hat's practice just business as usual for an open source company trying to make it? Time will tell. But one thing this practice is not is proprietary.