AGPL License Explained — Plain English Guide (Network Copyleft & Cloud/SaaS Use)

The GNU Affero General Public License (AGPLv3) is the strongest copyleft license — it closes the “SaaS loophole” of the GNU GPL by requiring source code disclosure even when the software is accessed over a network, not just distributed. It’s the license that makes companies nervous, used by MongoDB (pre-2023), ownCloud, and Grafana’s library components.

What You’ll Learn

By the end of this guide, you’ll understand how AGPLv3 differs from GPL, what the “network copyleft” means for SaaS products, why many companies ban AGPL code entirely, and when you might want to use AGPL for your own projects.

Why It Matters

The AGPL is the most controversial open-source license. If you use AGPL code in your SaaS product and users interact with it over the network, you must provide them with your complete source code — including your modifications. This single clause has led MongoDB to switch licenses (to SSPL) and caused many companies to explicitly ban AGPL from their codebases. Understanding AGPL is critical for anyone building cloud services.

Real-World Use

Your SaaS platform uses an AGPL-licensed document database. Users upload documents through your web app, and the database processes them on the backend. Under AGPLv3, every user who interacts with the software over the network has the right to request and receive the complete source code — including your proprietary business logic that integrates with the database. This is why most SaaS companies run from AGPL like it’s on fire.

Quick Reference

What the AGPLv3 Actually Says

The AGPLv3 is built on GPLv3 with one critical addition. The GPLv3’s copyleft triggers only when you distribute copies. The AGPLv3 adds Section 13:

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…

Translation: If users can interact with your modified AGPL software over a network (including through a web interface or API), you must provide them with the complete corresponding source code.

AGPLv3 vs GPLv3: The Key Difference

The AGPL closes the “SaaS loophole” — the GPL’s blind spot where companies could use and modify GPL code in cloud services without sharing their changes.

Can I Use AGPL Code in Commercial Products?

Technically yes, but practically it’s very difficult. Here’s what AGPL allows and requires for commercial use:

You Can:

• Sell AGPL-licensed software
• Use AGPL code in internal tools
• Charge for support and services around AGPL software
• Modify AGPL code for personal or internal use

But If Users Interact With It Over a Network:

• You must offer them the complete source code
• Your modifications must be under AGPL
• Users can download, modify, and redeploy your modified version
• You must provide installation information for certain devices

The SaaS Problem

If your SaaS product:

• Runs AGPL code on the backend
• Users interact with it through a web browser or API
• You’ve modified the AGPL component in any way

Then you must provide your users with the complete source — including the glue code, integrations, and custom features you built around it. This is why AGPL is effectively banned at most SaaS companies.

Why Companies Avoid AGPL

The AGPL creates a business problem: how do you build a proprietary service on top of AGPL code if your users can demand the source?

Real Business Impact

• Salesforce banned AGPL from its infrastructure entirely
• Google classifies AGPL as a “restricted” license — requires special legal approval
• Amazon has policies against AGPL in internal tools
• MongoDB switched from AGPL to SSPL specifically because enterprises refused to use AGPL-licensed databases
• Grafana Labs licenses the core under AGPL but offers commercial licenses

The “AGPL Poison” Problem

AGPL code is often called “poison” in enterprise environments because:

1. It creates obligations that most companies’ standard processes can’t handle
2. Legal teams rarely approve it without months of review
3. It’s incompatible with most corporate open-source policies
4. Using it in one product can affect the entire codebase through copyleft

Real-World Projects Using AGPL

The SSPL Split

MongoDB’s move from AGPL to SSPL (Server Side Public License) in 2018 was a watershed moment. The SSPL is AGPL with an additional clause: if you offer the software as a service, you must also release all software used to provide that service — not just the MongoDB code itself, but the entire management, monitoring, and orchestration stack around it.

OSI (Open Source Initiative) has rejected SSPL as not an open-source license. The debate highlights how AGPL was already at the edge of what’s acceptable for commercial use, and SSPL went further.

Common Misconceptions

“AGPL means I can’t use the code at all in a commercial product”

Not true. You can use AGPL code internally, for personal projects, and even in commercial products if you’re willing to share your source code with users who interact with it over a network.

“AGPL applies to every SaaS component”

It applies to the AGPL-licensed code and its derivative works. A separate service running on another server that communicates via standard APIs is generally not affected. The copyleft follows the code, not the data center.

“AGPL makes you open-source your entire app”

Only the parts that constitute a derivative work of the AGPL code. If you modify the AGPL component, those modifications must be AGPL. Code running in a separate process communicating via HTTP/API is generally not affected.

“AGPL and GPL are basically the same”

Only for distributed software. For cloud/SaaS services, the difference is enormous. GPL requires nothing for network use; AGPL requires full source disclosure.

“No one uses AGPL — it’s too restrictive”

Many significant projects use AGPL. The license is alive and well for projects that specifically target the self-hosted market or use a dual-license business model (open-source AGPL + paid commercial license).

The AGPL Dual-License Model

Many AGPL projects use a dual-license strategy:

1. AGPLv3 — free, open-source version with copyleft obligations
2. Commercial license — paid version that allows proprietary use without AGPL obligations

This is the business model behind:

• Grafana (AGPL core, commercial license for OEM/embedding)
• MinIO (AGPL + commercial for closed-source)
• ScyllaDB (AGPL + enterprise license)
• MySQL (GPL + commercial — same model, different license)

If you want to use AGPL code in a proprietary SaaS product without source disclosure, you buy a commercial license from the project’s vendor.

When to Choose AGPL

Choose AGPL for your own projects when:

• You’re building infrastructure for the self-hosted market
• You want the strongest copyleft protection available
• You offer a dual-license (AGPL + commercial) business model
• You specifically want to prevent cloud providers from profiting from your code without contributing back
• You’re building developer tools where users expect source access anyway

Avoid AGPL when:

• You want your code used in corporate environments (choose MIT, Apache, or BSD)
• You’re building a library that needs broad adoption (choose MIT, Apache, or LGPL)
• You don’t want to deal with sales inquiries for commercial licenses
• Your target audience is SaaS companies

FAQ

Copyleft Spectrum

graph LR
    A[Permissive
MIT / BSD / Apache] --> B[Weak Copyleft
LGPL / MPL]
    B --> C[Strong Copyleft
GPLv3]
    C --> D[Network Copyleft
AGPLv3]
    style A fill:#90EE90
    style B fill:#FFD700
    style C fill:#FFA500
    style D fill:#FF6B6B

Practice Questions

1. Your company runs a modified AGPL database behind its SaaS API. Users upload data through your app, which the database processes. What must you do? Offer every user who interacts with the database (even indirectly through your app) the complete corresponding source code, including your modifications.

2. You use an AGPL library in a CLI tool you distribute as a binary. What are your obligations? Same as GPLv3: provide the complete source with the binary, include the license text, document changes. The network clause doesn’t apply here since it’s not a network-interactive service.

3. Your startup uses AGPL code internally for data analysis. No customers ever touch it. Do you need to release anything? No. Internal use, even for commercial purposes, has no source disclosure obligations under AGPL.

4. Can a company take your AGPL project, modify it, and sell it as a proprietary SaaS product without releasing source? No — unless they buy a commercial license from you. The AGPL’s network clause prevents closed-source SaaS use of modified AGPL code.

5. What’s the difference between saying “AGPL is banned” and “AGPL needs legal review” at a company? “Banned” means no AGPL code anywhere, period. “Needs legal review” means you can use it after the legal team approves the specific use case — usually for internal or non-network tools.

Mini Project: AGPL Compliance Analysis

1. Create a list of dependencies for a hypothetical SaaS product (pick real libraries)
2. Identify any AGPL dependencies using a license checker (e.g., license-checker for npm, cargo-license for Rust, pip-licenses for Python)
3. For each AGPL dependency, determine:
   • Is it used in a network-facing component?
   • Are modifications made to it?
   • Can it be replaced with a permissively-licensed alternative?
4. Write a brief compliance report with recommendations

Challenge: Find a project that dual-licenses under AGPL and a commercial license (e.g., Grafana, MinIO, or ScyllaDB). Read their licensing page. Calculate how much a commercial license costs for a small team vs an enterprise. Analyze whether the dual-license model is sustainable for the project.

Built by the developers of Doda Browser, DodaZIP, and Durga Antivirus Pro. This guide is for educational purposes and does not constitute legal advice. Consult an attorney for specific licensing questions.