The GNU Affero General Public License v3.0 (AGPL) is functionally the GPLv3 with one added clause: if you run a modified version of AGPL-licensed software on a server that users interact with over a network, you must offer them the modified source code — even if you never distribute a copy of the software itself. That single clause is the entire practical difference from GPL, and it's also the reason AGPL shows up on so many corporate "avoid this license" lists.
What problem does AGPL actually solve that GPL doesn't?
GPL's copyleft obligation triggers on distribution — if you modify GPL code and hand a copy to someone (ship a binary, sell a product), you owe them the modified source. But GPL was written before SaaS was the dominant software delivery model, and running modified GPL code as a web service without ever distributing a binary doesn't trigger that obligation at all — a company could take a GPL project, modify it heavily, and run it as a hosted service without ever sharing the changes back, because no "distribution" in the GPL's legal sense ever happened. This became known as the "SaaS loophole" or "ASP loophole," and it's specifically what the Free Software Foundation wrote AGPL to close: AGPL adds network interaction as a trigger equivalent to distribution.
When does the AGPL obligation actually kick in?
It kicks in when you run a modified version of AGPL software and let users interact with it over a network — the obligation is tied to network-accessible use of a modification, not to shipping a binary. Concretely:
- Running unmodified AGPL software as a backend service: generally does not trigger the source-sharing obligation, since you haven't modified it.
- Modifying AGPL software and running it internally, with no external network users interacting with it: a gray area many companies treat as safe, though "internal" boundaries can get legally fuzzy at large-org scale.
- Modifying AGPL software and offering it as a hosted product or service that external users interact with over a network: this is the clear case where you must offer the modified source to those users.
Why do so many companies have a blanket "no AGPL" policy?
Because the network-use trigger is broader and less familiar than GPL's distribution trigger, and legal teams tend to prefer bright-line rules over case-by-case interpretation, especially at scale. A company running dozens of services built partly on open-source components doesn't want engineers individually judging whether a given modification "counts" as triggering AGPL — it's operationally simpler to disallow AGPL dependencies outright than to audit every network-facing service for AGPL-licensed, modified components. This is a business risk-management decision more than a strict legal requirement in every case, but it's extremely common at companies past a certain size.
Does using an unmodified AGPL tool as infrastructure carry the same risk?
Generally lower risk, but not zero. Running an unmodified AGPL database or tool (MongoDB's older versions, for a well-known example, were AGPL before MongoDB moved to its own SSPL) as infrastructure without modifying its source code typically doesn't trigger the obligation, since you haven't created a "modified version." The risk profile changes materially if you patch it, fork it, or embed its code into your own application logic rather than using it as an arm's-length service — at that point you're in modified-version territory and the network clause applies.
How should a team actually manage this risk?
- Track license type at the dependency level, not just at the project level — a permissively licensed application can still pull in an AGPL transitive dependency without anyone noticing.
- Flag AGPL (and copyleft licenses generally) in CI so a new dependency with that license triggers a review step before merge, not after the code ships.
- Distinguish clearly between "using a tool" and "modifying and redistributing/hosting a tool" in your internal policy, since the risk profile differs meaningfully between the two.
Safeguard's SCA scanning flags license type alongside vulnerability data for every dependency, including transitive ones, specifically so an AGPL component doesn't reach production because nobody checked past the direct dependency list.
FAQ
Is AGPL considered open source?
Yes — AGPL is OSI-approved and meets the Open Source Definition; it's a copyleft license, not a proprietary one, and its restrictions are about triggering obligations on modification and network use, not about restricting the freedom to use, study, or modify the code.
Can you use AGPL software in a proprietary product without releasing your own code?
Only if you don't modify the AGPL component and don't combine it in a way that creates a derivative work under the license's terms — using it unmodified as an arm's-length service is the safer pattern; embedding or modifying it generally is not.
Does AGPL apply if the software only runs internally with no external users?
This is genuinely debated and depends on how "network interaction" gets interpreted for your specific setup — many companies treat purely internal tools as lower risk, but it's not a bright legal line, which is part of why legal teams often default to avoiding AGPL entirely rather than parsing the internal-use case.
Is GPLv3 also considered risky by the same companies that avoid AGPL?
Less so — GPLv3's distribution-based trigger is more familiar and predictable to most legal teams, so many companies that ban AGPL still permit GPL dependencies used at arm's length (e.g., calling a GPL command-line tool as a subprocess rather than linking its code).