try another color:
try another fontsize: 60% 70% 80% 90%
Institut für Rechtsfragen der Freien und Open Source Software

License incompatibility and Linux Kernel modules – reloaded

by Florian Idelberger

The topic of license incompatibility, either between different free and open-source licenses or free and open-source licenses and proprietary licenses, especially in the context of Linux kernel modules has been a recurring topic, (not only) on This was for example a topic for this  ifross news about NVIDIA’s practices in making kernel modules with binary blobs work with the kernel, while trying not to fall under the copyleft clause of the GPL. These discussions continued, also among user as can be seen for example from the NVIDIA developer forums and in other cases.

Recently, there is more discussion again prompted by built-in support for ZFS for Linux ( in Ubuntu’s next release 16.04 LTS (as already present in testing versions) and the question whether this infringes upon usage and distribution rights of the Linux Kernel as published under the GPL v2 or those portions of ZFS for Linux originally written for Solaris and published under the CDDL (Common Development and Distribution License) as originally released by Sun Microsystems, now with copyright held by Oracle.

The relevant clauses of the GPL v2 which the Linux Kernel is licensed under are section 3 which requires “complete and corresponding source code” and that this source code is offered under the “terms of this license” GPL v2 Section2 (b) whereas the parts of ZFS on Linux implementation originally written for Solaris are only licensed under CDDL. The relevant clauses of the CDDL in the present issues specify, that while executables can be licensed under different licenses, with a literal reading of the license, source code has to be distributed under CDDL. In combination with a prohibition of additional terms and conditions these clauses are the source of discontent, even though both licenses are free and open-source licenses as recognized by the respective organizations that established these terms.

After it became public that Canonical would include a binary ZFS module with its Linux Kernel, social media discussions, mailing lists and blogs started whirring. More importantly, last Thursday the Software Freedom Conservancy (SFC) which is an organization that prescribes itself to advocating or even enforcing GPL compliance, also representing a number of Linux Kernel Developers and then one day later the Software Freedom Law Center (SF), a separate organization providing pro-bono legal services to developers of free and open-source software published their analyses [1] [2] and opinions about the events.

First, Bradley M. Kuhn and Karen M. Sandler from the Software Freedom Conservancy published their analysis last Thursday, finding that the combination of a Linux Kernel and ZFS on Linux creates a license incompatibility and infringes the GPL v2 license of the Linux Kernel. Their statement sees Canonical in an ‘ongoing violation’. SFC describe themselves as sympathetic to the frustration with the situation and urge friendly resolution, while at the same time acknowledging that there is no legal certainty. They then regarding the more substantial parts of their publication, establish license incompatibility based on the provisions mentioned above and a literal reading of the license texts, although acknowledging that both are free and open source licenses, GPL v2 with strong copyleft and the CDDL with weak copyleft. Thereafter, they get to the question of whether the integration of ZFS into the Linux Kernel with ZFS on Linux is a derivative work, which is really the crux of the matter, as only then the question of license incompatibility is important. In this part of their publication, SFC explicitly reference their involvement in other litigation such as funding the ongoing Hellwig vs VMware case, where they say this issue is also very important but at the same time they acknowledge that there is no certain precedent. Furthermore, they stress that in their years of work and careful analysis, the never saw a kernel module that was not a derivative work (Eds.: Though still didn’t try to establish this with precedent, as far is known) and that the FSF as ‘steward of the GPL’ states that it thinks that there is no difference between static or dynamic linking, as call and interfaces used stay the same.

Lastly, the SFC report argues that Canonical would contribute to 'license uncertainty' and reiterate that they see litigation only as a last resort.

The report by the Software Freedom Law Center (SF) followed one day later. Its conclusion and argumentation is quite different, also because it is sounds markedly less political or at least uses different political tactics.

Their report starts by discussing directly by discussing derivatives. They quote an old E-Mail from Linus Torvalds where he clarifies on the Kernel mailing list that there is no general exception from the GPL for proprietary binary kernel modules. He distinguishes grey areas and non-grey areas, saying that user space programs, because of an exception in the COPYING file of the Linux Kernel and common sense do not fall under the copyleft clause of the GPL, whereas Kernel patches clearly do. Modules he describes as a grey area.

SF uses that as basis for their analysis and support this view. First, they state the primary purpose of the GPL is to prevent proprietary extensions, and this is not an issue in the ZFS case. Especially as there is also a ZFS module for FUSE where the file system is only run in userspace, in such a case there would certainly be no issue, but there could be an issue in case code is statically or dynamically linked.

SF goes on that if compiled together, the binary of these results could then be licensed under the GPL v2 as the CDDL allows distribution of binaries under different licenses, so in so far there would be no infringement according to SF. Then they also go into the terms of the GPL v2 mentioned above, saying that with a literal interpretation section 3 and section 2 (b) this would be the ground to object to inclusion of CDDL code into the Kernel. Thereafter however, the SF gives further reasons not to object such as that 1) binary users have their rights fully protected under the GPL v2 2) no proprietary enhancement takes places that could be seen as an attempt at circumvention of copyleft 3) there are no issues of maintainability as the source code is accessible 4) files could be kept in the kernel source tree with CDDL licensing intact but as a GPL’d whole and 5) no developer or user is deprived of any right protected by GPL or CDDL. Concluding this part of the analysis, SF concludes that while the conduct is outside of the conduct permitted by a literal reading of the license, it is described as being 'within the spirit of the license' and equity (known as a correction of otherwise unjust results especially in Common Law jurisdictions) could come to the rescue. Putting this into ‘historical’ context, SF recall the case of Debian GNU/Solaris where the OpenSolaris C was to be linked with GNU tools, but Debian members decided to go for a literal interpretation, with Stallman and Moglen describing it as ‘close under literal interpretation’ but would have advised for spirit and equity of the GPL.

To conclude, SF summarize that there are different approaches, a separate source only distribution with less potential issues such as practiced so far by Ubuntu and often also used for proprietary or semi-proprietary video drivers (see above) and the ‘new’ approach of packaging binary modules directly. SF says that Kernel Developers or Oracle could clarify the situation but until then, good faith belief that this constitutes equitable use would be full defense and there would be almost no damages as there are no fees and no copies sold, so there could not be lost sales. They also refer to DTrace where they say that Oracle’s deep combination of DTrace (CDDL) and the Linux Kernel (GPL v2) and subsequent distribution estopped (in this case: no longer able to exercise copyright to prevent this, as it had performed this combination and distribution itself) it from preventing this combination, so something similar could be done here.

All in all, the statement by SFC is much more political with a focus on a literal interpretation of the two licenses, rallying Kernel developers and brandishing everything that is not GPL or can be subsumed under the GPL. The SF on the other hand has a much more considerate and adjudicating tone in its analysis, trying to highlight the similarities between the two licenses and trying to discern whether their intent is adhered to if there is a derivative work.

However, please keep in mind that a lot of this discussion has focused on US law, as this is the law that these two organizations are most familiar in and active with. An analysis in a different jurisdiction could very well turn out differently. Most of all, the scope of copyleft enforcement in Germany and Europe is still not very clear despite cases such as Fantec.