RELICENSING

The competitive restrictions in the SSPL.

The competitive restrictions in the SSPL are the heart of the license and the source of most confusion about it. This article explains the service condition plainly, says who it targets, and shows where an enterprise actually carries exposure rather than where it merely fears it.

The Server Side Public License reads like a copyleft license until you reach its central clause, and that clause is where the competitive restrictions in the SSPL live. The license was written to answer a specific commercial problem, not to govern your internal database. Understanding what it actually requires, and of whom, is the difference between a manageable position and a panicked migration. This article sets out the mechanics in plain terms.

What the SSPL service condition requires

The Server Side Public License starts from the GNU GPL family and adds a service condition. The core idea is this: if you offer the licensed software to third parties as a service, you must make available the source for the programs you use to provide that service. The license describes this broadly, reaching the management software, the orchestration, the monitoring, and the other code that makes the service work, all to be released under the same license. The obligation is deliberately wide, and its practical effect is to make offering the software as a commercial competing service impractical unless you also open everything around it or take a separate commercial license.

This is why the Server Side Public License is classed as source available rather than open source. The Open Source Initiative declined to approve it, on the view that the service condition discriminates against a field of use. The code is fully visible and broadly usable, but the freedom to use it for any purpose, the defining freedom of open source, is curtailed at exactly the point of competitive service. Source available is not open source, and the Server Side Public License is the clearest illustration of why the label matters.

Who the restriction is aimed at

The clause was not written with the ordinary enterprise in mind. It was written for the cloud provider. The pattern that prompted it was a large hosting company taking an open source database, offering it as a managed service at scale, capturing most of the revenue, and contributing little back. The service condition closes that gap by making the managed service model carry an obligation so broad that a provider must either open its whole stack or pay for a commercial license. The target is the competitor, not the customer.

That framing is useful because it tells an enterprise where to look. If your organization runs the software to support its own products and operations, you are probably not the party the clause was designed to catch. If some part of your business offers the software, or something built directly on it, to external parties as a service, you are closer to the line and the question becomes real. The distinction between using the software and offering it as a service is the one to examine first.

Where enterprises actually carry exposure

Most enterprise exposure under the Server Side Public License is not about deliberately reselling a database. It is about edge cases that look like internal use but function like a service. Offering an internal platform to separate legal entities, exposing a data service to partners, or building a customer facing feature directly on the licensed software can all move you toward the service condition. None of these is automatically a breach, but each is a fact pattern that deserves a deliberate look rather than an assumption.

The version trap

A second source of exposure is time. A project that adopted the Server Side Public License did so at a specific version. Older releases may remain under the prior open source license, and newer releases carry the new terms. An enterprise that upgrades without noticing the change inherits the service condition silently. Recording the exact version and license state of each deployment, and treating an upgrade as a license decision, prevents the quiet crossing of that line.

Which products carry these terms

MongoDB moved to the Server Side Public License in 2018, the first major project to do so. Elasticsearch and Kibana moved from Apache 2.0 to the Server Side Public License and the Elastic License in 2021, which prompted the AWS led fork OpenSearch. Redis moved to a model that includes the Server Side Public License as of March 2024, which prompted the fork Valkey. If your estate includes any of these, the relevant question is which version you run and how you deploy it. For the wider pattern, see why source available is not open source and the relicensing pillar.

What to do about it

Treat the Server Side Public License as a question, not a verdict. Identify every deployment of an affected product, record its version and license state, and describe honestly how each one is used and who can reach it. Where a deployment looks like a service, put the specific clause and the specific facts to your own counsel, because interpretation of the service condition is a legal question, not a risk advisory one. Where continued use under the license is uncomfortable, the options are the same as for any source available change: migrate to a community fork such as Valkey or OpenSearch, remove the dependency, or negotiate a commercial license. The companion OpenSearch fork story and the open source relicensing FAQ go further.

COMMON QUESTIONS

Questions buyers ask.

CONTAINMENT

Know where the SSPL service condition reaches you.

A confidential relicensing exposure review. Independent, buyer side, paid only by you.

Not ready to talk? Read the free open source license risk guides first.