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.
