In the early days of commercial open source, misinformation was a major impediment to adoption. Many enterprises, for example, explicitly forbade usage of code released under the GNU General Public License (GPL). When asked about the justification for this prohibition, the most common response centered around difficult-to-articulate concerns about being compelled to open source code they did not wish to. The fear that this “viral” license would infect their private repositories was rampant.
The truth, as became obvious following the mainstream adoption of GPL-licensed projects like Linux and MySQL, is that this was never the risk it was perceived to be. Simple usage of these technologies does not trigger the reciprocal provisions of the license, those that require modifications to be distributed under the same terms as the original source code, i.e. the GPL. More to the point, even if it was the case that applications built on top of Linux or MySQL were regarded as modifications, enterprises would not be subject to the terms of the license because of the so-called ASP loophole.
In short, the ASP loophole means that only those parties actually distributing their modified code would trigger the GPL. Google famously benefits from this; it is free to liberally modify the source to the Linux kernel, while being legally required to contribute nothing back, because it does not distribute Linux in the traditional sense. Those enterprises that did not ship technology products, in other words, had nothing to fear from the GPL.
Not so with the AGPL. The Affero General Public License was created to provide a version of the GPL with this loophole closed. Any modifications that are deployed in a network context need to be made available under the terms of the original license.
Advocates of the AGPL or similar licenses such as my colleague argue that the license reduces fragmentation by compelling public rather than private development of assets. In my view, the AGPL is a solution in search of a problem. Worse, it is a potentially dangerous solution.
To begin with, fragmentation is at best a theoretical risk for most projects. Consider popular permissively licensed projects like Hadoop, Subversion or the Apache web server. None enjoy protections from fragmentation, all can be privately modified, distributed and packaged and yet none have, at present, major issues with forks. And even if fragmentation was more common, distributed version control systems such as Git have turned forking from negative to positive [coverage].
Nor is there any evidence that open source contributions in general are a problem. If anything, the industry trend seems to be towards opening more software rather than less, because it more and more rarely confers a competitive advantage [coverage]. On an anecdotal basis [coverage] as well as a quantitative [coverage], software is provably less worth protecting than it was a decade ago.
According to Black Duck’s data, usage of the GPLv2 (the most popular version of that license, still) is down 15.3% since August of 2009 (50.1% to 34.8%). Over that same span, usage of the permissive Apache license has jumped from 3.9% to 11.15%; MIT from 3.8% to 11.56%. Even if one chooses to regard Black Duck as less than representative, it’s difficult to build the case that open source is becoming anything other than less protective over time.
In the face of the growing developer preference for permissive licenses, then, it would seem difficult to attract developers to a license even more restrictive than the GPL. And so it has been. Nearly five years after the release of the AGPLv3, Black Duck is currently tracking a total of 413 projects using the license. This places it 20th out of the top 20 licenses that Black Duck tracks, with a share of 0.15%. By comparison, the non-Affero GPLv3 – itself in decline – is at 13,960.
The most obvious downside to the AGPL – the fact that hostility towards it inhibits contributions to AGPL projects – is a marginal concern given the limited number of projects licensed under it.
But the developer indifference towards the license may be misplaced given its downstream implications. By redefining distribution to include network deployments, the AGPL has the potential to expose consumers of licensed projects to uncomfortable and unprecedented questions of license compliance. How many are aware, for example, that Iced Tea contains AGPL code? Having spent the better part of the last decade trying to make enterprises more comfortable with open source software rather than less, it would seem ill advised for advocates of open source to leverage a license with the potential to do the opposite.
Particularly when the evidence suggests that it is solving a problem that very few have.
