# AGPL License

> The AGPL license is GPLv3 plus a network clause: if you modify AGPL code and users reach it over a network, you must offer them its source code.

Also known as: AGPLv3, AGPL-3.0, AGPL-3.0-only, AGPL-3.0-or-later, GNU Affero General Public License, Affero GPL, Affero General Public License

Source: https://socket.dev/glossary/agpl

Last updated: 2026-10-22

The AGPL license (GNU Affero General Public License, also written AGPLv3, AGPL-3.0, or Affero GPL) is GPLv3 plus one clause, Section 13: if you modify an AGPL program and users interact with it over a network, you must offer those users its complete source code. Section 13 closes the gap where modified GPL software runs on servers without being distributed.

The trigger is modification plus remote interaction, not network use alone. Running an unmodified AGPL server creates no Section 13 duty. Importing an AGPL library into your own service, or shipping one inside a browser bundle, is where obligations reach your code. In our view, the AGPL exposure most teams actually carry is not a database they chose to deploy. It is a dependency that relicenses in a major version, as [ua-parser-js](https://socket.dev/blog/ua-parser-js-drops-mit-license) did in 2.0, and arrives through a routine upgrade. License policy belongs at install and pull request time, checked against what is inside the package, not what the registry metadata claims.

## What is the AGPL license?

The AGPL license is a strong [copyleft license](https://socket.dev/glossary/copyleft-license) that the Free Software Foundation (FSF) [published on November 19, 2007](https://lists.gnu.org/archive/html/info-gnu/2007-11/msg00006.html). Apart from its name and preamble, its text is GPLv3 with Section 13 rewritten. Its ancestor, the original Affero General Public License, was a GPLv2 derivative that Affero, Inc. released in March 2002. AGPLv3 is approved by the Open Source Initiative (OSI), which matters to companies that want to call their software open source.

To see why Section 13 exists, start with how the GPL works. Copyleft is a condition attached to copyright permissions. The GPL lets anyone run and modify the code freely, and it imposes its reciprocal obligation, sharing source under the same license, only when you convey a copy to someone else. GPLv3 and AGPLv3 both define that term in Section 0: "Mere interaction with a user through a computer network, with no transfer of a copy, is not conveying."

For software installed on users' machines, that rule covers everything that matters. For a web service, it covers almost nothing. A company can fork a GPL program, improve it, serve it to millions of users, and owe nobody a line of code, because no copy ever leaves its servers. The AGPL preamble names this case directly: on network servers, the sharing that copyleft is meant to produce "may fail to come about." Section 13 is the patch:

```text
Notwithstanding any other provision of this License, if you modify the
Program, your modified version must prominently offer all users interacting
with it remotely through a computer network (if your version supports such
interaction) an opportunity to receive the Corresponding Source of your
version by providing access to the Corresponding Source from a network
server at no charge, through some standard or customary means of
facilitating copying of software.
```

Read it as a conditional with three parts. The condition is that you modified the program. The scope is every user who interacts with your modified version remotely. The obligation is a prominent, free offer of the Corresponding Source, which [the license defines](https://www.gnu.org/licenses/agpl-3.0.html) as all the source needed to build, install, run, and modify the work, "including scripts to control those activities." Section 13's second paragraph lets you combine AGPL code with GPLv3 code, and GPLv3's own Section 13 returns the favor, so the two licenses are compatible in both directions.

## When does the AGPL require you to release source code?

The AGPL requires you to release source code in two situations: when you convey a copy, exactly as GPLv3 does, and when you run a modified version that users reach over a network. Most confusion comes from treating those as one rule. The first is about copies leaving your hands. The second is about modified code serving remote users. Every real deployment falls into one or both, and the figure below walks through the decision.

> Both outcomes can apply to the same software: a modified AGPL server you also ship as an image is conveyed and covered by Section 13.
>
> Decision flow for AGPL obligations. Question 1: do copies leave your control? Yes means conveying, so GPLv3 terms apply to the whole work. If no, question 2: did you modify it or link it into your own code? No means no obligation. If yes, question 3: do users interact with it over a network? No means no obligation while private. Yes means Section 13 applies: offer the Corresponding Source of the modified version to those users.

The figure asks three questions in order. First, do copies of the AGPL code leave your control, as downloads, container images, or browser bundles? If yes, you are conveying, and GPLv3's terms apply: license the whole work under the AGPL and provide its Corresponding Source. If no, did you modify the program or link it into your own code? If not, you owe nothing, because Section 2 explicitly permits running the unmodified program. If you did, do users interact with your version over a network? If not, private use that you never convey carries no conditions. If they do, Section 13 applies: prominently offer every remote user the Corresponding Source of your modified version, free, from a network server. Both outcomes can apply at once, for example to a modified server that you also ship as a container image.

The same decision as a table, with what you owe in the common cases:

| Scenario | Conveying a copy? | Section 13 triggered? | What you owe |
| --- | --- | --- | --- |
| Run an unmodified AGPL server and call its API | No | No, because you did not modify it | Nothing; keep its license notices intact if you ever redistribute it |
| Patch an AGPL server and expose it to users | No | Yes | Offer the patched version's Corresponding Source to every remote user |
| Import an AGPL library into your backend service | No | Yes, because your service is likely a modified version | Offer the whole service's Corresponding Source to its remote users |
| Bundle an AGPL module into frontend JavaScript | Yes | Not needed to create the obligation | License the whole bundle under the AGPL and provide its Corresponding Source |
| Ship a CLI, desktop app, or container image containing AGPL code | Yes | Only if modified and used over a network | GPLv3-style terms for the work; separate programs merely packaged together can form an "aggregate" |
| Run a modified version for employees only | No | Yes, because the text has no internal-use exemption | Offer source to those employees; exposure grows if outsiders later gain access |

Two cases in that table deserve a closer look because teams routinely get them backwards.

The browser bundle is the case teams most often miss. Server-side developers think of the AGPL as a network license, so they assume frontend code is safe. But a JavaScript bundle is object code that you transfer to every visitor's browser, which is conveying in the plain sense of the license. Section 13 never enters into it. Section 5(c) does: you must "license the entire work, as a whole, under this License," and Section 6 requires you to provide its Corresponding Source. If an AGPL module is linked into your bundle, the conventional reading is that the bundle as a whole is the work.

The imported backend library is the case behind most corporate bans. If your service calls into an AGPL library in the same process, your service is very likely a "work based on the Program," which makes it a modified version under Section 0. Section 13 then reaches the Corresponding Source of the whole service, not just the library. Whether two components that talk over HTTP or a database protocol form one work is less settled. The license's Corresponding Source definition points at "intimate data communication or control flow," and the conventional reading treats separate processes using a public API as separate works.

One more wrinkle: Section 13 binds whoever modifies the program. As lawyer Kyle Mitchell points out in [his close reading of the AGPL](https://writing.kemitchell.com/2021/01/24/Reading-AGPL), the modifier and the operator can be different parties, and the text does not plainly obligate an operator who runs someone else's modified version. Do not build a compliance strategy on that gap. The AGPL's own preamble says the license "requires the operator of a network server" to provide the modified source, and no court has settled the question.

## Does using an AGPL library make your code AGPL?

Using an AGPL library makes your code subject to the AGPL only when your code and the library form a single work that you then convey or serve as a modified version. In-process linking usually crosses that line. A network call to a separately running AGPL server usually does not.

AGPL vendors know this and design for it. When Grafana Labs [announced on April 20, 2021](https://grafana.com/blog/2021/04/20/grafana-loki-tempo-relicensing-to-agplv3) that it would relicense Grafana, Loki, and Tempo from Apache 2.0 to AGPLv3, it stated: "Plugins, agents, and certain libraries will remain Apache-licensed." As of October 2026, the npm registry still shows the split:

```bash
$ for p in @grafana/ui @grafana/data @grafana/runtime; do npm view $p version license; done
version = '13.2.4'
license = 'Apache-2.0'
version = '13.2.4'
license = 'Apache-2.0'
version = '13.2.4'
license = 'Apache-2.0'
```

The server is AGPL. The libraries you import into your own code are Apache-2.0. The split is deliberate, and it gives a useful review rule: check the license of the client library or SDK you link, separately from the license of the server it talks to.

Some companies decline to draw the line at all. Google's [AGPL policy](https://opensource.google/docs/using/agpl-policy/) is a flat ban: "Code licensed under the GNU Affero General Public License (AGPL) MUST NOT be used at Google." Its stated reason, that anything AGPL code links to "must also be licensed under the AGPL," is broader than Section 13 requires. We read the ban as a cost decision, not a legal interpretation. At Google's scale, one accidental in-process import can cost more than every AGPL tool the company would otherwise use.

We think most teams should land in between. Deny AGPL by default for libraries you import, including frontend packages. Allow unmodified AGPL servers that you run as separate processes, after a one-time review. That policy is cheap to enforce, and it matches the line the license text actually draws.

## How AGPL enters a codebase: the ua-parser-js relicense

The AGPL often enters a codebase through an upgrade, not a decision. ua-parser-js, a widely used library for parsing browser user-agent strings, is the clearest recent example. When Socket reported the planned change on June 18, 2024, the package had more than 12.5 million monthly downloads. Its maintainer moved version 2 from the [MIT license](https://socket.dev/glossary/mit-license) to a dual model: AGPLv3, or a paid "PRO" license.

The registry history shows exactly when the license flipped. We pulled the publish dates and per-version license fields from the npm registry:

> Source: npm registry metadata ( npm view ua-parser-js time and per-version license ), queried October 22, 2026.
>
> Timeline of the ua-parser-js license on npm. March 29, 2023: 2.0.0-alpha.1, MIT. October 5, 2023: 2.0.0-beta.1, first AGPL-3.0-or-later release. June 18, 2024: Socket reports the change, after 2.0.0-beta.3 on June 7. November 18, 2024: 2.0.0 stable, AGPL-3.0-or-later. August 19, 2025: 1.0.41, MIT, on the legacy tag. May 21, 2026: 2.0.10, AGPL-3.0-or-later, the latest tag as of October 2026.

The same history as a table, from `npm view ua-parser-js time` and each version's `license` field:

| Date | Event | License field |
| --- | --- | --- |
| 2023-03-29 | 2.0.0-alpha.1, first 2.x prerelease | MIT |
| 2023-10-05 | 2.0.0-beta.1, first AGPL release | AGPL-3.0-or-later |
| 2024-06-07 | 2.0.0-beta.3 | AGPL-3.0-or-later |
| 2024-06-18 | Socket reports the license change | n/a |
| 2024-11-18 | 2.0.0, first stable 2.x release | AGPL-3.0-or-later |
| 2025-08-19 | 1.0.41 on the legacy dist-tag | MIT |
| 2026-05-21 | 2.0.10, the latest dist-tag as of October 2026 | AGPL-3.0-or-later |

Nothing about that history violates [semantic versioning](https://socket.dev/glossary/semantic-versioning-semver). A license change shipped in a major version is the textbook breaking change. That is also why it slips through. A caret range such as `^1.0.38` never resolves to 2.x, so existing installs stay on MIT. The exposure arrives through a fresh `npm install ua-parser-js`, which resolves to 2.0.10 as of October 2026, or through a major-version bump pull request from an [automated dependency update](https://socket.dev/glossary/automated-dependency-updates) bot that a reviewer approves because the tests pass. Here is the same project's [package-lock.json](https://socket.dev/glossary/package-lock-json) entry before and after that one upgrade, trimmed to the relevant fields:

```json
"node_modules/ua-parser-js": {
  "version": "1.0.41",
  "resolved": "https://registry.npmjs.org/ua-parser-js/-/ua-parser-js-1.0.41.tgz",
  "license": "MIT"
}

"node_modules/ua-parser-js": {
  "version": "2.0.10",
  "resolved": "https://registry.npmjs.org/ua-parser-js/-/ua-parser-js-2.0.10.tgz",
  "license": "AGPL-3.0-or-later",
  "dependencies": {
    "detect-europe-js": "^0.1.2",
    "is-standalone-pwa": "^0.1.1",
    "ua-is-frozen": "^0.1.2"
  }
}
```

ua-parser-js runs in browsers as well as Node.js, so in many apps the upgraded package lands in the browser bundle case above. The obligation it triggers is conveying, not Section 13. Teams that could not accept AGPL terms had three exits: stay pinned to 1.x, which the maintainer kept patching under the `legacy` dist-tag (1.0.41 shipped on August 19, 2025); buy the PRO license; or switch to a fork. Node.js TSC member Matteo Collina forked the library under MIT as `my-ua-parser` for exactly this reason, as our original report describes.

You can find AGPL packages that npm has already installed with one command. `npm query` accepts CSS-style attribute selectors over the whole dependency tree, including transitive dependencies:

```bash
$ npm query '[license*=AGPL]' | jq -r '.[] | "\(.name)@\(.version) \(.license) \(.location)"'
ua-parser-js@2.0.10 AGPL-3.0-or-later node_modules/ua-parser-js
```

That check has a hard limit: it reads the `license` string each author declared in package.json, nothing more. Authors write free-form text there (`npm view n8n-workflow license` returns `SEE LICENSE IN LICENSE.md`), and the field says nothing about license files vendored deeper in the package. Registry metadata routinely understates what a package contains. In [our license analysis write-up](https://socket.dev/blog/socket-license-analysis), Django 5.1.1 carried seven distinct licenses across ten license files, while PyPI listed only BSD-3-Clause. That is why we analyze every file in a package rather than trusting the manifest. Socket's [license policy](https://docs.socket.dev/docs/license-policy) groups copyleft licenses into Weak, Strong, Network, and Maximal tiers, so a team can deny the Network tier, which covers licenses like the AGPL, and block, warn, or monitor at the pull request that introduces it.

## Can a vendor add restrictions to the AGPL?

A vendor can attach extra terms to AGPL code, but the result is no longer the AGPL, and the license itself invites recipients to strip them. AGPLv3 Section 7 treats any other non-permissive additional term as a "further restriction" and says that when a program arrives with one, "you may remove that term."

The [Neo4j v. PureThink](https://socket.dev/blog/fsf-goes-to-bat-for-agpl) litigation tested that clause. In 2018 Neo4j released Neo4j Enterprise Edition under AGPLv3 with the Commons Clause appended, a rider that restricts selling the software or services built on it. Its former partner PureThink and successor company iGov removed the rider and promoted the resulting fork, ONgDB, as "free and open-source." The courts sided with Neo4j. A [February 2022 Ninth Circuit memorandum](https://cdn.ca9.uscourts.gov/datastore/memoranda/2022/02/18/21-16029.pdf) held the claim "literally false," reading Section 7 to permit removal only of restrictions "added by an upstream licensee," not by the licensor itself. The FSF, which wrote the AGPL, filed an amicus brief in 2025 arguing that reading gets its own license wrong.

The practical lesson is for your policy engine, not your lawyers. A LICENSE file that reads "AGPL-3.0 plus additional conditions" is a different license from AGPL-3.0, and you should treat it as unidentified until someone reviews it. The [SPDX](https://socket.dev/glossary/spdx) identifiers to match are `AGPL-3.0-only` and `AGPL-3.0-or-later`. The bare `AGPL-3.0` identifier is deprecated but still appears in older manifests, and SPDX has no identifier at all for AGPL with a vendor rider.

## AGPL vs GPL vs SSPL

The AGPL sits between GPLv3, which ignores network use, and the Server Side Public License (SSPL), which MongoDB wrote to go further. MongoDB versions released before October 16, 2018 were AGPL. Later versions use the SSPL, whose Section 13 demands the source of the entire service stack, and the [MongoDB SSPL FAQ](https://mongodb.com/legal/licensing/server-side-public-license/faq) confirms the OSI does not consider it open source.

| License | Copyleft triggered by | Source you must provide | OSI-approved | Typical use |
| --- | --- | --- | --- | --- |
| GPLv3 | Conveying a copy | Corresponding Source of the conveyed work | Yes | Tools and libraries that ship to users |
| AGPLv3 | Conveying a copy, or remote users of a modified version | Corresponding Source of the modified version | Yes | Vendor-backed servers such as Grafana; an option for Elasticsearch and Redis 8 |
| SSPLv1 | Conveying a copy, or offering the program as a service to third parties | The program plus the service's management, monitoring, backup, storage, and hosting software | No | MongoDB since October 16, 2018; an option for Redis 7.4 and later |

Our verdict: choose GPLv3 for code that ships to users and has no hosted use. Choose AGPLv3 when you want OSI-approved open source and want hosted modifications to come back to the community. Treat SSPL as a commercial license in your policy, because it is not open source and its service clause is far broader than the AGPL's. Vendors have voted with their releases. Elastic announced AGPL as an option for Elasticsearch in August 2024, in [Elasticsearch's return to open source](https://socket.dev/blog/developers-burned-by-elasticsearch-license-change-arent-going-back). Redis added AGPLv3 alongside RSALv2 and SSPLv1 [starting with Redis 8](https://redis.io/legal/licenses/), after [Redis's 2024 license change](https://socket.dev/blog/redis-license-shift-splits-community) away from BSD pushed contributors to fork.

## How do you comply with the AGPL?

You comply with the AGPL by meeting GPLv3's terms whenever you ship a copy, and by publishing an exact source offer whenever you run a modified version for remote users. In practice that comes down to four decisions, and each has a cost.

**Classify every AGPL component by how you use it.** A server you run unmodified, a library linked into your code, and a module in a frontend bundle carry different obligations, as the table above shows. This step needs a dependency inventory that reads package contents, and it is the step where a manifest-only [license compliance](https://socket.dev/glossary/license-compliance) scan goes wrong.

**For a modified server, publish the source of the exact running version.** In practice, "prominently offer" means a link users can find, such as a "Source" link in the UI footer and a stable URL for API clients. The offer must cover your modified version, including build scripts, at no charge. The simplest durable implementation ties the link to the deployed commit:

```js
// Serve the Corresponding Source for the exact build that is running.
// GIT_SHA is injected at build time; the archive includes build scripts.
const express = require('express')
const app = express()

app.get('/source', (req, res) => {
  res.redirect(302, `https://git.example.com/our-fork/archive/${process.env.GIT_SHA}.tar.gz`)
})

app.listen(3000)
```

That route does not cover conveyed copies. If you also ship the code, Section 5 still requires prominent notices that you modified it, with a date, and Section 6 requires Corresponding Source to accompany the object code.

**Buy out of the copyleft when the vendor offers it.** Many vendor-backed AGPL projects are dual-licensed precisely so commercial users can pay instead of comply. ua-parser-js PRO licenses ranged from $12 to $500 when we covered the change in 2024. The cost is money, plus a license renewal to track.

**Avoid it, and accept what you give up.** Pinning to the last [permissive](https://socket.dev/glossary/permissive-license) version or switching to a fork keeps you out of scope. It also cuts you off from upstream features and, eventually, from upstream security fixes, so a pin is a decision with an expiry date, not a resolution.

We are engineers, not your lawyers. For a genuine combined-work question, such as an AGPL component inside a commercial product you distribute, get a legal opinion on your specific architecture.

## Where Section 13 is still unsettled

Two questions remain open. The first is the operator gap described above: Section 13 binds the modifier, and no court has ruled on whether it reaches an operator running someone else's modified code. The second is the boundary of a "work" in a system of containers and services. The Corresponding Source definition talks about linking and "intimate data communication," vocabulary written for processes on one machine, not for a dozen services exchanging JSON.

We are not aware of a court decision that construes Section 13's network clause, and the Neo4j litigation turned on Section 7 and false advertising, not Section 13. So the AGPL is enforced mostly by procurement: allowlists, legal review queues, and bans like Google's. That makes the AGPL's real cost a review cost, paid every time an AGPL package tries to enter a dependency tree. The cheapest place to pay it is the pull request that introduces the package, not the audit after the product ships.