Datamation content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Publicly, Canonical Software’s announcement that Ubuntu 16.04 will include the ZFS filesystem sounds like a potential violation of the second version of the GNU General Public License (GPLv2).
The fact that ZFS’s license, the Common Development and Distribution License (CDDL), is a free license but incompatible with the GPL makes the case unusual, but the problem routine.
However, the implications could prove extraordinary — in fact, they could indicate that, contrary to years of assumptions, the GPLv2 does not protect the Linux kernel at all. Many other projects could also be affected.
The Legal Opinion
Although the ZFS on Linux project has existed for several years, Canonical appears to be the first to obtain a legal opinion on the potential license incompatibility.
This opinion was obtained from Eben Moglen and Mishi Choudhary of the Freedom Software Law Center, the leading source of legal advice for free software.
Dustin Kirkland, a member of the Ubuntu Product and Strategy team, blogs that Canonical is “acting within the rights granted and in compliance with their terms of both of those licenses.” He goes on to state that CDDL covers files, and GPLv2 derivative work — code that modifies and extends earlier code released GPLv2.
He also maintains that 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.”
However, Moglen and Choudhary’s opinion appears to directly contradict Kirkland’s statements. For example, according to Moglen and Choudhary, code that is linked into the kernel “becomes part of one work with the kernel, and a potential conflict of license terms results.” In other words, it becomes a derivative work.
Moreover, since the CDDL allows relicensing such code and GPLv2 does not, Moglen and Choudhary find the two licenses incompatible.
So how can their legal opinion be used to justify going ahead with Canonical’s shipping plans? The reason is that Moglen and Choudhary go on to say that CDDL-licensed binary files can be legally shipped and stored with GPLed files. “In sum, therefore,” they conclude, “no developer and no user is deprived of any rights.”
In theory, all copyright holders could object to the use of the CDDL, who could object to the storing of CDDL and GPLv2 files together infringes on their “exclusive right to the copying and redistribution of their source code.”
However, a defense against such a claim would be a “reasonable good-faith belief that the conduct falls within the equity of the license.” Another problem in bringing a claim is that, because the Linux kernel cannot be licensed for a fee, no loss of sales or royalties is involved.
In other words, Canonical appears to be not so much acting within its rights, but calculating that nobody is likely to bring a case against them, or receive more than token damages if a case succeeds. So long as Canonical publicly asserts its belief in the compatibility of the licenses and minimizes discussion to avoid unintended disclosures, any consequences are unlikely, regardless of whether the licenses are incompatible or not.
The Problem of Multiple Copyrights
Canonical’s decision to ship is disturbing in any member of the community. Yet, Canonical’s apparent behavior seems almost trivial compared to the implications for the community at large.
The problem is not so much that a successful case against a license violation would be likely to result in only token damages. Probably, there are hundreds, if not thousands, who be willing to file such a case just on principle, to preserve the integrity of the kernel.
The trouble lies in how the Linux kernel and its developers are organized. Rather than a single copyright for the entire kernel, each contributor retains copyright in their own code. Over the last two decades, the kernel has had hundreds of contributors, at least some of whom are no longer programming or dead. As a result, organizing contributors to pursue a license violation would be tedious, time-consuming, and, quite possibly, impossible.
This same problem was part of the reason why Linus Torvalds resisted moving the kernel to the third version of the GPL a decade ago. Not only is the task of gathering consensus difficult, but most contributors are probably disinterested in legal matters, and only care about coding.
Moglen and Choudhary do not spell out the implications of their opinion. Yet, despite their dedication to free software, they are too honest not to give it. And unless I have missed something, what they are saying is that the Linux kernel — at least in some key situations — has no legal protection at all.
Quite simply, the kernel is unable to organize a defense of contributors’ collective rights. Anyone who denies any incompatibilities can apparently use the Linux kernel as they please.
Nor is the kernel the only vulnerable project. Any project whose contributors retain copyright or is careless about keeping track of contributors could be equally vulnerable if they use GPLv2, which despite the third version of the GPL, remains a popular license.
Whether other licenses are also vulnerable is uncertain without careful study. However, since the problem is not with the language of licenses, but their enforceability, the chances are that they are.
The implications need no spelling out out. Like the Maginot Line at the start of World War II, GPLv2 and other licenses may be a defense against some forms of attack, but useless against the most likely threat.
Avoidance Strategies
Some open source software may be immune. Assuming a willingness to pursue violations on principle, a small project with a complete record of copyright holders might still be able to mount a successful legal defense.
Better yet, a project that has transferred its affairs to non-profits like Software in the Public Interest (SPI) or the Software Freedom Conservancy. Among the services that such organizations offer is the management of member projects’ affairs, often with a transfer of copyright to them.
Some developers are suspicious about such centralized organizations. However, in the current situation, working with them may be the best response.
I would like to think that I am alarmist, and the situation is not as serious as I suspect. Still, at the very least, projects may want to watch developments in Canonical’s plans for ZFS — just to avoid unpleasant surprises.
