The AGPL-3.0 license — the GNU Affero General Public License v3.0 — is a strong copyleft license published by the Free Software Foundation in 2007 that is functionally identical to GPLv3 except for one added requirement: Section 13. That section closes what's known as the "SaaS loophole" in ordinary GPL, requiring that anyone who modifies AGPL-licensed software and lets users interact with it over a network must also offer those users the modified source code, even if the software itself was never distributed or sold. Of every type of license in open source, it's one of the strictest — a foss license in every legal sense, but one that most SaaS companies treat as high-risk rather than routine.
What is the AGPL license, exactly, and how is it different from GPLv3?
The AGPL license is the GNU Affero General Public License, and it starts from the same foundation as ordinary GPLv3 — strong copyleft, meaning any modified version you distribute must also be released under the same license, with source code available to recipients. The difference is entirely in Section 13, the "Remote Network Interaction" clause: under plain GPLv3, if you modify a program and run it only as a hosted service without ever distributing the binary or source to anyone, you have no obligation to share your modifications, because GPL's copyleft trigger is distribution, not use. AGPL removes that gap by defining network interaction as a trigger equivalent to distribution — if users can interact with your modified AGPL software remotely, you must offer them the corresponding source, whether or not a single copy of the software ever left your servers.
Why does the network-use clause matter so much for SaaS companies?
It matters because it directly targets the business model most modern software companies run on: hosting software as a service rather than shipping installable binaries. Before AGPL existed, a company could take a GPL-licensed database or application, modify it extensively, and offer it exclusively as a hosted product without ever triggering GPL's source-sharing requirement, since they never distributed a copy — this was a well-known and widely used strategy in the 2000s. MongoDB was originally licensed under AGPLv3 specifically to prevent cloud providers from doing exactly this: offering a hosted, modified version of MongoDB as a competing managed service without contributing improvements back. (MongoDB later moved to its own Server Side Public License, SSPL, in 2018, partly because even AGPL's obligations weren't seen as strong enough against large cloud providers.) Grafana Labs adopted AGPLv3 for Grafana itself in 2021 for a similar reason, aiming to ensure that hosted forks of its dashboarding software remain open.
Why do so many companies have a policy against using AGPL-licensed code?
Companies restrict AGPL primarily because the network-use trigger creates ambiguity about internal tooling that most other licenses don't. If an AGPL-licensed library ends up inside an internally hosted service that any external user or customer interacts with over a network — even indirectly, even as a small utility buried deep in a larger application — the question of whether that triggers Section 13's source-disclosure obligation for the entire combined work is a genuinely contested legal question that companies would rather avoid than litigate. Google's well-known internal open source policy bans AGPL-licensed code entirely for exactly this reason, and many other large tech companies have adopted similarly strict internal rules, treating "any AGPL dependency, anywhere in a network-facing service" as an automatic no rather than a case-by-case legal review.
How should you actually handle AGPL dependencies if you find one in your stack?
Treat any AGPL-licensed component the moment it's flagged as requiring a real legal review before it ships to production, not after. First, confirm the license is actually AGPL-3.0 and not a similarly named but different license — misidentification is common in automated scanning output. Second, determine whether your usage is purely internal-tooling with zero external network exposure (lower risk) or embedded in a customer-facing service (high risk, likely to trigger Section 13 if modified). Third, check whether an unmodified, vendored copy is sufficient for your use case — using AGPL software entirely unmodified as a standalone service you don't alter is generally lower-risk than modifying it, though legal review should still confirm this for your specific situation. If in doubt, look for a permissively licensed or dual-licensed alternative — an MIT or Apache2 license package covering the same functionality — before building further on top of an AGPL dependency.
How Safeguard Helps
Safeguard's license scanning flags AGPL-3.0 and other copyleft licenses automatically across your full dependency tree, including transitive dependencies that don't show up in a manual package.json or pom.xml read-through. Policy rules can gate a build the moment an AGPL component is introduced, so the question gets a legal review before it ships rather than after a customer's procurement team asks about it. See the SCA product page for how license and vulnerability scanning run together.
FAQ
What does AGPL stand for?
Affero General Public License — "Affero" comes from Affero Inc., the company that originally drafted the network-use clause this license is built around before it was adopted and formalized by the Free Software Foundation as AGPLv3.
Does AGPL apply if I only use the software internally with no external users?
Generally no — if there's no network interaction with anyone outside your organization, Section 13's trigger isn't met, but this is exactly the kind of boundary case where a real legal review matters, since "internal" tools sometimes have partner or customer access that isn't obvious at first glance.
Is "AGPLv3 license" the same thing as "AGPL-3.0"?
Yes, they're used interchangeably — AGPL-3.0, the AGPLv3 license, and "AGPL v3" all refer to the same 2007 Free Software Foundation text described above. (French-language resources sometimes search for this as "license logiciel AGPL," meaning software license.)
Is AGPL considered open source?
Yes — it's OSI-approved and meets the Open Source Definition. It's a copyleft license, not a source-available or proprietary one; the controversy around it is about business-model compatibility, not its open source status.
Can I use an unmodified AGPL library without triggering source disclosure obligations?
Using it unmodified generally doesn't trigger new disclosure obligations beyond what the license already requires for the unmodified source, but combining it into a larger work you distribute or host can still raise complex questions depending on how tightly integrated the combination is — this is a case where legal review, not a blog post, should have the final word.