The GNU Affero General Public License (AGPL) is a strong-copyleft license built on the GPL license, with one crucial addition: if users interact with a modified version of the software over a network, you must offer them the complete corresponding source code — even if you never distribute the software as a binary. This "network use" clause (Section 13 of AGPLv3, published in 2007) closes what free-software advocates call the "SaaS loophole" or "ASP loophole": the fact that ordinary GPL obligations are triggered only by distribution, which never happens when software runs purely as a hosted service. Projects like MongoDB (in its early days), Grafana, Nextcloud, and many self-hosted tools have used the AGPL license to ensure that cloud operators cannot benefit from the code without sharing their changes.
This article explains the AGPL in general terms. It is not legal advice — consult a qualified attorney for guidance on your specific situation.
What the AGPL Permits and Requires
The AGPL grants the same freedoms as the GPL and adds the network-use obligation on top.
| Category | Details |
|---|---|
| Permissions | Run for any purpose, study and modify, distribute, distribute modified versions, and use commercially |
| Conditions | Disclose complete corresponding source; license the whole derivative work under the AGPL (copyleft); preserve notices; state changes; provide source to remote users who interact with a modified version over a network |
| Limitations | No warranty; no liability; license terminates on violation, with a GPLv3-style cure period |
The distinguishing condition is that final one. Under the plain GPL, running modified software as a backend service that you never ship creates no source obligation. Under the AGPL, if remote users interact with your modified version over a network, you must give them access to the source — typically via a prominent offer in the running application.
Is the AGPL Copyleft or Permissive?
The AGPL is strong copyleft — the strongest in common use — because it extends the GPL's reciprocity into the one area the GPL leaves open: network-delivered software. Everything about the GPL's whole-work copyleft applies, and then the network clause removes the internal/SaaS escape hatch. If you modify AGPL code and let users reach it over a network, you owe them source.
This is why the AGPL is prized by developers who want genuinely reciprocal freedom for cloud-era software, and simultaneously why many enterprises are cautious about it. Some large companies, most famously Google, maintain internal policies that prohibit or heavily restrict using AGPL code, precisely because the network clause can reach services they would otherwise consider private. Our concepts library explores this tension, and our comparison pages place the AGPL against the GPL and the weaker copyleft licenses.
What the AGPL Means for Your Project and Compliance
The AGPL demands the most careful handling of any widely used open-source license, because its obligation can be triggered by activity the GPL would never touch: operating a web service.
The critical compliance question is do users interact with a modified version over a network? If you deploy unmodified AGPL software as a service, obligations are limited. But if you modify it and expose it to users over a network — which is common, since teams routinely patch and extend the tools they host — you must provide those users the complete corresponding source, including your modifications. Satisfying this usually means shipping an in-app "get the source" link and keeping a matching public repository.
The second consideration is the derivative-work boundary, which is as nuanced as it is under the GPL. Integrating AGPL code into your own service can pull your service's code into the AGPL-covered work, meaning your source must be offered to your users too. For a company building proprietary SaaS, that is often unacceptable, which is why AGPL frequently appears on corporate "do not use without legal review" lists.
None of this makes the AGPL bad — it is an excellent choice for keeping infrastructure software free. But it means an accidental AGPL dependency in a commercial SaaS product is one of the more serious license findings you can have. The academy shows how to define policies that catch it early.
How Safeguard Tracks AGPL License Compliance
Because the AGPL's obligation attaches to network use rather than distribution, an accidental AGPL dependency can create source-disclosure duties for a product you never thought of as "distributed" at all. Detecting it before deployment is the entire game.
Safeguard's Software Composition Analysis scans your full dependency tree and flags AGPL-licensed components wherever they appear, including transitive dependencies pulled in indirectly. Because AGPL is one of the highest-impact licenses to encounter unexpectedly, these findings are surfaced prominently in development and CI, before code reaches production.
SBOM Studio captures every component's license in a CycloneDX or SPDX software bill of materials, giving legal and engineering teams an auditable record of copyleft and network-copyleft exposure. Policy gates let you enforce a firm stance — for example, block AGPL in proprietary SaaS entirely, or require explicit legal sign-off — and evaluate every build automatically, so an AGPL component cannot silently ship inside a hosted service. Create a free account to check your dependencies for AGPL and other copyleft licenses, or read the documentation to set up a policy gate.
Frequently Asked Questions
How is the AGPL different from the GPL? The AGPL license is the GPL license plus a network-use clause. Under the standard GPL, copyleft obligations are triggered only when you distribute the software; running it as a hosted service does not count. The AGPL adds Section 13, which says that if users interact with a modified version over a network, you must offer them the source code. This closes the "SaaS loophole" that lets cloud operators use GPL code without sharing changes.
Do I have to release my source code if I only run AGPL software as a web service? If you run unmodified AGPL software, your obligations are limited. If you modify the software and users interact with your modified version over a network, you must provide those users the complete corresponding source, including your changes. The trigger is network interaction with a modified version, not distribution of a binary.
Why do some companies ban the AGPL? Because the network-use clause can reach software they operate as a service and would otherwise consider internal. For a company building proprietary SaaS, integrating AGPL code can create an obligation to share the source of that service with its users. To avoid this risk entirely, some organizations, including Google, restrict or prohibit AGPL code in their products.
Can I use AGPL software commercially at all? Yes. The AGPL permits commercial use and sale. The constraint is reciprocity: users, including remote network users of a modified version, must be able to obtain the corresponding source under the AGPL. Many companies use AGPL software successfully by either not modifying it, complying fully with the source offer, or purchasing a separate commercial license from the copyright holder where one is offered.