The AGPL licence is the strongest common copyleft licence because it does something the ordinary GPL does not: it triggers your obligation to share source code when users interact with your software over a network, not only when you distribute a copy of it. That single difference — the "network use" clause — is why the AGPL licence shows up on legal review checklists and why some companies ban it outright from their dependency lists. Understanding it is less about law and more about knowing which of your obligations quietly switch on.
The AGPL (formally the GNU Affero General Public License) exists to close what its authors saw as a loophole in the GPL. Under the GPL, if you modify open-source code but only run it on your own servers to provide a service, you never "distribute" the software, so you never have to share your changes. The AGPL removes that exemption for networked software.
What the AGPL actually requires
The core obligation is straightforward to state. If you run a modified version of AGPL-licensed software and let users interact with it remotely — over a network, typically a web application or API — you must offer those users access to the corresponding source code, including your modifications.
In practice that means:
- Source availability to your users. Anyone using your service over the network must be able to get the complete source, including your changes, under the AGPL.
- Same-licence propagation. Your modifications and combined work must themselves be licensed under the AGPL. This is the copyleft "share-alike" mechanism.
- No SaaS escape hatch. Running the software as a hosted service counts as the trigger. You cannot treat "we never shipped a binary" as a way to keep your changes private.
The obligation attaches to the modified work and its combination with the AGPL code. Merely using an unmodified AGPL tool as a standalone service is far less fraught than embedding AGPL-licensed code into your own product.
Where teams get caught out
Most AGPL surprises are not malice, they are inventory failures. A few recurring ones:
A transitive dependency is AGPL. You pulled in a permissively licensed package, which pulled in something else, which is AGPL. Your top-level license report looked clean; the risk was three hops down. This is the single most common way an agpl licence enters a codebase unnoticed, and it is exactly what automated license scanning is meant to catch.
"Internal only" becomes external. A tool used internally gets exposed through an API or a customer-facing feature. The network-use clause now applies where it did not before.
Combining AGPL code with proprietary code. If AGPL-licensed source becomes part of a larger work you offer over a network, the copyleft can extend to that combined work. Whether a given integration crosses the line is a genuinely fact-specific legal question — the boundary between "mere aggregation" and a combined work is not always obvious, and it is worth real counsel rather than a forum opinion.
AGPL is not "insecure," but it is a supply-chain fact
It is worth being precise: an AGPL licence does not make software less secure. Copyleft is about source availability, not code quality. The reason it lands in security and compliance conversations is that license risk is a species of supply-chain risk. The same discipline that tracks which vulnerable versions you depend on should track which licences you depend on, because both can appear transitively and both can create obligations you did not sign up for.
This is why software composition analysis tools report licences alongside vulnerabilities. Knowing that a deep dependency is AGPL is as operationally useful as knowing it has a known CVE. Our SCA product overview covers how that inventory is built, and tools such as Safeguard surface licence metadata on every package in the tree so an AGPL dependency does not slip through unreviewed.
Managing AGPL sensibly
Banning the AGPL outright is one option, and some organizations choose it for simplicity. But a blanket ban can cost you excellent software, and it is often unnecessary if you handle it deliberately:
- Maintain a licence policy that classifies AGPL clearly — allowed for internal tools you do not modify, reviewed for anything embedded in a product.
- Scan continuously, not once at launch. New dependencies and version bumps can introduce an AGPL package at any time.
- Segregate, do not embed. Running an AGPL tool as a separate, unmodified service behind a clean interface is far lower risk than compiling its source into your product.
- Get counsel for the grey zone. Whether a specific combination triggers copyleft is a legal determination. Engineers should flag it; lawyers should decide it.
Used knowingly, the AGPL is a legitimate and popular choice — plenty of well-run companies both consume and publish under it. The failures come from not knowing it is there.
FAQ
What is the difference between the GPL and the AGPL licence?
The GPL requires you to share source only when you distribute the software. The AGPL adds a network-use clause: if users interact with your modified version over a network, you must offer them the source too. That closes the "software as a service" gap the GPL leaves open.
Does using an AGPL tool make my whole product open source?
Not automatically. Running an unmodified AGPL tool as a standalone service is low risk. The obligation grows when you modify the software or combine its source into your own product offered over a network. Where the line falls in a specific integration is a legal question worth real counsel.
Why does my security scanner report AGPL dependencies?
Because licence obligations are a form of supply-chain risk that can appear transitively, just like vulnerabilities. A software composition analysis tool inventories the licence of every package in your tree so an AGPL dependency buried several levels deep gets reviewed rather than shipped unnoticed.
Is AGPL-licensed software less secure?
No. The AGPL governs source availability and copyleft, not code quality or security. It appears in security discussions only because managing licences is part of the same dependency-hygiene practice as managing known vulnerabilities.