What is AGPL-3.0?

The one sentence that differs

The GNU GPL family works through copyleft. You may use the software for anything. If you convey it, or a modified version of it, to anyone else, you must convey the source of your version under the same terms. That is the whole mechanism, and it is why GPL is a problem for a company that ships software and not for a company that runs it internally: no distribution, no obligation.

AGPL-3.0 keeps all of that and adds a paragraph addressing the case the original licence did not reach. If you modify the program, your modified version must offer the users interacting with it remotely a way of obtaining the corresponding source of your version. Network interaction counts as conveying.

That is the difference, and it is worth being precise about what it does and does not say. It is written around remote interaction rather than around commerce, and it does not restrict that interaction to customers. A deployment where staff reach a modified instance over a network is inside the language of the clause, and that is one of the points people argue about rather than one that is settled. It also does not affect the unmodified case: running the software exactly as published, without changing it, is not a modification, and the clause is about modified versions.

Two other features of the licence matter less often and are worth naming. The version suffix does real work: AGPL-3.0 binds you to that version, while AGPL-3.0-or-later lets you offer the work under this version or any later one, which matters when a successor version changes terms. And the licence is free software in the OSI sense, not a source-available or research licence. The permission is broad; the condition is publication.

Where the obligation actually triggers

The clause reduces to a short decision, and most of the confusion comes from not making the decision explicitly.

Running the software unmodified, for your own use or inside your own company, with no remote users, triggers nothing. This is the case most people assume covers everything, and it is the case that is genuinely safe.

Running a modified version and letting users reach it over a network triggers the source obligation. Hosting a web application, an API, a chat interface, a remote desktop, anything with users, is this case if you changed the code. The users include your own staff, and the clause does not make an exception for them.

Distributing a modified version, on a disk or in a container image that you hand to a customer, triggers the same obligation, and that is ordinary GPL behaviour rather than anything new.

Embedding a library. This is where careful reading matters and where most arguments start. If you link an AGPL library into your program and ship your program, the GPL's derivative-work analysis applies and your program inherits the obligation. If you merely run the library as a separate process and talk to it over a socket, most analyses treat that as the weaker case, and that distinction is a legal question rather than a technical one.

The practical consequence is that the deployment shape is a business decision made before the code is written. A team that intends to modify an AGPL project and offer it as a service has chosen the licence's condition, whether or not anyone noticed.

The business models around it

AGPL is unusual among free software licences in that its condition is well understood by the companies that use it, and the arrangements are conventional.

The hosted service. A company runs the AGPL project unmodified as a service, charges for it, and publishes nothing, because there is no modification. This is exactly what the licence permits, and it is why a great deal of self-hosted-and-also-offered software exists.

The dual licence. The same project is released under AGPL and sold commercially under a separate licence to customers who want the same software without the publication condition. The commercial licence is a private agreement, and the copyright holder is in a position to grant it because it holds the copyright in the first place.

The enterprise edition. A proprietary set of features is kept outside the AGPL tree, and the paying customers get both. Whether those additions are a separate work or a derivative of the AGPL part is the same derivative-work question as above, which is why the boundary is drawn in the repository layout and then argued about in the licence text.

The internal modification. A company modifies an AGPL project for its own use and never offers it to anyone. No obligation attaches, and the modification is a normal engineering investment.

What the licence does not do is prohibit any of this. The prohibitions people remember from other licences are not here. What it does is make publication the price of operating a modified version in public, which is a deliberate design choice by the copyright holders, and the most common reaction in the industry is to design around it rather than to argue with it.

The mistakes that get made

Six, and they are cheap to avoid.

Assuming internal use is always exempt. It is exempt for an unmodified program. Once you change it and staff or customers reach it over a network, the clause is in scope, and the argument happens after the deployment is live.

Treating it as plain GPL because nothing was distributed. The distribution trigger is the one everyone remembers, and it is not the one that matters for a service.

Assuming a thin wrapper escapes it. Whether your code is a modified version is a legal determination about linking and derivation, not something the repository layout decides on its own.

Reading the dependency and the deployment together. A licence scan that finds an AGPL dependency in a service you expose is raising a real question, and dismissing it because you did not modify that dependency answers half of it.

Ignoring the version suffix. AGPL-3.0 and AGPL-3.0-or-later are different grants, and which one you received determines what you may offer downstream.

Forgetting that the obligation is on your version, not on the whole product. The corresponding source required is the source of your modified version of the program, which is a much smaller thing than publishing your entire application, and that is the version of the question most companies find answerable.

How the projects use it

Reading this list is a good way to see which deployment shapes the licence was written for, because the projects cluster by shape.

Network services. firecrawl/firecrawl is the clearest case in this list: our analysis describes an API that turns URLs into Markdown or structured JSON, shipping a hosted service, a Docker Compose self-host path and an AGPL-3.0 core, and it names the licence as the part most teams underestimate. That is the exact configuration the clause addresses, and the fact that the hosted offering and the AGPL core coexist is the hosted-service model above.

Self-hosted workspaces. odysseus-dev/odysseus bundles chat, agents, research, email, notes and calendar into one self-hosted Python application, and our analysis records that the install is four commands, the default branch is dev, and the licence is AGPL-3.0-or-later. AppFlowy-IO/AppFlowy is the larger version: a Flutter and Rust workspace for projects, wikis and teams, distributed under AGPL-3.0, shipping desktop builds plus mobile apps, with the README pointing self-hosters at a step-by-step guide rather than a one-line installer.

Media libraries with clients. immich-app/immich is an AGPL-3.0 TypeScript monorepo that runs a photo and video library on your own hardware, with mobile apps that back up automatically; our analysis calls the install path Docker and records the README telling you to keep a 3-2-1 backup anyway, which is a reminder that the licence and the operations are separate problems.

Remote access. rustdesk/rustdesk is a self-hostable remote desktop that lets you point it at your own rendezvous and relay server, and our analysis names the trade-offs directly: a heavy build toolchain and an AGPL-3.0 licence that follows the code. Follows the code is the phrase to keep in mind, because it means the obligation moves with the modified source rather than with the binaries you happen to distribute.

Tools that mostly run locally. AUTOMATIC1111/stable-diffusion-webui is a browser interface over a local Python and PyTorch install with txt2img, img2img, inpainting and an extension system, and our analysis records its last push to master as 2025-02-09 and describes it as a stable, slow-moving codebase. hacksider/Deep-Live-Cam is a face-swap and deepfake tool that drives a webcam feed from one reference image, and our analysis notes that its licence is AGPL along with the cases where it is the wrong choice, which for a single-machine tool is a different question from the service case.

In practice

AGPL-3.0 is the GPL with a network clause, and the whole decision is whether you modify the program and then let anyone reach it over a network. Unmodified, you owe nothing; modified and served, you owe the source of your version, staff included. Everything else is derivative: which shape your deployment takes, whether your code counts as linked, and whether the version you received is or-later. Read the licence text at gnu.org before the deployment rather than after, decide the shape of the deployment while you are still choosing the tool, and if you intend to modify an AGPL project and sell the result, get a lawyer involved at the design stage rather than at the release.