The Server Side Public License Explained

The Server Side Public License was written to close a gap that copyleft licenses had left open. Traditional copyleft assumed that distributing software was the moment obligations attached. Cloud changed that. A provider could take a copyleft program, run it as a hosted service, never distribute a copy, and never trigger the share back requirement. The Server Side Public License responds to that by making the act of offering the software as a service the trigger, and by extending what must be shared well beyond the program itself.

What the Server Side Public License requires

At its core the Server Side Public License behaves like a strong copyleft license. If you modify and distribute the covered program, you must make your modifications available under the same terms. The distinctive clause is the service condition. If you offer the functionality of the covered program to third parties as a service, the license asks you to release the source of the programs you use to make that service available. The reach extends to the management and orchestration layer around the program, not only the program you started with. That is a far wider obligation than most teams expect, and it is the part that turns a quiet dependency into a real decision.

The practical effect is that the license sorts users by deployment pattern rather than by industry. An organization that runs the software for its own internal purposes faces a very different question from one that wraps the software in a product and sells access to it. The service condition is the dividing line, and where your usage falls on that line is the single most important fact about your exposure.

Source available is not open source

The Server Side Public License lets you read and modify the code, which makes it feel open. It is not open source in the recognized sense. The Open Source Initiative has not approved it, precisely because the service condition restricts a freedom that the open source definition protects. This distinction matters because inventories and policies written years ago often classify these components as open source by habit. A component logged as permissive or open that now sits under the Server Side Public License is a mislabeled risk, and the label itself becomes part of the exposure. The broader distinction is set out in permissive versus copyleft versus source available explained.

How the SSPL compares to the GNU AGPL

The closest familiar reference point is the GNU AGPL, which also reaches network use. The difference is scope. The GNU AGPL asks you to share the source of the covered program and your modifications when you make it available over a network. The Server Side Public License asks for more from those who offer the software as a service: the source of the broader stack used to provide the service. The GNU AGPL is an approved open source license. The Server Side Public License is not. For a buyer, the lesson is that experience managing AGPL components does not transfer cleanly, because the Server Side Public License sets a wider boundary and a different trigger.

Which projects moved to the Server Side Public License

MongoDB introduced 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 as of 2021, which prompted the AWS led OpenSearch fork. Redis moved to a dual model that includes the Server Side Public License as of March 2024, which prompted the Valkey fork, and later added an open license option for some users. Each event applied to software many enterprises were already running, so the exposure was created on the relicensing date rather than on the day anyone noticed. The database specific detail is covered on the MongoDB SSPL original relicense explainer, and the fork dynamics in the OpenTofu and Valkey fork story.

The Server Side Public License is one of two families driving the current wave, the other being the Business Source License. The two create different obligations and different cures, and a complete picture treats them separately. The full landscape sits on the relicensing pillar, and the cloud and hosting angle that the service condition turns on is covered in relicensing and cloud and managed service use.

What a buyer should do about Server Side Public License exposure

The first step is factual: find where the covered components sit in your estate, direct and transitive, and confirm whether your deployment pattern crosses the service condition. From there the options are familiar: stay on a pre change version where viable, move to a fork such as OpenSearch or Valkey, negotiate a commercial license, or remove the dependency. Each carries a cost to cure, and the right path is the cheapest defensible one for your situation. A relicensing exposure review maps exactly this and sizes each path.

We are independent and buyer side. We take no vendor fees and resell no software, so our read of your Server Side Public License exposure reflects your risk and nothing else. This is commercial and licensing risk advisory, not legal advice. For interpretation of the Server Side Public License and your compliance position, engage your own counsel.