Tuesday, April 03, 2012

Localizing the GPL

swiss army knife

Update: read killing proprietary drivers for all OSes for a followup

We have a huge proliferation of FOSS licenses in the community. Each one should be considered as a tool with its own set of capabilities and purpose. The GPL is one of such licenses. I've written about the importance of the GPL before. As an outsider to authoring process of the GPLv3 I now dissect issues I see with the advances of the GPL, the community, and provide some recommendations as a community member. I've noted before how even  IBM, Red Hat, Novell and Intel did provide a draft edit recommendation of the GPLv3. The big software project to persuade to follow the GPLv3 route was Linux, the kernel, and likely the GPLv3 got so much attention due to the possibility of Linux moving over. Linux did not follow though -- but one must not forget the fact that the FSF helps spearhead advances in Copyleft and although the sort of stuff they do state may make a few people cringe, specially businesses who are currently banking on an archaic business models, take it for granted that they are innovating philosophically. Its our roles in the community to take such new suggested philosophies, see to it where we can apply the ideas, and help evolve the ideas and create dialogue.


Caveman

The GPLv2 is ancient, the Linux kernel is stuck on it, and I frankly do not see the whole project moving away from it any time soon, nor do I have hopes of it. We had the 2006 Kernel developers' position on GPLv3, signed by 10 kernel developers. While this position only represents the views of 10 developers, this statement is based on an old draft of the GPLv2. Times are changing too, and at least the section that deals with assignment of copyrights as a requirement is not really something that we need, this has been proven by SFLC's work on GPL enforcement through the copyrights of only a few developers. Some statements IMHO still do hold true though, particularly those that deal with not changing the freedoms the users of a project already had. But that doesn't mean copyright holders cannot decide at a later time to choose another license. In fact Linus did this himself when he decided for the first time to actually use the GPLv2.

Mount Budawang Cool Temperate Rainforest

A change in licensing of a FOSS project requires a compelling reason to not only address new philosophical ideas but also ensure the project's success and help the ecosystem. The  2006 Kernel developers' position on GPLv3 is trying to ensure that we don't bust the current investments made on the ecosystem, but doing a very poor job at addressing the philosophy. Its not an easy task to do though, after all the FSF deliberates with the community quite a bit before pushing out new licenses, and tackling the philosophy means being actively involved in the process of authorship of the new licenses. Lets not forget that the GPLv3 did have some corporate review as well. I wonder if the GPLv3 might look a bit different today if other new major current stakeholders like Google would be involved in working with the FSF on a new license. What would that look like?

Teslas cornering

As software philosophy evolves though so does software, software evolves faster. Linux in particular has evolved as the most rapidly evolving software project in the world, with impressive stats from Greg KH's kernel-development stats as follows:

3,160 developers 439 companies 12,300 lines added 8,800 lines removed 2,300 lines modified per day for all of 2011 5.77 changes per hour Kernel releases 2.6.37 – 3.2.0 January 2011 – January 2012

I value the philosophy behind the GPL3 and I wish we had a kernel using it and business models in place to embrace it. But we don't. Even if we wanted to relicense a GPLv2 project to GPLv3 is not trivial and this becomes increasingly difficult if the project is large with lots of contributors. The Linux kernel in particular has evolved to a type of project that accepts different types of GPLv2 compatible licenses on it. It also embraces a technique to allow contributors to ensure that their contribution are kept under the same license as the original file by the usage of the Singed-off-by tag on every single commit into the Linux kernel. What this has done is is allow for an ecosystem of GPLv2 compatible licensed files.

WTF

The Linux kernel is no longer a GPLv2 only project. The project as a whole is licensed under the GPLv2. Historically there has been a bit of confusion over what exactly can go into the Linux kernel, even among kernel maintainers. This became evident when Nick Kossifidis took OpenBSD's ar5k HAL, ported it to Linux, and we started working on getting a replacement for MadWifi upstream into the Linux kernel. At that time we were under the impression we needed to GPLv2 the content. Theo de Raadt correctly nagged at us that our kernel maintainers should allow GPLv2 compatible files. Rightly so -- this was possible but it required some work and we got the help of the SFLC to accomplish this. After we got ath5k upstream into the Linux kernel, ath9k followed suit, and it became the first completely permissively license driver in the Linux kernel. The goal and intent was simple: keep helping BSDs benefit from the work we made on Linux on the wireless front. I have helped spearhead a an effort to use permissive licenses in other areas of of Linux, even in userspace -- examples are CRDA, wireless-regdb, regsim -- a userspace regulatory simulator. I even relicensed the Linux kernel's regulatory core code to the ISC permissive license to help share more with the BSDs -- and this wasn't easy... it required getting ACKs from 24 of the contributors to it, took about 2 months and even had to address the contributions of two deceased developers to the Linux kernel... I hope it is clear that I've taken to heart the idea of sharing with the BSDs. Dot.

Tux & The BSD Daemon

Not to seem contradictory but I still value the GPL. In fact I remember quite a few times, maybe countless now, where some BSD developers have gotten worked up about how their code is used. If the GPLv2 is old, guess what, the BSD license is older. In terms of philosophy the only thing innovative about the permissive ISC license has is it has been made simple due to the Berne Convetion. The beauty about FOSS though is you have the freedom to work on the projects you want to though and you get then to express, use, and give freedoms to others in software the way you want to. I choose to help share as much as I can when it makes sense with the BSD family and even proprietary drivers (to kill them). I strongly believe it helps with the FOSS ecosystem as a whole.

Zelda
Areas where sharing makes no sense though I am a big proponent of considering new licensing techniques though. For example, and to make one last strong statement against why its hard to consider the GPLv3 for the Linux kernel, as an experiment I've started toying with the idea of relicensing the Linux kernel backporting project I work on to automatically backport the Linux kernel on to the GPLv3. The most difficult technical issue I found was that GPLv2 files that do not have clauses in the license of "GPLv2 or later" would be incompatible with the GPLv3 content. To address this issue on the Linux kernel would be seriously hard. Consider the relicensing effort I went through on just making the regulatory core of the Linux kernel to the ISC license. Imagine doing that for every non "GPLv2 or later" file. Technically when backporting though one makes copyrightable changes to software though in order to make new features / APIs work with older kernels. These changes are copyrightable but I should not be able to GPLv3 content that is GPL only (ie, not "GPLv2 or later"). I didn't even begin to analyze the redistribution implication differences of embracing the GPLv3, but the licensing incompatible differences alone proved sufficient to disregard this idea.

Lightsaber Sy

The strength of the GPL should by no means undermine fostering our ecosystem, and that is exactly what Linux kernel developers sought to avoid back when writing the  2006 Kernel developers' position on GPLv3. I'll take this a step further though and say that the GPL should be treated as one of our most precious tools in our licensing toolbox, but, the weight that it carries must be carefully considered in light of our FOSS ecosystem. Let me provide one clear example. The hostapd project is a successful project that both the BSD and Linux communities reap benefits from, its licensed under a permissive license. It would be detrimental to the community for us to GPLv2 the project at this point. We stand more to gain than to loose by licensing the project under the GPLv2. When we could leverage more support from working with the BSD family or if we want to start bridging other ecosystems and development efforts in them we should consider using a license that suits those needs best.
dumb caveman

Drivers development is not rocket science, even if people make it out to be as such. Drivers should be simple, but due to how hardware development works even if you get all the documentation to a specific piece of hardware chances are that if you try to write a driver based on it that it will not work correctly. Sure, one could ask for the errata to hardware as well, but that's not easy to make available for various reasons. Hardware tends to always have bugs and these bugs are typically addressed through new iterations of hardware, or addressed through software workarounds in software. It is our capacity in the community to address hardware issues really fast, our community's diversity, and through random sampling and reporting that I believe makes FOSS driver development critical for a successful driver to succeed in the long run. This is best explained by Tim Harford's God Complex, when something is so complex at times the best answer typically is not to assume perfect engineering, but instead expect mistakes and engineer around that. I think the community does a great job at addressing this type of engineering. When you understand this and learn to feed it properly, I believe you tend to see projects thrive.


Protect your jewels

Given that we stand more to gain by working with different communities together on driver development and that driver development is not rocket science, we should share more drivers in Linux with the BSD family and in fact we should see if its possible to even share with other OSes. We should use permissive licenses for new drivers, and only localize the GPL on places in the Linux kernel that we feel are our jewels. The GPLv2 does a great job at protecting our assets, but the extent to which it provides protection to all of our assets should be considered. Given that device drivers are not rocket science, to help share more with the BSD family, and other OSes (to kill proprietary drivers), and help foster a better ecosystem between userspace and kernelspace we should prioritize permissively licensing device drivers, and only localize the GPL to areas where we feel we are innovating and differentiating the operating system. An example of a technology that helps differentiate the Linux kernel from any Operating System is the Linux kernel's RCU Mechanism. IBM even has patents over this technology and by implementing this in software and contributing it to the Linux kernel they added software to the Linux kernel with software patents. The nice thing about this though is that IBM provided a sort-of form of an explicit patent grant on it through the Documentation/RCU/RTFP.txt section of the Linux kernel. In any case, the RCU mechanism is innovation and the documentation over it by its authors on the Linux kernel make it clear that proprietary Operating Systems cannot use this software, I guess unless you are willing to pay IBM for licensing these patents. The GPLv2 here was used strategically by IBM, to protect their own investment on Linux, to protect one of their jewels. Companies who invest in FOSS soon realize the value of the GPL, this typically only becomes evident once you are a major stakeholder in software. The days of using just once license for a whole piece of software are over, as software and collaborative development grows we should strategically consider the license and the areas of technology that such licenses are applied to to help foster our ecosystem.
Post a Comment