The AGPL: Solution in Search of a Problem

Share via Twitter Share via Facebook Share via Linkedin Share via Reddit

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.


  1. Stephen, there are two reasons to use the AGPL, one of which is a good reason, and one is a bad reason.  The AGPL was created because of the good reason but is more often used because of the bad one.

    The good reason is if you’re a low-budget end-user open source project and you have good reason to fear a large predatory company slurping your code and offering a heavily-marketed, closed-to-the-user online service based on it.  A good example of this is CiviCRM; if they were not AGPL, they would have a justified fear of BlackBaud offering an online service to compete with project supporters, and giving no code or money back, eventually starving the project.

    The bad reason is the many companies who want the PR of being open source without releasing any control of their software whatsoever.  Open source in name only, if you will.  A good example of this is MongoDB: they want the developer appeal of being open source, but thanks to the AGPL, development of MongoDB is and must remain 100% in the hands of 10gen, and nobody can offer services which compete with 10gen directly.

    Based on conversations, Bradley created the AGPL to support the first reason, without considering the second reason.

    1. Josh: I agree that there are cases like CiviCRM in which the AGPL seems like a plausible solution to an existing problem, but I would argue that over time the costs will outweigh the benefits. It seems possible, as an example, that CiviCRM would run afoul of the many organizations that outright ban AGPL projects. Nor are they likely to see much if anything in the way of contributions. 

      So while the license allows them to maintain an open source project in name, in practical terms I don’t see first category usage differing much from the second. 

    2. wait a second, what? AGPL code just means that if you modify the code, you have to release it even if it’s a private SASS for example, so I can still take mongodb, modify it and do what I want, I am merely forced to give the code back if I use it internally, stopping the google problem mentioned.

      but 100% in the hands of 10gen? since when? I can still do that and 10gen can’t do anything about it, but my mods will be open and 10gen’s will be too.

      so it’s about closing off modified versions hiding behind the SASS model, it has nothing to do with forcing everybody to deal with and only with 10gen, the normal GPL rules apply AFAIK.
      I’m 99% sure anyway…unless somebody can tell me otherwise.

  2. The OSL v3 is similar to the AGPL with it’s “External Deployment” clause closing the ASP loophole.

    According to Black Duck it’s about as popular as AGPL, though the only major project I know of that uses it is Magento. In that case it is a mechanism to push customers towards the paid-for Enterprise edition.

    I’ve always recommended that people stay away from licenses such as AGPL and OSL3. The downside in the majority of cases outweighs the upside.

  3. To judge the effectiveness, it’d be interesting to see a direct AGPL vs. Permissive example. So, status.net (AGPL) vs. ??? (Permissive) in microblogging. There’s AskBot (GPL) v. Shapado (AGPL) — that might be an interesting one to consider.

    As much as I love the “solution in search of a problem” frame (see http://www.theonion.com/articles/new-michael-landon-biography-resolves-many-unasked,8832/ ) I think the problem is pretty clear (as Josh mentioned): how does a small outfit get GPL-like don’t-crush-me assurances in the Web world?

    1. Jason: While it would be nice to see a more direct comparison as you propose, the data here seems pretty clear. In the five years since the introduction of the AGPLv3, Black Duck has seen just over 400 projects adopt the license. That’s around 7 per month. By that data – and I have no reason to suspect that it’s less than representative – says that the market has rejected the license and its proposition.

      Nor is it just that interest in that license has lagged; the popularity of the permissive licenses, the philosophical opposite of the AGPL, has exploded.

      As for the question as to what do small outfits do, my answer would be find a model that doesn’t require the AGPL. The costs will outweigh the benefits, IMO. If a project is considering the AGPL, it’s worth asking why it requires protections that > 99% of other projects do not.

  4. There are 413 AGPL projects and the number is growing. So what is the issue with this? What are the costs you associate? If organizations don’t like AGPL that is their choice and often (like with ownCloud) they will be willing to purchase a relicensed version!

  5. Stephen: There is one source file in the IcedTea codebase that is under AGPL, built and used solely as a tool in the build process.

  6. In my experience, the primary use of AGPL is to coerce a license payment (or support – same thing) by waiving the AGPL for money. Not exactly the principled rationale it started with.

  7. […] I was at Monktoberfest, our esteemed host reminded me that I’d disagreed with his article “AGPL: Solution In Search of a Problem”, and nudged me to elaborate on the point. Here goes nothing. TL;DR: for most developers, AGPL is […]

Leave a Reply

Your email address will not be published. Required fields are marked *