SSPL is MongoDB's rewrite of the AGPL. Offer the software as a service and its section 13 asks for the source of your whole service stack.
On this page
What it does
The Server Side Public License is MongoDB's 2018 rewrite of the AGPL. It keeps the AGPL body and replaces section 13 with a far wider one. If you offer the functionality of the software as a service to third parties, you must release the source of everything you used to make that service available, under the SSPL. That reaches management software, monitoring, backup, orchestration and the APIs around it. The OSI has not approved the license and the submission was withdrawn from review in 2019, so source available is the accurate label rather than open source.
Details
The line that decides your case is whether the SSPL software is the service you sell, or a database sitting behind a product you sell. Offering a hosted MongoDB is the exact scenario the license was written to stop. Running MongoDB under your own application is the arguable case, and arguable is not the same as settled. Check the version boundary too: Elasticsearch and Kibana moved to SSPL at 7.11 and Redis at 7.4, and both later added an AGPL option, so the answer depends on the version in your lockfile.
Pros
- Stops the SaaS loophole: you cannot take the code, run it as a service, and never share your changes.
- Makes the network trigger explicit, so a hosted product has a yes-or-no question instead of a distribution debate.
Cons
- A SaaS product that includes this code may have to offer corresponding source of the service, not only of a downloadable binary.
- Procurement and investors treat this family as high scrutiny. Expect extra review before you publish a page that lists it.
What it allows and requires
Choose a category to see the full grant in one scannable list. Permissions show what the license allows, limits show what it withholds, and obligations show the conditions your release process must satisfy.
Permissions
Commercial use
You may ship the code inside a paid product. The license does not restrict commercial use.
Modify
You may change the code, including keeping those changes private, unless a later obligation says otherwise.
Distribute
You may give copies to others. Distribution is what usually turns notice and source duties into real work.
Private use
Use inside your company, including internal forks, does not by itself trigger distribution duties.
Limits
Hold liable
The authors disclaim warranty. Recipients cannot hold them liable for damages arising from the software, except where law forbids that disclaimer.
Use trademark
The license is not a trademark license. Names, logos and product marks stay with their owners unless a separate grant says otherwise.
Open your product
Copyleft can reach a combined work you distribute, not only the original files. How far that reaches in your stack is a counsel question.
Obligations
Include copyright
Keep copyright notices on distributed copies.
Include license
Give recipients a copy of the license with the program.
Disclose source
When you distribute a binary of a covered work, corresponding source has to be offered in the way the license describes.
Same license
The combined work you distribute has to stay under this license. You cannot close the covered work with a more restrictive grant.
Hosted service
SSPL's service clause reaches the software you use to offer the program as a service, not only the program itself. Many buyers treat it as source-available, not OSI-approved open source.
What SSPL-1.0 requires when you ship
For SSPL-1.0, offering the software as a hosted service can trigger the same source duty that handing someone a binary would. Confirm what you run, not only what you ship as a file. Network copyleft is written for that gap. The steps below are the shipping and hosting work, in the order a reviewer usually walks them.
You are outside section 13 while the software runs for your own purposes and you offer nobody its functionality as a service.
You meet section 13 when the source of every program you use to offer that service, management, monitoring, backup and orchestration included, is public under the SSPL.
You meet the ordinary copyleft terms when a binary you convey carries the complete corresponding source of the covered work under the same license.
You have done the whole review when you have also looked at the alternatives: Valkey replaced Redis and OpenSearch replaced Elasticsearch for many teams, both under OSI-approved licenses.
You have the version answer when the lockfile, and not the project's home page, tells you which license applies to the exact release you install.
The duties named in SSPL-1.0
Notice still travels with any copy. SSPL-1.0 also names a source duty that can fire when you offer the software as a hosted service. These are the conditions in the text.
Include copyright
Keep copyright notices on distributed copies.
Include license
Give recipients a copy of the license with the program.
Disclose source
When you distribute a binary of a covered work, corresponding source has to be offered in the way the license describes.
Same license
The combined work you distribute has to stay under this license. You cannot close the covered work with a more restrictive grant.
Hosted service
SSPL's service clause reaches the software you use to offer the program as a service, not only the program itself. Many buyers treat it as source-available, not OSI-approved open source.
Things to be aware of
- Calling SSPL open source because the code is on GitHub. The OSI has not approved it and Debian and Fedora reject it, which is why buyers ask about it by name.
- Assuming an SSPL database behind your own hosted product is settled. It is the arguable case, not the clear one, and section 13 was drafted to be read widely.
- Upgrading through a relicensing boundary without noticing. A minor version bump moved Elasticsearch and Redis off their old licenses, and a lockfile will not warn you.
- Filing SSPL next to AGPL and reusing the same analysis. AGPL section 13 asks for the modified program; SSPL section 13 asks for the whole stack you run it with.
What the Server Side Public License 1.0 does not do
Search results often flatten Server Side Public License 1.0 into a slogan. These are the usual misreads. SSPL-1.0 is a grant with conditions, not a permission to skip the paperwork below.
- SSPL is not OSI-approved open source. Offering the software as a service can require you to release the management stack, not only the SSPL program.
- It is not AGPL. The service clause is broader than AGPL's network copyleft.
How SSPL-1.0 differs from nearby licenses
These licenses are often confused with SSPL-1.0, but their release duties differ. Each row summarizes what the license requires when you ship. Open the linked page for the full checklist.
- SSPL-1.0
- SSPL is MongoDB's rewrite of the AGPL. Offer the software as a service and its section 13 asks for the source of your whole service stack.
- AGPL-3.0-only
- AGPL is GPLv3 plus section 13: if you let users reach your modified version over a network, they can ask you for its source.
- Elastic-2.0
- Source available with three prohibitions: no offering it as a managed service, no defeating the license keys, no removing notices.
Common questions about Server Side Public License 1.0
Answers to common questions about what Server Side Public License 1.0 requires, when its duties apply, and what evidence belongs with a release.
What is the Server Side Public License 1.0?
The Server Side Public License is MongoDB's 2018 rewrite of the AGPL. It keeps the AGPL body and replaces section 13 with a far wider one. If you offer the functionality of the software as a service to third parties, you must release the source of everything you used to make that service available, under the SSPL. That reaches management software, monitoring, backup, orchestration and the APIs around it. The OSI has not approved the license and the submission was withdrawn from review in 2019, so source available is the accurate label rather than open source.
What does SSPL-1.0 require when you ship a product?
You are outside section 13 while the software runs for your own purposes and you offer nobody its functionality as a service. You meet section 13 when the source of every program you use to offer that service, management, monitoring, backup and orchestration included, is public under the SSPL. You meet the ordinary copyleft terms when a binary you convey carries the complete corresponding source of the covered work under the same license. You have done the whole review when you have also looked at the alternatives: Valkey replaced Redis and OpenSearch replaced Elasticsearch for many teams, both under OSI-approved licenses. You have the version answer when the lockfile, and not the project's home page, tells you which license applies to the exact release you install.
Does running SSPL-1.0 as a hosted service trigger the source duty?
Yes. For SSPL-1.0, offering the software as a hosted service can trigger the same source duty that distribution would. That is the point of this family.
What is corresponding source for SSPL-1.0?
Corresponding source is the source a recipient needs to build and run the same binary, including scripts and interface files the license names. Hosting a repository URL can be an offer. The offer has to match what you actually shipped. SourceTrust records that a person on your team confirmed the offer. It does not publish your source and does not host a mirror.
How is SSPL-1.0 different from GNU AGPL v3.0?
SSPL-1.0 asks this: SSPL is MongoDB's rewrite of the AGPL. Offer the software as a service and its section 13 asks for the source of your whole service stack. GNU AGPL v3.0 asks this: AGPL is GPLv3 plus section 13: if you let users reach your modified version over a network, they can ask you for its source. Open the GNU AGPL v3.0 page for what that license requires when you ship. Do not treat the SPDX ids as interchangeable because the short names look similar.
Where do I record SSPL-1.0 for a buyer?
The catalog marks SSPL-1.0 as a license that network use does not clear, so a network review item appears on the project checklist for SaaS and Mixed projects. A source offer item is added when the project also ships binaries. SSPL is a templated license as well: the published text carries fill-in fields, so the fetcher never lands it on confirmed. It shows as SSPL-1.0 with package-specific parameters and waits for you to read the actual wording. The component page also shows a critical compatibility warning when an SSPL component sits in a project whose context is SaaS or Mixed.
Where do I record SSPL-1.0 for a buyer?
The catalog marks SSPL-1.0 as a license that network use does not clear, so a network review item appears on the project checklist for SaaS and Mixed projects. A source offer item is added when the project also ships binaries.
SSPL is a templated license as well: the published text carries fill-in fields, so the fetcher never lands it on confirmed. It shows as SSPL-1.0 with package-specific parameters and waits for you to read the actual wording.
The component page also shows a critical compatibility warning when an SSPL component sits in a project whose context is SaaS or Mixed. Read /docs/auto-fetch-license for how the fetch works.
- When a package declares an OR expression such as SSPL-1.0 OR Elastic-2.0, SourceTrust holds the component until a reviewer elects the one arm your product will live under.
- Confirming the network review stores your team's attestation on the component. It is not a check that your service stack sits outside section 13.
See also
The hub is the pillar for this cluster. Sibling licenses are the other spokes. Product FAQ links explain how SourceTrust records the duty, not the license text itself.
Practical guidance for procurement review, not legal advice. Confirm high-stakes use with counsel.