AGPL License Debate for OSS Companies in 2026

TL;DR

The GNU Affero General Public License is a legal and governance choice, not a business result. AGPLv3 section 13 addresses a modified version that supports remote network interaction and requires an opportunity for those remote users to receive the corresponding source under the license's conditions. The exact result is fact-specific: code relationships, modifications, conveyance, network use, product boundaries, and applicable law matter. This guide is not legal advice. Review the exact license text and obtain qualified counsel for a real product or deployment.

Key Takeaways

Start with the canonical AGPLv3 text. Secondary summaries are not a substitute for the license.
GNU's explanation connects AGPL to modified programs run on servers, but the source-offer mechanism is a license condition, not an outcome guarantee.
Do not reduce AGPL analysis to a short trigger test. The exact code relationship needs fact-specific analysis.
Repository labels and release records must be checked by project, path, edition, and revision.
Compare AGPL, permissive, weak-copyleft, strong-copyleft, and source-available options against the project's exact goals with qualified counsel.

At-a-glance decision table

Question	Evidence to collect	Why it matters
Which exact code is licensed?	Canonical license file, repository, path, edition, and revision	A top-level label may not describe every directory or product surface
Has the program been modified?	Patch set, build inputs, vendored code, generated artifacts, and deployment revision	AGPLv3 section 13 refers to a modified version
Who interacts with it remotely?	Architecture, user roles, network paths, and deployment model	Remote network interaction is part of the section 13 analysis
What source is offered and how?	Source-offer interface, corresponding-source scope, and operational procedure	Compliance depends on the exact licensed condition and implementation
How is other code related?	Process, linking, libraries, APIs, distribution, and service architecture	The result cannot be inferred from the word “integration” alone
Are commercial terms involved?	Exact vendor terms and access date	Dual-licensing and commercial terms are project-specific

Evidence cards

The canonical license condition

AGPLv3 section 13 says that when a modified version supports interaction with users remotely through a computer network, the program must offer those users an opportunity to receive the corresponding source under the license's conditions. Read the complete license text for definitions, scope, and related obligations; this summary is not a replacement.

GNU's server-use rationale

GNU's AGPL explanation describes the license as addressing modified programs run on servers. That rationale helps explain the network provision, but it does not decide a particular architecture. Application-specific analysis still depends on the actual code, modifications, users, deployment, and law.

OSI record

The Open Source Initiative lists GNU AGPL version 3 as an approved license and links the license text. Approval identifies the license category; it does not answer a project's compliance, product-boundary, procurement, or commercial question.

Project records at the access date

Grafana repository metadata identified AGPL-3.0 at access time. Mattermost's repository metadata returned NOASSERTION, so its canonical license file must be reviewed by path and edition rather than copied into a general table.

The official APIs also reported Grafana v13.2.0, published 2026-08-18, and Mattermost v11.10.0, published 2026-08-04. Both records were non-draft and non-prerelease. The key boundary is that release status is not license history and does not explain when, why, or how a project's licensing changed.

What AGPL does and does not establish

It establishes a license condition

The canonical text provides a source-offer mechanism for the covered network-interaction scenario. That is the relevant legal evidence. It should be implemented and reviewed as a license requirement where it applies.

It does not establish a hosting outcome

A license condition does not prove that a cloud provider will or will not host a program. It also does not prove contribution, community value, project survival, revenue, support, or lower user cost. Those are separate outcomes requiring separate evidence.

It does not settle code relationships by label

An API, library, plugin, executable, service, or embedded component can create different technical and legal facts. Do not state a categorical result from the interface name alone. Record the exact code relationship, modifications, distribution or conveyance facts, remote users, and license boundaries, then consult qualified counsel.

Comparing licensing approaches

AGPL, permissive licenses such as MIT and Apache-2.0, other copyleft licenses, and source-available terms answer different legal and governance questions. The useful comparison is project-specific:

Decision area	Questions for the project
Collaboration	Which changes should be shared, with whom, and through what mechanism?
Distribution and service model	How will software be conveyed, deployed, modified, and accessed?
Ecosystem compatibility	Which dependencies, plugins, clients, and integrations are required?
Commercial model	Are there separate editions, services, trademarks, or commercial terms?
Contributor governance	Who accepts contributions, controls relicensing, and maintains notices?
User obligations	What must adopters understand and operate in their exact use case?

Treat this as a project-specific licensing decision. Read each candidate license in full, document the intended architecture and governance, and obtain legal review for the jurisdiction and product.

Project and edition boundary review

A repository can contain multiple notices or product surfaces. Use a project and edition boundary review before attaching a license label, and recheck exact repository identity whenever the revision or edition changes:

Identify the canonical repository, branch, revision, and release.
Read the top-level license and every path-specific notice relevant to the build.
Separate community, enterprise, hosted, mobile, plugin, and third-party directories.
Check contributor agreements, exceptions, trademarks, and commercial terms separately.
Trace the deployed artifact back to its source and dependency set.
Record the access date and repeat the review when the revision or product boundary changes.

This prevents a product table from carrying one license label across unrelated editions or directories.

Network-use review for a real deployment

A practical review should be architecture-specific:

draw the processes, libraries, data flows, and user-facing network paths;
identify every modification to the covered program;
record which users interact with which program component;
determine what corresponding source means for the reviewed build;
design and test the source-offer mechanism where required;
preserve notices and build materials needed by the license;
have qualified counsel review the facts and applicable law.

The terms “internal,” “external,” “API,” “embedding,” and “configuration” do not settle the analysis on their own.

Commercial and procurement questions

Pricing and dual-licensing are project-specific commercial terms. Do not infer that an AGPL project offers a separate license, who it targets, or what it costs. If commercial terms matter, obtain the exact vendor terms and access date, then compare their scope with the canonical open-source license and the intended deployment.

Procurement should keep separate records for:

open-source license obligations;
commercial license or subscription terms;
hosted-service terms;
support commitments;
data processing and security requirements;
trademark and redistribution rules.

A commercial contract may address some operational concerns without changing the facts of another product or edition.

Methodology

The analysis uses the canonical GNU AGPLv3 text, GNU's AGPL rationale and remote-interaction FAQ, the OSI AGPL record, canonical project repositories and license files, and official release APIs accessed on 2026-08-24. Repository and release records are point-in-time evidence.

Treat project examples and release records only as dated repository context, not license-adoption evidence. Volatile repository counters are omitted because they are not decision-critical. Do not infer legal assurances, adoption trends, or business outcomes from project records. Recheck exact repository and license boundaries before using a project example.

FAQ

Does AGPLv3 apply whenever software is reachable over a network?

The canonical section 13 language concerns a modified version that supports remote network interaction and a corresponding-source offer. A real conclusion is fact-specific and requires the full license, architecture, code relationship, and legal analysis.