Google maintains a public web page whose entire purpose is to tell Google engineers not to use one specific open source license. Not a general licensing policy (they have one of those too); a dedicated page, for one license, that opens with “MUST NOT” in capital letters and goes on to prohibit installing the stuff on a Google-issued laptop. The license is the GNU Affero General Public License, and if you manage engineers, sooner or later one of them will ask whether some piece of AGPL software is safe to use, and someone in legal will make a face.
The face is mostly unearned. The AGPL is not radioactive for the reasons people assume, and Google’s ban, while entirely rational for Google, is a terrible template for everyone else. But to see why, you need the history.
The loophole
The ordinary GPL’s copyleft has a trigger condition: distribution. Hand someone a binary, and you owe them the source, your modifications included. Never hand anyone anything, and you owe nothing. Run a heavily modified GPL program on your own servers, put a web interface in front of it, serve a hundred million users; the GPL is silent, because your users received web pages, not copies of the program.
In 1991, when GPLv2 was written, this was a corner case. By the early 2000s it had a name, the ASP loophole (we’d say SaaS loophole now), and it was becoming the dominant way software reached users. A company called Affero, with the Free Software Foundation’s cooperation, published the first Affero GPL in 2002 to close it; the FSF published the modern version, AGPLv3, in November 2007.
AGPLv3 is GPLv3 plus one section, and the entire controversy lives in that section. Section 13 says: if you modify the program, then everyone who interacts with it remotely over a network must be offered the source code of your modified version. Distribution is no longer the trigger. Letting users touch the software over a network is.
What Section 13 actually requires
Less than people think, and this gap between the text and the fear is most of the story.
First, the trigger is modification. If you run stock upstream AGPL software as part of your service, Section 13 asks nothing of you; the source your users are entitled to is the source they can already download from the project. The license was written to catch service providers carrying secret private patches, not people running the released version.
Second, the scope of the requirement is the modified program: the covered work, in license terms. It is not your entire service, not the proprietary application talking to it over a socket, not your infrastructure. A company that patches its Grafana build and serves dashboards to customers owes those customers the patched Grafana source. It does not owe them the billing system.
Where it gets genuinely murky is exactly where the GPL gets murky: the boundary of “the work.” What counts as a derivative? Where does linking create obligations? These questions have decades of practice and commentary behind them for the GPL. For Section 13 specifically, there is essentially no case law.
At this point someone always brings up Neo4j, which has been litigating since 2018 against a small consultancy and its founder, in a case with “AGPL” on nearly every page of the filings. It gets cited constantly as the AGPL precedent. It isn’t, and the reason is worth two paragraphs.
Neo4j never licensed the software at issue under the AGPL. It licensed its Enterprise Edition under AGPLv3 plus the Commons Clause, a bolted-on restriction forbidding sale of the software; the combination is a proprietary license wearing the AGPL’s text. The defendants stripped the Commons Clause back out, relying on language in Section 7 of the AGPL that permits licensees to remove “further restrictions,” and marketed the result, a fork called ONgDB, as free and open source Neo4j Enterprise. The district court held that Section 7 does not let a downstream licensee delete a restriction the copyright holder itself attached; that made the “free and open source” claims false advertising under the Lanham Act. The Ninth Circuit affirmed a preliminary injunction on that basis in 2022, the FSF and the Software Freedom Conservancy have both filed amicus briefs arguing that the courts misread the FSF’s own license, and the full appeal is still pending at the Ninth Circuit as I write this.
Notice what never appears in that story: Section 13. The entire dispute is about license-text surgery, trademarks, and marketing claims. No court in the case has construed the network clause, interpreted what “modify” means for a running service, or drawn the boundary of a covered work. To the extent Neo4j establishes anything about the AGPL, it is a contested holding about Section 7 that the license’s own authors insist is wrong. As precedent for the thing Google is afraid of, it is worth nothing.
So the network clause remains untested, and nobody can tell you with certainty where its edges are. Lawyers hate that, and what lawyers hate, corporate policy bans.
Why Google, specifically
Three reasons, in escalating order of importance.
The AGPL is aimed at exactly Google’s business model. Google distributes almost nothing; its products are services accessed over a network. That makes distribution-triggered copyleft nearly free for them, which is why Google runs GPL code on its servers all day without controversy. It also means the AGPL’s trigger condition describes their flagship products precisely; their policy page names Search, Gmail, Maps, and YouTube as the things at risk. The worst-case outcome isn’t a fine. It’s a colorable claim that they owe the world the corresponding source of a core service.
The monorepo makes the scoping question terrifying. Nearly all of Google’s code lives in one enormous, densely interlinked repository. The Google policy asserts that AGPL code infects anything it links to; that is the maximalist reading of the license, not a settled one, but when your codebase links everything to everything, you price the risk at the maximalist reading. Google says as much: the page describes its own policy as an “aggressively-broad” ban, deliberately wider than the license requires, so that no engineer can wander within a mile of the actual boundary.
Compliance economics. Case-by-case legal review of AGPL dependencies across a hundred thousand engineers costs more than any of the software is worth to them. Chris DiBona, who ran Google’s open source office for years, said in 2011 that the ban existed to save engineering time, and that Google didn’t much want the available AGPL software anyway. (Google applies the same reasoning to the OSL, the SSPL, and the EUPL, which are banned on the same page for the same reasons. The AGPL just gets top billing.)
All of this is sound reasoning for a trillion-dollar service company with one giant codebase. Notice how little of it applies to a 200-person company with normal repositories and a normal legal budget.
The controversy
If the AGPL were used only by free software idealists, none of this would be interesting. The FSF’s position is coherent on its own terms: users of a network service deserve the same freedoms as users of a distributed binary, and the AGPL restores them.
What made the license controversial is what it turned out to be for. In practice, the AGPL’s most visible role has been commercial: it is the free half of the dual-license business model. License your server product under AGPLv3, watch every large enterprise’s legal department refuse to touch it (with Google’s public policy as Exhibit A), and sell them a commercial license instead. The corporate allergy is not a side effect; it is the sales funnel.
The examples are not obscure, and several sit close to home for PostgreSQL people. MongoDB was AGPL from 2009 until 2018. Grafana, the dashboard in front of half the world’s Postgres metrics, relicensed from Apache 2 to AGPLv3 in 2021; MinIO, a popular backup target, did the same that year. Elastic added AGPLv3 to Elasticsearch in 2024 as its route back into open source. Citus, the distributed-Postgres extension, has been AGPLv3 since it was open-sourced in 2016, with its client drivers under the PostgreSQL License specifically to keep the copyleft’s reach unambiguous.
The punchline of the cloud wars is that the AGPL turned out not to be strong enough for the job. When MongoDB concluded that AWS was eating its lunch, the problem was exactly the Section 13 limits described above: a hyperscaler can run unmodified builds, or keep its changes outside the covered work, and owe nothing new. So MongoDB wrote the SSPL, which extends the source requirement to the entire service stack, and which the Open Source Initiative would not accept as open source. The AGPL sits at the outer edge of what the open source establishment still calls open source. Everything past it doesn’t get the label.
So: one camp sees a license that closed a real loophole in the copyleft project. The other sees a legally ambiguous instrument whose main real-world function is enterprise sales, with Google’s fear doing the persuading. Both camps are describing the same license accurately. That’s what makes it a good controversy.
What you should actually do
Depends on which chair you sit in.
You use AGPL software, unmodified. Grafana dashboards, MinIO buckets, a Citus cluster. Your Section 13 obligations are approximately nothing. Keep an inventory anyway, because the next people to ask will be an acquirer’s due-diligence team, and they pattern-match on Google’s policy, not on the license text. “We run unmodified upstream” is a fine answer; not knowing what you run is not.
You modify AGPL software and expose it over a network. Now the license is real. You have two legitimate options: publish your modifications (ask honestly whether those patches are secret sauce or merely secret), or buy the commercial license the vendor will be delighted to sell you. The one thing you cannot do is quietly carry private patches in a customer-facing service. That is the precise behavior the license was written to catch.
You’re choosing a license for your own project. Understand what the AGPL buys: it will keep your software out of Google, and out of the many companies that copied Google’s policy with far less reason to have it. If your goal is maximum adoption, that’s a defect. If your goal is forcing hyperscalers to pay or stay away, it’s the point, and it works better than anything else that still qualifies as open source.
You’re writing your company’s license policy. A blanket ban is rational if you are a network-services company with a giant integrated codebase and thousands of engineers making dependency decisions daily. You are probably not. For everyone else, a lightweight review gate (“AGPL gets a legal look before it ships in anything customer-facing”) delivers the protection without banning your monitoring stack.
Obligatory closing note: I am not a lawyer, and none of this is legal advice. For actual advice about actual AGPL exposure, you pay someone by the hour, which is, come to think of it, its own kind of dual licensing.