News/Resources: Blog

Emerging Technologies BLOG

The Lore of Linux

Posted on Tuesday, Jun 12, 2012


Advising clients on open source is always hard, because there’s not much law but a lot of lore.  There are a couple of court decisions that discuss open source licensing, but they don’t get at the really complicated and interesting issues that arise in the day-to-day.  For those, it’s often necessary to take guidance from very informal sources – FAQs on the GNU website, or postings on the LKML mailing list, or even quotes in articles or blogs from kernel developers.

Last year, for instance, I wrote about how Google had worked around the GPLv2 when it created Android’s Bionic library, using an automated script to “clean” the Linux kernel headers.  After analyzing the code in several files, I concluded that Google’s categorical, automated approach to “clean” the headers didn’t work as a matter of copyright law, and I observed that Google’s methods provided an easy bypass of the GPL for commercial exploitation.

A number of journalists and bloggers recognized the implications of Google’s approach.  But after Linus Torvalds gave a flippant quote to a blogger that the idea “seems totally bogus” – even though Torvalds had not bothered to review the code or the “cleaning” of the Linux kernel header files – critics of my analysis declared it “debunked.”

This sort of thing has happened before.  Back in the early 2000s, the FOSS community  was quite fractured over the issue of whether loadable kernel modules (“LKMs”) could be offered under a non-GPL license.  Many, including the Free Software Foundation, took the view that LKMs were derivative works of the kernel that were subject to GPLv2.  Viewed strictly from the perspective of copyright law, that analysis has some force.  Many open source companies (including some of my clients) were trying to understand their obligations and their risks.

Torvalds took the view that LKMs were by definition derivative works of the kernel.

You just can’t make a binary module for Linux, and claim that that module isn’t derived from the kernel. Because it generally is — the binary module not only included header files, but more importantly it clearly is not a standalone work any more. So even if you made your own prototypes and tried hard to avoid kernel headers, it would still be connected and dependent on the kernel.

And note that I’m very much talking about just the binary. Your source code is still very much yours, and you have the right to distribute it separately any which way you want. You wrote it, you own the copyrights to it, and it is an independent work.

But when you distribute it in a way that is clearly tied to the GPLd kernel (and a binary module is just one such clear tie — a “patch” to build it or otherwise tie it to the kernel is also such a tie, even if you distribute it as source under some other license), you’re by definition not an independent work, any more.

Torvalds announced, however, that he would grant exceptions case by case, on the basis of his own idiosycratic judgments:

(But exactly because I’m not a black-and-white person, I reserve the right to make a balanced decision on any particular case. I have several times felt that the module author had a perfectly valid argument for why the “default assumption” of being derived wasn’t the case. That’s why things like the AFS module were accepted — but not liked — in the first place).

*      *      *

I’d just like to finish off with a few comments, just to clarify my personal stand:

I’m obviously not the only copyright holder of Linux, and I did so on purpose for several reasons. One reason is just because I hate the paperwork and other cr*p that goes along with copyright assignments.

Another is that I don’t much like copyright assignments at all: the author is the author, and he may be bound by my requirement for GPL, but that doesn’t mean that he should give his copyright to me.

A third reason, and the most relevant reason here, is that I want people to know that I cannot control the sources. I can write you a note to say that “for use XXX, I do not consider module YYY to be a derived work of my kernel”, but that would not really matter that much. Any other Linux copyright holder might still sue you.

I don’t really care about copyright law itself. What I care about is my own morals. Whether I’d ever sue somebody or not (and quite frankly, it’s the last thing I ever want to do — if I never end up talking to lawyers in a professional context, I’ll be perfectly happy. No disrespect intended.) will be entirely up to whether I consider what people do to me “moral” or not. Which is why intent matters to me a lot — both the intent of the person/corporation doing the infringement, and the intent of me and others in issues like the module export interface.

Another way of putting this: I don’t care about “legal loopholes” and word-wrangling.

This informal, ad hoc process doesn’t provide certainty for developers who are trying to make signficant technical and business decisions (and for the lawyers trying to advise them).   But, over the years, companies quietly developed their own practical strategies for dealing with the issue, and there were no GPL enforcement actions involving LKMs.

Recently, however, some comments by Alan Cox, a leading kernel developer, resurrected the issue.  On the LKML mailing list, there was discussion about the interaction of a proprietary, non-GPL driver with the GPL Linux kernel.  Cox made clear that he (and other kernel developers) took a different view from Torvalds:

The GPL covers *all* derivative works. EXPORT_SYMBOL doesn’t magically make code non-derivative. If you need to modify the kernel to make your driver work *and* you want to claim it is not derivative then I hope there are good lawyers involved 8-)

The kernel is GPL, all derived works of a GPL codebase are required to be GPL. There is no magic rule about modules. I’ve stated that repeatedly for anything containing a line of code I own. GregKH [Greg Kroah-Hartman, another leading kernel developer] has made it very clear for his code, and so it goes on.

(Given this, I can’t help but wonder about Cox’s view of the “scrubbed” Linux kernel headers in Bionic.)

What’s more, Cox apparently wants to preserve his ability to enforce his rights and seek multiple damages for willful infringement:

I’m a rights holder. . . . The code I provided is licensed under the GPL. Whether the symbol is EXPORT_SYMBOL or EXPORT_SYMBOL_GPL any derivative code (eg code that requires the kernel be modified to match it) cannot call it. I’m recommended by my lawyer to always remind people of this when such a claim is made. It ensures that triple damages for wilful infringement will apply unless the other party can show it reviewed the situation carefully and its appropriately qualified legal staff reached a different conclusion.

It seems unlikely that Cox is seriously considering imminent legal action against companies distributing proprietary kernel modules, but his comments are a timely reminder that Linux kernel developers don’t speak with one voice.  And when his comments are read in their entirety, Cox seems to show particular frustration with the kind of wink-and-nod exceptions to the GPL that seem to happen.   In this he’s not alone.  As Eben Moglen has observed:

it would be very helpful if the kernel developers had decided to formalize the nature of their exceptions, and the Free Software Foundation and I have made a few attempts to discuss that matter with kernel developers. I had conversations with Ted Ts’o, I talked to Linus about it and I understood there were some reluctances to clarify, in a full and complete way, what was going on. There may have even been disagreements among kernel developers about that, I wouldn’t know. But I continue to think that it would be useful, for a whole variety of people who are trying in good faith to do the very best they can, and who may be navigating some dodgy legal territory, for them to be able to refer to something beyond the COPYING file which — with all due respect — I think probably doesn’t contain all the terms that are relevant to the use of the kernel.

Unfortunately, for the foreseeable future, many of us are left to navigate dodgy legal territory, relying only on blogs, mailing lists, and our wits. Blogs