To reiterate those comments, the SSPL only affects people who are offering the licensed software to the public as a service. This does not include any software that uses MongoDB as a component, even if it's a commercial SaaS offering itself. The FAQ we put out here makes that clear: https://www.mongodb.com/licensing/server-side-public-license.... 99.999% of MongoDB users are not affected by this license change.
People have expressed concerns that the 1) the FAQ is not the license, and 2) the language of the license does not make the intended responsibility clear enough. But it was drafted with that intention (and reviewed by outside counsel, with an eye towards being explicit without giving bad actors loopholes to exploit). Nonetheless, addressing those concerns is extremely important to us. This exact issue is being discussed on the OSI license approval mailing list, and we are considering very seriously all of the feedback.
The article anchoring this thread contains a lengthy discussion of copyright misuse and of impracticability. Those are also the subjects of discussion on the OSI mailing list, where Heather Meeker, writing on MongoDB's behalf, refutes claims that are similar to those made in the article. In particular, the SSPL is not trying to make people release substrate infrastructure, or adjacent tooling, under the SSPL. Consider the last line of section 13: "...all such that a user could run an instance of the service using the Service Source Code you make available." This means that as long as the Service Source Code you release is enough for anyone to run the service, you've fulfilled your obligation. As an example, you would not have to somehow be able to offer CircleCI under the SSPL (an impossibility), as long as your tooling that orchestrates its use is public, because anyone can use CircleCI.
It's our hope that these discussions will lead to an accepted understanding of the actual obligations of the SSPL. The only people we want to be in any way affected by it are those who are literally offering the licensed software as a service, and we want those people to release their management stack under the SSPL. Thanks for helping us with that.
...while the license itself absolutely does not. I can read the GPL and tell what's expected of me, but I have no idea how to interpret clauses like:
> Making the functionality of the Program or modified version available to third parties as a service includes, without limitation, enabling third parties to interact with the functionality of the Program or modified version remotely through a computer network,
Explicitly calls out allowing users to access MongoDB.
> offering a service the value of which entirely or primarily derives from the value of the Program or modified version,
Explicitly calls out interacting with MongoDB. My company's website is basically a wrapper around accepting a query from a user, converting that into the appropriate NoSQL query, reformatting the result, and presenting it to the users. Since our web server is more or less an abstraction layer from the underlying database, it sounds like our whole website would be subject to the new terms.
> or offering a service that accomplishes for users the primary purpose of the Software or modified version.
Does not explicitly mention MongoDB, except by contrast implying that if we offer a service - even one not MongoDB-based - that accomplishes the primary purpose of MongoDB or a fork of it, then we're subject to the new terms.
FAQ be damned, it's the license itself that's clear as mud.
> The only people we want to be in any way affected by it are those who are literally offering the licensed software as a service, and we want those people to release their management stack under the SSPL.
Engineer to engineer, do you understand why so many of us find this uniquely onerous?
I make no claim that the SSPL is as easy to understand as the GPL. It's not. IMO the GPL's domain is such that it's easier for it to capture its intention succinctly. Do you link your software to this library? No? You're in the clear. You do? Then your software has to be released under the GPL.
The SSPL wants one thing: for people who make software available as a service to release their service stack under the SSPL. The problem is that defining "as a service" too narrowly makes it easy to circumvent. Imagine you used a really narrow definition, something along the lines of "running and managing an unmodified version of the software on behalf of someone.” It would be easy to add a single junk feature and get out of that obligation.
Every ambiguity you cite in the license is precisely crafted to thread that needle. Lawyers can certainly debate whether it was done so effectively, but the way I see it, we are looking at competing design goals: 1) embody the above licensing requirements, and 2) be easily comprehensible to laypeople. In a perfect world, these goals would not be in competition, but as we designed the SSPL, it was clear that they are.
The language you cite in your concern here is a good example of that:
>> or offering a service that accomplishes for users the primary purpose of the Software or modified version.
>Does not explicitly mention MongoDB, except by contrast implying that if we offer a service - even one not MongoDB-based - that accomplishes the primary purpose of MongoDB or a fork of it, then we're subject to the new terms.
At first glance, that last phrase "or offering a service that accomplishes for users the primary purpose of the Program or modified version" is an astounding overreach; it seemingly attempts to obligate you to release completely unrelated software under the SSPL just because it provides the licensed software's behavior. But the mere fact of a license's existence cannot obligate you to its terms; you have to use the licensed software. So it follows that the clause only affects you if your "unrelated" software is used to provide the same functionality as the licensed software that you are using in the service. I.e. you wrap the software in a clean-room implementation of a connecting driver and then build an external proxy that offers an identical API to the wrapped software but uses none of its code.
I hope that example at least makes clear that the language used in the SSPL doesn't introduce ambiguity for its own sake, or as a means to drive users to commercial licenses, it is a byproduct of the need to counter real-world means of circumventing its requirements.
>> offering a service the value of which entirely or primarily derives from the value of the Program or modified version,
>Explicitly calls out interacting with MongoDB. My company's website is basically a wrapper around accepting a query from a user, converting that into the appropriate NoSQL query, reformatting the result, and presenting it to the users. Since our web server is more or less an abstraction layer from the underlying database, it sounds like our whole website would be subject to the new terms.
Looking at the example of your company's website, I would say with complete certainty that it is not affected. You are not making that database's functionality available to anyone, and no matter how thin the functional layers are that you put on top of it, the value you provide doesn't derive primarily from the value the database provides.
Now, without implying that the SSPL is so perfectly crafted that it needs no refinement, I'd like to present this thought experiment:
If the area that the SSPL seeks to cover inherently means that its language has to be less straightforward, but if also it is shown to be legally sound and confined to the territory we claim it to be, then is it a worthy endeavor to pursue? If so, what constitutes "shown to be legally sound" etc.?
Apologies if this has been asked a million times -- didn't see it in a skim of your linked discussions nor the FAQ.
MongoDB does not release the stack for Atlas, our SaaS. That's possible because we own the copyright to the source code -- we don't have to issue the software to ourselves.
The blog post we published announcing the change covers this, as well as our motivations and expectations in a lot of detail:
There's a big difference between a piece of free software being vital to your codebase and you simply selling that free software as-a-service.
and since there is no dual licensing or anything that says that the mongodb inc does not do what the license says...