MongoDB SSPL and service providers.

The MongoDB SSPL and service providers relationship is where the Server Side Public License does its heaviest work. MongoDB moved to the Server Side Public License in 2018, becoming the first major project to adopt it, and the license was written with a specific target in mind: the service provider who takes the software, hosts it, and offers its functionality to others. For an enterprise that simply runs MongoDB behind its own applications, the license is usually a quiet presence. For an organization whose product is a hosted service built on MongoDB, it is a central commercial fact that shapes the whole offering.

This article sets out what the license asks of service providers and how to think about containment. The same license now appears across the database landscape, including in the Redis dual model, which we cover in the Redis license change and what RSALv2 and SSPL mean. The pillar on Redis, Elastic, and database license risk is the hub.

What the Server Side Public License asks

The Server Side Public License builds on a strong copyleft foundation and extends it to the service case. The key idea is that if you make the functionality of the licensed software available to third parties as a service, the obligation reaches beyond the software itself to the programs you use to offer that service. In broad terms, the license asks the service provider to release the source of those surrounding service programs under the same terms. That sweep is intentional. It is meant to make the service provider case unattractive unless the provider either contributes the surrounding source or holds a commercial license instead. The license is source available, not OSI approved open source, and that classification is part of why it sits outside the usual open source comfort zone.

The exact boundary of what counts as offering the functionality as a service, and what programs fall inside the release obligation, is the hard interpretive question. It is genuinely contestable at the edges, and it is precisely the kind of question that belongs with your own counsel rather than with a vendor or a forum thread.

Who is actually a service provider here

The label service provider is narrower than many teams fear. Running MongoDB internally to store data for your own applications is not the targeted case, even though that data ultimately serves your customers. The license is concerned with offering the database functionality itself as a service, the way a managed database platform does. The clearest examples are organizations that host MongoDB for others to use as a database. The harder cases are products that expose database functionality more directly, where a customer is effectively given access to the data store rather than to an application built on top of it.

For most enterprises, then, MongoDB sits in the permitted internal lane, and the Server Side Public License is something to understand rather than to act on. The minority that operate hosted services, or whose products blur into offering the database itself, are the ones who need to look closely. The same internal versus service distinction governs the Redis case, which we work through in is your Redis use affected by the license change.

Containing the exposure

If your service does sit inside the Server Side Public License obligation, the practical options come down to a small set. The most common is a commercial license from MongoDB, which removes the copyleft obligation and lets you operate the service without releasing surrounding source. The second is re architecting the offering so the database functionality is not what you are providing as a service, which can be feasible where the database is an implementation detail rather than the product. The third is moving to an alternative data store under terms that fit your model, which is a larger undertaking but sometimes the cleaner long term answer. Each option carries cost, timeline, and engineering trade offs, and the right choice depends on how central the hosted database functionality is to the value you sell.

Whatever the path, it starts from the same place: a clear map of where MongoDB sits in your service, which versions you run, and exactly how the database functionality is exposed to customers. The wider set of relicensed data stores that raise the same questions is covered in time series and analytics database relicensing risk.

What buyers should take away

The MongoDB SSPL and service providers picture is less alarming than its reputation for most organizations and genuinely consequential for a few. The license is built to make the service provider case pay, through either contributed source or a commercial agreement, while leaving ordinary internal use largely untouched. The work for a buyer is to determine honestly which category the use falls into, to involve counsel on the interpretive question rather than assuming, and to size the containment options against the value of the service before any vendor conversation begins. This article is commercial and licensing risk advisory, not legal advice. For interpretation of the Server Side Public License and whether your service triggers its obligations, your own counsel is the right place to turn.