Bradley M. Kuhn

• Contact
• Blog  
• Interviews / Articles  
• Software
• Résumé

Thoughts On GPL Compliance of Red Hat's Linux Distribution

Friday 11 March 2011 by Bradley M. Kuhn

Today, I was interviewed by Sam Varghese about whether Red Hat's current distribution policies for the kernel named Linux are GPL-compliant. You can read there that AFAICT they are, and have been presented with no evidence to the contrary.

Last week, when the original story broke, I happened to be at the Linux Foundation's End User Summit, and I had a rather extensive discussion with attendees there about this issue, including Jon Corbet, who wrote an article about it. In my mind, the issue was settled after that discussion, and I had actually put out of my mind, until I realized (when Varghese contacted me for an interview) that people had conflated my previous blog post from last weekend as being a comment specifically on the kernel distribution issue. (I'd been otherwise busy this week, and thus hadn't yet seen Jake Edge's follow-up article on LWN (to which I respond to in detail below).)

(BTW, on this issue please note that my analysis below is purely a GPLv2 analysis. GPLv3 analysis may be slightly different here, but since, for the moment, the issue relates to the kernel named Linux which is currently licensed GPLv2-only, discussing GPLv3 in this context is a bit off-topic.)

Preferred Form For Modification

I have been a bit amazed to watch that so much debate on this has happened around the words of preferred form of the work for making modifications to it from GPLv2§3. In particularly, I can't help chuckling at the esoteric level to which many people believe they can read these words. I laugh to myself and think: not a one of these people commenting on this has ever tried in their life to actually enforce the GPL.

To be a bit less sardonic, I agree with those who are saying that the preferred form of modification should be the exact organization of the bytes as we would all like to have them to make our further work on the software as easy as possible. But I always look at GPL with an enforcers' eye, and have to say this wish is one that won't be fulfilled all the time.

The way preferred form for modification ends up working out in GPLv2 enforcement is something more like: you must provide complete sources that a sufficiently skilled software developer can actually make use of it without any reverse engineering. Thus, it does clearly prohibit things like source on cuneiform tablet that Branden mentions. (BTW, I wonder if Branden knows we GPL geeks started using that as an example circa 2001.) GPLv2 also certainly prohibits source obfuscation tools that Jake Edge mentions. But, suppose you give me a nice .tar.bz2 file with all the sources organized neatly in mundane ASCII files, which I can open up with tar xvf, cd in, type make and get a binary out of those sources that's functional and feature-equivalent to your binaries, and then I can type make install and that binary is put into the right place on the device where your binary runs. I reboot the device, and I'm up and running with my newly compiled version rather than the binary you gave me. I'd call that scenario easily GPLv2 compliant.

Specifically, ease of upstream contribution has almost nothing to do with GPL compliance. Whether you get some software in a form the upstream likes (or can easily use) is more or less irrelevant to the letter of the license. The compliance question always is: did their distribution meet the terms required by the GPL?

Now, I'm talking above about the letter of the license. The spirit of the license is something different. GPL exists (in part) to promote collaboration, and if you make it difficult for those receiving your distributions to easily share and improve the work with a larger community, it's still a fail (in a moral sense), but not a failure to comply with the GPL. It's a failure to treat the community well. Frankly, no software license can effectively prevent annoying and uncooperative behavior from those who seek to only follow the exact letter of the rules.

Prominent Notices of Changes

Meanwhile, what people are actually complaining about is that Red Hat RHEL customers have access to better meta-information about why various patches were applied. Some have argued (quite reasonably) that this information is required under GPLv2§2(a), but usually that section has been interpreted to allow a very terse changelog. Corbet's original article mentioned that the Red Hat distribution of the kernel named Linux contains no changelog. I see why he said that, because it took me some time to find it myself (and an earlier version of this very blog post was therefore incorrect on that point), but the src.rpm file does have what appears to be a changelog embedded in the kernel.spec file. There's also a simple summary as well that in release notes found in a separate src.rpm (in the file called kernel.xml). This material seems sufficient to me to meet the letter-of-the-license compliance for GPLv2§2(a) requirements. I, too, wish the log were a bit more readable and organized, but, again, the debate isn't about whether there's optimal community cooperation going on, but rather whether this distribution complies with the GPL.

Relating This to the RHEL Model

My previous blog post, which, while it was focused on answering the question of whether or not Fedora is somehow inappropriately exploited (via, say, proprietary relicensing) to build the RHEL business model, also addressed the issue whether RHEL's business model is GPL-compliant. I didn't think about that blog post in connection with the distribution of the kernel named Linux issue, but even considering that now, I still have no reason to believe RHEL's business model is non-compliant. (I continue to believe it's unfriendly, of course.)

Varghese directly asked me if I felt the if you exercise GPL rights, then your money's no good here business model is an additional restriction under GPLv2. I don't think it is, and said so. Meanwhile, I was a bit troubled by the conclusions Jake Edge came to regarding this. First of all, I haven't forgotten about Sveasoft (geez, who could?), but that situation came up years after the RHEL business model started, so Jake's implication that Sveasoft “tried this model first” would be wrong even if Sveasoft had an identical business model.

However, the bigger difficulty in trying to use the Sveasoft scenario as precedent (as Jake hints we should) is not only because of the “link rot” Jake referenced, but also because Sveasoft frequently modified their business model over a period of years. There's no way to coherently use them as an example for anything but erratic behavior.

The RHEL model, by contrast, AFAICT, has been consistent for nearly a decade. (It was once called the “Red Hat Advanced Server”, but the business model seems to be the same). Notwithstanding Red Hat employees themselves, I've never talked to anyone who particularly likes the RHEL business model or thinks it is community-friendly, but I've also never received a report from someone that showed a GPL violation there. Even the “report” that first made me aware of the RHEL model, wherein someone told me: I hired a guy to call Red Hat for service all day every day for eight hours a day and those jerks at Red Hat said they were going to cancel my contract didn't sound like a GPL violation to me. I'd cancel the guy's contract, too, if his employee was calling me for eight hours a day straight!

More importantly, though, I'm troubled that Jake indicates the RHEL model requires people to trade their GPL rights for service, because I don't think that's accurate. He goes further to say that terminat[ing] … support contract for users that run their own kernel … is another restriction on exercising GPL rights; that's very inaccurate. Refusing to support software that users have modified is completely different from restricting their right to modify. Given that the GPL was designed by a software developer (RMS), I find it particularly unlikely that he would have intended GPL to require distributors to provide support for any conceivable modification. What software developers want a license that puts that obligation hanging over their head?

The likely confusion here is using the word “restriction” instead of “consequence”. It's undeniable that your support contractors may throw up their hands in disgust and quit if you modify the software in some strange way and still expect support. It might even be legitimately called a consequence of choosing to modify your software. But, you weren't restricted from making those modifications — far from it.

As I've written about before, I think most work should always be paid by the hour anyway, which is for me somewhat a matter of personal principle. I therefore always remain skeptical of any software business model that isn't structured around the idea of a group of people getting paid for the hours that they actually worked. But, it's also clear to me that the GPL doesn't mandate that “hourly work contracts” are the only possible compliant business model; there are clearly others that are GPL compliant, too. Meanwhile, it's also trivial to invent a business model that isn't GPL compliant — I see such every day, on my ever-growing list of GPL violating companies who sell binary software with no source (nor offer therefor) included. I do find myself wishing that the people debating whether the exact right number of angels are dancing on the head of this particular GPL pin would instead spend some time helping to end the flagrant, constant, and obvious GPL violations with which I spent much time dealing time each week.

On that note, if you ever think that someone is violating the GPL, (either for an esoteric reason or a mundane one), I hope that you will attempt to get it resolved, and report the violation to a copyright holder or enforcement agent if you can't. The part of this debate I find particularly useful here is that people are considering carefully whether or not various activities are GPL compliant. To quote the signs all over New York City subways, If you see something, say something. Always report suspicious activity around GPL software so we find out together as a community if there's really a GPL violation going on, and correct it if there is.

Posted on Friday 11 March 2011 at 17:20 by Bradley M. Kuhn.

Comment on this post in this identi.ca conversation.