The GNU Affero General Public License (AGPL) is a strong copyleft license, based on GPLv3, that adds one significant obligation: if you modify AGPL-licensed software and let users interact with it over a network — including running it as a SaaS backend — you must offer those users the modified source code, even though you never distributed a binary to them in the traditional sense. This closes what's often called the "SaaS loophole" in the regular GPL, where a company could modify GPL code, run it only on their own servers, and never trigger the GPL's source-disclosure requirement because they never distributed a copy of the software itself. For readers looking for a plain-English GNU license explained rundown, AGPL is the variant most worth understanding first, since its network clause changes the rules in a way that regularly catches teams off guard.
What problem was the AGPL specifically written to solve?
The GPL's copyleft obligations are triggered by distribution — if you never hand someone a copy of the software (as a download, an installer, a shipped device), the GPL's requirement to also give them the corresponding source code never activates. Software-as-a-service broke that model: a company could take a GPL-licensed database, modify it heavily, and offer it as a hosted product to millions of users without ever "distributing" a single copy under the GPL's definition, keeping all their modifications proprietary. The Free Software Foundation wrote the AGPL specifically to close this gap for network-hosted software, adding a clause that treats letting users interact with the software over a network as functionally equivalent to distribution for licensing purposes.
What does the AGPL actually require that plain GPLv3 doesn't?
The added obligation is in AGPL Section 13, which requires that if you run a modified version of the covered software on a server and let users interact with it remotely, you must provide those users a way to get the modified source code — typically a visible link or notice with source access. Every other core provision of the AGPL mirrors GPLv3: derivative works must remain under the AGPL, you can't add further restrictions, and patent grants and termination provisions carry over largely unchanged. In practice, the network clause is the entire reason companies treat AGPL dependencies with more caution than regular GPL ones — it's the difference between "we don't redistribute this binary, so we're fine" and "we run this over a network, so we're not."
Does using an unmodified AGPL project as a hosted service still trigger the obligation?
Yes — the trigger is running the covered code (modified or not) and letting users interact with it over a network, not modification specifically. Even an unmodified deployment of an AGPL database or application, offered as a hosted service to external users, requires making the source available under the AGPL, because the license's network clause applies to the software as covered, not just to changes made to it. This surprises teams who assume the risk only exists if they've patched the code themselves; running AGPL software as-is behind a paid API still means the source (as-is, since there's no modification to disclose beyond what's already public) needs to be made available per the license terms.
Why do companies treat AGPL dependencies more cautiously than MIT or Apache-licensed ones?
Because the obligation reaches deployment patterns — internal-only SaaS offerings — that a permissive license or even a standard copyleft license like the GPL would never touch. Many companies with a "no copyleft" or "no strong copyleft" open source policy specifically call out AGPL by name as a blocked license category for anything that touches a service they operate, distinct from GPL/LGPL policies that might only restrict distributed binaries. MongoDB's shift away from AGPL to its own Server Side Public License, and Elastic's parallel move to SSPL and later a dual-license model, were both driven by exactly this dynamic in reverse — vendors wanting AGPL-like protection against cloud providers repackaging their software as a competing hosted service.
How should engineering teams check for AGPL exposure in their dependency tree?
Direct dependencies are usually easy to spot in a license file or package manifest, but transitive dependencies are where AGPL exposure most often goes unnoticed — a small utility library pulled in three levels deep in a dependency graph can carry an AGPL license that nobody on the team reviewed, because nobody reviews every transitive package by hand. This is exactly the gap SCA tooling is built to close: scanning the full dependency tree, not just direct package.json or requirements.txt entries, and flagging copyleft licenses — AGPL specifically, given how differently companies treat it — before a build ships with an obligation nobody signed off on.
How Safeguard Helps
Safeguard's SCA engine identifies license types across the full dependency graph, including transitive dependencies, and flags AGPL and other strong copyleft licenses against configurable policy so legal and engineering teams see the exposure before a release ships, not after a customer or competitor points it out.
FAQ
Does the AGPL apply if I only use the software internally, with no external users?
If no outside users interact with the software over a network, the AGPL's network clause generally doesn't trigger, since there's no one to whom source access is owed — though internal tooling with any external-facing component should be reviewed carefully.
Is AGPL compatible with GPLv3?
Yes, code under GPLv3 and AGPL can generally be combined, though the combined work typically must be licensed under the AGPL to preserve its network-use obligations.
Can I use AGPL software in a proprietary product if I don't modify it?
The modification isn't the trigger — running the software (modified or not) and letting users interact with it over a network is what requires source availability under the AGPL.
Why did MongoDB and Elastic move away from AGPL?
Both companies wanted stronger protection than the AGPL provided against cloud vendors offering their software as a competing managed service, leading them to adopt custom licenses (SSPL) with broader source-disclosure triggers.
How does AGPL compare to other GNU license options like GPL and LGPL?
In short — the GNU license explained version: GPL's obligations trigger on distribution, LGPL relaxes those requirements for linking against a library, and AGPL extends the trigger to network use, making it the strictest of the three mainstream copyleft options for anyone running software as a service.