The GNU AGPL v3 is the GPL v3 with one added obligation: if you run modified AGPL-licensed software so users interact with it over a network, you must offer those users the corresponding source code — even though you never distributed a copy. That single clause, section 13, is the entire reason the license exists. It closes what license authors call the SaaS loophole, and it is why AGPL v3 dependencies deserve deliberate attention in any codebase that ships as a hosted service.
If you have ever wondered why an open source component is flagged as high-risk by a license scanner despite being freely available, AGPL is often the answer. Here is what it actually requires and how to handle it.
The loophole AGPL closes
Standard copyleft licenses like the GPL trigger their source-sharing obligation on distribution — technically, on "conveying" the software to another party. If you never hand someone a copy, you never trigger the obligation.
Running software over a network is not conveying. So under GPL v3, a company could take GPL-licensed code, modify it heavily, and run those modifications as a web service for paying customers, and the modified source could remain effectively private because the software was accessed, never distributed. The users benefit from the improvements but never gain the right to the source that copyleft was meant to guarantee.
The Free Software Foundation viewed this as a gap that undermined copyleft in the era of hosted software. AGPL v3 was written to close it.
What section 13 actually requires
The operative text of AGPL v3 adds a requirement on top of everything GPL v3 already demands. If you modify the program and let users interact with it remotely through a computer network, you must give those users an opportunity to receive the corresponding source of your modified version, typically by offering it for download from the same running instance.
A few points people get wrong are worth stating plainly. The trigger is network interaction with a modified version, so running unmodified AGPL software as a service does not create a new source obligation beyond what the license already provides. The obligation runs to the users of that specific running instance, not to the whole world. And "corresponding source" means the complete source for the version actually running, including your modifications and the build scripts needed to produce it.
Everything else about AGPL v3 mirrors GPL v3: it is strong copyleft, so derivative works must also be AGPL, and it carries the same patent and anti-tivoization provisions.
Why this matters for your codebase
The practical risk is inadvertent obligation. A developer adds an AGPL v3 library as a dependency of your hosted product, modifies it or links it into your service, and now — by the strong-copyleft and section 13 terms — your service can be argued to fall under the AGPL's source-disclosure requirement. For a company that intended to keep its application proprietary, that is a serious surprise to discover late.
The reach of AGPL depends on what counts as a derivative work, which is a genuinely contested legal question, especially for dynamically linked or loosely coupled components. This post is not legal advice, and edge cases warrant a lawyer. But the engineering-side takeaway is simple: you need to know when AGPL v3 code enters your dependency tree, and that includes transitive dependencies you never chose directly.
Detecting AGPL v3 in your dependencies
You cannot manage a license risk you cannot see, and AGPL frequently arrives transitively — a direct dependency you vetted pulls in an AGPL package three levels down. Manual review of a package.json or pom.xml will not catch it.
License scanning as part of software composition analysis resolves the full dependency graph and reports the license of every component, direct and transitive. A tool such as Safeguard's SCA can flag an AGPL v3 component buried in the transitive tree and surface it before it ships, which is exactly the case manual review misses. The workflow that works is to define a license policy — which licenses are allowed, which require review, which are prohibited — and enforce it in CI so an AGPL dependency triggers a review gate rather than sailing through unnoticed.
Here is the shape of a policy decision most hosted-software teams land on:
Permissive (MIT, BSD, Apache-2.0): allowed
Weak copyleft (LGPL, MPL-2.0): allowed with review
Strong copyleft (GPL, AGPL): review required; AGPL flagged
for hosted services specifically
The point is not to ban AGPL reflexively — plenty of teams use AGPL software deliberately and comply happily. The point is to make the decision consciously instead of discovering the license during due diligence for an acquisition.
Using AGPL software the right way
If you decide to use an AGPL v3 component in a hosted service, compliance is entirely achievable. Offer the corresponding source of the running version to your users, typically via a clearly linked download from the application, keep that source current with whatever you deploy, and preserve the license and copyright notices. Many well-known projects ship under AGPL precisely because it keeps the hosted derivatives open, and using them is a normal, supported path.
The failure mode is not using AGPL software. It is using it without realizing the obligation exists, and then either violating the license or scrambling to comply after the fact.
FAQ
What is the difference between AGPL v3 and GPL v3?
AGPL v3 is GPL v3 plus section 13, the network use clause. GPL's source-disclosure obligation triggers only on distribution, so software offered over a network never triggers it. AGPL treats network interaction with a modified version as a trigger, requiring you to offer users the source of the running version.
Does using AGPL software force me to open source my entire application?
Potentially, if your application is a derivative work of the AGPL component and you run it as a network service. Whether loosely coupled or dynamically linked components create a derivative is legally contested, so consult a lawyer for edge cases. The safe practice is detecting AGPL dependencies and deciding consciously.
How do I find AGPL v3 dependencies in my project?
Use license scanning within software composition analysis, which resolves the full transitive dependency graph and reports each component's license. This catches AGPL packages buried several levels deep that manual review of your direct dependencies would miss, and lets you enforce a license policy in CI.
Is AGPL v3 safe to use in a commercial product?
Yes, if you comply. For a hosted service running a modified AGPL component, offer users the corresponding source of the running version and preserve license notices. Many commercial products use AGPL software successfully. The risk is using it unknowingly and failing the obligation, not using it deliberately.