Knowledge base

What does "no AGPL" really mean?

If you have seen a "no AGPL" rule in a company policy and wondered why one license gets singled out, this explains exactly what it does, and what it does not.

6 min read · Updated June 26, 2026

Why you see "no AGPL"

The AGPL is the one open-source license that large companies routinely ban outright. Google’s open-source policy is blunt about it: AGPL-licensed code "MUST NOT be used at Google." When a license is singled out like that, it is worth understanding the specific clause behind the reputation, rather than treating it as a mystery to avoid. Source: Google open-source policy

What the AGPL adds: Section 13

The AGPL is the GPLv3 with one extra clause. Section 13 says that if you modify the program and let users interact with your modified version over a network, you must prominently offer those users the Corresponding Source of your version. That is the entire difference, and it is the source of both the fear and the misunderstanding.

The loophole it closes

An ordinary GPL obligation triggers on distribution: when you ship the software to someone. Running software as a service does not distribute it; users interact with it over the network but never receive a copy. That gap is the "SaaS loophole": a company could take GPL software, modify it, run it as a hosted service, and never share the changes. The AGPL exists to close that gap for network-delivered software.

What "no AGPL" does NOT mean

The common myth is that touching any AGPL tool forces you to open-source your entire company. That overstates it. The new network-source duty in Section 13 is gated on modifying the program; deploying an unmodified AGPL program over a network does not create a new disclosure obligation beyond what upstream already offers.

So why the blanket bans? Because at the scale of a large codebase, the boundary between "using", "modifying", and "creating a derivative work" is fuzzy and expensive to police. A blanket "no AGPL" rule is a cheap, safe proxy for a legal analysis nobody wants to run on every dependency. It is risk management, not a literal reading of the license.

The accurate one-liner

AGPL can require you to share source for a modified version you run as a network service. It does not automatically open-source unrelated code. The trigger is modification plus network availability.

The MongoDB example

MongoDB shows how contested network copyleft is. MongoDB was AGPL, then in October 2018 relicensed to a brand-new license it wrote itself, the Server Side Public License (SSPL), to push the obligation even further: SSPL would require anyone offering the database as a service to open-source their entire service stack. The target was cloud providers monetizing the database without contributing back. Source: MongoDB SSPL FAQ

The catch: the Open Source Initiative never approved the SSPL. MongoDB submitted it for review and withdrew it in 2019, so SSPL is not recognized as an open-source license. The episode is why "is this actually open source?" is a real question, not a pedantic one. Source: OSI license list

What to do about it

The practical posture is simple: know whether AGPL (or non-open licenses like SSPL) are anywhere in your dependency tree, decide your policy deliberately, and enforce it automatically. That means an SBOM and license scanning that can fail a build when a banned license appears, instead of finding out during a customer security review.

Frequently asked questions

What does "no AGPL" mean in a company policy?

It means the organization forbids using AGPL-licensed components in its software. The concern is the AGPL Section 13 network clause, which can require sharing source for a modified version offered as a network service, so many companies ban the license outright as a precaution.

Does using an AGPL database mean I have to open-source my app?

Not by itself. The Section 13 source obligation is triggered by modifying the AGPL program and offering that modified version over a network. Running an unmodified AGPL program generally does not force you to release your own application code, though you still must respect the license’s other terms.

Is the AGPL open source?

Yes. The AGPL-3.0 is an OSI-approved open-source license. By contrast, the SSPL that MongoDB created to replace it is not OSI-approved and is not considered open source.

Why did MongoDB stop using the AGPL?

In October 2018 MongoDB moved from the AGPL to its own Server Side Public License to stop cloud providers from offering the database as a service without contributing back. The SSPL was stricter, but the OSI never approved it.

Keep reading

What is copyleft (and why it matters)? Copyleft is the idea that turned open source into a movement. It is also the single licensing concept most likely to surprise a business that did not know it was there. Permissive vs copyleft licenses Every open-source license falls on a spectrum from permissive to copyleft. Knowing which is which, and what each obligates you to do, is the core of open-source license compliance. What is software composition analysis (SCA)? If an SBOM is the inventory of what your software is made of, software composition analysis is what reads that inventory and tells you where the risk is.

Sources

Part of the software supply-chain field notes on this site. Written by Antoni K Pestka.