Article · License risk

Is AGPL safe for commercial and SaaS use?

Short answer: yes, the AGPL-3.0 is safe to use commercially — it’s an OSI-approved open-source license, not a “non-commercial” one, and you can sell products and services built on it. The risk everyone worries about is narrower and more specific than “AGPL is banned”: a source-disclosure obligation that a hosted, SaaS product can trigger where a shipped desktop app might not. Understand the exact trigger and the AGPL becomes a component you can make an informed decision about — not a landmine.

Updated 26 Jul 2026 · by the depproof team

“Commercial use” is allowed — the real question is disclosure

So can you use AGPL commercially? Yes. The most common misconception is that AGPL means “no commercial use.” It doesn’t. Like the GPL, the AGPL grants everyone — companies included — the right to run, modify, and even sell the software. What it asks in return is reciprocity: under certain conditions you must pass the same freedoms downstream by making your complete corresponding source available under the AGPL. So the useful question is never “can we use AGPL commercially?” (you can) but “does our use trigger the source-disclosure obligation, and can we accept it?”

The one thing AGPL adds over GPL: the network clause

The AGPL is the GPL-3.0 plus one extra obligation, and that single addition is the entire reason SaaS teams treat it differently.

This is why AGPL is the license SaaS and internal-platform teams flag: your server-side code that you never ship to anyone can still fall within scope precisely because you expose it over a network. A desktop-app or internal-CLI shop faces a much smaller version of the same question.

When a SaaS product is affected — and when it isn’t

The trigger has two hinges: did you modify it, and is it combined with your code or arm’s-length. Roughly, the risk ladder looks like this:

Lower risk

• Running an unmodified AGPL program as a service. You generally must let users obtain the (unchanged) source you already have, but you aren’t forced to open your code — you didn’t modify it and it isn’t your work.
• An AGPL tool as a separate process you merely call — a standalone service behind an API, or a CLI you invoke. Many treat a clean process boundary as arm’s-length rather than a single combined work. (Debated — see below.)
• Internal-only use with no external users interacting with it over a network — though “internal network users” is exactly the kind of fact worth checking with counsel.

Higher risk

• Forking and modifying an AGPL component, then exposing that modified version to users over a network. This is the textbook Section 13 trigger — plan to disclose your corresponding source under the AGPL.
• Linking an AGPL library into your application so your code and the AGPL code form one program. The copyleft can then reach your code, and offering it as a network service can pull your source into scope.

The linked-vs-separate line — whether calling an AGPL component creates one “combined work” — is genuinely contested and hasn’t been cleanly settled in court. That’s not a reason to panic; it’s a reason to treat a linked AGPL dependency as high-risk until your policy or counsel signs off, and to prefer a clear process boundary when you do use one.

AGPL vs GPL vs LGPL, at a glance

For a SaaS business specifically, the ordering that matters is: LGPL is usually workable, GPL is often workable for the hosted case, and AGPL is the one to review deliberately before it lands in a networked product.

The practical problem: you rarely choose AGPL — you inherit it

Teams almost never sit down and add an AGPL library on purpose. AGPL risk shows up as a transitive dependency — something three or four layers deep that a package you did choose happens to pull in. Nobody reviewed it, because nobody saw it. It surfaces later at the worst possible time: an acquisition’s technical due diligence, a customer’s license questionnaire, or an OSS-compliance audit.

So “is AGPL safe for us?” becomes an inventory question before it’s a legal one. You can’t make a decision about a license you don’t know you’re shipping. The defensible move is to know every component’s license, including transitive ones, and to be told when a new AGPL dependency enters — on the pull request, not in due diligence.

Concretely: generate an SBOM that resolves your full transitive dependency tree and records each component’s declared license, then check it for AGPL-3.0 and its SPDX variants (AGPL-3.0-only, AGPL-3.0-or-later). Run that check in CI so a copyleft license you’ve chosen to prohibit fails the build instead of slipping through.

• Check your npm dependency licenses — surface AGPL and other copyleft licenses across the full tree, straight from the lockfile.
• Check Maven dependency licenses without building — the same license inventory for the JVM.
• AGPL-3.0 explained — the reference version: Section 13, the obligations, and where they bite. See also which licenses you can ship.
• The depproof hub — find every AGPL (and other copyleft) dependency across all your repos in one view.

So — is it safe?

Yes, with eyes open. The AGPL-3.0 is safe for commercial and SaaS use as long as you understand the one obligation it adds and decide, deliberately, whether your architecture triggers it. Use it unmodified, or behind a clean process boundary, and it behaves much like any other open-source dependency. Fork-and-modify it into a networked product, and plan to disclose your corresponding source. The failure mode isn’t “using AGPL” — it’s not knowing you’re using it. Fix that first, and the license decision becomes routine.

Frequently asked questions

This article is general information, not legal advice; confirm any specific license decision with counsel. depproof is free for open source and teams under $1M revenue — see pricing. “AGPL,” “GPL,” and “LGPL” refer to the Free Software Foundation’s licenses and are used nominatively.