Ubuntu may ship ZFS as a module… Or not?
Guest post by Dustin Kirkland of Ubuntu, the author of the announcement, explained Canonical's position, albeit light on details:
The CDDL cannot apply to the Linux kernel because zfs.ko is a self-contained file system module -- the kernel itself is quite obviously not a derivative work of this new file system. And zfs.ko, as a self-contained file system module, is clearly not a derivative work of the Linux kernel but rather quite obviously a derivative work of OpenZFS and OpenSolaris. Equivalent exceptions have existed for many years, for various other stand alone, self-contained, non-GPL kernel modules.
Software Freedom Conservancy (SFC), a non-profit with self-assigned mission of carrying on a crusade against GPL violations, quickly pointed out that the "obvious" conclusions of Canonical are not really all that obvious:
f ZFS were statically linked with Linux and shipped as a single work, few would argue it was not a "work based on the Program" under GPLv2. And, if we believe there is no legal difference when we change that linking from static to dynamic, we conclude easily that binary distribution of ZFS plus Linux - even with ZFS in a .ko file - constitutes distribution of a combined work.
Another non-profit organization - Software Freedom Law Center (SFLC) - provides yet another opinion on the matter. Eben Moglen points out that CDDL permits distribution of binaries under other licenses, so in case of Linux module GPL's requirements in case of binary module may be fullfilled by distributing it under GPL. Admittedly, this does not solve the issue of the license incompatibility of the code bases. The proposed solution is basically to ignore the wording of GPL's viral clause:
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.
The issue of GPL compatibility and kernel modules' licensing arised before. For example, Linus Torvalds already noted that kernel modules are in "gray area" when it comes to the issue of derived worked. Using an example of Andrew filesystem he stated that external code base that was designed on different system and only required minimal porting effort due to interface similarities, in his opinion, was not a derived work of Linux. Even more appropriate example is Nvidia's infamous proprietary Linux driver, which interfaces the kernel via specially-crafted module that abstracts away Linux kernel implementation details, so that Nvidia's binary blob may still considered to be a self-contained work targetting module's interface, not the interfaces of Linux. This driver is widely used and generally tolerated by distributions.
The differences in these two positions reveal the two conflicting opinions on Linux copyright situation. SFLC is more concerned about the ability of opensource ecosystem to survive in face of fanatic GPL enforcement: their statements goes into painful details about difficulties that projects with permissive licenses are facing when they need to maintain the ports of their code in GPLed projects. If stictly enforced, GPL could hinder such projects to the point when whole ecosystem comes to net loss. Such situation could be particularly painful in cases like this, when the goals of GPL are met, but the legal mechanism that was chosen by opensource Foundation prevents both Linux and OpenZFS from cross-polination.
But on the other hand, making such excuses would open gates for projects that don't really contribute to the opensource, but only use it to their own benefit. While proponents of permissive licenses (myself included) don't find anything wrong with such outcome, GPL was specifically designed to prevent it, and that is why it is one of the most popular opensource licenses out there. Obviously, every concession weakens the position of those seeking GPL enforcement, including SFC, whose mission right now is endangered by both SFLC's and Canonical's views on ZFS integration into Linux. Being a self-styled GPL crusader with several battles already fought, SFC knows that the ZFS inclusion in Ubuntu may come at a price of legal actions lost, and potentially tolanted hackers driven out of opensource by frustration and disappointment.
There is another interesting angle to this situation: by now it is common knowledge that Sun Microsystems specifically designed CDDL to be incompatible with GPL, so that ZFS, while being opensource, could not be included with Linux. Shipping ZFS with Ubuntu would defeat this tactics and potentially remove motivation for such unfortunate choice of license for companies like Sun or Oracle, to benefit of all involved sides.
And yet another thing to consider: some (most?) jurisdictions explicitly require sticking with literal meanings of laws and contracts. This means that even if SFLC's position is defendable in United States, it might be dismissed in other parts of the world, giving Linux copyright holders ability to sue Canonical over copyright infringement. Given that Oracle holds copyright in both Linux and OpenZFS, and that it already demonstrated willingness to take legal actions against opensource projects, Canonical might still be under significant risk.
At any rate, the outcome of this discussion, if any, have potential to settle a long-standing issue in opensource community, and to make legal implications of using GPL more transparent and clear.
Submitted by 
Submitted by 
Submitted by