AGPL-3.0-only vs SSPL-1.0
One is open source with a network clause; the other is not open source at all.
Can you use them, and where?
They differ in 5 of the 5 ways you can ship software.
- Hosted SaaS: AGPL-3.0-only is obligation triggered, SSPL-1.0 is needs review. AGPL-3.0-only section 13 requires that users interacting with a modified version over a network be offered the corresponding source of the whole work. Your distribution model is hosted SaaS, which triggers that obligation. This is the clause that makes AGPL behave differently from GPL for hosted services.
- Distributed binary: AGPL-3.0-only is obligation triggered, SSPL-1.0 is needs review. AGPL-3.0-only carries the GPL-3.0 copyleft terms it is built on: distributing a work that incorporates it requires licensing the whole work under the same terms with corresponding source made available. Your distribution model is distributed binary or application, which is distribution and triggers that obligation. Section 13 additionally extends this over a network, so hosting the same code would not avoid it.
- On-premises delivery: AGPL-3.0-only is obligation triggered, SSPL-1.0 is needs review. AGPL-3.0-only carries the GPL-3.0 copyleft terms it is built on: distributing a work that incorporates it requires licensing the whole work under the same terms with corresponding source made available. Your distribution model is software delivered to a customer environment, which is distribution and triggers that obligation. Section 13 additionally extends this over a network, so hosting the same code would not avoid it.
- Internal use only: AGPL-3.0-only is no obligation, SSPL-1.0 is needs review. SSPL-1.0 is not an OSI-approved open source license. Licenses in this family commonly restrict offering the software as a commercial or competing service. The specific terms need individual review.
- Published library: AGPL-3.0-only is obligation triggered, SSPL-1.0 is needs review. AGPL-3.0-only carries the GPL-3.0 copyleft terms it is built on: distributing a work that incorporates it requires licensing the whole work under the same terms with corresponding source made available. Your distribution model is a published library, which is distribution and triggers that obligation. Section 13 additionally extends this over a network, so hosting the same code would not avoid it.
Side by side
Runtime dependency, dynamically linked. A build-time-only dependency reaches no user and carries no distribution obligation, whichever license it uses.
| How you ship | AGPL-3.0-only | SSPL-1.0 | |
|---|
| Hosted SaaS |
Obligation triggered |
Needs review |
They differ here |
| Distributed binary |
Obligation triggered |
Needs review |
They differ here |
| On-premises delivery |
Obligation triggered |
Needs review |
They differ here |
| Internal use only |
No obligation |
Needs review |
They differ here |
| Published library |
Obligation triggered |
Needs review |
They differ here |
AGPL-3.0-only
The one that catches SaaS companies. Section 13 extends copyleft across the network: if users interact with a modified version remotely, they must be offered the corresponding source of the whole work. The GPL "hosted service is not distribution" reasoning does not apply here.
Full obligations for AGPL-3.0-only
SSPL-1.0
Not OSI-approved. Created by MongoDB to close the perceived AGPL loophole: offering the software as a service obliges you to release the entire service stack used to run it. In practice this makes commercial hosting untenable for most companies.
Full obligations for SSPL-1.0
LicenseGuard reports information derived from published license texts and dependency manifests.
It is not legal advice and using it does not create an attorney-client relationship.
Results reflect license metadata as declared; they do not identify every obligation or violation.
Consult qualified counsel for decisions that matter.
Listed in the
official MCP registry,
on Glama
and on Smithery.
Source on GitHub (Apache-2.0).