Affero GPL is toxic – avoid it like the plague

Disclaimer (I): I currently work at Google. These are my own opinions and do not represent Google in any way. If you’re interested in Google’s position on AGPL you might want to check here: AGPL Policy –

Disclaimer (II): Even if I work at Google, I had this very same point of view way before joining the company.

Disclaimer (III): I am not a lawyer. This article is not legal advice.

Around 10 years ago I had a heated discussion about Affero’s licenses on FSFE Spanish mailing lists. Back then AGPLv3 was still not a thing, but the FSF did incorporate it shortly after. Lots of years have passed since and I still have the very same concerns, but glad that AGPL did not become very popular. Still, there are good products which do use it.

AGPL is like a regular GPL license with an extra requirement. As the FSF states:

if you run a modified program on a server and let other users communicate with it there, your server must also allow them to download the source code corresponding to the modified version running there.

The reason for adding this is that in a GPL license (and also nearly all copyleft licenses) does not require anyone to send source code as long as there’s no binary distribution of the application, and this can be exploited with the trend of Software as a Service (SaaS).

It goes like this: you just dowload someone’s else program, run it in a server, and resell it as a service; users pay to access it and they never have the software running in their computers. Or if they do have something running, is usually JavaScript, which is probably 5% of the whole application. And also minified, which difficults reverse engineering. (Back then we didn’t have WebAssembly, that could make matters worse)

So they wanted a license that would protect developers from this abuse. If you’re using their software as a service, they want the users of the service to be able to deploy the software as well if they like.

The problems with AGPL

So this looks good, the user can retain more rights and it should avoid the problem of becoming captive in a SaaS tool, right?

Well, no. The reality is quite different.

Ineffective against SaaS

AGPL does not stand a chance to do anything on the SaaS panorama. If you know anyone using any SaaS product, I can almost guarantee that they’re captive on the service in one or other way.

First and foremost, AGPL talks about source code but it doesn’t care about interoperability or users ability to dump their own data in an easy way. So, if even the SaaS product was AGPL compliant, they could remove or complicate the ways the user can export. By doing this, they ensure you have it really rough in order to move away from the provider. Yes, you can run the software in your premises if you know how to, but with no data, this is useless.

AGPL also cannot target ill-manned modifications of the source code that make the software almost impossible to install in a compatible/usable way, while making the tool totally incompatible with upstream. Good luck there.

AGPL is not used in almost any SaaS, probably not even GPL for big products. The reason is, SaaS is very profitable. Companies can afford making the product from scratch and will outpace quickly any open source alternative while still having huge margins.

See for example Plesk or cPanel. These apps that manage servers would be a perfect fit for AGPL, but the reality is not only they are a mess of custom privative code, it also turns out that there aren’t any good alternatives to these. The only alternatives are quite bare, and don’t stand a chance against the big players.

The reality is that there’s marginally any SaaS product that uses free software, just for making money of exploiting the loophole.

Those that might exploit it, if the software was AGPL, most probably would have chosen a different product or done one internally. For those that might still proceed, the changes might require other stuff that is on the server or the cluster architecture that is not part of the application, so our chances of benefiting from that would be near to zero.

To finalize, FSF says:

The GNU Affero GPL does not address the problem of Service as a Software Substitute (SaaSS).

But they don’t clearly give examples of the differences between SaaS and their own term SaaSS. Every software “computes” in their own machine, in this case, on the server. So, what is FSF understanding of SaaS? Regular, old websites? That wouldn’t even count as SaaS. To me, it looks they renamed SaaS to SaaSS, changing SaaS meaning to something that was never intended.

Regardless, this also clearly shows that FSF is aware that AGPL is useless for SaaS applications (proper ones, not regular websites).

If you still think that AGPL is useful against the SaaS problem, be aware that most of these offer also a commercial license as well, so we still can see SaaS services based on those software but the companies aren’t tied to the terms.

Difficult to comply

There are lots of concerns when deploying AGPL software. First, you should familiarize yourself on the mechanism on the software to share the sources with its users.

It might not exist at all; we could have products that comply with their AGPL licenses when distributed, but not when run as-is in a server. Just downloading and starting up the service as-is might not be enough to comply.

Some might require manual configuration before starting the service.

In others they might rely with an URL to the upstream download page. If this is the case, you cannot change the source code locally without making sure there’s something in place for your users to download your version of the code.

Some have specific terms saying you cannot remove/turn down/hide/change the built-in system to share your sources. If that system is unsuitable to you or has security concerns (being able to download data that it’s confidential) you’re out of luck.

Most software has a big codebase. This might be 50MB, 200MB, or even more sometimes. This could enable users to DoS your server by asking the sources repeatedly. Even if you manage to isolate this download from the software, so it’s not affected, then you are also not complying with AGPL, because you can have users that can’t download the software, as it’s down.

If it is a website, like PhpMyAdmin, WordPress or similar (these examples aren’t AGPL) you need to modify or add new files within the source code folder to add your custom configuration that includes encryption keys for cookies, user and password for database, and other sensitive stuff. Now, with AGPL you have to be careful making sure these don’t leak during a source code request. If they do, it would be a major security issue.

So, what is a user, again?

Before AGPL, we were just talking about the distribution recipients. This is clear: by distributing a software you also distribute rights to it. Network interaction is explicitly excluded here:

(…) To “convey” a work means any kind of propagation that enables other parties to make or receive copies. Mere interaction with a user through a computer network, with no transfer of a copy, is not conveying. (…)

GNU Affero General Public License, Chapter 0, Definitions.

But now we have a license that is distributing those right to “the users”:

(…), if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software. This Corresponding Source shall include the Corresponding Source for any work covered by version 3 of the GNU General Public License that is incorporated pursuant to the following paragraph.

GNU Affero General Public License, Chapter 13, Remote Network Interaction

It is unclear how far this “user interacting through network” can be stretched. For example:

  • News Website: A user accessing the website seems to fall under this clause.
  • Forum website for registered users only: Are the anonymous users also covered? i.e., even if we set up a forum for friends, are strangers also entitled to the source code?
  • Database behind a website: If the database is AGPL and users have access to a forum, there is a network chain: The user is producing interactions with the database. Are they entitled to the source code?
  • PhpMyAdmin or similar on top of a Database: If we hide the interaction of the database using an admin website on top, are the users entitled to the database source code?
  • If we add a webserver or reverse proxy: Can we argue that the user is in fact interacting with the first layer, and not with the application?
  • If we use an AGPL operating system: Since the TCP stack is in the OS, any user communicating through TCP is in fact interacting with it. Are they entitled to the OS source code?
  • Hitting login pages: So the app is locked by user and password, but users can hit the login part which is withing the source code of it. Just by hitting the login form, are they entitled?
  • Are pings and automated scrapes considered interaction?

I think I made my point clear. It’s hard to impossible to know to what extent this license could or could not be enforced. What makes logic sense or not, does not map to the tech bellow. It’s quite subjective, and not hard to find adversary examples that use the same logic to extend or nullify the claim.

It seems to me that these terms put the actual users who deploy the software into risk of being sued in creative ways. It’s very hard to comply properly and you never know if it’s okay. Even if it is okay with what the software author meant, there’s no guarantee that the author changes its mind and starts stretching the AGPL terms to claim the sources.

To me AGPL is not about freedom, is about making the people who got a copy of the program slaves of its terms, forcing them to setup tooling to auto-publish and putting them into the risk of leaking confidential information, as well of depriving them from having no competitive advantage for making any suitable profit from it. Basically what it says is that they should work for free (as in free beer) to deploy the sharing tooling, and give their work away also for free.

I don’t think this is fair, and also I don’t think this follows the original philosophy of free software. Since ever, I have been avoiding AGPL like the plague.

Actual uses of AGPL

So far I have seen AGPL for different kinds of purposes, this is subjective as I’m guessing intention.

  • AGPL Websites: The main purpose here is to get “forced contributions” for free. As you deploy the new version, your own design and customization are shared with the viewers, so the main authors usually expect to be able to “collect for free” in exchange of them giving away the software for free.
  • AGPL Databases and other non user-facing services: This is done to prevent/discourage monetization from third parties in a SaaS. Big modifications would end quickly into the competitor, so they can choose to contribute to the upstream directly and look good, or don’t change the product at all for their SaaS.
  • AGPL Software for internal company usage: This would include ERP, CRM and similar software. Here it implies that at least internal users would have access to the source code; which could leak confidential algorithms, so this encourages companies to buy the commercial license instead.
  • AGPL messaging software: Mainly used for avoiding incompatible forks that create a second network effectively privative. So far this is the best use case I’ve seen.


Just to finish this article I’ll say the obvious: I don’t like Affero-like licenses, never liked them and I’m concerned on deploying those on any servers even for private use (only me).

Carefully check the licenses of the software you deploy, because you might be breaking the terms just by installing it. Sadly, those licenses are usually FSF approved and OSI approved. Even Debian includes them as well.

TL;DR Affero-like licenses puts on the person/team/company deploying the software additional responsibilities that they might not expect or be aware of.