DDG search drop in powered by ddg.patdryburgh.com
tl;dr - AGPL aligns creators, maintainers, tinkerers, and users of software while leaving avenues for monetization. AGPL isn’t actually anti-hosting (IANAL) but is instead a forced improvement repatriation scheme. Nimbus Web Services will host AGPL software and contribute back – hyperscalers can too. Read the fundamentals of the AGPLv3 and Why the affero GPL.
After some discussion on HN I figured I'd highlight it here -- this post is meant to address software that can be re-hosted, or "self-hosted" software.
The AGPL has many consequences that may be entirely unwanted for library authors or those who value wide adoption of their software (which to be fair arguably provides the most good/utility, if you're into that kind of thing).
“Free software” and “Open source software” are terms that mean different things. Lots of software that is effectively shareware has been drafting on the good graces and radical roots of “free software” by branding themselves as openly as possible as “open source” and hoping others make the association.
I’m not one to judge of course, I benefit from open source projects (free or otherwise) all the time, and continue to selfishly use them without contributing back as much as I should!
In general, more open source projects is not a bad thing (the projects are open source), but the definition of “free software” is a distinct one and it shaped the ecosystem we have today. The idea of Copyleft is a radical one, and the proponents of free software did something that was completely unthinkable for their time, leading to an cambrian explosion of free and open source software.
Before we discuss how AGPLv3 works for Free or Open Source (“F/OSS”), let’s get our terminology right and be sure that AGPL software satisfies the “F” in F/OSS.
The Free Software Foundation has noted the widely reality of AGPL being widely misunderstood. They attempt to clear up misunderstandings:
The AGPLv3 was created to solve a very specific problem: how to protect a user’s rights when the program in question is being utilized over a network.
They also go into the history of the AGPL:
The AGPLv3 traces its origins to a company called Affero, Inc. Affero was established in 2001, and they provided a platform for interactive “Web applications” like discussion forums, mailing lists, email, and blogs. Affero wanted to be sure that users could access the source code for these applications, and that anyone who built derivatives from them would also share alike. The copyleft license of choice at the time was the GNU General Public License version two (GPLv2). However, the GPLv2 was written when the client/server paradigm was not widespread; it could not provide the copyleft assurance desired for Affero’s platform. That is to say, one could obtain Affero’s source code, modify it, and allow users access to the program over a network without the obligation of releasing its source code to the public. With this dilemma in mind and some help from the FSF, the Affero General Public License version one (AGPLv1) was published in March 2002 by Affero. In November of 2007, the AGPL joined the GNU family of licenses with version three, giving us a freedom-protecting copyleft license for an increasingly networked world.
BTW if you want to see what Affero was all about, check out the wayback machine in November 2019 for affero.org. The FSF goes on to state very clearly:
The AGPLv3 does not adjust or expand the definition of conveying. Instead, it includes an additional right that if the program is expressly designed to accept user requests and send responses over a network, the user is entitled to receive the source code of the version being used.
The AGPL is free software, because it does not restrict the users of software, but rather the hosters of software that users can interact with – requires them to make the source code of what is being transmitted to users available. f you run a tool with a GitHub repo, that’s as easy as pointing to the GitHub repository. Users maintain their freedom to study, change and distribute the software they use when the source is made available.
Right now AGPLv3 represents uncertainty (there is no precedent testing the bounds of the “virality” of AGPLv3) and thus unnecessary risk for companies. The fact that companies must contribute back changes to the original source code of hosted services represents a kiss of death to corporate approval.
There’s one caveat everyone is missing this is only a problem if you planned on modifying the software and not contributing back!. If you either do not modify the software or contribute back your changes you’re free to host and offer services built on AGPL.
Companies that use and contribute back to open source (as one should) need not fear the AGPL, they should be able to happily embrace it. In general the AGPL works for just about everyone in the equation:
The only group that loses here are the companies that don’t intend to contribute their hacks and improvements back to the project.
Of course, I’m a bit biased here – I think AGPLv3 is the future – but a widespread adoption of the AGPL is not without at least one downside.
F/OSS projects that adopt the AGPL are going to have to live with a dearth of sweet sweet VC/Large corporate funding for the critical early part of their lifetimes. While we talk a lot about companies not contributing to open source, there are some that use Apache2 and MIT licensed projects, and properly contribute back.
Companies who would have been drivers of adoption and helpful contributors (of bug reports, features, documentation, etc) may be warded off from ever contributing to projects. It’s hard to judge absence but we’ll likely see some projects that would have received corporate backing if they were Apache2/MIT wither on the vine due to their choice to adopt the AGPL.
As the cost of not allowing use/attempting to extract profit from of AGPL software grows, companies will start to re-evaluate their stance.
Some efforts (like my Nimbus Web Services project) intend to host AGPL software and contribute back any improvements. Careful reading of the AGPL provisions seems to indicate (IANAL) that it’s on the table, and companies who can leverage that interpretation as a competitive advantage will.
This is the internet, so I’ll wrap up by making some unreasonable conjecture about the future (that will be saved forever so I can be lambasted later):
This paints a rather rosy static picture for AGPL, but I’m a strong believer in “History doesn’t repeat but it rhymes”.
Monetization will break some projects (humans act differently when money is involved), and some areas will see a renaissance of non-AGPL F/OSS licenses (MIT/Apache2), but on the whole the creators/maintainers/BDFLs who can guide their projects through monetization will end up with far stronger projects than those that can’t.
Strong projects means strong ecosystems, and strong ecosystems mean better F/OSS for everyone. The future looks bright.
