AGPL is usually about free riding, not fragmentation or adoption

Posted on by Luis Villa

When 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 really about preventing free riding, not fragmentation – so as long as there is concern about free riding people will use AGPL.

Stephen makes a few key points in his article (mistakes in paraphrasing mine):

  1. AGPL’s alleged benefit (the “problem that doesn’t exist”) is the prevention of fragmentation.
  2. Permissive licenses are on the rise, so using a super-strong copyleft is counter-productive when you’re looking to attract developers.
  3. By being so aggressive, it courts FUD about all open source licenses, which could be counter-productive to open source generally.

Let me take these in order.

Urban Fragments, by APM Alex, used under CC-BY 2.0

Issue #1 is based on a misapprehension: I don’t think it’s correct to think of the purpose of any copyleft (Affero or otherwise) as preventing fragmentation. GPL has never prevented fragmentation – there have been forks of many GPL projects (and complaints about same) for about as long as GPL has been around. (*cough*emacs*cough*)

Critically for many developers, what GPL does attempt to prevent is free riding – taking a benefit without contributing back. GPL means any valuable improvements in forks (whether or not incompatible) are available to integrate back under the same license terms. This means you can’t “cheat” the primary developers by building your business around proprietary forks of “their” work – they can always reincorporate the valuable bits if they want to.

The frequent use of AGPL in commercial dual-licenses also suggests that free riding is the problem being attacked by strong copylefts, not fragmentation. The logic is simple: AGPL means users usually pay some cost (i.e., not free ride) to participate: either by buying a commercial license, or by sharing code. In contrast, if the goal was to limit fragmentation, the license would say something like “your patches have to be accepted back into the core, or else you have to write a check”, or even better “you have to pass a compatibility test, or else you have to write a check.”

It is important to note that “cheat” is in quotes above. In many cases, people have realized that maintaining proprietary forks isn’t actually cheating the primary developers. For example, in many cases, we’ve realized that forking primarily cheats the forkers. For example, many users of the Linux kernel have learned the hard way that running an old fork + a small proprietary module leads to very high maintenance costs. In other cases, the permissive license actually helps fund the primary developers by enabling an open-core model (even if those aren’t trendy at the moment). In yet other cases, the primary author is making their money from other tools or services and so doesn’t care if anyone free-rides on their open source components. 37 Signals and Rails are probably the poster child for this. And of course, much of the industry has simply gotten more mature and less possessive about their software – realizing that whether or not they are “cheated” is usually a silly concern.

This leads to my response to issue #2: in my opinion, the recent increase in permissive licenses is driven as much by the decreasing concern about “cheating” developers (aka free riding) as it is by increased interest in adoption. In that light, the use case for AGPL is straightforward: AGPL makes sense if you’ve got a good reason to be concerned about free riding (say, if your revenue is directly tied to the tool you’re choosing a license for). This is a decreasing number of people, for the reasons described above, but it’s still far from zero. For those folks, increasing adoption may not actually be useful – it’s a case of “we lose money on every sale, but we’ll make it up on volume”.

On Issue #3 (increased FUD risk): this certainly seems like a possibility, but in my practice, I’ve seen only a single instance of confusion caused by AGPL spilling onto other licenses, and it was quick and easy to clear up. There is certainly plenty of worry about AGPL, but the worriers are quite clear that this stems from requirements other licenses don’t share. Maybe there will be more confusion if/when someone drafts another Affero-style license, but it doesn’t appear to me to currently be an issue. (By way of contrast, the confusion about the various patent clauses, and who licenses what to whom when, is a recurring theme of discussion with any company that is both filing patents and doing open source.)

Finally it’s important to note that both my post and Steve’s are about the costs, benefits, and freedoms accorded to developers. As I’ve mentioned before, when thinking about what “problem” is being solved by a license, it’s always important to remember that for some people (particularly the authors of the AGPL) the analysis begins and ends with problems for users. A full analysis of that issue has to wait for another day (it may be reminiscent of bike helmets) but suffice to say that neither of us are attempting it here, and we should always be cognizant of that.

Published by Luis Villa

16 thoughts on “AGPL is usually about free riding, not fragmentation or adoption”

  1. One driver of interest in more-permissive licenses is the change in programming languages used in the free software community. The GPL and LGPL are fairly well-understood for C programs, but if Python were licensed under the GPL, it would be substantially more confusing. The same is true for other non-C languages, which involve JITs or whole-program compilers etc.

  2. Sam: That’s an interesting point. Javascript is the canonical “languages that really don’t play with (L)GPL” example- in particular, the common delivery mechanisms (like minification) for javascript don’t play well with GPL’s notice requirements or LGPL’s dynamic linking requirements.

    That said, I don’t think python supports your point at all. I’m certainly not aware of any massive shift away from GPL in the Python community, and the data support my instincts: of the 1946 packages in “main” Fedora that require python, 1235 are licensed under some sort of GPL variant – about 63%. That is basically indistinguishable from the overall use of GPL in Fedora (14567/21656, or 67%).

  3. My point isn’t really about Python libraries, but about Python itself (which is released under an MIT-style license). If the Python runtime was under the GPL or the LGPL, what would the requirements for a closed-source Python application distributed to end-users be, esp. if modifications were made to the Python core? I think the answer here is genuinely unclear, and that’s a disincentive to use GPL-derived licenses in much of our core software.

  4. Oh, sure – but “language cores using a permissive license” isn’t a new trend, so it isn’t driving any of the larger-scale changes we’re seeing right now. It is very long-established (e.g., gcc has had a GPL exception for ages) and languages are a small and not-fast-growing niche. Or to put it another way: we’re seeing vast numbers of new projects using permissive licenses right now. New languages are a very, very small portion of those, because I can count the number of new languages in a given year on one hand.

  6. My hunch is that they are on the rise because (i) people don’t realize the importance of a patent grant and (ii) the unfortunate Apache-GPLv2 issue. I will definitely write more on the latter soon.

  7. Good post… of course, I think there’s another aspect that you kind of but didn’t fully touch on: there’s an increase in permissive licenses because of a shift also in what’s being released as free software. Nowadays it’s almost the norm to release libraries as free software, where the application is kept private as the “secret sauce” of the business. But we still don’t see enough applications being released as free software. I still suspect that if we saw enough applications released as free software, we’d see increasing copyleft usage in the web application space.

  8. Chris: I think it is hard to tease out cause-effect there. It is certainly true that fewer full apps are being released, and more frameworks/libraries. But it isn’t just that there are more releases; it is also the case that they’re not under LGPL, which was traditionally what you used when you were concerned about free-riding on libraries. Maybe this would change if there were an ALGPL/AMPL?

  10. […] AGPL is usually about free riding, not fragmentation or adoption Martin Michlmayr's OSI News Items – Wed, 2012-10-17 08:43 Categories: OSI News Picks Opensource.org site content is licensed under a Creative Commons Attribution 2.5 License. | Terms of Service […]

  11. I would consider OSL 3.0 an Affero-style license, and it’s an interesting one in that it seems designed for libraries or frameworks.
    I don’t know how much it is in use currently. Last year’s change of CodeIgniter PHP framework to OSL 3.0 has raisen a lot of confusion though, I’d say.

Comments are closed.