I actually find MongoDB's SSPL license quite hard to understand, especially when thinking about what might constitute „offering MongoDB as a service“.

While I do understand that the primary intention is to prevent Amazon etc. from offering the MongoDB product as part of their cloud service without disclosing the source code AND without paying for it, the terms of the license could very well have an impact in other scenarios as well. Maybe someone who understands could explain in which cases the source code of which modules would have to be made public under the terms of the SSPL:

a) We create a classic web application, e.g. a web shop that is used by human users through a web page. This shop application uses MongoDB as it’s main database, meaning that all product orders etc. are stored in a MongoDB database.

b) We add a machine callable web service to that shop from a), so that for example mobile applications or other modules can consume the shop API and place orders, make transactions etc.

c) We offer MongoDB as a direct 1:1 service called „SuperDB“ :-) with an API identical to MongoDB. Then the shop from a) or b) uses „MySuperDB“.

d) We create a „MMORPG Game Server Framework“, where multiplayer game objects (i.e. „Entities“) are managed by our server. Within that framework we allow our clients to upload code to customize the behavior of these server managed entities. Our Clients code is run on our server. It does not access MongoDB’s API directly, but through our „Entity-API“. All entities are persisted / processed with MongoDB. Game clients (e.g. browser apps) make use of our service via web API calls.

e) like d), but now the Game Entity Framework uses „MySuperDB“

It would greatly help us to understand in which cases and WHY source code would have to be made public according to the terms of the SSPL.

1 Answer 1


The lack of clarity around the SSPL's definition of a “service” is part of the reason why this isn't a good license. The SSPL does provide a definition, but it might have a surprising scope. Below, I first recap some discussion on this definition, and then try to apply the SSPL's definition to your scenarios.

During the OSI license-review process of the SPPL, MongoDB's then-CTO Eliot Horowitz explained the definition of “service” as follows:

The definition of “making the functionality of the Program . . . available to third parties as a service” that we included in the second sentence of Section 13 is meant to describe the concept of offering the Program as a service in three ways:

  • From a technical perspective: “enabling third parties to interact with the functionality of [MongoDB] remotely through a computer network”;
  • From a value-based perspective: “offering a service the value of which entirely or primarily derives from the value of [MongoDB]”; and
  • From a functional perspective: “offering a service that accomplishes for users the primary purpose of [MongoDB].”

Replacements and elisions are part of the original. Note that the SSPL combines these three tests with an “or”, not an “and”.

Earlier, he wrote:

In this context, “making the functionality of the Program … available to third parties as a service” includes running the software on behalf of someone else where they are the one using the software.

Although you correctly observe that the word “service” can have various meanings, referring to software as a service is very common today and well understood.

So in the opinion of Horowitz, this definition of “service” is more about providing a service to a third party, less about running the software as a service/microservice in the technical sense.

Some such as Lawrence Rosen have argued that this definition of “making available” is unclear: the “value” of a service cannot be calculated, and what a program “accomplishes for users” is subjective and addled by marketing. “You have created, at least in part, an unenforceable FOSS license with a nicer definition than AGPL of "program as a service" that still doesn't help much. :-)”

We can try to apply the SSPL's criteria to your scenarios.

a) A web application that uses a SSPL-covered database is not making the functionality of that program available as a service. This webshop does not enable third parties to interact with the database, does not derive its value primarily from the database (but from being a webshop), and does not provide the purpose of the covered program (the webshop doesn't act like a database).

b) Adding an API doesn't change this. The API allows third parties to interact with the webshop, not to use the webshop API as a database.

c) Offering the SSPL-covered program as a service under a different name would meet the SSPL's definition of a service. You would enable third parties to interact with the functionality of the covered program. This service would derive its value almost entirely from the covered program. And the service accomplishes the primary purpose of the covered program, being a database.

However, if the offered service is actually a completely unrelated software that merely offers the same API as an SSPL-covered database for interoperability purposes, that might be perfectly fine. For example, AWS DocumentDB is such an interoperable database. This database could only fall under the SSPL if it was a derivative work of the SSPL code. Many jurisdictions value interoperability and provide explicit legal protections or supportive case law, e.g. Oracle v Google in the US.

d) An API is added to allow persistence of objects, this persistence is backed by a SSPL-covered database. This is a scenario where I find the SSPL quite difficult. Public communications by MongoDB indicate that they wouldn't think this falls under the SSPL's concept of a service. However, I find that difficult to reconcile with the actual license text, which can be reasonably interpreted to consider that to be the offering of a service. In particular, the persistence API effectively allows interaction with the SSPL-covered database through a thin translation layer, and achieves the primary purposes of a database. While this particular API might not derive its value primarily from the database, that is not the only factor.

e) Just renaming a backend service won't change anything, the same arguments as in c) and d) apply.

  • So, one could say, that the "thinner" (Web Shop would be THICK, Entity Service would be THIN) and the more "databaseish" the provided service is, the higher the risk of triggering article 13, correct? And of course that it would have to be tried in court (which does not yet seem to have happened)
    – Andi
    Commented Apr 15, 2021 at 10:06
  • BTW @amon: thank you for your superb explanation of the matter!
    – Andi
    Commented Apr 16, 2021 at 8:29
  • 1
    @Andi Yes, I think “databaseishness” would be a large factor. “Thickness” wouldn't be a direct factor, but a thinner wrapper is more likely to derive its value primarily from the SSPL database. And yes, any enforcement action relation to SSPL section 13 would likely have to involve a court because the definition of “service” is somewhat subjective, see also the remark by Rosen. The license is pretty new so there's no case law, but I don't think section 13 would ever be invoked – I think this lack of clarity is deliberate and meant to scare MongoDB users into buying a commercial license.
    – amon
    Commented Apr 16, 2021 at 10:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.