AGPL is usually about free riding, not fragmentation or adoption
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):
- AGPL’s alleged benefit (the “problem that doesn’t exist”) is the prevention of fragmentation.
- Permissive licenses are on the rise, so using a super-strong copyleft is counter-productive when you’re looking to attract developers.
- 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.
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.