February 26, 2016

Prologue

Linux kernel licensing

The license terms on the Linux kernel are those of GPLv2. This is the unanimous consensus of the extensive community of copyright holders. No other terms, or modifications of those terms, are represented in any document as the consensus position of the relevant parties.²

The programmers who build the kernel have declared specific intentions with the respect to the interpretation of GPLv2's terms as those terms apply to their work in the COPYING file in the top level of the kernel source tree. This declaration reads:

NOTE! This copyright does not cover user programs that use kernel services by normal system calls - this is merely considered normal use of the kernel, and does not fall under the heading of "derived work". Also note that the GPL below is copyrighted by the Free Software Foundation, but the instance of code that it refers to (the Linux kernel) is copyrighted by me and others who actually wrote it.

Also note that the only valid version of the GPL as far as the kernel is concerned is this particular version of the license (ie v2, not v2.2 or v3.x or whatever), unless explicitly otherwise stated.³

The kernel is built with APIs for the attachment of modules---which in a user space program might be called "plug-ins"---which can be statically linked with the kernel or dynamically loaded into kernel space by a running kernel. As with any such interface in a GPLv2 program running outside kernel space, we can assume that within kernel space the overwhelming preponderance of such modules or plug-ins can be assumed to fall within the scope of the copyleft on the kernel. The kernel developers use the phrase "derived work" as a term of art to indicate descriptively those modules or other forms of code that might be attached to or linked with a copy of the kernel that fall within the scope of the copyleft.⁴ As an example, Linus Torvalds wrote in 2003:

On Wed, 3 Dec 2003, Kendall Bennett wrote:

I have heard many people reference the fact that the although the Linux Kernel is under the GNU GPL license, that the code is licensed with an exception clause that says binary loadable modules do not have to be under the GPL.

Nope. No such exception exists.

There's a clarification that user-space programs that use the standard system call interfaces aren't considered derived works, but even that isn't an "exception" - it's just a statement of a border of what is clearly considered a "derived work". User programs are clearly not derived works of the kernel, and as such whatever the kernel license is just doesn't matter.

And in fact, when it comes to modules, the GPL issue is exactly the same. The kernel is GPL. No ifs, buts and maybe's about it. As a result, anything that is a derived work has to be GPL'd. It's that simple.

Now, the "derived work" issue in copyright law is the only thing that leads to any gray areas. There are areas that are not gray at all: user space is clearly not a derived work, while kernel patches clearly are derived works.

But one gray area in particular is something like a driver that was originally written for another operating system (ie clearly not a derived work of Linux in origin). At exactly what point does it become a derived work of the kernel (and thus fall under the GPL)?

THAT is a gray area, and that is the area where I personally believe that some modules may be considered to not be derived works simply because they weren't designed for Linux and don't depend on any special Linux behaviour.

Basically:

• anything that was written with Linux in mind (whether it then also works on other operating systems or not) is clearly partially a derived work.
• anything that has knowledge of and plays with fundamental internal Linux behaviour is clearly a derived work. If you need to muck around with core code, you're derived, no question about it.

Historically, there's been things like the original Andrew filesystem module: a standard filesystem that really wasn't written for Linux in the first place, and just implements a UNIX filesystem. Is that derived just because it got ported to Linux that had a reasonably similar VFS interface to what other UNIXes did? Personally, I didn't feel that I could make that judgment call. Maybe it was, maybe it wasn't, but it clearly is a gray area.

Personally, I think that case wasn't a derived work, and I was willing to tell the AFS guys so.

Does that mean that any kernel module is automatically not a derived work? HELL NO! It has nothing to do with modules per se, except that non-modules clearly are derived works (if they are so central to the kenrel that you can't load them as a module, they are clearly derived works just by virtue of being very intimate - and because the GPL expressly mentions linking).

So being a module is not a sign of not being a derived work. It's just one sign that maybe it might have other arguments for why it isn't derived.⁵

The primary architectural purpose of GPL's copyleft is to prohibit the making of proprietary extensions or enhancements to free software programs. See SFLC Guide to GPL Compliance, 2d Edition. The kernel development community, speaking through leading members, has repeatedly indicated that they do not somehow favor or make a GPL exception for proprietary-licensed or "closed source" kernel modules, including particularly device drivers. The kernel community has taken measures in many cases to encourage, assist, or require of parties making non-GPL'd modules that they comply with the kernel's license terms.

CDDL

CDDL is a free software license, originally written and used by Sun Microsystems to release various programs copyrighted by Sun. Among the most important works so licensed by Sun was OpenSolaris, a version of its Solaris operating system now no longer actively maintained by Sun's successor in interest, Oracle. CDDL permits source code under its terms to be compiled or otherwise made into executable versions or combinations that can be redistributed under any license terms. At the file level, all source code files initially distributed under CDDL by the copyright holder must be redistributed, in all modified or unmodified versions, under the terms of CDDL. This is a "partial copyleft" license.

Because both GPLv2 and CDDL have some elements of strong copyleft, requiring some forms of redistribution to occur only under the terms of that license, questions have repeatedly arisen over their history about the consequences of various combinations of code under the licenses. Such questions are again important, and raise issues on which clarity is essential for the avoidance of deadweight loss to the users copyleft is designed to protect.

ZFS

ZFS is a "file system," an operating system component designed, in Unix-descended operating system kernels like Solaris or Linux, to be modularized, so that any instance of the running OS kernel may support multiple file system architectures over uniform APIs, and can add or remove support for particular file system architectures while the kernel is running. From Sun's first publication of ZFS as part of Solaris in 2005, its innovative features and robustness in operation won it a loyal following. Users of systems built on the Linux kernel, which is now the preponderant server OS kernel in the world, have shown the value of ZFS in such systems. ZFS has been made available by programmers working from the free software CDDL-licensed versions, for use as a "userspace filesystem" in GNU/Linux systems through the FUSE APIs. This mode of use presents no licensing issues: the filesystem is running as a distinct userspace process making system calls to the kernel through stable, defined, standard interfaces. As the kernel COPYING file states, in that mode of employment the filesystem is not a "derived work" of the kernel, which means it is not within the scope of the kernel copyleft.

But when essentially the same code is linked into kernel space through the LKM APIs, it becomes part of one work with the kernel, and a potential conflict of license terms results. In this mode of use, a translation layer of code---licensed under GPLv2's terms and subject to the kernel copyright holders' interpretation of those terms---mediates between the filesystem and the kernel into which it is linked, translating between Solaris system calls made by the filesystem and Linux kernel system calls and services. The combination of those parts is then compiled into a kernel module which can be statically linked into a single kernel binary, or loaded by a running kernel into kernel space "on the fly."

When, in this mode of employment, the CDDL-licensed code implementing the filesystem is combined with the module-specific translation layer and the result is then statically or dynamically linked into the Linux kernel, the resulting binary is licensed to all users under the terms of GPLv2, and only GPLv2, as the license requires. This happens because CDDL gives permission for binary forms of the code it licenses to be released under any license, and the license terms in effect are those of GPLv2. The making of the binary itself does not result in infringement of the kernel copyrights, or a violation of GPLv2's terms.

But GPLv2 section 3 requires for compliant distribution of such a binary that "complete and corresponding source code" be provided or offered. GPLv2 section 2(b) requires that the source code must be made available under "the terms of this license." The source trees of many GPL-licensed works, including the Linux kernel, contain files originally published by their authors under other free software licensing terms. In these cases, where the licenses involved are "permissive" licenses---such as a GPL-compatible BSD license, the MIT/X11 license or the equivalent---it can be said that GPLv2 section 2(b) is literally complied with, because those licenses permit the source code to be placed under other license terms, and those files are "relicensed" to GPL when they are included in the larger project's source tree. Though this is literally satisfactory from the GPL perspective, it raises equitable concerns of another kind. The improvements or modifications made to that code within the context of the GPL'd project can now not be picked up and used by the original projects or other downstream developers, unless they are prepared to place their entire work under GPL copyleft terms. This "traps" the improvements to the original contribution where they cannot be reused by the original contributors under their preferred terms. This is legitimate conduct on the part of the GPL-using project, but it unnecessarily deteriorates comity among free software developers. A better approach than the "relicensing" approach is to keep the files so employed within the GPL-licensed project's source tree with their additional licensing material intact, even when modified, so that if those files, or any parts thereof, are removed from the GPL'd project they can be reused under the original license, with the improvements made in the GPL'd context fully available under those terms. This is the official advice of SFLC to its GPL-using clients. See Maintaining Permissive-Licensed Files in a GPL-Licensed Project: Guidelines for Developers

In the present case, the files containing the code of the ZFS filesystem are available under free software license, but the terms offered are CDDL, not GPLv2. So although complete and corresponding source code for the GPLv2-licensed kernel binary is available under free license, some files are available only under terms of CDDL, which is inconsistent with the literal meaning of GPLv2 section 2(b). For a community of copyright holders whose consensus intention is to limit their permission to the literal meaning of GPLv2's words, this is a sufficient basis for an objection to the combination.

There are also, however, good reasons for a community of GPLv2 licensors so situated not to object:

1. All users of the binary (which is the form in which the overwhelming preponderance of users interact with the work) have their rights fully protected by GPLv2, which is the only license covering the binary;
2. There is no proprietary enhancement to the program, or any other frustration of the purpose of copyleft, because all the source code is freely available under license terms that guarantee all future versions will also be free software;
3. There are also, therefore, no "closed source" issues of maintainability or reliance in unmodifiable code on modifiable interfaces that future kernel development might change;
4. These files can be kept within the kernel source tree in a GPL'd whole, while managed with their CDDL licensing material intact, as is done with other non-GPL'd free software source files in other GPL-licensed projects following current best practices;
5. In sum, therefore, no developer and no user is deprived of any rights that either copyleft license, GPLv2 or CDDL, is designed to ensure and protect.

In this specific sense, then, the conduct which falls outside the words of GPLv2 falls within the "equity of the license," or its "spirit." As all Western legal systems have known since Aristotle, literal interpretation of any legal material will sometimes produce unintended unjust results, which can and should be corrected by the invocation of "equity." This present issue is evidently an example in which the tension between literal and equitable interpretation is raised, and it is the consensus of the kernel copyright holders' intention which determines which mode of interpretation is to be employed.

There is some historical precedent, outside the kernel development community, for application of the equity of the license to the issue of GPLv2/CDDL combination---precedent which has lately gained sad resonance. When the late Ian Murdock joined Sun Microsystems in order to make Project Indiana---a combination of the GNU userland with the Solaris kernel space comprising a Debian GNU/Solaris---a related licensing issue developed. This combination required the linking of GPLv2-licensed GNU Project programs with the CDDL-licensed OpenSolaris C library. The question was, whether the "system library exception" in GPLv2 applied to a "free but incompatibly copylefted" library linked with every GPL-licensed executable, or whether the system library exception failed to cover that case, and the combinations involved violated GPL. Some acute and freedom-vigilant members of the Debian community raised the question, and advocated deciding it on the basis of literal interpretation of GPLv2's "system library exception."

Richard Stallman and I⁶ both felt, and said publicly, that the issue was a close one under a literal interpretation of GPLv2, but that the combination involved plainly fell within the equity or spirit of GPLv2. Agreeing that licensors could differ in their intention with respect to the interpretation to apply, and concerned to avoid the ambiguity in future, we modified in GPLv3 the definition of "system libraries" and the accompanying exception from source code copyleft requirements, to make the most literal interpretation of the new license text coincide with our understanding of the equity of the license.

The Project Indiana case did not involve the interpretation of GPLv2 section 2(b); it concerned whether section 2(b) applied at all, as to which the literal language and the equity of the license may have suggested divergent conclusions. And the copyright holder expressing its intention with respect to the terms was the GNU Project of FSF, not the completely separate and independent licensing community of Linux kernel developers. This is not controlling precedent in any sense, but the situation instructively shows why the literal meaning of the license's words may not be entirely dispositive of the licensing interpretation that a community of GPL-using developers might choose to apply.

There are sound reasons on both sides of the question, therefore, representing a clear illustration of the tension between literal and equitable interpretation of license terms. In US copyright law, the meaning of any license is determined by the intentions of the licensor: because a license is a unilateral permission by a holder of otherwise exclusive rights, the law holds that the licensor gives neither more nor less permission than the evidence shows it actually intended.

No existing record conclusively or convincingly demonstrates whether the only relevant licensing community, the holders of kernel copyright, intends a literal or equitable interpretation of its license terms under present circumstances. As so often in the long history of our law, both literal and equitable postures of interpretation are completely tenable, and reasonable people in the relevant roles may justifiably disagree. The matter is smaller than that which divided the Pharisees from the Saducees, but from a legal theory point of view it is of the same fundamental kind. As bystanders, the evidence does not allow us to determine whether there is a consensus among the relevant licensors, or what that consensus is. If there were a consensus among the kernel copyright holders that they wished to communicate, the briefest of modifications to the kernel COPYING file would be sufficient to publish the outcome in an effective form. Private communications from the kernel community's leadership to the leading distributors of free software GNU/Linux and Android/Linux distributions would no doubt be treated as dispositive by the parties receiving the communications. Publicly announcing a decision for literal interpretation would have other, perhaps far-reaching, consequences. But it is unquestionably within the scope of a project whose license is GPLv2 only to adopt a literalist interpretive posture of this kind.

In the absence of a relevant specific indication of consensus on license interpretation, we observe that parties making integrated GNU/Linux distributions have recently taken different approaches to the combination of the ZFS filesystem with the Linux kernel. The Debian project has chosen to place ZFS source code in a form equipped with the relevant translation layer for incorporation into the Linux kernel in its "contrib" hierarchy, but is not shipping kernel packages with ZFS integrated, allowing downstream users to make the combination conveniently for themselves. This is obviously prudent: whatever the kernel development community's preferred license interpretation posture, this arrangement is consistent with their views. If the kernel copyright holders prefer the literal meaning to the equity of the license, Debian need not recede from what it currently does. If the kernel licensors choose not to object to the making of such combinations, Debian has a clear path forward. Once again, the issue is not the binary executables of the kernel themselves, which are unquestionably licensed under GPLv2 and only GPLv2 as required, but whether the distribution as a whole, including the relevant source trees provided under GPLv2 section 3, meets the requirements of GPLv2 section 2(b) as interpreted by the intention of the licensor.

Canonical, in its Ubuntu distribution, has chosen to provide kernel and module binaries bundling ZFS with the kernel, while providing the source tree in full, with the relevant ZFS filesystem code in files licensed as required by CDDL.

If there exists a consensus among the licensing copyright holders to prefer the literal meaning to the equity of the license, the copyright holders can, at their discretion, object to the distribution of such combinations. They would be asserting not that the binary so compiled infringes their copyright, which it does not, but that their exclusive right to the copying and redistribution of their source code, on which their copyright is maximally strong, is infringed by the publication of a source tree which includes their code under GPLv2 and ZFS filesystem files under CDDL, when that source tree is offered to downstream users as the complete and corresponding source code for the GPL'd binary.

In response to such an objection, all distributors would no doubt cease distributing such combinations, which it would remain perfectly legal and appropriate for users to make for themselves. An objectively reasonable good-faith belief that the conduct falls within the equity of the license, until such time as the licensors state that they are interpreting the license literally, would be a full defense against claims of intentional infringement. A party swiftly adjusting its behavior in response to complaint is not an appropriate object of request for injunctive relief, as it is not threatening to create an irreparable injury and the equities do not require intervention, a point made by Judge Patti B. Saris in denying a preliminary injunction in the GPL-compliance action between MySQL AB and NuSphere in 2002. Because the Linux kernel program cannot be licensed for a fee under the terms of GPL, and the copyright holders do not sell copies of the kernel, there are no lost sales or lost royalty damages liabilities. Nominal statutory damages, divided among the thousands of copyright holders entitled to equal shares, scarcely lift the matter above the level of damnum absque injuria.

Clarity on the matter beyond the current state of affairs is certainly desirable. If the kernel copyright holders choose to clarify their interpretation publicly, certainty will immediately result. If they do not object privately or publicly to current behavior by other parties, the equity of the license will eventually come to be seen as the measuring rod, and relative certainty will also eventuate. Oracle can, by choosing to broaden the license terms on ZFS to include GPLv2, also provide certainty to all other distributors.⁷

Epilogue: Dtrace

ZFS is not the only CDDL-licensed code whose copyrights are owned by Oracle that parties find it useful to combine with the Linux kernel. The tracing and profiling utility Dtrace, also part of Solaris, is an attractive tool to use in conjunction with the kernel for debugging and performance analysis of running GNU/Linux systems. Dtrace, when used in this mode, requires recompilation of the kernel to produce an executable in which fragments of Dtrace code are spread throughout the kernel, as well as being combined with files that are wholly devoted to implementing Dtrace functionality.

With respect to Dtrace, the argument that the equity of the license gives permission under GPLv2 for such a combination is much weaker. The resulting combination is undoubtedly a "derived work" of the kernel as that term of art is used by the kernel licensors. Unlike a filesystem, Dtrace is not a separate an independent work when integrated with the software it is tracing.⁸

But the interpretation of GPLv2 with respect to Dtrace would be irrelevant if the copyright holder of Dtrace, Oracle, gave permission for Dtrace to be integrated with the kernel on GPL-compatible terms. This, by its own actions, it has done. As part of its Oracle Unbreakable Linux product, and the services it provides to Oracle customers, Oracle has itself made and distributed the combination of the Linux kernel and Dtrace. Those kernels were distributed to its customers under the terms of GPLv2, and Oracle is therefore estopped to deny others the permission to do what it has done. Oracle being the only copyright holder in Dtrace, it has the power to give permission for the combination to be made under terms compatible with GPLv2, and in the context in which it has acted it has, by its acting, done so. No question arises whether the kernel licensors have permitted, would permit, or should permit this combination: the required permission has already come, by way of estoppel, from the other side.