VADOSWARE Logo
3 fresh Startup/SaaS ideas in your inbox, every week
Launched 🚀🧑‍🚀
Waaard For Login Logo
Build your OAuth login flow in less than 60 seconds
Launched 🚀🧑‍🚀

The Future of Free and Open Source is AGPL

Categories
AGPL v3 logo

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.

UPDATE (2022/04/27)

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).

AGPL software is “Free Software”

“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.

Why AGPLv3 is the future of open source

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:

  • Creators/maintainers can create software that is free and open source, while leaving themselves the option of supporting the inevitable maintenance burden with alternate licensing schemes, a cloud offering, etc.
  • Users continue to get software at relatively low cost to them
  • Tinkerers are basically unfettered from advancing the projects and doing interesting things, also in practice AGPL violations are unlikely to be enforced against this group of people
  • Companies that contribute back will be able to enjoy a competitve advantage in exchange for their commitment of time and resources to a given project.

The only group that loses here are the companies that don’t intend to contribute their hacks and improvements back to the project.

Downsides to the adoption of AGPLv3?

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.

Corporations will likely reconsider their relationship with AGPL, because money

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.

What does the future look like?

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):

  • AGPLv3 profliferation will continue and accelerate over the next 5-10 years, and at some point the majority of ambitious new projects will be AGPL.
  • Companies will start adopting AGPL in their stacks “by hook or by crook” – they’ll either be paying for AGPL projects or enforcing careful consideration when making changes
  • More F/OSS software projects will capture the immense value they create, and this will lead to creating more stable better maintained software
    • A cottage industry will spring up to drive monetization of open source software
  • AGPL will make it’s way to libraries and absolutely revolutionize the relationship between large companies and F/OSS. This is the real big kahuna that will likely be a monumental shift
  • Some companies that can afford to build in house will shift inwards, but they’ll be build in house and we’ll see another test of closed vs. open source

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.

Like what you're reading? Get it in your inbox