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 targetsGPL_ONLYsymbols,
in which case for some reason it isn’t.Featured Content Ads
add advertising hereOne 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_ONLYmechanism
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.