Kernel Licensing Hell

From time to time, the Linux kernel has to deal with copyright and licensing issues. The kernel has always been available under the terms of the GNU General Public License (GPL) v2. An interesting detail is that it would be virtually impossible to change that license, because of the tens of thousands of people who have contributed code to Linux over the decades. Changing the license would mean first getting permission from each and every one of those people to release their contribution under the terms of the new license. As a result, this seems to be unlikely.

At the same time, it's possible for contributors to release their own contributions under different licenses if they choose. If Barack Obama submits a patch, for example, he retains the copyright himself. So he could license that patch for use in the Linux kernel under the terms of the GPL v2, but he could also license that same code for use in a different project under any other terms he wanted, including terms that were incompatible with the GPL. The reasoning behind this is essentially the same as the reason why any change to Linux's licensing would require getting his permission to release his kernel contributions under the new license. He holds the copyright for his contribution, so he would be free to agree to the new license, just as he is free to release his code separately under any other license.

At the same time, it's also possible for Linux to load proprietary drivers that are released only as binary code. There may be some question as to whether those binary drivers are thereby obligated to be released under the GPL – but that's a question for lawyers, and I'm not one. However, traditionally, a running kernel is able to identify whether it has been "tainted" by a binary-only driver by asking the driver to identify its license. If the driver claims to be licensed under the GPL, then presto! But if the driver is licensed under some other license, it would not be able to claim GPL licensing without potentially creating some legal problems for itself. This is useful for the kernel developers, because they're unlikely to waste time chasing down bug reports from users with tainted kernels. What's the point of hunting for a bug that is in all likelihood buried in a binary-only blob of code doing goodness knows what? It's also the case that some parts of the kernel API only make themselves available to drivers that are released under the GPL.

There's another interesting case that came up recently on the Linux Kernel Mailing List: Drivers released into the Linux kernel under multiple licenses, such as the GPL and BSD licenses.

Thomas Gleixner recently pointed out that as far back as 2003 a patch went into the kernel that created some serious ambiguity in how modules should identify their license.

Before the patch, Thomas said, a module could simply use the string "GPL" to identify that it was released under the terms of GPL v2. The goal of the patch itself was to implement the feature I mentioned above – allowing portions of the kernel API to refuse to link to proprietary modules.

Thomas pointed out that as an undocumented side effect, the 2003 patch also changed the meaning of the string used to identify a module's license. Specifically, "GPL" no longer meant only GPL v2, but included any later version of the GPL, at the user's discretion.

The new string to specify only GPL v2 was "GPL v2." Additionally, three other options were also added, for dual licensing and licensing with other additional rights.

One of the main problems with the 2003 change was that, as Thomas said:

"It broke all modules which were using the 'GPL' string in the MODULE_LICENSE() already and were licensed under GPL v2 only.

"A quick license scan over the tree at that time shows that at least 480 out of 1,484 modules have been affected by this change back then. The number is probably way higher as this was just a quick check for clearly identifiable license information.

"There was exactly one instance of a 'GPL v2' module license string in the kernel back then – drivers/net/tulip/xircom_tulip_cb.c , which otherwise had no license information at all. There is no indication that the change above is any way related to this driver. The change happened with the 2.4.11 release, which was on Oct. 9, 2001 – so quite some time before the above commit. Unfortunately there is no trace on the intertubes to any discussion of this."

Thomas also added, "The dual licensed strings became ill-defined as well because following the 'GPL' vs. 'GPL v2' distinction, all dual-licensed (or additional rights) MODULE_LICENSE strings would either require those dual-licensed modules to be licensed under GPL v2 or later or just be unspecified for the dual-licensing case. Neither choice is coherent with the GPL distinction."

To add to the horror of it, Thomas went on to say, "As of 5.0-rc2, 2,873 out of 9,200 instances of MODULE_LICENSE() strings are conflicting with the actual license in the source code (either SPDX or license boilerplate/reference). A comparison between the scan of the history tree and a scan of [the] current Linux tree shows to the extent that the git rename detection over [the] Linux tree grafted with the history tree is halfway complete that almost none of the files which got broken in 2003 have been cleaned up vs. the MODULE_LICENSE string. So subtracting those 480 known instances from the conflicting 2,800 of today, more than 25 percent of the module authors got it wrong, and it's a high probability that a large portion of the rest just got it right by chance."

To address this problem, Thomas posted a patch intended to:

"Remove the well-meant, but ill-defined, distinction between 'GPL' and 'GPL v2' and document that:

• 'GPL' and 'GPL v2' both express that the module is licensed under GPL v2 (without a distinction of 'only' and 'or later') and is therefore kernel license compliant.
• None of the MODULE_LICENSE strings can be used for expressing or determining the exact license.
• Their sole purpose is to decide whether the module is free software or not.
• Add a MODULE_LICENSE  subsection to the license rule documentation as well."

Joe Perches supported Thomas's patch, as did Greg Kroah-Hartman and Jessica Yu. Jessica also offered some textual fixes.

Rusty Russell also supported Thomas's patch, saying, "Thanks [for] taking on such a thankless task Thomas." And remarked, "Frankly, this should be autogenerated rather than 'fixed' if we want this done properly."

In fact, Rusty was the originator of the 2003 patch. By way of explanation, he said that he, "might have been overzealous in assuming a versionless GPL string meant 'or later' (I'm happy for that for my own code, FWIW). My memory is fuzzy, but I don't think anyone cared at the time."

Alan Cox also came in with his recollection of which string meant what in 2003. He said, "Versionless always meant 'or later' outside of the tags. It's the default version of the licence. (Whether 'v2' only has any meaning beyond intent is another debate that I guess some year a lawyer will have to figure out)."

In terms of additional licensing strings, Alan remarked, "They should just have used GPL and additional rights. Either you have GPL rights (and it's ok to use in the kernel) or you don't (and it's proprietary, and the rest is down to derivative works). We don't actually care whether its dual-licensed BSD, or whether it merely grants you an additional right to cheap pizza."

At one point, Thomas also remarked, perhaps somewhat bitterly, "Most people simply do not care, and I'd say most do not understand what licensing means in the first place. But at the same time, a lot of people do not care at all what they are doing."

And there you have it.