What this license is
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.
Why it matters for your product
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.
You are meeting the terms when
- 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.
Where teams get it wrong
- 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.
How SourceTrust handles this license
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 Auto-fetch license text 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.
Related guides
- Distribution and network-use review
- GPL vs AGPL (two different triggers)
- GNU AGPL v3.0
- Elastic License 2.0