Saturday, February 27, 2016

I'm part of Conservancy's GPL Compliance Project for Linux

I am one of the Linux copyright holders who has signed an agreement for the Software Freedom Conservancy to enforce the GPL on my behalf, as part of the Conservancy's GPL Compliance Project For Linux Developers. I’m also a financial supporter of Conservancy. We're a group of Linux kernel developers that give input and guidance on Conservancy's strategy in dealing with compliance issues on the Linux kernel.


  1. I don't take this lightly
  2. "Don't be evil" is hard
  3. Why things are hairy when it comes to the Linux kernel and GPL enforcement
  4. Why we need GPL enforcement
  5. How can we enforce the GPL responsibly
  6. Evolving copyleft

I don't take this lightly


Joining was not something I took lightly, when I started hacking on Linux I was at ends with arguments over morality on free software put forward by the FSF and simply felt the GPLv2 on Linux was a nice coincidence; I felt I just wanted to hack and be productive. It took me over 10 years in philosophical thought to make a final decision about where I stand with regards to software freedom. I've made my motivation and intent in the community clear before, but its worth reiterating now: work harder always in spirit of what I believe is right, and accept no compromises on shit engineering.

"Don't be evil" is hard


I've been hacking on Linux since I was in college, after doing kernel development in the industry for a while I have learned the hard way that "Don't be evil" or "Do the right thing" is easier said than done for companies, specially with regards to software freedom. I've determined that without a mathematical and economics framework that takes into consideration and appreciates freedom it will take a lot of foresight, or for Free and Open Source software principles to be part of your company DNA in order for a company to appreciate the freedoms behind free software. To help companies embrace copyleft, within the community we really need to figure out how copyleft can affect and help businesses, the complexities it brings about, and work with both the community and companies on helping evolve both copyleft and businesses in amicable ways. Its easier said than done.

Why things are hairy when it comes to the Linux kernel and GPL enforcement





Consider answering these questions in today's business world when contributing to Linux.
  • Who owns the copyrights or patents to the software that Joe Hacker wrote prior to joining Yoyodyne, Inc?
  • Who owns the copyrights or patents to the software that Joe Hacker will write for Yoyodyne Inc?
  • What software projects can Joe Hacker contribute to while at Yoyodyne Inc?
There are four challenges that the above complexities bring about for businesses that affect their capacity to contribute to the Linux kernel and participate in GPL enforcement:

  1. How to replace proprietary solutions
  2. The Linux kernel is licensed under GPLv2 and as such only gets implicit patent grants
  3. These days companies have no option but to address patents considerations
  4. Addressing possible company conflict of interests

I've covered these issues before, what follows is a terse summary. Copyleft obviously is an imminent threat to proprietary software that relies on copylefted software such that the proprietary software is arguably subject to the conditions of the license that the copylefted software is distributed under. An implicit requirement however is that copyright holders of the copylefted software are both willing to and capable of seeking legal remedies against distributors of the proprietary software. In this light, if a business does not know how to phase out proprietary software it can be affected, short term, or long term. Patents can be implicated by some free software licenses. Paying for patent licensing also adds up. Patents can also be used to sue people. If you have signed conflict of interest agreement with business partners, things can get really hairy, and puts the industry at ends when it comes to free and open source software even if you're an "open source company". Since we lack the mathematical and economics framework to tangibly appreciate freedoms over patents and since patents can ultimately be endangered by certain free software licenses its only natural corporate interests will want to undermine certain free software licenses.




As businesses evolve, copyleft evolves. Patents were one of the latest additions to free software licenses, both through the GPLv3 and the Apache 2.0 license. I consider the Apache 2.0 license one of the best legal innovations in our arsenal in the free software world: if you want to really test what seems to be claim of only opposition to copyleft, ask if the Apache 2.0 license can be used instead. Now in the Linux kernel though we have an issue, since its GPLv2 and it only provides an implicit patent grant, and since we can't add GPLv3 or Apache 2.0 licensed material to the Linux kernel -- it still leaves the patent question open for businesses to address. To help with this, its why linux-firmware now also requires an explicit or implicit patent grant requirement. We need to close all the gaps that prevent copyleft evolution.  And sure, we can use permissive licenses on Linux, but that should only be used as a compromise -- not a de-facto practice. For instance getting ZFS relicensed to the ISC license might be a great compromise for all parties involved. Fully permissive licenses without patent provisions should be our last resort and compromise. Since patents are prevalent everywhere this means businesses have to deal with a lot of issues implicitly behind the scenes.

Case in point, as covered recently by lwn, at linux.conf.au 2016 Bradley talked about corporate opposition to copyleft. He explained how corporations will typically not do GPL enforcement in the name of the community, unless of course it fits your business model. He gave the example where Red Hat was sued by a patent troll, and in response Red Hat then alleged GPL infringement against Twin Peaks, with this Red Hat got a patent license but Twin Peaks software remained proprietary. Red Hat is an example that has Open Source software built-in to its business DNA, and even they seem to walk on eggshells when it comes to GPL enforcement. They are not to blame though, doing GPL enforcement for the community responsibly is hard, specially these days in such a complex, technology business sector, where anyone can be your partner and business contracts typically forbid you from engaging in actions that may harm any of your business partners.

Why we need GPL enforcement


Because of the challenges explained above even the best of Free and Open Source companies are walking on egg shells when it comes to GPL enforcement. By now you should have a sense of why some corporate interests may be trying to undermine copyleft licenses to effectively be as good as permissive licenses. We can't let that happen. Evidence shows the number of GPL violations has skyrocketed over the years to the extent that we cannot deal with them. There were only a few community groups dealing with GPL violations as well, this was outside of the Linux kernel, Linux kernel GPL violations remain common and unenforced. For this reason GPL enforcement is critical for the Linux kernel and community.

How can we enforce the GPL responsibly?


To address this Conservancy published a set of principles that should govern GPL enforcementthe primary objective is simply to bring about license compliance. We are not out for money, or blood, simply compliance to the license to strengthen the commons. We give input and guidance on Conservancy's strategy in dealing with compliance issues on the Linux kernel. Responsibly enforcing the GPL for the community, within the community with due care should be of utmost interest to any business contributing to Linux. If you're a Linux developer and would like to chime in and help us with these efforts you should consider joining the Conservancy's GPL Compliance Project For Linux Developers, please contact <linux-services@sfconservancy.org> for more details.


Evolving copyleft


On the post where I describe my epiphany which after over 10 years allowed me to finally cope with software freedom philosophy I explained how helping evolve copyleft is important, I'll provide a summary of that in light of the Linux kernel and its GPLv2 license. I believe some of the challenges described above are self inflicted as we were not able to move to GPLv3, given that we have all these patent considerations. I don't necessarily think we should move to GPLv3, but do consider the tensions that arose from those discussions really unfortunate. Lesson learned: we should consider evolving copyleft openly, in the community, with the community. If you'd like to help with that I invite you to take a look at copyleft-next, there is a github tree and mailing list. Copyleft-next is GPLv2 compatible.

Thursday, February 25, 2016

ZFS, Linux, illumos and the ISC license

People are discussing whether or not Canonical including and shipping ZFS as a Linux kernel module of the GPLv2 licensed Linux kernel might be a GPL violation or not. James Bottomley recently posted an interesting opinion in that although it is a technical GPL violation "it’s difficult to develop a theory of harm and thus the combination is allowable" given that you'd need to prove the harm is done to prosecute. Meanwhile just today Conservancy has released a Statement on ZFS and Linux combinations. In it are very important pieces of information on serious incompatibilities which takes this a bit further outside of the scope simply adhering to the GPL compliance standards to make people happy and not harm people. I'll review those but also explain a bit more of the history of why ZFS is under CDDLv1 and why Oracle no longer benefits ZFS being licensed under CDDLv1. We should be focusing more on the illumos community, the BSD community, what their goals are and thinking about what they can do and why they should do anything anyway. If we want a middle ground where we can all benefit, including the proprietary folks, we should all just lobby for the ISC license as a reasonable compromise for ZFS community. I'll explain why.

You can currently only use CDDLv1 for ZFS



CDDLv1 says that if you redistribute any binaries the software must be distributed only under the CDDLv1. There are a series of issues with this. The easiest to grok is that modules can be built-in, and that the kernel as whole is GPLv2. Canonical will ensure ZFS might live as a Linux kernel module only though it seems, however there are a series of serious issues with this as well. I won't list them all and I'll purposely be vague about it as I do not want to do anyone's dirty homework, but I'll at least describe one item that you can find discussed on archives today. We have only:

MODULE_LICENSE("Dual BSD/GPL")

We do not have:

MODULE_LICENSE("GPL-Compatible")

This is on purpose. I know because I actually proposed such a change years ago! I did this because at that time I was on the hippie bandwagon wanting to help Linux and the BSD camp sing kumbaya together on the 802.11 front. The "Dual BSD/GPL" thing was added for historical purposes to account for old BSD incompatibility, but for all intents and purposes all upstream Linux kernel modules currently using the dual declaration might as well just outright be declared as:

MODULE_LICENSE("GPL")

This hasn't been done and we keep the dual thing just to avoid confusion, but its perfectly possible to use the GPL declaration on even only permissively licensed Linux kernel modules. Another just utterly stupid issue with this incompatibility is you can't hack on ZFS unless you use the CDDLv1 license. As I'll describe below perhaps this might have been a good thing for Sun, but as things stand now even or Oracle -- this is not really a good thing.

When shipping binaries the GPLv2 applies


CDDLv1 prohibits you to abide by this. This is perhaps one of the more obscure incompatibilities, but I've tried to summarize it as best as possible with the above statement.

CDDLv1 was not purposely incompatible with GPLv2


CDDLv1 was not just the license of ZFS, it was the license chosen for OpenSolaris. Some ex-Sun employees have claimed that the CDDLv1 was purposely made incompatible with GPLv but according to Bryan M. Cantrill, one of the Sun employees who actually ended up staying even after Oracle acquired Sun, at USENIX Lisa XXV clarified this is not true. He clarified (starting at video 22:00) that part of the incompatibilities came from the fact that although they wanted copyleft they needed a form of copyleft that enabled proprietary drivers such as drivers for partners such as EMC and Veritas. This shows that even if you have great intentions and want to use copyleft, if you are have any proprietary strings attached, you'll be affected and can only produce GPL incompatible solutions.

Oracle does not benefit from CDDLv1 ZFS anymore



To understand this we'll have to review a bit of history. ZFS was just part of OpenSolaris. Let's consider the original motivation at Sun to be enable them to keep proprietary drivers, how this aligns to Sun's old business model and then review Oracle's current business model for "Solaris", and obviously what remains from the OpenSolaris effort and how this can impact in any way Oracle's business.

First credit where due. Bryan credits Jonathan Schwartz for making it a priority to open source the operating system, he mentions that OpenSolaris started in January of 2005 when DTrace became the first of the system to be open sourced, and that the rest of the OS was open sourced in June 2005. Sun was bought out by Oracle in 2009, the acquisition closed on February 2010. Ben stayed at Oracle until July 25, 2010.
On August 3, 2010 illumos was born, not as a fork but rather an entirely open downstream repository of OpenSolaris with all the proprietary pieces rewritten from scratch or ported from BSD. On Friday August 13, 2010 however an internal memo was circulated by the new Solaris leadership to say that they will no longer distribute source code for the entirety of the Solaris Operating System in real-time as it is developed. It seems this was never publicly announced, and that updates just stopped on August 18th, 2010. Solaris 11 was released on November 9, 2011 and there was no source code released to go with it.

That marked the end of OpenSolaris...

Oracle decided to keep Solaris proprietary then, and they were able to do this as OpenSolaris development required copyright assignment. Although OpenSolaris died, the illumos project continued to chug on, independent of Oracle, with a striking difference, copyright assignment was not required. This means Oracle does not own copyright on the illumos project and its new innovations. Oracle cannot use illumos versions of ZFS unless they also release their own Oracle Solaris under the copyleft CDDLv1. Oracle Solaris cannot reap benefit of the illumos version of ZFS, unless they open source their own source code again, and the reason is that the little pieces of GPLv2 incompatibility require them to use the CDDLv1.

illumos innovations can never be part of proprietary Oracle Solaris






illumos has seen critical innovations and bug fixes to ZFS, Dtrace, Zones and other core technologies. The real kernel architects behind ZFS have left Oracle, are not in favor or Oracle's idea to stop OpenSolaris, and have gone to great lengths to ensure that Oracle play by the archaic copyleft CDDLv1 license. Examples of a features added to illumos ZFS are SPA versioning that allows disjoint features from different vendors without requiring conflicting versions, UNMAP for STMF, allowing for better ZFS-backed ISCSI LUNs, getting estimates for ZFS send and receive. To top this all off, even if the Linux community made changes to ZFS to fix issues or add new innovations Oracle could not benefit from it. The BSD community would have contributed first to ZFS than the Linux community, but those contributions also could not be used by Oracle.

Why the ISC is a win for all



Are the old reasons for Sun to use CDDLv1, to enable proprietary drivers, still part of illumos' and the BSD community's own goals ? If not can someone confirm if the illumos or BSD community is forever stuck with the CDDLv1 ? If so would they be perfectly happy with that? Is the potential gain of contributing with the Linux community worthy enough for illumos to wish to want a relicense that would make things work for all parties involved ? What would it take for them to relicense? Does the illumos community really want Oracle to release Oracle Solaris under the CDDLv1 ? If Oracle wanted to upkeep the Oracle Solaris solution, help illumos collaborations on the Linux front, enable contributions on Linux to be usable even on proprietary Solaris solutions the ISC license would make a good middle ground for all parties involved. We did this with on the 802.11 front, it should easily apply as a reasonable compromise to ZFS as well, if parties really wanted a good middle ground.