The GPL has a limitation that became obvious as web applications spread: its obligations apply when the software is distributed. But an application running on a server and used through a browser is not distributed to anyone. Whoever runs it can modify it at will, offer the service to thousands of people and never share the code. This is often called the "ASP loophole" or "SaaS loophole". The GNU Affero General Public License, in its version 3 published in 2007, was created to close it.
What the AGPL adds to the GPL
AGPLv3 is almost identical to GPLv3. The difference lies in section 13, which deals with remote network interaction. In essence it says: if you modify the program and your modified version lets users interact with it remotely through a network, you must offer those users the opportunity to receive the corresponding source code of your version.
Three elements deserve attention:
- A modification is required. Running the original, unmodified program brings no obligations beyond the GPL: the source is already available upstream.
- User interaction is what counts. The obligation concerns the people who use the service, not everyone in the world.
- The offer must be visible. It is usually done with a link in the interface, for example in the footer, pointing to a downloadable archive or a repository with the source of the running version.
A practical example
An association installs AGPL-licensed event management software and uses it for member registrations. As long as it uses it as is, it has nothing special to do. Then a volunteer adds a payments module and customises the confirmation emails. From that moment, members using the site interact with a modified version: the association must offer them the complete source of those changes, including the payments module.
Credentials, API keys and database contents are not part of the source code and must not be published. That is why it is good practice to keep configuration separate from code, for example in environment variables.
Why some projects choose the AGPL
- Software designed to run on servers: collaboration platforms, decentralised social networks, document management systems. With the classic GPL, copyleft would have no effect in their typical use.
- Protection against those who offer the project as a service without contributing: a cloud provider that modifies the software must share its improvements.
- Dual licensing models: some companies publish the code under the AGPL and sell a commercial license to those who do not want to accept network copyleft.
Why some companies avoid it
Many organisations have internal policies that forbid or limit AGPL components. The most common reasons are:
- fear that even a small change will force them to publish code they consider confidential;
- uncertainty about which components form a single work with the AGPL software;
- difficulty ensuring, at every release, that the published source exactly matches what is running.
These concerns are understandable, but they are often better handled with clear rules than with blanket bans.
How to handle it in an orderly way
If an organisation decides to use an AGPL component, a few practices reduce the risk of violations to almost zero:
- Keep a public fork of the component, where all changes are collected.
- Automate publication: the release pipeline publishes the source of the version going to production, with the same identifier.
- Put the source link in the interface, in a stable place.
- Isolate the component behind well-defined interfaces, such as network APIs, instead of merging it with proprietary code. If your own software talks to the AGPL service without being a derivative work of it, it stays outside the obligation; borderline cases, however, need careful assessment.
- Document the decision, naming who is responsible for compliance.
Quick comparison
| Situation | GPLv3 | AGPLv3 |
|---|---|---|
| Internal use without changes | no obligation | no obligation |
| Internal use with changes, no external users | no obligation | no obligation towards outsiders |
| Modified web service used by users | no obligation | offer the source to users |
| Distributing the program | source to recipients | source to recipients |
Compatibility
GPLv3 and AGPLv3 contain reciprocal clauses that allow code from each to be combined in a single work: each part keeps its own license, and the whole is also subject to the AGPL's network requirement. GPLv2 alone, on the other hand, is not compatible with AGPLv3.
In short
- AGPLv3 extends GPLv3's copyleft to software used over a network.
- The obligation arises when you modify the program and users interact remotely with the modified version.
- Users must be offered the source of the running version, not the data or credentials.
- A public fork and automatic publication at every release make compliance simple.
- GPLv3 and AGPLv3 can be combined; GPLv2 alone cannot be combined with the AGPL.
