AGPL License Explained: What It Means for Your Team

AGPL is a copyleft license that keeps source code open and extends that duty to users who interact with a modified version over a network. So the key question isn't only what you download. It's who uses your changed version, and how they reach it.

You may be looking at a self-hosted tool right now. You like the code. You want to run it on your own server. Then you see AGPL in the license file and pause. That's a normal place to start. This guide has the AGPL license explained in plain steps, with real cases you can check against your own setup.

What AGPL Means in Plain English

Maya is a developer. She finds a useful open-source tool. She wants to host it for her team. She may fix a bug. She may add a feature. One day, she may give clients a login. Can she do these things? What must she share? What can she keep private?

These are the three real questions. What can you do? What must you share? Who must get the source? If you can answer those three, you understand most of AGPL.

One Plain Sentence

The full name is the GNU Affero General Public License, or AGPLv3. It's a strong copyleft license for software used over networks, and the Free Software Foundation published the final version on November 19, 2007. Strong copyleft means the sharing rules travel with covered changes. They don't just stop at the first copy.

AGPL works like a shared workshop rule. You may use the tools and improve them. But if you give an improved tool to others, you must pass on the same rights. AGPL adds one more step: letting others use your changed tool over the web can count too.

What It Does Not Mean

AGPL doesn't ban business use. That's a common mix-up. You can use it at work. You can host it yourself. You can charge for services around it. The limit is about source sharing, not about money.

It also doesn't mean you must post every file you own. Your data is still your data. Your passwords are still your passwords. Unrelated tools that only sit near the software aren't the focus. The focus is the covered software itself, and your changes to it.

First check: Ask if you changed the code, and if people outside your team will use that changed version. Those two facts drive most of the duty.

So read the next parts with Maya in mind. Her internal test is one case. Her client login is a very different case. Same tool, same license, different trigger.

How the Network Rule Closes the Hosted Gap

Think of open source code as a shared recipe book. Anyone may read it. Anyone may cook from it. Anyone may improve a recipe. With ordinary GPL, the sharing duty starts when you hand the book to someone else. Give away your changed book, and you must share your changed recipes too.

But a restaurant creates a gap. The chef changes a recipe. The chef cooks for guests. The guests eat the food. They never get the book. On the web, that's a hosted app. Users get screens and answers. They never get the server code.

The GPL Gap

Under plain GPL, merely running software on a server is generally not conveyance, as the Free Software Foundation explains in its guide to AGPLv3 basics. Conveyance means handing a copy to someone. Running code for your own users isn't the same act. So a team could change GPL code, host it, and keep the changes private.

That gap mattered more as software moved to the web. Fewer people got downloads. More people got logins. The old trigger, handing out copies, stopped matching real use.

The AGPL Trigger

AGPL adds Section 13 to fix that gap. It covers a changed program that works over a network. Look for two signs:

• It takes user requests. A person clicks, sends a form, or calls the service from afar.
• It sends responses back. The user gets a page, a result, or app data in return.
• You changed the program. Your server runs your modified version, not just the plain upstream one.

When those signs line up, remote users must be offered the complete corresponding source code for the version they're using. Not the old version. Not part of it. The source that matches what's live.

We state the same plain rule for Loupe. It's licensed under AGPL-3.0-or-later, and if you run a modified version as a network service, the licence requires you to make your source available to its users. That's Section 13 in daily life.

No download does not mean no duty. A web login can be the trigger by itself.

So don't ask only, "Did we ship a copy?" Ask this too. "Do outside users use our changed version over the network?" If the answer is yes, plan for the source offer from day one.

Your Duties When Self-Hosting a Modified Version

Running a changed version for others brings clear duties. None of them are hard, but you must do them on purpose. Teams often fail by forgetting, not by refusing. A small checklist fixes that.

Step by Step Duties

1. Keep the license and notices. Leave the copyright notes in place. Ship the full AGPL text with the software. Don't strip out names or license notes when you clean files.

2. Mark your changes. Note what you changed. Note when you changed it. A short log in your repo works. Future readers should see what's yours and what came from upstream.

3. Save the exact source. Keep the same code that runs in prod. Include your local patches. Include build scripts and build settings. A link to the clean upstream repo isn't enough if your live copy differs.

4. Give users a durable source link. Put it in the app footer, the about page, or your docs. Make it easy to find. Make sure it stays up while users use the service.

Check Your Stack Too

Compliance isn't only about your own files. It's also about the parts you combine. The Catrobat guide on AGPLv3 duties puts it well. Keep a software bill of materials. List each dependency. Note if it's linked, bundled, or just called through a separate API. Get legal help for grey cases.

Our own code shows this habit. Some of the code that runs Loupe was written with AI coding tools, all of it is reviewed by a human before it ships, and all of it is public. Public code makes every check above much easier.

A Quick Self-Check

• License text: Is it in the repo and in the shipped copy?
• Notices: Did all copyright notes survive your edits?
• Source offer: Can a user reach the exact live source in one or two clicks?
• Change log: Can a reader spot your edits fast?
• Deploy record: Do you know which code version runs today?

If you run an unmodified copy with no outside users, the network duty is much lighter. To see how teams weigh this kind of setup, read our guide to choosing self-hosted project management for your team. The steps above are for the harder case, a changed copy that others use.

Real Team Scenarios Under AGPL

Rules feel clear in the abstract. Real setups can feel messy. These three cases cover common questions. Find the one that looks most like you.

Case One: Internal Use Only

A firm runs an unmodified AGPL tool on its own network. Only staff use it. No clients get logins. No partners get access.

This is the lightest case. There's no handover of copies. There's no changed version offered to others. The team should still keep the license and notices in place. It should also write down who can reach the tool. If a client login ever gets added, the case changes at once.

Private items stay private here. Staff data stays put. Internal notes stay put. Nothing forces the firm to post its own content.

Case Two: Customers Get a Web Login

A startup modifies an AGPL app. It adds branding and two new features. It hosts the app and sells logins to customers. No one downloads anything. It all runs in the browser.

This is the classic AGPL trigger. The GNU FAQ on GPL and network use is clear that running a modified AGPL app as a web service can trigger the source-offer rule, even with no downloads. Customers must be able to get the source for the live version, at no charge, by a standard copy method.

What can the startup keep private? Its customer data, its billing records, and its server secrets. What can't it hide? The source for the changed covered app it's offering. If plans call for closed features, AGPL fits poorly here. The team should know that before launch, not after.

Case Three: AGPL Code Inside Your Own App

A team wants to link an AGPL library into its own product. Now the hard question is the boundary. How tight is the link? Is the AGPL part a separate service with its own API? Or is it woven into one combined program?

Don't guess here. Map the parts first. Sketch how data crosses between them. Then get legal review for the boundary. The safer design often keeps AGPL code as a clearly separate piece. Even then, a lawyer should check your exact setup. Small design choices can shift the answer.

Comparing AGPL with MIT and GPL

The three licenses share one base idea. You may use the code. The split shows up in one place: what happens to your changes.

MIT works like a lending library with no return slip. The GPL-3.0 license text shows the contrast. MIT permits use, modification, and sale, asking mainly that you keep copyright and permission notices in place. You may keep your changed version closed. That's why vendors often pick MIT code for products they won't open.

GPL adds one condition. Hand someone a changed copy and the source duty starts. The trigger is the handover itself. Hosting that same changed copy on your own server can fall outside it, because no copy ever reaches the users.

AGPL keeps GPL's rule and adds Section 13. The duty now follows the network users, not the download. Run a modified version where outside users reach it and those users get a source offer. That is the exact trigger that decides whether AGPL applies to your team: other people, over a network, touching your changed code.

How MIT, GPL, and AGPL Handle Your Changes

What AGPL Looks Like in a Real Project

Loupe is open source under AGPL-3.0. If you run a modified version as a network service, the licence requires you to make your source available to its users. You can read the code before you commit, and Loupe is free to host yourself with Docker Compose.

The license itself never asks why you picked it. It only asks what you do with the code. Check your setup against the trigger, and the comparison answers itself.

Deciding Whether AGPL Fits Your Team

You now know the trigger and the duties. The last step is a clear choice. Be honest about your plans for the code.

A Good Fit

AGPL fits well if you can say yes to most of these points:

• Shared gains: You're fine with users seeing your changes to the covered code.
• Simple stack: The AGPL part is a whole tool, not a library deep in a closed product.
• Clear records: Your team can keep source, notices, and change logs tidy from day one.

A Poor Fit

Think hard if these sound like you:

• Closed edge: Your business edge sits in secret changes to this same code.
• Tight embedding: You must weave the code into a product that has to stay closed.
• No review time: The boundary is grey, and no one can check it before launch.

A poor fit doesn't make the license bad. It means the license wants one thing and your plan wants another. It's cheaper to spot that now.

One Practical Next Step

Read the license text once, in full. It's long, but you only need the flow. Then run a small test on your own server. Loupe is open source and free to host yourself, and Loupe has a self-hosting guide. So you can test the full setup at no cost. Try it with fake data first. Check your source link. Check your notices. Then decide, with proof in hand.

---

If you want a workflow platform you can read, host, and change on open terms, try Loupe. It coordinates coding agents across design, build, and review, with human sign-off at each key step. Start with the self-hosting guide, run a small test, and see if the AGPL fit works for your team.