![[RSS]](/static/img/feed-icon-14x14.png)
Conservancy Blog
Displaying posts by Bradley M. Kuhn and Karen M. Sandler
The Importance of Following Community-Oriented Principles in GPL Enforcement Work
by on July 19, 2016
UPDATE:2022-01-24: the Netfilter Core Team, one of the first groups to endorse our Principles of Community-Oriented GPL Enforcement have worked since that time to address concerns about McHardy's behavior discussed below. The Netfilter Core Team has now announced a settlement with Patrick McHardy (which follows a lawsuit they filed against McHardy in 2020 — that lawsuit was confidential until the settlement was announced (a practice that is common in Germany). The settlement requires all enforcement to be done in concert with a majority vote of the active Netfilter Core Team members, and also covers the exercise of contractual penalty provisions in contracts from past enforcement matters. The team also reiterated their continued endorsement of our Principles of Community-Oriented GPL Enforcement.
When we wrote the blog post below, we were the first organization to publicly criticize McHardy's use of enforcement in this manner, and we know many find this post when searching for information about McHardy's enforcement. We've left the remainder of the post as it original stood at its first posting for posterity. We now congratulate the Netfilter Team on standing by the Principles and effectuating legal mechanisms to ensure that they are followed for the benefit of software freedom. We look forward to coordinating with the Netfilter team in future enforcement that focuses on the right to software repair.
Our original post, as written on 2016-07-19, follows:
The GNU General Public License (GPL) was designed to grant clear permissions for sharing software and to defend that freedom for users. GPL'd code now appears in so many devices that it is fundamental to modern technology. While we believe that following the GPL's requirements is neither burdensome nor unreasonable, many fail to do so. GPL enforcement — the process to encourage those who fail to correct problems and join our open software development community — is difficult diplomacy.
Our community learned together over the last 20 years how to do this work well. Last year, Conservancy and the FSF published the concise but comprehensive Principles of Communited-Oriented GPL Enforcement. The Principles are endorsed by Conservancy, FSF and gpl-violations.org — the three historic community-oriented GPL enforcement organizations, as well as other non-enforcing organizations such as OSI. Recently, these principles were also endorsed by the Netfilter team, a core and essential group of Linux developers. However, despite our best efforts, we have been unable to convince all enforcers to endorse these Principles. Here, we express our concern and desire to ameliorate that situation as best we can. Furthermore, we also bring some transparency and context where enforcers seem unlikely to ever endorse the Principles.
One impetus in drafting the Principles was our discovery of ongoing enforcement efforts that did not fit with the GPL enforcement community traditions and norms established for the last two decades. Publishing the previously unwritten guidelines has quickly separated the wheat from the chaff. Specifically, we remain aware of multiple non-community-oriented GPL enforcement efforts, where none of those engaged in these efforts have endorsed our principles nor pledged to abide by them. These “GPL monetizers”, who trace their roots to nefarious business models that seek to catch users in minor violations in order to sell an alternative proprietary license, stand in stark contrast to the work that Conservancy, FSF and gpl-violations.org have done for years.
Most notably, a Linux developer named Patrick McHardy continues ongoing GPL enforcement actions but has not endorsed the community Principles. When Patrick began his efforts, Conservancy immediately reached out to him. After a promising initial discussion (even contemplating partnership and Patrick joining our coalition) in mid-2014, Patrick ceased answering our emails and text messages, and never cooperated with us. Conservancy has had no contact with Patrick nor his attorney since, other than a somewhat cryptic and off-topic response we received over a year ago. In the last two years, we've heard repeated rumors about Patrick's enforcement activity, as well as some reliable claims by GPL violators that Patrick failed to follow the Principles.
In one of the many attempts we made to contact Patrick, we urged him to join us in co-drafting the Principles, and then invited him to endorse them after their publication. Neither communication received a response. We informed him that we felt the need to make this public statement, and gave him almost three months to respond. He still has not responded.
Patrick's enforcement occurs primarily in Germany. We know well the difficulties of working transparently in that particular legal system, but both gpl-violations.org and Conservancy have done transparent enforcement in that jurisdiction and others. Yet, Patrick's actions are not transparent.
In private and semi-private communications, many have criticized Patrick for his enforcement actions. Patrick McHardy has also been suspended from work on the Netfilter core team. While the Netfilter team itself publicly endorsed these Principles of enforcement, Patrick has not. Conservancy agrees that Patrick's apparent refusal to endorse the Principles leaves suspicion and concern, since the Principles have been endorsed by so many other Linux copyright holders, including Conservancy.
Conservancy built a coalition of many copyright holders for Linux enforcement so that we as copyright holders in Linux could share with each other our analysis, strategy, plans and diplomacy. Much like Linux development itself, enforcement functions best when copyright holders collaborate as equals to achieve the desired result. In coding, Linux copyright holders seek to create together the best operating system kernel in history, and in an enforcement coalition like ours, we seek to achieve proper compliance in the best possible way for the community. (More collaboration is always better for various reasons, and we always urge copyright holders in Linux, Debian, Samba, and BusyBox to join our coalitions.)
Nevertheless, Conservancy does not object to individual copyright holders who wish to enforce alone; this is their legal prerogative, and with such limited resources for (and political opposition against) GPL enforcement on Linux, everyone who wants to help is welcome. However, Conservancy must denounce anyone who refuses to either endorse the Principles, or (at least) publicly explain why the Principles are not consistent with their efforts to advance software freedom.
There are few public facts on Patrick's enforcement actions, though there are many rumors. That his enforcement work exists is indisputable, but its true nature, intent, and practice remains somewhat veiled. The most common criticism that we hear from those who have been approached by Patrick is an accusation that he violates one specific Principle: prioritizing financial gain over compliance. Meanwhile, some who criticize Conservancy's enforcement efforts ironically believe we are “too nice” — because we don't seek to maximize financial gain, and therefore we ultimately fund some license compliance work with donations from the general public. Despite that criticism, and the simple fact that Conservancy's settlement funds from GPL enforcement usually fail to cover even the staffing costs associated with our enforcement efforts, we continue to abide by the Principle that compliance is paramount over monetary damages. While we sympathize with those who wish GPL enforcement would fund itself, we also see clear problems if an enforcer prioritizes financial gain over compliance — even if the overarching goal is more comprehensive enforcement in other areas.
Conservancy does all our enforcement specifically through a USA 501(c)(3) charity, precisely because that makes us transparently financially accountable. The IRS requires that our work benefit the general public and never bestow private inurement to anyone. Success in enforcement should never personally benefit one individual financially, and a charity structure for GPL enforcement ensures that never happens. Furthermore, the annual Form 990 filings of charities allows for public scrutiny of both enforcement revenue and expenditure1.
Conservancy, as a charity in the center of GPL enforcement, seeks to make enforcement transparent. We devised the Principles in part to clarify long-standing, community-accepted enforcement procedures in a formalized way, so that violators and GPL-compliant adopters alike can discern whether enforcement behavior is acceptable under community norms. We welcome public debate about any enforcement action's compliance with the Principles (i.e., its meta-compliance with the Principles). We encourage all those who enforce GPL to come forward to either endorse the Principles, or publicly propose updates or modifications to the Principles. (We've created the mailing list, principles-discuss, as a public place for that discussion.) We urge developers to state that they support enforcement undertaken in a principled manner, including litigating only as a necessary last resort and to never prioritize financial gain.
We chose the phrase “meta-compliance with the Principles” carefully. Applying the Principles themselves to compliance with those Principles seems apt to us. For example, we publicized the concerns about Patrick's enforcement only after two years of good-faith attempts to discuss the problems with him, and we waited for more than a year before publicizing the problem, and only after both ample warning to Patrick, and discussion and coordination with the Netfilter team. Just as we would with a GPL violator, we exhausted every path we could find before making this statement publicly.
Thus, we now call on Patrick to endorse the Principles or publicly engage in good faith with the community to discuss proper methods of enforcement. We further welcome anyone who does not currently abide by these Principles to join us anew in our coordinated community-oriented GPL enforcement work.
In conclusion, to contrast GPL enforcement with the much more common proprietary software litigation, violators should always have a simple and solid method to quickly resolve the rare legal action around the GPL: compliance. GPL enforcers should always seek compliance as the primary and paramount resolution to any enforcement matter. In this manner, where community-oriented enforcement exists and thrives, the risk for danger from lawsuits diminishes. Today's violators can then become tomorrow's contributors.
Finally, if you are in a situation where you are unsure what your obligations are under GPL, we urge you to read and study the Copyleft Guide to learn more about how to properly comply with GPL and other copyleft licenses.
1 Looking at Conservancy's Form 990s, you can see by examining Page 2 (Part III) (in FY 2011, see Page 25, Schedule O, for continuation) each year how much revenue Conservancy received from enforcement settlements, and how much Conservancy spends on license compliance activity. Most notably, Conservancy has not received a single dollar in GPL enforcement revenue since FY 2012.
Free Software Foundation Issues Statement in Support of Community's ZFS Concerns
by on April 11, 2016
FSF Confirms Conservancy's Analysis & Urges ZFS Copyright Holders to License Under GPL
In a statement today, the Free Software Foundation (FSF), the charity that publishes all versions of the GNU General Public License (GPL), issued a statement regarding GPL-incompatible licenses and their interactions with strong copyleft licenses. The statement, written by Richard M. Stallman, President of the FSF and author of all versions of the GPL, confirms various points that we made previously in our blog post on the matter in late February.
The FSF's statement covers various topics, but most importantly, it confirms that distribution of software created by combining GPL-incompatibly licensed copyrighted works with GPL'd works violates GPL, stating:
The only permissible way to make available a binary (non-source) work that includes GPL'd material is under the GPL. … Code under GPL-incompatible licenses cannot be added, neither in source nor binary form, without violating the GPL.
The FSF's statement also reiterates many important points that are central to Conservancy's work on GPL compliance, particularly as it relates to combined works, such as Linux modules, which are “dynamically linked”:
[I]f you distribute modules meant to be linked together by the user, you have made them into a combined work, and you must release the entire combined work under the GNU GPL.
Specifically regarding the ZFS matter, the FSF has joined Conservancy in calling on Oracle to also license their ZFS copyrights under GPL, so that combinations with Linux are permitted:
[T]he copyright holders of ZFS … can give permission to use it under the GNU GPL, version 2 or later, in addition to any other license. This would make it possible to combine that version with Linux without violating the license of Linux. This would be the ideal resolution and we urge the copyright holders of ZFS to do so.
The FSF does point out that as stewards of the GNU project, they look to organizations like Conservancy, with a direct relationship with substantial Linux copyright holders, to assure compliance with the GPL for Linux. The FSF lauded our efforts to enforce the GPL, concluding with:
[W]e enthusiastically encourage enforcement of the GPL on Linux in accord with the Principles of Community-Oriented GPL Enforcement, and we wish the enforcers success in bringing violators into compliance, thus maintaining the GPL's integrity so it can defend users' freedom.
Both of us, in addition to our work in our day jobs with Conservancy, also volunteer our time to help the FSF — Bradley has been an FSF volunteer (focused primarily on licensing issues) since 1997 and Karen since 2006. We have been grateful to have a fruitful collaborative relationship with the FSF, and we appreciate that both John Sullivan and Richard Stallman actively sought our direct feedback and input on the FSF's statement over the last month.
Conservancy has also engaged in many more formal collaborations with the FSF in the past two years. Most notably, Conservancy and FSF co-published the aforementioned Principles of Community-Oriented GPL Enforcement. Conservancy and the FSF also jointly manage the copyleft.org effort, which publishes the most comprehensive guide ever created on the use of and compliance with GPL and copyleft.
In the six weeks since publication of our blog post about the license compliance problems with Canonical, Ltd.'s inclusion of ZFS in Ubuntu, some have opined with statements that do not fit with the interpretations and analysis that the FSF has carefully created over the last 30 years regarding how copyleft works. We believe the FSF's statement definitively settles this issue, showing that the FSF position remains consistent. We're glad the FSF has clarified the confusion created by the many pundits who have published inaccurate licensing advice.
Conservancy, now joined by the FSF, continue to call on copyright holders of ZFS to end the licensing problems and simply grant permission under GPL for ZFS' inclusion in Linux. Without such permission, users who seek to combine Linux and ZFS live in a precarious situation without the necessary copyright permissions to exercise their software freedom. The easiest path to resolution is a responsible and community-friendly licensing action by ZFS's copyright holders. Oracle should lead the way, as the largest single copyright holder in the ZFS codebase, to either relicense ZFS, or, if they prefer, publish an updated CDDL that is compatible with the GPLv2 and GPLv3 (which would be another viable route to solve the same problem).
GPL Violations Related to Combining ZFS and Linux
by on February 25, 2016
This post discusses an atypical GPL violation. Unlike most GPL violations Conservancy faces, in this case, a third-party entity holds a magic wand that can instantly resolve the situation. Oracle is the primary copyright holder of ZFS, and, despite nearly eight years (going back to the days of Sun's control of the code) of the anti-license-proliferation community's urging, Oracle continues to license their code under their own, GPL-incompatible license. While this violation has many facets, and Oracle did not themselves violate GPL in this specific case, they hold the keys to this particular kingdom and they forbid the Linux community to enter. While there are complexities that we must address, in this context, Oracle could make everyone's life easier by waving their magic relicensing wand. Nevertheless, until they do, since GPL-incompatible licenses are the root of all GPL violations, combinations of GPL'd code with Oracle's GPL-incompatible code yield GPL violations, such as the ongoing violation by Canonical, Ltd.
The Basic Facts
Sun released the Z File System (ZFS) code under the Common Development and Distribution License, version 1 (CDDLv1) as part of OpenSolaris. Sun was ultimately acquired by Oracle. Community members, mostly acting non-commercially, have improved ZFS and adapted it to function with Linux, but unfortunately, CDDLv1 is incompatible with GPLv2, so distribution of binaries is not permitted (see below for details). Many community members have been frustrated for years that Oracle didn't simply relicense the code under a GPLv2-compatible license.
The situation escalated last week because Canonical, Ltd. announced their plans to commercially distribute, in Ubuntu 16.04, a binary distribution of ZFS as a Linux kernel module, which adapts ZFS natively for Linux. Conservancy contacted Canonical to inform them of their GPL violation, and Canonical encouraged us to speak publicly. We're glad to do so to clarify the differing views on this issue. As you'll read below, Conservancy disagrees with Canonical's decision, and Conservancy hopes to continue dialogue with Canonical regarding their violation. We do not give up on friendly resolution of a GPL violation easily and are glad Canonical seeks to transparently discuss both sides of this issue in public.
Summary of our Conclusion
We are sympathetic to Canonical's frustration in this desire to easily support more features for their users. However, as set out below, we have concluded that their distribution of zfs.ko violates the GPL. We have written this statement to answer, from the point of view of many key Linux copyright holders, the community questions that we've seen on this matter.
Specifically, we provide our detailed analysis of the incompatibility between CDDLv1 and GPLv2 — and its potential impact on the trajectory of free software development — below. However, our conclusion is simple: Conservancy and the Linux copyright holders in the GPL Compliance Project for Linux Developers believe that distribution of ZFS binaries is a GPL violation and infringes Linux's copyright. We are also concerned that it may infringe Oracle's copyrights in ZFS. As such, we again ask Oracle to respect community norms against license proliferation and simply relicense its copyrights in ZFS under a GPLv2-compatible license.
GPL Incompatibility
The license of Linux, the GNU General Public License, version 2 (GPLv2), is conceptually known as a strong copyleft license. A strong copyleft license extends software freedom policies as far as copyright law allows. As such, GPLv2 requires that, when combinations and/or derivatives are made under copyright law with GPLv2'd works, the license of the resulting combination and/or derivative is also GPLv2.
The Free Software Foundation (FSF) has long discussed the question of licenses incompatible with the GPL, pointing out that:
In order to combine two programs (or substantial parts of them) into a larger work, you need to have permission to use both programs in this way. If the two programs' licenses permit this, they are compatible. If there is no way to satisfy both licenses at once, they are incompatible.
License compatibility is not merely a question for Free Software licenses. We can analyze any two copyright licenses and consider whether they are compatible.
In the proprietary software world, rarely are two licenses ever compatible. You can't, by default, license a copy of Oracle's database, and then make a combination with Apple's iOS. To do so, you would need to negotiate (and pay for) a special license from both Apple and Oracle to make that combination.
Furthermore, with proprietary software, there is a practical problem somewhat unrelated to the legal permission: you must procure (again, likely for a rather expensive fee) a copy of the source code for Apple's and Oracle's proprietary software to have the practical ability to make the combination.
Since the GPL, and all copyleft licenses, are fundamentally copyright licenses, the analysis is similar. However, GPL requires that all software distributions include complete corresponding source code to any binaries, so the practical problem never presents itself. Nevertheless, when you wish to combine GPL'd software with some other software and distribute the resulting combination, both the copyright holders of the GPL'd software and the copyright holders of the other software must provide a license that allows distribution of the combination.
Most prefer to discuss the issue of combining truly proprietary, no-source-available copyrighted material with GPL'd software, as it creates the most stark practical contrast, and is the most offensive fact pattern. Proprietary software gives the users no freedom to even examine, let alone modify, rebuild, and reinstall the software. The proprietary license doesn't allow nor even give the practical ability to redistribute source code, and the GPL mandates source distribution when binary distribution occurs. The incompatibility is intuitively obvious. Few consider the fact that proprietary software licensing is just one (rather egregious) example of a GPL-incompatible license.
In that context, we can imagine licenses that are GPL-incompatible, but do give some interesting permissions to users. An example is source-code-available systems that prohibit commercial distribution and forbid modification to the source code. The GPL has terms that permit modification and allow commercial distribution of GPL'd software, and as such, even though source code is available for non-commercial, non-modifiable software, the license is nonetheless GPL-incompatible.
Finally, we can consider the most subtle class of GPL-incompatibility, in which we find ZFS's license, the Common Development and Distribution License, version 1 (CDDLv1). The CDDLv1 is considered both a Free Software and an Open Source license, and is a weak copyleft license. Nevertheless, neither CDDLv1 nor GPLv2 permits combination of copyrighted material under the other license.
To understand this non-intuitive incompatibility, we can analyze in detail the requirements of both licenses. First, GPLv2 requires:
[§2](b) You must cause any work that you distribute … that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole … under the terms of this License.…
[§]3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also…
a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above…
[§]6. …You may not impose any further restrictions on the recipients' exercise of the rights granted herein.
According to these provisions of GPLv2, if you create a binary work that incorporates components from the GPLv2'd program, you must provide the complete corresponding source for that entire work with the binary, and the terms of the GPLv2 apply to that source. If the sources as a whole cannot be outbound-licensed under GPLv2, you have no permission under copyright law to distribute the binary work, since GPLv2 didn't grant you that permission.
GPLv2-compatible licenses do not contradict the requirements of GPLv2, which is what makes them compatible. For example, highly permissive licenses like the ISC license allow imposition of additional licensing requirements (even proprietary ones), and so combining ISC-licensed source and GPLv2'd source into a binary work is permitted; compliance with GPLv2 is possible when distributing binaries based on the combined sources.
CDDLv1, however, contains various provisions that are incompatible with that outcome. Specifically, CDDLv1 requires (emphasis ours):
[§]3.1 … Any Covered Software that You distribute or otherwise make available in Executable form must also be made available in Source Code form and that Source Code form must be distributed only under the terms of this License. …
[§] 3.4 … You may not offer or impose any terms on any Covered Software in Source Code form that alters or restricts the applicable version of this License
CDDLv1 is a weak copyleft license in that it allows you create a binary work with components under different terms (see CDDLv1§3.6). However, as seen in the text above, with regard to the specific copyrighted material already under CDDLv1, that material must remain only licensed under the terms of the CDDLv1. Furthermore, when redistributing the source code, you cannot alter the terms of the license on that copyrighted material.
GPLv2, as shown above, requires that you alter those terms for the source
code — namely, as a strong copyleft, the terms of GPLv2 apply to the
entire complete corresponding source for any binary work. Furthermore,
downstream users need permission to make GPLv2'd modifications to that
source. This creates a contradiction; you cannot simultaneously satisfy
that obligation of GPLv2 and also avoid alter[ing]
the terms of
CDDLv1-licensed source. Thus, the licenses are incompatible, and
redistributing a binary work incorporating CDDLv1'd and GPLv2'd copyrighted
portions constitutes copyright infringement in both directions. (In
addition to this big incompatibility, there are also other smaller
incompatibilities throughout CDDLv1.)
We believe Sun was aware when drafting CDDLv1 of the incompatibilities; in fact, our research into its history indicates the GPLv2-incompatibility was Sun's design choice. At the time, Sun's apparent goal was to draw developers away from GNU and Linux development into Solaris. Not only did Sun not want code from GNU and Linux in Solaris, more importantly, Sun did not want technological advantages from Solaris' kernel to appear in Linux.
Much has changed in the seven and a half years since CDDLv1's publication and promulgation. OpenSolaris has been discontinued; CDDLv1 codebases never became an active area of Free Software development like GNU and Linux. Oracle could now easily indicate that combination of ZFS with Linux into binary works is permitted, (e.g., as the overwhelming majority copyright holder0, Oracle could make a decree like the one University of California did to fix a similar incompatibility). Until Oracle takes an action like that, it remains a license violation of both CDDLv1 and GPLv2 to distribute binary works that combine together and/or derive from both GPLv2 and CDDLv1 sources.
What Constitutes a Combined/Derivative Work?
Once license incompatibility is established, the remaining question is solely whether or not combining ZFS with Linux creates a combined and/or derivative work under copyright law (which then would, in turn, trigger the GPLv2 obligations on the ZFS code).
Conservancy has helped put similar questions (still pending) before a Court, in Hellwig's VMware case that Conservancy currently funds. In fact, the same questions come up with all sorts of GPL-incompatible Linux modules and reuses of Linux code.
Courts have not spoken specifically on this question; precedents that exist are not perfectly on-topic. Citing an opinion of a lawyer is often not helpful in this context, because lawyers advise clients, and argue zealously for their clients' views. When Courts are unclear on a matter, it generates disputes, and only Courts (or possibly new legislation) can ultimately resolve those disputes.
Nevertheless, our lawyers have analyzed these situations with the assistance of our license compliance and software forensics staff for many years, and we have yet to encounter a Linux module that — when distributed in binary form — did not, in our view, yield combined work with Linux. The FSF, stewards of the GPL, have stated many times over the past decades that they believe there is no legal distinction between dynamic and static linking of a C program and we agree. Accordingly, the analysis is quite obvious to us1: if 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, which we name Linux+ZFS.
Canonical has found some lawyers who disagree — a minority position, from our understanding of community norms. But Canonical's public position on the matter contributes to license uncertainty, and opponents of Free Software may use this as an opportunity to marginalize copyleft enforcement generally. Canonical can resolve the situation by ceasing the infringing distribution, but Oracle can also unilaterally resolve this trivially with a simple relicense of ZFS to a GPL-compatible license.
Thus, all parties currently stand at an impasse. Conservancy (as a Linux copyright holder ourselves), along with the members of our coalition in the GPL Compliance Project for Linux Developers, all agree that Canonical and others infringe Linux copyrights when they distribute zfs.ko. Canonical's lawyers disagree. Oracle refuses to relicense their ZFS copyrights under a GPL-compatible license.
Ultimately, various Courts in the world will have to rule on the more general question of Linux combinations. Conservancy is committed to working towards achieving clarity on these questions in the long term. That work began in earnest last year with the VMware lawsuit, and our work in this area will continue indefinitely, as resources permit. We must do so, because, too often, companies are complacent about compliance. While we and other community-driven organizations have historically avoided lawsuits at any cost in the past, the absence of litigation on these questions caused many companies to treat the GPL as a weaker copyleft than it actually is.
Why Conservancy Does Not Use Litigation Immediately
As discussed in our principles, Conservancy, while willing to litigate, uses litigation only as a last resort. Compliance actions are primarily education and assistance processes to aid those who are not following the license. We completely exhaust every other diplomatic option for compliance before seeking resolution from the Courts.
“Almost There” is More Painful Than Proprietary
Conservancy and our GPL Compliance Project for Linux Developers are quite sympathetic to the feeling of “almost there” that exists with ZFS for Linux. CDDL is a Free Software license, but sadly a GPL-incompatible one. Like a partial fix for a problematic bug, a GPL-incompatible Free Software license feels like a solution that's “oh-so-close”. Everyone wants to try to tweak that incomplete solution into a full one. We hope this explanation helps bring clarity that the seemingly “almost there” of combining CDDL'd and GPL'd code is a mirage. The community must seek together a better solution.
Oracle holds the better solution in their hands; like waving a magic wand, they can take any of a myriad of actions to communicate permission to relicense ZFS under GPL. Conservancy encourages Free Software enthusiasts and for-profit companies alike to lobby Oracle to relicense their ZFS copyrights. While this change by Oracle cannot resolve Canonical's violation, Oracle's relicensing would create a path for Canonical that might ultimately yield a compliant binary distribution of Linux+ZFS. As such, we've asked Canonical to commit to lobbying Oracle for this change.
Is The Analysis Different With Source-Only Distribution?
We cannot close discussion without considering one final unique aspect to this situation. CDDLv1 does allow for free redistribution of ZFS source code. We can also therefore consider the requirements when distributing Linux and ZFS in source code form only.
Pure distribution of source with no binaries is undeniably different. When distributing source code and no binaries, requirements in those sections of GPLv2 and CDDLv1 that cover modification and/or binary (or “Executable”, as CDDLv1 calls it) distribution do not activate. Therefore, the analysis is simpler, and we find no specific clause in either license that prohibits source-only redistribution of Linux and ZFS, even on the same distribution media.
Nevertheless, there may be arguments for contributory and/or indirect copyright infringement in many jurisdictions. We present no specific analysis ourselves on the efficacy of a contributory infringement claim regarding source-only distributions of ZFS and Linux. However, in our GPL litigation experience, we have noticed that judges are savvy at sniffing out attempts to circumvent legal requirements, and they are skeptical about attempts to exploit loopholes. Furthermore, we cannot predict Oracle's view — given its past willingness to enforce copyleft licenses, and Oracle's recent attempts to adjudicate the limits of copyright in Court. Downstream users should consider carefully before engaging in even source-only distribution.
We note
that Debian's
decision to place source-only ZFS in a relegated area of their archive
called contrib, is an innovative solution. Debian
fortunately had a long-standing policy that contrib was
specifically designed for source code that, while licensed under an
acceptable license
for Debian's
Free Software Guidelines, also has a default use that can cause
licensing problems for downstream Debian users. Therefore, Debian
communicates clearly to their users that this code is problematic by
keeping it out of their main archive. Furthermore, Debian
does not distribute any binary form of zfs.ko.
(Full disclosure: Conservancy has a services agreement with Debian in which Conservancy occasionally gives its opinions, in a non-legal capacity, to Debian on topics of Free Software licensing, and gave Debian advice on this matter under that agreement. Conservancy is not Debian's legal counsel.)
Do Not Rely On This Document As Legal Advice
You cannot and should not rely on this document as legal advice. Our lawyers, in conjunction with our GPL compliance and software forensics experts, have analyzed the Linux+ZFS that Canonical includes in their Ubuntu 16.04 prereleases. Conservancy has determined, with the advice of both inside and outside law firm legal counsel, that the binary distribution constitutes a derivative and/or combined work of ZFS and Linux together, and therefore violates the GPL, as explained above. We also know from Canonical's blog post that they have found other lawyers to give them contradictory advice. Such situations are common on groundbreaking legal issues, and, after all, copyleft is perhaps the most novel legal construction for copyright in its history. Lawyers and their clients who oppose copyleft will attempt to limit copyleft's scope (with litigation, FUD, and moxie), and those of us who use copyleft as a tool for software freedom will diametrically seek to uphold its scope to achieve the license drafter's and licensors' intended broad impact for software freedom.
Indeed, Conservancy believes this situation is one battle in a larger proxy war by those who seek to limit the scope of strong copyleft generally. Yet, the GPL not only benefits charitable community organizations like Conservancy, but also for-profit companies, since GPL ensures your competitors cannot circumvent the license and gain an unfair advantage. We therefore urge charities, trade associations and companies who care about Linux to stand with us in opposition of GPL violations like this one.
0 More work might be required to relicense all modern ZFS code, since others have contributed, but we expect that those contributors would gladly relicense in the same manner if Oracle does first.
1 More discussion on these issues can be found in this section of Copyleft and the GNU General Public License: A Comprehensive Tutorial and Guide, which is part of copyleft.org, a project co-sponsored by the FSF and Software Freedom Conservancy.
2015 YIR: Bradley and Karen Speak at FOSDEM 2015
by on December 16, 2015
[ This is a blog post is the third in our series, Conservancy 2015: Year in Review . ]
At the end of January 2015, Bradley and Karen came back from LCA and left almost immediately for FOSDEM 2015, where they co-organized the FOSDEM 2015 Legal & Policies Issues DevRoom with Tom Marble and Richard Fontana. Karen gave an amazing FOSDEM-wide keynote (in the giant room :) entitled Identity Crisis: Are we who we say we are?, and Bradley gave a talk in the DevRoom.
Sadly, it looks like the cameras were not functioning for Karen's keynote, but you can read her interview with the FOSDEM organizers about the talk. Fortunately, there is video for Bradley's talk, entitled Fork and Ignore: Fighting a GPL Violation By Coding Instead (The Story of Kallithea). The video of the talk is included here (and is also available on Youtube). The slides aren't clear on the video, but you can follow along with the slides on Bradley's website.)
Bradley's talk in particular tells a story of one of Conservancy's successes from the previous year, the launch of the Kallithea project. Just a few weeks ago, Conservancy launched its own Kallithea instance for Conservancy's public repositories.
Karen and Bradley are again co-organizers of the Legal & Policy DevRoom at FODEM 2016.
