License guide · Copyleft
AGPL-3.0, in plain English: the network clause
AGPL-3.0 is strong copyleft plus a network clause — OSI-approved open source, and essentially GPL-3.0 with one crucial addition: Section 13, the network-use provision. That one clause is why AGPL is the license most commonly banned by corporate open-source policies: if remote users interact with a modified AGPL program over a network, you may owe them the source — even though you never shipped a binary.
Updated 27 Jul 2026 · by the depproof team
General information, not legal advice. The controlling text is the license itself, and several key questions here are genuinely debated — confirm any specific decision with counsel. Primary source: the GNU Affero General Public License v3.0.
AGPL is GPL-3.0, plus Section 13
Start from what you already know about copyleft: GPL-3.0 says if you distribute a covered program or a derivative of it, you must make the complete corresponding source available under the same license. The gap it left is that hosting software as a service was never “distribution” — you run a modified version on your servers, users hit it over the network, and no binary changes hands. That gap became known as the SaaS loophole.
AGPL-3.0 closes it. Its Section 13 adds one obligation on top of everything GPL-3.0 already requires: if you modify an AGPL-covered program and let users interact with it remotely over a network, you must offer those users the complete corresponding source of your modified version. Interaction over a network is treated much like distribution — so “we only host it, we never ship it” is no longer a way out.
What actually triggers the network clause
The obligation is not “using anything AGPL taints your whole company.” It is specific, and being precise about the trigger is what keeps this from turning into either false panic or false comfort:
- It attaches to the AGPL work and your derivatives of it. The duty rides on the AGPL-covered code plus the modifications and derivative works you make from it — not automatically on every unrelated module in your product.
- The trigger is remote users interacting over a network. Section 13 fires when outside users interact with your modified version of the AGPL program remotely. That is the scenario a SaaS creates.
- The output you owe is complete corresponding source. Users must be given the opportunity to receive the source of the version they are interacting with, under the AGPL — the same “corresponding source” standard as GPL, now reached without any distribution.
The honestly-debated part is the boundary: exactly which of your code counts as a derivative of the AGPL work, what qualifies as “modified,” and how “interact over a network” applies to a component buried behind your own front end. There is little settled case law here. That uncertainty — not a clear rule that AGPL swallows proprietary code — is what makes legal teams cautious, and it is precisely why this is a “ask counsel, scope it deliberately” decision rather than a checkbox.
Deeper dive: for the SaaS decision specifically — when a hosted product actually triggers disclosure, and how teams reason about the derivative-work boundary — read Is AGPL safe for commercial and SaaS use?
Can we ship or host it? The obligations at a glance
Framed as the “can we do this?” decision a compliance or engineering team actually faces:
| Can you… | Under AGPL-3.0? |
|---|---|
| Use it internally with no external/remote users | Generally yes — Section 13’s trigger isn’t met |
| Run it unmodified as part of your service | Generally yes, but confirm scope — no modifications keeps you clear of the modified-version trigger |
| Build a proprietary SaaS on top of / modifying an AGPL component and keep your source private | No — Section 13 requires offering corresponding source to your remote users |
| Distribute a derivative binary without source | No — standard GPL-style copyleft applies to distribution too |
| Keep it in a public network service with private modifications | No — the network clause is exactly this case |
| Sell a commercial service based on it | Yes — but you must offer the corresponding source to your users |
So AGPL is not “un-shippable.” You can host it, build on it, and charge for the service — the price is transparency: your remote users get to see the source of the AGPL-derived version they’re using. The problem teams hit is almost never deciding to pay that price. It’s not knowing an AGPL dependency was there at all.
How AGPL compares to the rest of the copyleft family
AGPL only makes sense next to its neighbors. The single distinguishing feature is that network clause:
- GPL-3.0 — same strong copyleft on distribution, but no network clause. Hosting a modified version as a service does not, by itself, trigger source disclosure. This is the exact gap AGPL was written to close.
- LGPL-3.0 — the weaker copyleft option: you can link it into proprietary software with far lighter obligations, the opposite end of the spectrum from AGPL.
- Elastic License 2.0 — the other answer to the same hosting problem, and the one that gives up the open-source label to solve it.
- Copyleft, explained — the parent concept behind all three, and how “weak” vs “strong” vs “network” copyleft differ.
Where AGPL trips up dependency and license policy
This is the reason AGPL earns a dedicated detection rule in almost every serious policy. A single transitive AGPL dependency — pulled in three levels deep by something you did choose — can put an entire network service in scope of Section 13, or fail a policy scan outright. Because it arrives transitively and looks like any other package in a lockfile, it is the license most likely to be present without anyone having decided to accept its terms.
The practical move is to detect AGPL (and other strong-copyleft licenses) explicitly across your full transitive tree, so the “can we ship or host this?” decision happens on purpose — not during due diligence.
- Check your Maven dependency licenses — surface AGPL and other copyleft licenses across the full transitive tree, without a build.
- Check your npm dependency licenses — find AGPL in your Node/JavaScript dependencies.
- Find every AGPL dependency across all your repos — org-wide license posture for legal and compliance, so no AGPL component hides in a single service.
Frequently asked questions
Is AGPL-3.0 open source?
Yes. The GNU Affero General Public License v3.0 (AGPL-3.0) is an OSI-approved open-source license and a Free Software Foundation license. It is strong copyleft — essentially GPL-3.0 with one addition, Section 13, the network-use provision. So AGPL is fully open source; the reason it has a strong reputation is not its open-source status but the extra obligation that clause creates for software offered over a network.
What is the AGPL network clause (Section 13)?
Section 13 is the difference between AGPL-3.0 and GPL-3.0. It says that if you modify an AGPL-covered program and let users interact with your modified version remotely over a network, you must give those users an opportunity to receive the complete corresponding source of your version — even though you never handed anyone a binary. It closes the so-called “SaaS loophole” in ordinary GPL, where running modified software as a hosted service was not considered “distribution” and therefore triggered no source-sharing duty.
Does AGPL force me to open-source my whole SaaS?
This is where careful reading matters. The obligation attaches to the AGPL work and to your modifications and derivatives of it, and it is triggered by remote users interacting with that modified work over a network — not automatically to every unrelated line of your product. In practice the fear that drives corporate bans is a transitive AGPL component becoming entangled with proprietary code such that the “complete corresponding source” you must offer sweeps in code you meant to keep private. Where the boundary of a derivative work sits, and what counts as “modified” or “interact over a network,” has genuine legal debate and little case law. Treat it as a real risk to scope with counsel, not a settled rule.
Why do so many companies ban AGPL?
Because the network clause creates a plausible path from “we used an open-source library” to “we may owe our users the source of our service,” and large organizations would rather avoid that ambiguity entirely than litigate its edges. Google’s open-source policy famously bans AGPL outright, and many corporate policies follow suit. The ban is usually about risk tolerance and the difficulty of proving a proprietary codebase was never entangled with an AGPL dependency — not a claim that AGPL is unsafe or not open source.
Can I use AGPL software internally without triggering it?
Generally yes. If you run AGPL software for your own team with no remote users interacting with it, and you are not distributing modified copies, Section 13’s trigger — remote users interacting with your modified version over a network — is typically not met. Purely internal use is the common safe case. The moment you modify it and expose that modified version to outside users over a network, the network clause is in play, so the internal-vs-external line is the one to watch.
Why does AGPL matter for my dependency and license policy?
Because AGPL is the license most likely to fail a policy scan or a due-diligence review, and it is often introduced transitively — a dependency of a dependency — where no one chose it deliberately. A single unnoticed AGPL package in a network service can put the whole service in scope of the very obligation your policy is trying to avoid. That is exactly why AGPL is the license teams most want to detect explicitly and early, rather than discover during an acquisition or an audit.
General information, not legal advice; the scope of the network clause and of a “derivative work” is genuinely debated, so confirm specific decisions with counsel. “AGPL” refers to the GNU Affero General Public License published by the Free Software Foundation and is used nominatively.