← All articles · 7 min read · 2026-05

AGPL and commercial use: what changes when you ship SaaS

The AGPL is the GPL with one extra requirement: if you let users access your software over a network, you must offer them the source code. That single addition is why AGPL is the license commercial SaaS most needs to understand — and the one most often misunderstood.

What plain GPL does, and what it misses

The GPL was written for the era of distributed software. If you took a GPL'd program, modified it, and gave the modified version to someone else, you had to include the source. The trigger was distribution. If you used GPL'd software internally without giving it to anyone, you owed the world nothing.

Then SaaS happened. Companies could take a GPL'd program, modify it, run it on their servers, and serve users over a network — without ever "distributing" the modified code in the GPL's sense. The users got the benefit; the upstream got nothing. Critics called it the "ASP loophole."

What AGPL adds

Section 13 of the AGPLv3, in plain English: if you modify this software and let users interact with it over a network, you have to offer those users the source code of your modifications.

That's the only practical difference from GPLv3. Everything else — the strong copyleft, the "or later" pattern, the no-additional-restrictions rule — is the same.

The implications for SaaS:

If your SaaS includes AGPL-licensed code, and you've modified that code, you're obligated to offer your users (the people accessing your SaaS) the source code of the modifications.
If you're using the AGPL'd code unmodified — exactly as the upstream published it — you don't owe anyone modifications you haven't made. But you do still owe a way for users to get the upstream source.
The obligation is to "users who interact with it remotely through a computer network." That language is broad. It covers your customers; it likely covers your customers' end-users, too, if your product passes through to them.

"Modifications" is doing a lot of work in that paragraph. The interpretation is contested — does linking to the AGPL library from your own non-AGPL code count as "modifying" the AGPL component? FSF says yes; some lawyers disagree. The conservative answer is the same as GPL: assume any combination that includes the AGPL code creates a "modified work" subject to the source-disclosure requirement.

What this means in practice

Scenario 1: AGPL package as a build dependency only

You use an AGPL-licensed tool in your CI pipeline to lint, format, or compile, but its code never ends up in the bundle you serve to users. You're fine. The AGPL trigger is "users interacting with it over a network" — your CI pipeline isn't a service to users.

Scenario 2: AGPL package included in your bundled JavaScript / Python service

Your dep tree includes an AGPL package, your build bundles it into the runtime your users access. You owe source disclosure. Either remove the package, replace with a permissively-licensed alternative, or commit to publishing your modifications.

Scenario 3: AGPL package as a separate service you call

You run an AGPL'd service (say, a database) on your servers, your application calls it via a network API. This is the contested case. Most readings: the AGPL'd service's users — the ones interacting with it over the network — are limited to the consumers of its direct API. Your own service is a "user" in that sense, not your application's end-users. So you owe source disclosure to your own application, not to your end-users. Practically, you can satisfy this by hosting the upstream source link prominently on the service's own admin endpoints.

This is why MongoDB switching to SSPL — and Redis briefly going AGPL — caused so much turmoil. Anyone using those projects had to figure out which scenario they were in.

How AGPL gets into a dependency tree

Almost never directly. Engineers who deliberately add AGPL'd code know what they're signing up for. The trap is transitive:

A popular permissively-licensed wrapper library wraps an AGPL native module.
A package that was MIT in v2.x switched to AGPL in v3.x; you took an automatic minor-version bump.
An AGPL-licensed CLI is invoked as a subprocess from a permissively-licensed wrapper, and the wrapper is your direct dep.

The fix is the same in each case: scan your full transitive tree, find the AGPL'd package, and decide whether you can replace it. If it's in build tooling only, document that. If it's in your bundled runtime, replace it. Don't ship AGPL'd code in your SaaS bundle and hope nobody asks.

Replacement strategies

If you found AGPL...	Common replacement path
...in a Markdown library	Most have MIT or Apache-2.0 alternatives; switch.
...in a charting / visualisation lib	Recharts, Chart.js, Plotly's open-core builds — all permissive.
...in an OCR or PDF tool	Often the upstream offers a commercial license; for $0–$5k you swap out the AGPL conditions.
...in a database (MongoDB community / Redis SSPL)	Either move to a service offering (Atlas, ElastiCache, MongoDB Atlas) where the SSPL/AGPL terms don't bind you, or switch to a fork (Valkey for Redis).
...in a transitive dep brought by a popular library	File an upstream issue; the maintainers typically aren't aware and will swap it.

What to put in the procurement response

If you ship AGPL'd code and you're certain about your scenario, say so explicitly:

"This SBOM includes [package X] under the AGPL-3.0-or-later license. We use this package unmodified as a build-time tool only; it does not ship in the runtime our users access. No source-disclosure obligation arises under AGPL § 13 in this configuration."

Procurement reviewers vary widely in license literacy. Some will accept that statement; some will escalate it to legal. Either way, the explicit explanation is better than hoping they don't notice.

LicenseHound flags AGPL packages in your tree by default and lets you mark them as "build-time only" via policy so the same explanation is generated automatically each time.

Notify me when v0.1 ships: