MongoDB SSPL: The Original Relicense Explained

When buyers ask where the relicensing wave began, the honest answer is MongoDB. The HashiCorp and Redis changes of 2023 and 2024 drew the most enterprise attention, but the pattern they followed was set in 2018. MongoDB looked at a familiar problem, that cloud providers were offering its database as a managed service without contributing back, and responded by writing a new license to address it. That license, the Server Side Public License, became the instrument that Elastic and Redis later reached for. The MongoDB case is the root of the family tree.

What changed in 2018

MongoDB moved its database server from an open source license to the Server Side Public License in 2018. The earlier license placed conditions on distributing the software. The Server Side Public License extended that idea to the act of offering the software as a service. Under it, a party that provides the functionality of the program to third parties as a service takes on a far reaching obligation to release the source of the surrounding service software under the same terms. That condition is the heart of the license and the reason the Open Source Initiative did not approve it. Source available is not the same as open source, and the Server Side Public License is a source available license, not an open source one.

The target was clear. MongoDB wanted to prevent large cloud platforms from building a competing managed database on its work without either contributing back or taking a commercial license. The mechanism was a service condition severe enough that a provider would not want to trigger it, which in practice pushed those providers toward a commercial arrangement or toward a different product entirely.

Why the MongoDB SSPL set the template

The shape of the MongoDB move repeated almost exactly in the years that followed. As of 2021, Elastic moved Elasticsearch and Kibana from Apache 2.0 to the Server Side Public License and the Elastic License, citing the same cloud provider concern, and the AWS led OpenSearch fork followed. As of March 2024, Redis moved to a dual model that included the Server Side Public License, and the Valkey fork followed. Each time, the same license, the same stated motivation, and the same outcome: a community fork to preserve an open option, and a commercial path for those who wanted vendor support. MongoDB wrote the script. The later cases performed it.

This matters for buyers because the MongoDB case lets you reason about the others by analogy. Once you understand how the service condition works, the Elastic and Redis moves are recognizable rather than novel. The mechanics of the license itself are set out in the Server Side Public License explained, and the broader pattern across the wave sits on the Redis, Elastic and databases pillar.

Who the MongoDB SSPL actually reaches

The most common worry is misplaced. The Server Side Public License is aimed at the party that offers the database as a service to others, not at the enterprise running it for its own applications. An organization that uses MongoDB to power its internal systems and customer facing products is using the software the way most enterprises use any database. It is not offering MongoDB itself as a service to third parties, which is the act the license condition targets. The distinction between using a database and offering it as a service is the line that decides exposure.

Where that line sits can blur. A company that builds a platform on top of MongoDB and lets its customers run their own queries, or that exposes database functionality directly as a feature, may sit closer to the service case than it first assumed. The relevant question is whether you are providing the functionality of the database itself to third parties as a service, and that is a question for your own counsel applied to your specific architecture. The general distinction is the same one that runs through the whole wave, examined in commercial licensing for Redis Enterprise for a parallel case.

What buyers should do about a MongoDB footprint

The first step is the same as for any relicensed component: know what you run and how you run it. Because the 2018 change is older than the rest of the wave, many MongoDB deployments have already passed through one or more decisions, whether deliberate or not. Some teams adopted MongoDB Atlas, the vendor managed service, and inherited commercial terms that way. Others stayed on a self managed server under the Server Side Public License without ever examining whether their use touches the service condition. A dependency map that records which MongoDB editions and versions run where, and under which terms, turns that uncertainty into a clear picture.

From there the choices mirror the rest of the database cases: stay on terms you accept, take a commercial license where the use warrants it, or weigh an alternative document database. Choosing between continuing to pay and moving off is its own decision, taken up in forking versus paying the database decision. Containing the exposure in a sequenced way, rather than reacting under pressure, is the work of an open source remediation advisory engagement.

We are independent and buyer side. We take no vendor fees and resell no software, so the map and the recommendation reflect your risk and nothing else. This is commercial and licensing risk advisory, not legal advice. For interpretation of the Server Side Public License against your MongoDB use, engage your own counsel.