[metheus]

Disclosure: I work for MongoDB. If you look at these two threads you'll find my comments in them, addressing similar concerns to those raised in this one.

https://news.ycombinator.com/item?id=18229452 https://news.ycombinator.com/item?id=18229013

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.

[kstrauser]

> The FAQ we put out here makes that clear

...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?

[metheus]

Absolutely I understand. And you taking the time to articulate the issues is generous, and I appreciate that as well.

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.?

[kstrauser]

I disagree with your reasoning on much of that. That said, thank you for the detailed reply! I appreciate the extra context.

[codemaverick123]

These things need to be made clear in the license and not in a discussion thread. Otherwise there is too much uncertainity 1. Applicability of this licence - "value derives primarly from MongoDB..."is too vague to be just accepted as is. 2. The extent to which the code is to made open source. There needs to be clear definition of what needs to be included and what doesnt. Who is going to decide what is enough? Otherwise you can leave the thread of lawsuit hanging and it is not good for the ecosystem

[ballenf]

Does MongoDB also release their stack or are they exempt from the disclosure requirement?

Apologies if this has been asked a million times -- didn't see it in a skim of your linked discussions nor the FAQ.

[codemaverick123]

At this point they are exempt which speaks to the double standard. MongoDB makes copious use of open source components. E.g. They use PostGres for their reporting solution and make money off it. What do they contribute back to the PostGres community for this?

[metheus]

No apologies required! If we see this question come up a lot we can add it to 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:

https://www.mongodb.com/blog/post/mongodb-now-released-under...

[rand0mthought]

That takes some level of hypocrisy - you are not making your Atlas as opensource, but you require others to do so. This clearly indicates that you are using an opensource license as an extortion schema against competitors.

[nemo44x]

It absolutely does not make them hypocritical. They own the copyright and can do as they choose. They simply don't want other companies getting rich on their back by simply offering a MongoDB SaaS. Why is it OK for AWS to just take a project and start making millions off of it while the people who invested in the project get nothing? AWS and similar cloud companies are simply trying to strip mine all the value from some popular open source projects and contribute nothing back. Most of these cloud companies show zero interest in partnering with the copyright owners so now we're seeing copyright owners take a stand against this exploitation.

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.

[merb]

that's sketchy and means you are violating your own license.

and since there is no dual licensing or anything that says that the mongodb inc does not do what the license says...

[nemo44x]

They aren't violating anything. They own the copyright. The license exists for everyone else that isn't MongoDB Inc. They can do as they please and this isn't sketchy or in violation of everything. Open source software still has copyright and the owner of the copyright has no limitations to what they can do with the software they own. Open source software comes with a license which limits what everyone else can do with the software.