Linux's GPLv2 licence is routinely violated

The Linux kernel is licenced under the GPLv2. There are several notable things about this:

  • The licence is specifically GPLv2 and not “GPLv2 or later”, which is the default when applying the GPLv2 to software.

  • Linus Torvalds seems to speak as though he has the power to interpret the GPL. He does not; nor does the FSF.

  • Supposedly, the requirements of the GPLv2 do not apply to the userspace ABI.

  • Conversely, the Linux kernel project claims that the GPLv2 conditions do apply to the kernel-mode ABI. The legal theory behind this is that by linking to the kernel, you create a derived work of it. This argument is somewhat strengthened by the project's refusal to create a stable kernel-mode ABI, meaning that the ABI is constantly changing, requiring modules to be built against a precise version.

    Nonetheless, there is nothing preventing someone from, with sufficient effort, producing cleanroom documentation of the ABI and targeting it, thereby creating compatible modules without creating a derived work.

  • The situation gets more bizarre with the introduction of “GPL_ONLY” symbols. The idea is that binary modules are allowed, but only if they target only “GPL_ONLY” symbols. This makes no sense, because the GPLv2 does not enable any such distinction; either something is a derived work, in which case the GPLv2 applies, or it is not. Again, the implication here seems to be that the Linux kernel project has the power to interpret and selectively disapply provisions of the GPLv2. This is not the case. Doing so would require the authorization of all kernel copyright holders (i.e. all contributors).

  • If modules are derived works, then every non-GPL non-cleanroomed module is violating the GPLv2. This creates a ticking time bomb for companies which rely on this ability, because they could get sued by any contributor at any time.

  • If modules are not derived works, the “GPL_ONLY” provision is meaningless and unenforceable.

  • The userspace ABI is stable and intended not to cause anything targeting it to become a derived work. But once again, this seems to be a way in which the kernel project seems to think it has the power to interpret the GPL. In their minds, targeting the userspace ABI doesn't make a derived work, but writing a module does, unless it only targets GPL_ONLY symbols, in which case for some reason it isn't.

    One argument in favour of the userspace ABI not creating a derived work is probably that other systems, such as FreeBSD, implement support for the Linux userspace ABI. Moreover, as a stable ABI, consumption of the userspace ABI is less dependent on header files, etc. which make classification as a derived work more likely. Mere implementation of a protocol cannot constitute derived work; protocols and file formats cannot be copyrighted, and indeed it would be a disaster for interoperability if they could be.

  • It is rather ironic that in some ways, one has more freedom in how one licences a kernel driver for Windows than the freedom one supposedly has in writing a kernel module for Linux. But again, the only thing forcing modules to be GPLv2-compatible is the rate of change of the kernel mode ABI making it impractical to target it via cleanroom methods. (If the project were to contest the legal validity of this, then some of the copyright claims made by the Linux kernel project would actually be stronger than copyright itself can provide. Under such a model of copyright, the IBM PC could never have been reverse engineered and cloned, and the computer on which I am typing this would not exist.)

  • TLDP's Module HOWTO explicitly recognises that the GPL_ONLY mechanism is probably nonsense:

    What about GPL-ONLY symbols? Kernel developers have selected some symbols that one uses in interfacing an LKM to the base kernel as GPL-only. These symbols have "GPL_ONLY" in their names, making this intent obvious. Furthermore, in order for the Linux module loader to let your LKM use them, you must include some code in your LKM that supposedly certifies you license your module under GPL.

    These probably have no legal significance. If the LKM is not a derivative work of Linux, then the kernel developers simply have no legal way to block you from putting the GPL annotation in your code and distributing it binary-only anyhow. If the LKM is a derivative work of Linux, then the absence of the GPL-only classification of the symbol is probably not enough to give permission to use it in a binary-only LKM. The license document does not mention them. At best, you can use GPL-only symbols as a gentleman's promise not to sue you for use of all the other symbols in a binary-only LKM.

    This “promise not to sue” of course relies on the goodwill of everyone who has ever contributed to Linux.

What this basically comes down to is that the Linux kernel isn't really GPLv2. It's nominally licenced under a licence which is routinely violated, even with the implicit authorization of the people in charge of the project (an authorization that isn't theirs to give).

This is actually quite a bad situation. You have use cases for binary kernel modules which need to be accommodated, and people trying to accommodate them, and the result of this is to make the GPLv2 essentially a mere suggestion that, in practice, everyone violates.

This demonstrates the issue with GPLv2-style licences: if it turns out you really need to grant an exception, and the project has had a large number of external contributions, and you don't do copyright assignment, you're basically royally screwed. You have no choice but to soldier on basically hoping that no contributor to the project decides to start copyright trolling the users.

The very fact that the FSF feels the need to include “or later” in the standard licence application boilerplate demonstrates that even they think locking huge amounts of source code and compounded years of effort to a given licence, one which is quite particular and complex, is too hazardous.

Actually, it gets worse. Here's what the GPLv2 says about termination:

You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance.

So if you violate the licence, it is terminated. That's it. Given that “you” may refer to a corporation, this creates the following disturbing possibility:

  • A corporation sustains a majority of its business using Linux-powered technology.

  • At some point, they fall for the pretence that they can avoid GPL_ONLY symbols and have their binary kernel module be in compliance. Or they violate the GPLv2 in any other way; they neglect to provide source code, for example.

  • A malicious Linux contributor (with money to waste on legal fees) uses this to their advantage. They might demand protection money or else they sue. Or they might be a competitor which simply demands they cease using Linux outright. Since the GPLv2's termination clause is irreversible, if a corporation violates the GPLv2 even once, even only temporarily, they are perpetually vulnerable to this forever after.

    Keep in mind this contributor could be a corporation which received copyright under work-for-hire provisions with regard to code contributed to the kernel by their employees.

This trolling corporation could become a SCO-on-steroids. The difference is that their legal arguments are actually, seemingly, valid. This demonstrates the hazards of GPL_ONLY and encouraging people to selectively ignore the GPL.