MongoDB's Server Side Public License Is Likely Unenforceable

Yeah, I&#x27;m not necessarily opposed to the general spirit of what they&#x27;re trying to do here, but this license just doesn&#x27;t make sense in practice. Now that I&#x27;ve had more time to look at it, I&#x27;d really recommend that everybody stay the f%!# away from MongoDB.<p>This bit in particular really hits the nail on the head:<p><i>Let&#x27;s assume that it is ok somehow to pass forward other open source software, solving that problem. What about my continuous integration software (e.g. CircleCI), or my business backup software (e.g. Jungle Disk) or my code hosting service (e.g. Github)? There is no logical bound to this license. Taken on its face, I would theoretically be bound to release the internal source code of services from third parties that I included in or relied upon to deliver my service.</i><p>Copyleft is one thing, but this is so invasive and byzantine that it beggars belief that anybody actually thought this license made sense.

Only a data point here -- after I read about this license change on HN, it took me about 2 hours to struggle over the issue, discuss with my team, and switch from MongoDB to PostgreSql. We are very lucky in that we were into this project for only two months, prototyping and learning the ropes with MongoDB schema. With PostgreSql now, everyone feels secure in a familiar territory. Yes, we have to make changes and its not rocket science to move over.<p>The issue is not about having to buy a license here. The problem is the uncertainty with a product whose license agreement is being switched over mid-stream. It makes me weary of what else might happen with their license structure further down the road.

Absolutely. This license change takes it completely out of the contention for anything I would have previously considered it for. Can you imagine if Nginx said you had to release any software you run behind it as FOSS?

Remind me of that one time when they went berserk on every tooling vendor using the name « Mongo » in their product name :<p>RoboMongo,MongoGUI etc... they all received a legal notice to remove the name mongo from their product.<p>This was probably one of the most evil thing have seen in the open source industry .<p>Most of those vendors were open source with paid premium features or donation.<p>After receiving their legal notice most of those vendors deprecated or sold their project to a company feeling betrayed by Mongo.<p>As a result Mongo Compass became the de facto GUI for MongoDB and is advertise as sold with MongoDB Enterprise.

For people defending this, you&#x27;re being naive. It&#x27;s way too easy to argue that the value of any app resides mostly in the data it collects. That data is stored in MongoDB, therefore the value of the app &quot;primarily derives from the Program.&quot;<p>Of course their sales people are saying &quot;No. We won&#x27;t use it that way.&quot; Sales people gonna sell.<p>I&#x27;m sure the people currently running MongoDB would not do that. What happens when they get acquired by, say, Oracle? Or some other company that absolutely would do that?<p>The bottom line that you have to assume from a legal point of view is that any part of an agreement that can be abused, will be abused. This not only can be and will be, but it will be really easy.<p>If they are doing this to prevent people from competing with their own service--which they absolutely are--then they need to rewrite it and make that explicit. This is way too squishy for anyone with an ounce of brains to use in a commercial product.

MongoDB of course has right to change their license to anything they want. One day they might decide to go proprietary with no notice too...<p>According to our poll many users will seek alternatives for MongoDB because of the license change<p><a href="https:&#x2F;&#x2F;www.percona.com&#x2F;blog&#x2F;2018&#x2F;10&#x2F;24&#x2F;poll-mongodb-license-change&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.percona.com&#x2F;blog&#x2F;2018&#x2F;10&#x2F;24&#x2F;poll-mongodb-license...</a><p>MongoDB probably feels they have reached critical mass so it does not matter any more...

Okay so after reading the article, and thinking about this for a while, I get the following out of this debacle:<p>The issue here is that SaaS providers are building tools on top of MongoDB that effectively add functionality, instead of modifying MongoDB (which would force them to share those changes publicly).<p>This is a valid concern and I understand the motivation behind the license change. However, how is this different from any other FOSS?<p>Just as a random example, think of a proprietary blog&#x2F;site provider like Tumblr and Weebly. They are effectively a SaaS provider that introduces tools on top of open-source web servers (like nginx or apache) to make hosting a website much easier. Instead of building the entire model&#x2F;code of your website, you simply add customizations using a frontend.<p>Maybe the comparison is not ideal, but my understanding is that all FOSS suffers from this concern, and the industry seems to be doing well enough.

I can understand the sentiment and realize the need to monetize, it&#x27;s hard when others take your code and make more money out of it then you (which I am assuming is the case).<p>But even if they are right, this doesn&#x27;t seem smart, it feels like a knee jerk reaction. I imagine that they hope that by doing this they&#x27;ll cause people who are using mongo on other providers to move to mongolabs, since there is 0 chance of these providers open sourcing their infra.<p>But that&#x27;s not whats going to happen, either cloud providers will remain with old versions and people will gradually move to different dbs or they&#x27;ll just fork it, they certainly have the manpower for it, this will give them incentive.<p>Frankly though I think this is well within the agpl, cloud providers aren&#x27;t modifying the code they are building things around it.

As a non-lawyer who&#x27;s tried to understand copyright law, this analysis confuses me; my understanding was that in the realm of source code &quot;by default&quot; you only have rights to use that source code through a license or contract, so it seems odd that any restriction on the terms would be misuse or detrimental to competition, when the option always exists to not use MongoDB.<p>This isn&#x27;t me trying to argue against the article; I&#x27;m trying to understand the law as it applies to my profession.

Huh. So, the rush to release and announce the license before OSI vetted it, was in fact VERY VERY intentional. Not some poorly planned &quot;rush the news out&quot; mismanagement.<p>And the recent stink on HN where OSI claimed MongoDB was not Open Source because the license had not yet been reviewed, with many claiming (correctly) that OSI is not the determiner of what is open source, appears to have been out of order.<p>I think there was a base assumption that the license would in fact be fine, and OSI claiming it wasn&#x27;t because they hadn&#x27;t stamped it ... yet ... was overreaching.<p>Anyway my understanding is that the single largest user (and commercial licensee) of MongoDB hates it and can&#x27;t wait to get away from it. With that in mind, this licensing nonsense smells like a desperate grab. Maybe it&#x27;s time to short $MDB?

I honestly don&#x27;t see how this can pass OSI or DFSG approval. It&#x27;s a blatant violation of rule 9, which prohibits restrictions on distribution of other software.

Isn&#x27;t it just so that the Mongo&#x27;s SSPL is a natural extension of AGPL, modified to make it cover things that wouldn&#x27;t otherwise be considered a derived work (which is exactly what FSFs interpretation of GPL does for more typical, &#x27;single-host&#x27; situations), and inheriting the AGPL&#x27;s problems?

Why does the article think MongoDB is located in the jurisdiction of the 9th Circuit? I mean sure they operate nationally in some senses, but their HQ is in NYC (2nd Circuit). And if they&#x27;re incorporated in Delaware as most funded tech startups are, that isn&#x27;t 9th Circuit either.<p>Am I missing something or is the author? Also, what stance has the 2nd Circuit taken on copyright misuse, if any?

I&#x27;d be interested in seeing a license that better accomplishes the goals cited as motivation for moving to this license, that would hopefully also avoid the flaws mentioned in this article and throughout the comments.<p>Is there an example of such a license?<p>Could this type of license even be created in an enforceable way?

MongoDB doesn&#x27;t deserve all the credit (or blame) for what they&#x27;ve created. The client libraries are true open source projects, and a lot of the good parts of the design have probably come from them. I think they&#x27;ve also accepted a lot of contributions to mongod without compensation, and had the copyright assigned to them. Having the copyright assigned to them is reasonable, but it facilitates them closing an open source project that&#x27;s received many community contributions, which is unethical IMHO.

Just thinking. Can you make a fork of MongoDb before license change and keep merging upstream changes under former license? Not asking because I want to hurt Mongo, just curious.

Why isn&#x27;t a straightforward solution to the &quot;impracticability&quot; problem just a &quot;to the extent possible&quot; or &quot;authorized&quot;-type predicate?

Sincere question: who is actually using MongoDB these days?

Interesting that none of the clouds even offer hosted mongodb in the first place, and from everything I know there were 0 plans for any of them to start. They all have their own proprietary databases to promote instead. Meanwhile MongoDB Atlas seems to be doing well so the entire impetus for this license change seems rather unwarranted.

I think both this discussion, as well as last year&#x27;s Facebook&#x2F;React Patent License brouwhaha (and Redis, more recently) would all be far better if people assumed good faith, and tried to actually get at the core of the problem.<p>It&#x27;s clear that there&#x27;s a gap in existing licences that some regard as unfair. It also seems plausible that many projects could have dramatically better resources if the companies they are attached to could find a way to capture a fraction of their product&#x27;s worth to their largest users. Just offering service with their competitive advantage being only the result of name recognition seems to work only for a very select group of huge projects. And even there, the likes of Canonical or SUSE show how hard it is.<p>Yet it is obviously challenging to write a license that adequately captures these facts. I think everyone would have something to gain from finding a way to make these situations work.<p>A required part of that solution may be for the community to interpret licenses not with the current they-are-trying-to-screw-us mindset but with, say, the &quot;reasonable person&quot; standard often used by the courts in contract&#x2F;license disputes.<p>That&#x27;s not going to be easy, considering &quot;expect the worst and don&#x27;t risk anything&quot; always looks like sound advice, given that you will never know what you missed on the path not taken.<p>But the GPL&#x27;s success should be inspiring here: it was initially met with scepticism, especially among corporate lawyers. Their essential pessimism never changed (it&#x27;s how they became corporate lawyers in the firs place). But as it happened, it was enough for just few to take the risk, and subsequently creating precedents in court affirming the GPL, that made the concept cross the chasm to being palatable even to initial sceptics. Once courts fill in the questions of interpretation currently clouding these (necessarily somewhat abstract) licence, some doubts may dissipate.

Startup idea: A MongoDB as a Service company with the entire hosting&#x2F;management platform written from scratch in Befunge or Brainfuck...<p>(VCs please form an orderly queue. Priority given to investors willing to pay in Bitcoin or Monero. Contact deets in profile...)

Use Postgres, problem solved.

Cloud computing is becoming the dominant model, and the current combination of OSS licenses and public cloud players&#x2F;incentives make it nearly impossible for OSS companies to monetize in the cloud. While there are no perfect answers, we either need to come up with new licenses (difficult) or pursue a new approach to cloud (decentralization) that supports OSS monetization.

So has there been a startup yet that forked mongodb&#x27;s pre-license change form? Get cracking, VC folks.

It&#x27;s hilarious to me that out of all the problems <i>with the way MongoDB works</i> it&#x27;s the license, of all things, that gets a strong reaction from the HN crowd that says, &quot;I&#x27;m never using that!&quot;

Apple&#x27;s SDK has an EULA that says it cannot be deployed on a server and made available as a service. Why can&#x27;t mongo just create a license that says such a deployment requires a commercial license from them?

Arguing that the license is invalid as a defense in court seems to be a risky legal strategy.<p>‘Your honour, my argument is that I was copying this copyrighted software, for profit, without any legal license to do so. Oh wait...’

Disclosure: I work for MongoDB. If you look at these two threads you&#x27;ll find my comments in them, addressing similar concerns to those raised in this one.<p><a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=18229452" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=18229452</a> <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=18229013" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=18229013</a><p>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&#x27;s a commercial SaaS offering itself. The FAQ we put out here makes that clear: <a href="https:&#x2F;&#x2F;www.mongodb.com&#x2F;licensing&#x2F;server-side-public-license&#x2F;faq" rel="nofollow">https:&#x2F;&#x2F;www.mongodb.com&#x2F;licensing&#x2F;server-side-public-license...</a>. 99.999% of MongoDB users are not affected by this license change.<p>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 <i>was</i> 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.<p>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&#x27;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: &quot;...all such that a user could run an instance of the service using the Service Source Code you make available.&quot; This means that as long as the Service Source Code you release is enough for anyone to run the service, you&#x27;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.<p>It&#x27;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.

Intellectual &quot;property&quot; is cancerous repression. It&#x27;s time for copyright to die.

I don&#x27;t understand the line of reasoning. Can anyone give me a lay explanation?<p>My understanding of the license change is basically &quot;if you use MongoDB to support any site, all software higher in the stack needs to be released as well&quot;.<p>Is that accurate?<p>If so, why can&#x27;t an author make this part of the license?

Doesn&#x27;t Unifi use this?

Is this similar to the GPL3 in intent to force website backends to become open source?

&gt; accused infringer would then, quite rightly, plead impracticability<p>I’m not a lawyer, but I wouldn’t expect that to be a valid defense. If you can’t comply, don’t use it.

I never understood all the hate mongo gets. Like any tool, if people simply took the time to understand it and use it correctly, maybe they wouldn&#x27;t run into issues.