Hacker News new | past | comments | ask | show | jobs | submit login
MongoDB's Server Side Public License Is Likely Unenforceable (processmechanics.com)
255 points by willlll on Oct 25, 2018 | hide | past | favorite | 239 comments



Yeah, I'm not necessarily opposed to the general spirit of what they're trying to do here, but this license just doesn't make sense in practice. Now that I've had more time to look at it, I'd really recommend that everybody stay the f%!# away from MongoDB.

This bit in particular really hits the nail on the head:

Let'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.

Copyleft is one thing, but this is so invasive and byzantine that it beggars belief that anybody actually thought this license made sense.


There are many arguments provided as justification for this new license - they seem specious in my opinion

1. Big cloud vendors are making money off MongoDB's investment Completely untrue. The big three - AWS, Azure and GCP dont have a MongoDB as a service solution. The only commercial entity making any real money off MongoDB is MongoDB, Inc. AGPL has achieved its purpose here. The only big cloud vendor with a solution is Rackspace and they release their modified MongoDB code.

2. Big cloud Vendors in China are breaking the law and they need this new license to control them If they are technically modifying the source code and not providing it back to the community then they are already breaking the law. You don't need a new license to control this problem

So what is this about? In my opinion it is an exercise in naked extortion and control

1. Clear out any ISV Vendors/As-a-service Competitors - Any commerical entity who does anything remotely interesting with MongoDB is in big trouble. I'm talking about Monitoring, backup, performance profiling, analytics, reporting etc..anything really. MongoDB could easily bring a reasonable claim against them that the value of their service is "primarily or mostly derived from MongoDB". Also its very unclear on what needs to be open sourced to be compatible. The license seems deliberately vaguely worded so that it is as broad as possible.

2. End users using MongoDB - While MongoDB claims this does not affect end users in any way I would be very wary of this claim. The license in authored in such a generic way that there are many possible interpretations. If MongoDB, Inc for some reason does a claim against you then your only defence is to buy a license or go into litigation. "Trust us, we will never do that" is not a good enough argument.

To summarize, be very wary of this. If you are a developer and dont think this affects you run this by your legal deparment or VC and see the alarm on their faces :)


Also, print out and have notarized a copy of their current FAQ. It's probably legally binding for promissory estoppel. If their interpretation of the license suddenly becomes much stricter, it may be handy to prove that they promised you explicitly in writing that they intended the looser meaning.


Isn't Rackspace the owner of ObjectRocket?


What law?


After spending some time reviewing this licencse the only conclusion I come to is that this license is malicious...let me explain

Let say you are a young startup building a cool SaaS solution. E.g. A data analytics solution. If you make heavy use of MongoDB it is very possible that down the line the good folks at MongoDB come calling since "the value of your SaaS derives primarily from MongoDB..." So at that point you have two options - buy a license from MongoDB or open source your work (which they can conveniently leverage at no cost).

Either way if you are SaaS solution doing anything data related I would not use MongoDB having read this license.


I think we're all on the same page about the shoddiness of being in the open source insurance business, but that is not what the SSPL is for, nor could it be used for that. We simply can't make the claim that any SaaS other than specifically MongoDB as a service derives primarily from MongoDB -- or rather, it it's possible to make the claim, but it's easier to defeat it.


The whole point of this discussion is that MongoDB, Inc could make that claim (as you agree)...and we as users of MongoDB will have to spend money fighting off that claim. You'd have to pretty naive to use software that has these terms.


Sorry, let me clarify. It's always possible to claim anything. I meant that the claim is too weak for the SSPL to create that threat.

It's obvious that several people disagree, but within this thread, conversing about this article, we should expect a bias to see things that way. I hope you'll stay open to being convinced otherwise. The SSPL has been submitted for review to the OSI, and this issue is one of the points of discussion that we're listening very closely to.


It’s great that you’re listening closely, but it seems to me that regardless of what OSI says, the consensus is that nobody in this thread will continue to use MongoDB under this new license.


the value of your SaaS derives primarily from MongoDB

If that were true they could switch to Postgres and become 200x as valuable overnight.


>Copyleft is one thing, but this is so invasive and byzantine that it beggars belief that anybody actually thought this license made sense.

It makes complete sense if its purpose is to be so onerous that no one can actually use it without a commercial license.


Yep. I don't understand why Mongo doesn't just come clean and say "We're discontinuing support for the free version." Maybe they're afraid it'll get forked?


> I’ve had more time to look at it, I'd really recommend that everybody stay the f%!# away from MongoDB.

That’s virtually the word-for-word conclusion that anyone who’s “has some time to look at mongoDB” has come to. It’s a steaming pile of feces, and this is no surprise. From day one, the mongo team has made it clear that they are a startup first (in the sense of “focus on wooing investors with buzzwords and making money”) and a software engineering firm last.


There is no need to stay away from MongoDB (well, not for licensing reasons anyhow). There is only a need to stay away from MongoDB(TM).

Because of its previous license, the code base can be forked as of immediately before the license change, and it can continue to be offered under the previous license.

I would recommend that anyone using MongoDB do that.


> I'm not necessarily opposed to the general spirit of what they're trying to do here

Can you elaborate on this?


Hmm ... Would this technically be the ultimate Stallman dream?


No. RMS has stated more than once that he is entirely ok with the "service provider loophole" in the GPL. They made the AGPL for those not ok with the loophole, but he never had any issue with it in the original GPL at all.


No, technically, Stallman is firmly rooted in copyright law. GPL says you take this software and make derived works, as copyright law says what they are, as long as you make derivative works available under the same terms as you received the original software.

GPL steers clear of non-derived work. If you use VMWare on Linux, VMWare is not a derived work as far as copyright law is concerned and there is no relation between them as far as GPL is concerned.

This SSPL, is another story.


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.

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.


I had actually started a new project two days before this drama started (my first MongoDB project in a couple of years) and made the same decision. This license is so bad I've lost faith in the company itself.


weary (tired) -> wary (concerned)

not nit-picking, just attempting to help other readers who aren't native English speakers


For those that don’t know, they are sometimes pronounced the exact same, which is why they are often mixed up (see also affect and effect). Where I’m from weary is pronounced WEER-y though.


Not true (at least in the US): weary (at least the adjective) is pronounced with a "we" at the beginning, while wary is pronounced with a "wear" at the beginning.


I hear "weary" spoken so very rarely that I have no idea how it's pronounced here (Indiana). I can't even make up my mind how I pronounce it, but I'd wager it's almost, but not quite, indistinguishable from wary.


Of course it varies with accent and locale. So phonetic transcriptions don't help unless we use IPA. But in British English, "weary" has a diphthong and "wary" does not. Very distinctly different words.

On the subject, we pronounce "router" and "router" (two different words, same spelling) differently, one with a diphthong, one without.


One is w-ee-ry the other w-ah-ry.


> w-ah-ry

I've always heard it pronounced way-ree.


Ware-ee?


Yes...ish. That's the correct pronunciation, but neither are used frequently enough for me to be confident that's the actual pronunciation, and I'd wager it's different in different places.


They're also sometimes spelled the same. Doesn't make it correct.


Thanks for saying it right. This will help me remember.


Mongo doesn’t need a questionable license to make Postgres a better choice.


Bullshit, every software and business decision has tradeoffs. To universally claim one decision is better in all cases is ridiculous.


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?


And then what? The owner of the code is entitled to license the software as they want it [1]. If you dislike the license, then use a different program or fork the last version before the license change.

I can fully understand the frustration of pro-copyleft developers and companies that want to use copyleft for a 'share or pay model'. Cloud computing makes existing licenses toothless by moving the software from the client to the server, thereby avoiding distribution. It can be argued that such use is not in the spirit of copyleft and is effectively a loophole from the perspective of copyleft licensing.

It is not surprising that people try to make new copyleft licenses that fill that loophole. This may not be the best formulation, but it is definitely much better than the Commons Clause nonsense that was hyped a couple of weeks ago (which makes software proprietary).

[1] Whether it is enforceable is another issue.


Of course they’re entitled, but I’m also entitled to say I think this move was either idiotic or malevolent.

I’m unsympathetic to the “oh no the cloud” mindset. I’ve worked at companies that have made on-premise patches to FOSS since the 90s. Can you imagine if Linux required you to make the source available of all software you ran on it? Or MySQL? Or Perl/PHP? I can vaguely see the point of the AGPL for things like web front end stuff where there’s a blurry line between you visitor merely visiting your site and you distributing the software to them. But that’s just madness for infrastructure code.

And I’ll bet that the MongoDB team has used lots of FOSS that they didn’t financially support, so I see it as whining when they complain about others doing the same.


You use their code for free and call them "idiotic or malevolent" when they make it harder for you to use their code for free. I can completely understand the frustration of their users if this move makes their life harder but it's still pretty entitled of you to insult them because they changed the license to something you don't like.

It's perfectly understandable if you decide not to use their software because you find their license unacceptable but don't insult them for doing what they want with their own project. If a sizeable enough number of contributors are unhappy with the move they're still free to fork and continue the previous version of Mongo DB with the old license.


There is a decent chance that they’re using code I’ve written, and I haven’t seen a penny from them. Have you? Has anyone?

I think it’s either:

- Idiotic, because they meant well but managed to shoot themselves in the foot by making their software unviable, or

- Malevolent, because they’re using this as a wedge to either force you into a pay-or-lose-it situation, while still trying to paint themselves as FOSS.


Because you don’t feel others are freeloading on you does not mean software consumers aren’t freeloading.

You’re free to change your licenses (or not), just as other projects are (but should).

It’s time the free ride and expectations of charity by for-profit users ends.


What is freeloading? MongoDB is building a project off the works of others and selling it. So am I. If you're employed, so are you. And in return, hopefully we all contribute back to that ecosystem so that the next person can build off our new work.

You say "freeloading". I say "participating in a rich culture of shared work". Maybe I don't contribute all my local work to Emacs upstream, but I push out a lot of Python stuff. Maybe you don't bother sharing all the Python tweaks you've made, but you're an active Vim contributor. Perhaps there's someone else that's a Vim "freeloader" but who cranks out a lot of kernel code that you and I both benefit from. I think that's a healthy, mutually-beneficial arrangement.


Try paying your rent and grocery bill with “participating in a rich culture of shared work”. It’s just as much of a joke as “pay you? It’ll give you exposure!” frequently expressed to creatives.

It’s clearly not mutually beneficial when one side is reaping outsized rewards (and not at all ashamed about it), and your example of small contributions to vim and python is disingenuous; we’re talking about entire software packages used without compensation by businesses (Redis, Elastic, Mongo to name a few).


Did Redis, Elastic, Mongo et al pay for Linux development, or glibc, or their text editors, or compilers, or ...? Why should they get the financial benefit from building on top of others' donated work - and claim to be an equal participant in the FOSS ecosystem - and then be peeved with others expect the same in return?

If Mongo were a closed, proprietary product who wanted to be paid, sure. I happily pay for Apple stuff, for instance. But saying "hey, come use our FOSS project!" and then pivoting to "...as long as you pay up!" is extremely disingenuous.


Situations change. What you get for free today, you are not guaranteed to get for free tomorrow, nor should you feel entitled to continue using a tool previously provided for free.

This is absolutely no different than commercial vendors who change pricing or licensing terms year to year (ie “we no longer offer an on prem version; SaaS only now; last year you paid $100k, this year our price is $200k”). You’ve just been anchored to an unusually low price previously.


You use their code for free and call them "idiotic or malevolent" when they make it harder for you to use their code for free.

MongoDB is little more than mmap() attached to a socket. They would be nowhere without piggybacking on a million lines of other people’s free code.


MongoDB uses WiredTiger storage engine currently. mmap storage engine is all but deprecated.


> The owner of the code is entitled to license the software as they want it [1]

> ...

> [1]Whether it is enforceable is another issue.

As per the article, apparently not. Copyright Misuse [1] will stop them setting terms beyond a certain scope. You could argue that that merely makes the licence unenforceable but by that definition the only thing worth talking about is enforceability, so that doesn't seem like a good definition as there are practical enforceability issues to separately consider

[1] https://en.wikipedia.org/wiki/Copyright_misuse


>> This license change takes it completely out of the contention for anything I would have previously considered it for.

> If you dislike the license, then use a different program

That's exactly what he said he would do, isn't it?


The SSPL does not create that obligation.


No, because it's even worse than that. "management software, user interfaces, application program interfaces, automation software, monitoring software, backup software, storage software and hosting software" encompasses everything behind the server, everything in front of the server, and basically everything beside the server.


See my main thread post addressing this misconception. The SSPL's obligation to release those components only applies in the case that the user is offering the licensed software itself as a service.


Even if it wasn’t intended to do that, the sheer amount of uncertainty this creates is untenable for many projects.


Remind me of that one time when they went berserk on every tooling vendor using the name « Mongo » in their product name :

RoboMongo,MongoGUI etc... they all received a legal notice to remove the name mongo from their product.

This was probably one of the most evil thing have seen in the open source industry .

Most of those vendors were open source with paid premium features or donation.

After receiving their legal notice most of those vendors deprecated or sold their project to a company feeling betrayed by Mongo.

As a result Mongo Compass became the de facto GUI for MongoDB and is advertise as sold with MongoDB Enterprise.


I have absolutely no problem with trademarks as long as they're used as consumer protection.

For example, there's the whole uBlock vs uBlock Origin thing, where uBlock Origin is the good one run by the original maintainer, and uBlock is run by people who had nothing to do with the original project.

https://en.wikipedia.org/wiki/UBlock_Origin

Trademarks can be used offensively, and few cases were more offensive than the Linux trademark dispute back in the 1990s, when William R. Della Croce, Jr., someone with nothing to do with the Linux kernel or anything else of value, acquired the trademark to "Linux" in September 1995 and began to demand royalties from the people who did useful things with their time. It took a court case to dislodge him.

https://en.wikipedia.org/wiki/Linux_Mark_Institute

https://www.linuxjournal.com/article/2559

What Mongo did was meaningfully better than what Della Croce did, and closer to the spirit of "prevent people from confusing products and thinking stuff is from the original development team when it isn't", but I can see how it would be an unpleasant shock in the Open Source world which, sadly, usually doesn't know or do a damned thing about trademarks until some asshole forces the issue.


It often seems like trademark lawyers must be fairly dim, as a lot of things confuse them that don't confuse anybody else.


That's a rather unnecessary ad hominem.

What you should consider in your rage against trademarks is that they protect something far weaker than copyrights and patents. Trademarks are fundamentally exchangeable identifiers. They do not hold any value beyond what they are infused with due to their attachment to some company (person/organisation/...). Unlike patents, which cordon off the part of scientific reality from most, or copyright, which fundamentally relies on deadweight losses to make its mechanism work, trademarks are almost exclusively positive: there is nothing you gain from calling your product "Mongo-X" apart from the meaning the term carries based on the company creating the product.

(This slightly glosses over some practicalities, such as some terms having meaning before being adopted as a trademark, or the possible depletion of combinations of letters that can be pronounced. But those are just superficial practicalities, and they are acknowledged in various limits to trademarks).


MongoDB is a profit company riding hard on the opensource bandwagon. This company is a publicly traded company, make no mistake about it. Profit over community. Every 3 months, they gotta report to Wall Street.


I had no idea that's why it was renamed to Robo3T so confusing. Man what a way to bruise people trying to help.


Pretty much everything MongoDB has done as a company has come at the cost of its goodwill. I rarely meet devs who like or advocate for it. I meet plenty who advocated for it, but few who advocate for it.

I fully expect them to flame out in the next couple of years.


Maybe Mel Brooks and/or the estate of Richard Pryor would like to capture some of that "Mongo" money.


For people defending this, you're being naive. It'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 "primarily derives from the Program."

Of course their sales people are saying "No. We won't use it that way." Sales people gonna sell.

I'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?

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.

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

According to our poll many users will seek alternatives for MongoDB because of the license change

https://www.percona.com/blog/2018/10/24/poll-mongodb-license...

MongoDB probably feels they have reached critical mass so it does not matter any more...


>MongoDB probably feels they have reached critical mass so it does not matter any more...

They have become a new standard and they are aware of it.

Just look at any bootcamps for devs this days , it’s basically always JS + MongoDB. Not Postgres or MySQL , Mongo.

Mongo has become the new MySQL for a lot of devs these days.

It’s often the only DBMS they know...

These move is somewhat coherent with what others are doing in the industry ( Redis Enterprise Modules new licence , Docker preventing download without creating an account etc...)

Open Source is now Venture Backed , as a result it needs to make profit.


Good points... But same as MongoDB replaced as database of choice for developer training it can be replaced again


> Just look at any bootcamps for devs this days , it’s basically always JS + MongoDB. Not Postgres or MySQL , Mongo.

The online classes love Firebase. :-D

But yeah, I had to explain to a bootcamp dev a few weeks ago what Postgres was. I felt rather sad.


I am a bootcamp dev (still in it) and I can confirm that its all node + mongo. I know what postgres is but obviously dont know anything about it technically. I am struggling to understand what this license change means for someone like myself who is building a web app with mongo...


Postgres is orders of magnitude safer, sometimes a bit slower, but requires a bit more forethought when it comes to planning a schema to match your models. You typically appreciate this more in maintenance and later development more than you appreciate it up front.

The general risk with any for profit open source company is either them pulling all the good features into the paid version, or suddenly changing your license so that closed source projects have to either stay on the old versions or pay for a commercial license.


Okay so after reading the article, and thinking about this for a while, I get the following out of this debacle:

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

This is a valid concern and I understand the motivation behind the license change. However, how is this different from any other FOSS?

Just as a random example, think of a proprietary blog/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/code of your website, you simply add customizations using a frontend.

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.


Disclosure: I work for MongoDB.

You're in the right ballpark, for sure, but the SSPL addresses the difference explicitly. I'll use your example of Tumblr to clarify.

Tumblr is built on some component technologies, like a database, an app framework, operating systems, backup systems, load balancing, etc. But Tumblr itself is not any of those things. Nor does it make any of its component technologies available to the public as a service. You cannot pay Tumblr to backup your servers, or to rent you VMs running an OS, or to do load balancing for your infrastructure. Even if every single one of those components were licensed under the SSPL, Tumblr would not have to release a single line of their code under the SSPL, because they provide something else -- a publishing platform.


Technically, Tumblr provides persistence for ramblings and pictures and makes them available to the public. Tumblr is a brand wrapped around a database.

I could do the same thing with a worse UI by hosting MongoDB on an open port.


And taps are just zero-length swipes!


I understand the difference is that Nginx Inc. as a company is not in the business of providing a blogging platform or e-commerce hosting while MongoDB Inc. is actually providing SaaS (MongoDB Atlas) which I believe is their major revenue source.


The difference is that those projects (apache, nginx) are ASL or MIT licensed.


I can understand the sentiment and realize the need to monetize, it's hard when others take your code and make more money out of it then you (which I am assuming is the case).

But even if they are right, this doesn't seem smart, it feels like a knee jerk reaction. I imagine that they hope that by doing this they'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.

But that's not whats going to happen, either cloud providers will remain with old versions and people will gradually move to different dbs or they'll just fork it, they certainly have the manpower for it, this will give them incentive.

Frankly though I think this is well within the agpl, cloud providers aren't modifying the code they are building things around it.


> it's hard when others take your code and make more money out of it then you

Just my opinion, of course, but I think this is only true for sales and management types who are profit driven. For engineers and artists, it's not really an issue. We want to see our best work appreciated, primarily.


> For engineers and artists, it's not really an issue. We want to see our best work appreciated, primarily.

I want to be paid first. Everything else comes second. That doesn't not make me an engineer. It makes me a wise engineer. Money buys options and freedom. Prestige and other abstract concepts are used to steal your time and value.


Right, but you aren't going to raise hell if someone makes more money on your work than you did. That's not the attitude of a craftsman, but business folks think in terms of lost potential revenue and junk like that and thus are not above such things.


It's okay if they make 'more' money, but whenever an entity makes giant piles of money I wish there was a small mandatory royalty to the original creators.


All the engineers I know still want a paycheck every two weeks. Engineers aren’t (and shouldn’t be!) all Above All This - sure, it’s great to make something and give it away just to help the community, but you still gotta eat.

That said, I think MongoDB REALLY screwed up the execution here, even though I can definitely sympathize with what they were aiming to accomplish.


As a non-lawyer who's tried to understand copyright law, this analysis confuses me; my understanding was that in the realm of source code "by default" 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.

This isn't me trying to argue against the article; I'm trying to understand the law as it applies to my profession.


This uncertainty and confusion is by design and the whole point of this license. It's designed to make people who are not lawyers consider getting a commercial license just to avoid the potential for legal headaches that may or not materialize.

I doubt it will work since many people will indeed not want to deal with companies that are dangling legal threats over their own users like this. IMHO there's no other way to interpret this than as exactly that: a user hostile move. Whether this thing is enforceable or not is beside the point.


It is actually silly, because being “the only unpaid open source nosql” is a pretty good position to be in. It’s how MySQL became huge: by being “the only unpaid open source relational db” good enough for real work.

It’s not with licensing shenanigans that they’ll fix a monetization failure; in fact, it will likely backfire. It’s hard enough to push (A)GPL software in enterprise contexts, by making it even more awkward they are basically begging users to go away.


Disclosure: I work for MongoDB.

Forcing droves of community users to buy commercial licenses is not the intention of the SSPL -- indeed, it cannot serve that function, as it does not obligate them to do anything at all unless they are making the licensed software itself available to the public as a service.


The problem with that statement is that it is your company's lawyers interpretation of what it is all intended to mean. Yet, it's not certified by the OSS foundation and there are now loads of articles trying to interpret what it all means, which suggests to me that this is not a clear cut case of this being all that clear at all. Either way, your company is trying to actively restrict how the software is used even further than the AGPL already did.

I'd recommend sticking with well understood OSS licenses. There are plenty of those. This one is neither OSS (until the OSS foundation says otherwise) nor well understood. Both are problems. Especially when mixing with GPLed code. It creates all sorts of headaches. And conveniently your company's way to solve that is a commercial license. I'd still argue that that was the main point. I'd suggest celebrating any successful use of your software instead of trying to constrain it.

My suggestion would be to use Apache 2.0 and try to get companies to take a commercial license based on the merit of added value in terms of support, extra goodies, etc. This seems to work well for others in the industry (e.g. Elastic that recently IPOd); it's well understood; explicitly compatible with GPL; and has none of the disadvantage of rolling your own license.


Much of what you say about the lack of clarity is fair, but we hope that those things will be resolved when the SSPL gains OSI certification. In the meanwhile, we will do our best to 1) listen closely to the specific arguments as to what is unclear, and 2) attempt to dispel what we see as misunderstandings, often prompted by what is essentially FUD.

I appreciate your suggestions on what other licensing options we have. I think you really get what we are trying to do. That strategy is exactly how MongoDB has sold its enterprise edition for years. With apologies if I'm pointing you to something you've already read, we think the current landscape of the tech industry makes that insufficient, as our CTO's announcement post goes into: https://www.mongodb.com/blog/post/mongodb-now-released-under...

Anyhow, I do want to address this:

> It creates all sorts of headaches. And conveniently your company's way to solve that is a commercial license.

I think this is unfair. Everything we have said about the SSPL makes clear that it has one very exclusive set of targets in mind: large scale cloud providers with the means to strip-mine not just MongoDB, but any open source project with significant traction. And the one actual data point in this conversation supports that position: fatbird posted that they were on a sales call with MongoDB recently, specifically asked if they were affected by the license change, and were told "no". Is that a legally binding rider to the SSPL? Of course, not, but if the plan for the SSPL was to use it to wring money out of community users, wouldn't the answer have been "yes"?

If you've already read that announcement post, or if you now do, would you let me know if it makes anything clearer?


> I think this is unfair

I'm just parroting the sentiments here. This is how this move is perceived.

I think your CTO is wrong on this. This situation is not something that is going to improve with more blog posts, explations, or proclamations from your c level executives.

So, a wise move would be to roll this back ASAP and withdraw the SSPL.

This license is no a solution to Mongo's revenue problems and may actually make things worse. It sure doesn't solve any problems your users are having so whatever this is, it is not in their interest.


Thats exactly how our legal dept intepreted it when it was announced. It took me several days to calm them down, including having to write up a migration plan to mitigate the risk.


> As a non-lawyer who's tried to understand copyright law, this analysis confuses me; my understanding was that in the realm of source code "by default" 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

Note that the same is true of any property, and terms of sale, rental, or permissive use of other property may be unlawful as anticompetitive or otherwise contrary to public policy; while copyright misuse is a social doctrine evolved from the related doctrine of patent misuse, it's not really all that out of line with the kind of considerations that song with property rights in general.


>my understanding was that in the realm of source code "by default" you only have rights to use that source code through a license or contract

No, not at all, and this is a key difference between OSS licenses and EULAs. By default "you" (the entity in question, which may be an individual human or legal organization) have the right to use lawfully acquired source code for absolutely anything you wish. What copyright governs is distribution (either of the copyright works or any derivatives, except for exemptions made by Fair Use in places that have such a legal concept). So if I just put source code up for my program and make it freely available and nothing else, then by default you may download that and run it or hack it up or whatever else you want, just as if I gave you a book I wrote you'd be free to mark up the pages or tear some out and reorder it or whatever. You don't need the copyright holder's permission for any use of it.

What you do need permission for is to then share any of that on. So standard open source created a fair and thus very strong quid pro quo essentially: someone is offered additional rights beyond what they'd have by default via a license that requests they do some task in consideration related specifically to that copyrighted work (for some licenses it might only be indemnification from liability and maybe giving credit somewhere, for copyleft it means applying the license to any derivative works as well). There is no click through or "by using this you agree to..." there, your acquisition of the source is entirely separate from a later choice to distribute the source. No license is needed for use, but if you don't agree with the license and don't get another one then you have no right under copyright to distribute [1].

Anyway that's a simplified basis for the theory behind OSS. It's founded in the simple and straightforward application of copyright law and contracts, and it's fundamentally quite fair to all parties and has a very limited and directly related to the work aim. As the article says the further away one tries to get to that the more complex and iffy things can become and the easier it may be to include something that is legally challengeable. Copyright is open source's hammer, but not every aspect of technology is a nail.

----

1: Note that in practice this can at least theoretically get sticky if you're a programmer in a related field (as so many on HN are) rather then a random user, because having read the source code if you then down the road wrote something that looked the same it could be claimed it was derived which is then a huge pain to fight about. For non-high profile areas it's unlikely it'd ever come up, but the future is hard to predict in that area of life so many ethical or just cautious programmers would be careful about looking at source that wasn't open source.


Huh. So, the rush to release and announce the license before OSI vetted it, was in fact VERY VERY intentional. Not some poorly planned "rush the news out" mismanagement.

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.

I think there was a base assumption that the license would in fact be fine, and OSI claiming it wasn't because they hadn't stamped it ... yet ... was overreaching.

Anyway my understanding is that the single largest user (and commercial licensee) of MongoDB hates it and can't wait to get away from it. With that in mind, this licensing nonsense smells like a desperate grab. Maybe it's time to short $MDB?


Who’s their single largest user?


Just because A is false B doesn’t automatically become true.


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


Only if you think that related software necessary to make and run the service is "other software" and not an improvement over the primitive default service.


There is no restriction, only the requirement that the systems that make your service run be made available under the SSPL.


If your license places any requirements on software that is not a derivative work of software you own the copyright to, the license is nonfree by the standards of the OFSI and the DFSG and probably others.


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


I'm not sure what the question is, but the AGPL is very carefully drafted to avoid the problems Van is talking about.


Well, according to the article the second problem is directly inherited from AGPL.


Not quite. There are administrative problems with the AGPL, which are inherited here. But it is the scope of this license that pulls in these new defenses.


I'm sure they will address your concerns in SSPL v2. But make no mistake, you can't win here.


I will then create Anticensor's Public License, stating everything interacting with said work must be licensed under the same license.


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're incorporated in Delaware as most funded tech startups are, that isn't 9th Circuit either.

Am I missing something or is the author? Also, what stance has the 2nd Circuit taken on copyright misuse, if any?


I'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.

Is there an example of such a license?

Could this type of license even be created in an enforceable way?


MongoDB doesn't deserve all the credit (or blame) for what they'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'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's received many community contributions, which is unethical IMHO.


They use plenty of other open source components as well. As I pointed out in other parts of the discussion they use PostGres beneath the scenarios for their reporting solution and charge customers for it. What do they contribute back to the PostGres community?


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.


Yes, you can fork, but no, you can't merge new changes, those come with a different license (except maybe for third-party contributions, you could ask them to double license them under the old one too).


> keep merging upstream changes under former license?

Upstream changes made by the project sponsor would be expected to be copyright and released only under the new license.

Unless the copyright holder permitted it (perhaps via the new license), it'd be copyright infringement for anyone to distribute those upstream changes under different terms.


Why isn't a straightforward solution to the "impracticability" problem just a "to the extent possible" or "authorized"-type predicate?


This would significantly ameliorate the problem.


So then, really, a big part of the critique here is that the SSPL is simply not written very well?


Yes, but it is deeper. My overall take is that SSPL overreaches based upon the tools that it is using, making it infirm for multiple reasons.

I don't necessarily disagree with the sort of thing they want to do, that definitely fits one kind of business model. But I wouldn't want to go to court the license as presented (and now entered into by some unknown number of people).


i mean to be fair that's the big problem with most licenses as "not written very well" covers almost all problems with contracts :)

Like the LGPL is confusing because it is not written well in some sense. But that goes to "confusing" instead of "unenforceable".

But yes, better written the problem with this license would just be "They are trying to claim things they know they can't claim" instead of "they are actually claiming things they know they can't claim".

The next question that would pop into my head would then be "At what point does attempting to claim rights to things you know you can't, as a way of scaring people into paying you, cross into unfair and deceptive trade practices"


Sorry, I just meant: "a more conscientious lawyer could have straightforwardly drafted that contract to avoid some of its major problems". Like, the subtext of the question is, if I was MongoDB, and stipulating that I didn't create unreasonable work conditions like "get it done in a day", should I be pissed at my lawyer?

Additional question: if you can fix that problem with the contract with a "to the extent possible" predicate, is that really not the default? Like, if a clause can be interpreted as requiring the impossible, even if a straightforward alternate interpretation doesn't, that clause is broken?


Yes, they could have. So yes, you should be pissed at your lawyer if they didn't warn you.

In my experience, the lawyers mostly warned the clients and the clients did it anyway.

Part of being a lawyer is simultaneously taking the blame for stuff like that while having done very careful diligence so that your malpractice insurance rates don't go up from clients successfully suing you :)


Sincere question: who is actually using MongoDB these days?


At GitLab we still use it for Gitter. It wasn't a priority to convert it to PostgreSQL. After the WiredTiger updates I think Mongo got a lot more reliable. But I would start any new project with PostgreSQL.


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's Facebook/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.

It's clear that there'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'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.

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.

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 "reasonable person" standard often used by the courts in contract/license disputes.

That's not going to be easy, considering "expect the worst and don't risk anything" always looks like sound advice, given that you will never know what you missed on the path not taken.

But the GPL's success should be inspiring here: it was initially met with scepticism, especially among corporate lawyers. Their essential pessimism never changed (it'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/management platform written from scratch in Befunge or Brainfuck...

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


Performance is pretty damn good too compared to MongoDB: https://www.percona.com/live/e17/sites/default/files/slides/...


Thank you for that presentation, it is pretty cool to see other production systems using FreeBSD + ZFS together with PostgreSQL :-)


Solves many more problems than just the licence, too.


Given my personal experience with Mongo, using Postgres will solve far more issues than just the license.


While I like relational data and I _love_ Postgres specifically, there are some tasks and contexts for which non-relational stores are better suited.


I agree, although I think the use cases for non-relational databases is overstated, but I view MongoDB as one of the most dangerous pieces of software I’ve had to touch. It demos great, but long term usage of MongoDB has been nothing but pain for me. Lost writes, all three nodes deciding the other is primary, crappy performance if you’re just outside of the indices, and extremely painful migrations all come to mind.

I really hate MongoDB. I’ve been burned by it consistently for the past half decade or so, across several companies, data sets, ops teams, and underlying hardware. I’ve just decided that fundamentally MongoDB doesn’t work.


Let me echo that sentiment, I also hate MongoDb. I had to setup / manage a MongoDb cluster in 2012-2013. It was a giant shitshow. Maybe things have gotten better, but I have little desire to test the waters with MongoDb again. I'd rather use https://www.rethinkdb.com/ if I really needed NoSQL / scalability.


I'm sure that there are tasks for which non-relational stores might be better suited, but pretty much anything MongoDB does, Postgres does it better and in a more performant way (esp after the optimizations to the JSONB data type in the last few major releases).


Performance is definitely an important aspect, but coming from a background working at smaller companies, bootstrapping time and development time are a factor as well -- and while Postgres is easy to set up if you're familiar with it (and I dare say it makes DB design fairly straightforward), Mongo and other NoSQLs are pretty objectively easier to just get working if you aren't fluent in relational databases.


No offense, but if you don't know how to design/develop a database schema, making it easier to shoot yourself in the foot by using NoSQL database is not the answer.


None taken. And I agree -- but database design is inherently different under SQL and non-/noSQL. Constraints and relationships may be modelled completely differently in either case.


So, I've been trying to figure this out a bit lately.

How would you go about writing a customer facing query builder that is analogous to the MongoDB aggregation pipeline with SQL?

With MongoDB I could conceivably generate/store a JSON object for such a query. In SQL it seems a lot more obtuse to do.


Keep it simple: stick with MongoDB-like JSON objects for queries but write some code to map those queries to SQL immediately before execution.


This is a very bold comment, explain how you scale write, do HA in pg?



This is not what I called HA or horizontal scaling. Have a look at what MongoDB or Cassandra do.


Unless you're operating at Google/FB/Twitter/etc scale, this is not a problem most of us face IRL. We need to stop pretending we have these problems at 99% of the places we work at. Most of us don't. We don't need 1,000 microservices, Kubernetes, Docker, and a terribly unreliable NoSQL database like MongoDb (there are better, more optimal solutions for those companies than MongoDb (Cassandra being one of them.))


The fact that someone has to manually promote a slave as master is a big operational cost. The people that actually use PG at scale have to write a lot of tools / plumbing to overcome those issues, the same "issues" that were solved by most NoSQL solution, horizontal scaling, HA, shards re-balancing ect ...


> The fact that someone has to manually promote a slave as master is a big operational cost.

It doesn't need to be manual, only in a layer above/outside PostgreSQL. There are solutions that automate leader elections for any secondary-promotable-to-primary system (not just PostgreSQL), just not built into PostgreSQL.

We looked for about two years, on and off, to setup smoother, less-manual HA for our PostgreSQL setup. We ended up writing some, as you say, "tools / plumbing to overcome those issues". By far, though, the most time we spent on it was been spent in reading, testing, and getting to understand how things work.

After everything, unfortunately, no other system fit our requirements. Many came close in their marketing copy, but on closer look, every system had caveats. Ultimately, PostgreSQL is the only system I could still trust to do the right thing. In fact, the solid foundation that Postgres provides is why I can trust third-party layers (similar to Stolon and Patron) to focus on the job of switchover correctly without losing or otherwise messing with my data. In fact, I can even switch which tool I use, without it affecting my data.

The little plumbing we've written over Pg's built-in replication allows us to horizontally scale using logical replication and assuredly have HA using physical replication. At the end of the day, any shop that does anything important with data at scale needs to know how their data is actually being treated, irrespective of what the marketing promises. Hell, even when the data-store does not blatantly lie to you about keeping your data safe or uncorrupted, you can lose data due to bad use of tooling or explicitly-set unsafe configuration. "I'll just use this; it'll solve all my problems!" is rarely a thing to blindly believe when dealing with important data.


You're technically correct, but this case study was really eye-opening to me: http://blog.sagemath.com/2017/02/09/rethinkdb-vs-postgres.ht... They migrated from a RethinkDB cluster (similar to MongoDB) to a single Postgres server and the result was faster. And a single server is very large today, like 48 cores and 384 GB RAM.

And speaking of Postgres HA management, master promotion, etc. there are several tools like https://github.com/sorintlab/stolon available.



Citus, but it takes a while. Until you need thatw


I'm guessing you're already aware, but for anyone that isn't - Postgres supports JSON as well https://www.postgresql.org/docs/10/static/datatype-json.html


While Postgres definitely has support for document-store like behaviors and can function in that capacity just fine, that's not the same thing as saying you can just substitute it for a document-oriented store like MongoDB.

Having said that, for someone who's already using Postgres, it's a great way to introduce some document-related behaviors (as opposed to strictly relational ones) by using the features it already has.

Even MariaDB is taking steps in this direction with many non-traditional relational types of storage options now available.


I think you can absolutely do it (and have) using something like: http://jasperfx.github.io/marten/


> there are some tasks and contexts for which non-relational stores are better suited.

And if you have one of those tasks I congratulate you on finding a project with particularly unique data needs.


This, by the way, is also a good answer to many questions along the lines of, "which NoSQL database should I use".

99% of the time, you're losing a lot from NoSQL, and you're not gaining anything. Most people who talk about NoSQL perf would never actually hit the perf limits of Postgres on their real life workloads.


The technical side of it is irrelevant IMHO. I'm pretty sure they wouldn't but what if Postgres people did this too? What if others followed?


I don't think that's even remotely possible given how Postgres is structured: https://wiki.postgresql.org/wiki/FAQ#Who_controls_PostgreSQL...


[flagged]


Please review https://news.ycombinator.com/newsguidelines.html and follow the rules when posting here, regardless of how unhelpful another comment is (or feels). Uncivil swipes in particular are not ok.


Unhelpful how? I'm providing an alternative NoSQL option (Postgres supports JSON - https://www.postgresql.org/docs/10/static/datatype-json.html) and you don't have to deal with this MongoDB licensing nonsense.


NoSQL usually have built in constructs for horizontal Scalling / HA, pg have none of that.


Cloud computing is becoming the dominant model, and the current combination of OSS licenses and public cloud players/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.


The umbrella issue is monetization of software. Perhaps the philosophy of OSS as a monetization strategy is fatally flawed for certain types of software. I love OSS and it is very useful, but in the world we see that some things are better suited for selling online (not usually pet food), etc. Perhaps it is simply an issue of a particular problem that cannot be well solved by OSS. If that is the case, then perhaps we fall back to the idea of "software monetization" and go proprietary for certain things which work best that way, while pushing OSS for things where it works very well.


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


A viable VC-backed startup business model for a GPLv3 or AGPL MongoDB isn't necessarily possible.


This is more likely to come from big companies, not VC funded startups


It's hilarious to me that out of all the problems with the way MongoDB works it's the license, of all things, that gets a strong reaction from the HN crowd that says, "I'm never using that!"


MongoDB's technical problems are so well known that it's boring to bring them up again.


Mongodb is like Marmite, half tbe world loves it, half hates it, go figure.


Apple's SDK has an EULA that says it cannot be deployed on a server and made available as a service. Why can'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.

‘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'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.


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


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


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


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


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.


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?


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


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.


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.


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


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.


Intellectual "property" is cancerous repression. It's time for copyright to die.


I don't understand the line of reasoning. Can anyone give me a lay explanation?

My understanding of the license change is basically "if you use MongoDB to support any site, all software higher in the stack needs to be released as well".

Is that accurate?

If so, why can't an author make this part of the license?


No. If you take MongoDB and offer it as SaaS, the additional software that's part of your offering, such as monitoring, backup solutions, etc, have to be open-sourced, or you have to make their code available (since the chair of OSI defines what's open source).


I just had a call with MongoDB sales yesterday, and specifically asked if the licence changes impacts us, where we use Mongo as a datastore for our application, but we're not offering Mongo itself as a service. They were very quick and clear to say that the change is about those providers offering Mongo itself as a service. Using mongo in your stack to provide your service is not implicated at all.

The only grey area I see is if you offered some sort of database-as-a-service backed by Mongo but not explicitly sold as Mongo-as-a-service.


This makes sense, and I believe you, but lawyers being lawyers, I don't think any corporate legal team is going to even bother with trying. Easier to say "no".

Source: 1 data point; the company I work for's legal team just said "no".


Same fight here, but we're digging in our heels and bothering to convince the internal lawyer that it's not a problem. We'll win, but it takes time we'd rather not have to spend.


We'll win, but it takes time we'd rather not have to spend.

In a fraction of the time, you could convert to Postgres, with the added bonus that doing so will also be massively more fun than arguing with lawyers. Below, you mention professionalism too.


What mongo says on a sales call is not going to be found usable in court.


The odds of anyone here ending up in court over licence terms for using Mongo as part of their backend, are so vanishingly small that to actually decide against Mongo on the basis of that chance amounts to professional malpractice.


For now. Their intent can change. Or they can be bought by oracle.

Always consider license changes based on the possibility of the company being bought by oracle, there should be a law about it!


Yes this also came up with my coworkers when we were discussing this. It's better to treat every software license as strict and malicious as possible because everyone can be eventually bought by Oracle and Oracle can sue you for misusing "their" license.


those providers offering Mongo itself as a service

I can’t think of a single Mongo-as-a-service provider apart from Mongo themselves. None of the major clouds do it, neither do the also-rans like IBM or Oracle. So I call shenanigans on them.


Statemens made by sales, are they legally binding?


Thanks for the explanation! That makes sense.

So... why does the blog post argue that it's unenforceable?

My understanding is that they are saying "you can't use copyright to enforce something that isn't part of a creative work".

If that's an accurate version of their argument, then why not? The agreement is a contract with copyright as one side of the equation, and some behavior on the other side. Why wouldn't you be able offer a license for a creative work contingent upon things unrelated to a derivative work?


Quick summary:

1) It is problematic to use copyright infringement as a hammer to force people to release/relicense code that is not related to the copyrighted code. (That's the "misuse" bit)

2) If you try to do this via contract, there are lots of practical difficulties associated with actually releasing the code - the biggest of which is that you probably don't own all the code you would be required to release. (That's the "impracticability" bit)


The copyright owner can indeed license their work anyway they see fit. But often, the purpose of OSS seems to be "to share good software with the world." If that's the case, and then they change their license to a "... and you must also share _your_ work with the world," then they can't really complain when A) users stay on old versions licensed with the old license, and B) when use of their systems drops off lots.

I don't see that as the case here necessarily. TFA just points out to potential users that the license has changed and might necessitate dropping MongoDB from your stack.


Not quite—if you offer MongoDB itself as a service, then yes. If you just use it on the backend, no.

(Read the license and consult your lawyer for details, of course.)


"offering a service the value of which entirely or primarily derives from the value of the Program"

That sounds pretty squishy and likely to be broader than just the use case of offering Mongo as a service.


It doesn't seem squishy to me insofar as you can't offer Mongo as a service and then swap Mongo out for a different product, while leaving your offering unchanged.

Any app using Mongo simply as a datastore on the backend can swap it out without altering their offering.


Yes, it clearly targets Mongo as a Service. I'm not clear, though, on whether that's where it stops.


Yeah, that throws off huge “what would Oracle do” red flags.


That's a good point—it likely trips the unofficial "tentacles of evil" test of the Debian free software guidelines, from https://people.debian.org/~bap/dfsg-faq.html :

> Imagine that the author is hired by a large evil corporation and, now in their thrall, attempts to do the worst to the users of the program: to make their lives miserable, to make them stop using the program, to expose them to legal liability, to make the program non-free, to discover their secrets, etc. The same can happen to a corporation bought out by a larger corporation bent on destroying free software in order to maintain its monopoly and extend its evil empire. The license cannot allow even the author to take away the required freedoms!

If MongoDB does not say in a legally binding way that this is clearly not what they mean, an acquirer could very likely twist the clause.


it also really doesn't sound like "if you use MongoDB in your streamingplatform/blog/whatever you need to opensource everything, which seems to be the gripe many a commenter is having.


Maybe. If there's more lines of code in the Mongo part than the other part, is the value "primarily" Mongo? What if I made a file upload/download site? Mongo might constitute the bulk of the value/lines of code/whatever.

Words like "primarily" and "including, without limitation" make lawyers nervous.


That depends on how you think a court would weigh the source of value of your offering; and any factor that makes MongoDB more valuable as a component before considering the license makes it more risky when you consider the license.


It's not you that needs convincing, it's the lawyers of the company that's acquiring your Mongo-using startup that need convincing.


That's not correct, the license only says if you make SSPL licensed software itself available as a service, you have to release the service code under the SSPL. Using the licensed software to build anything else at all is ok to do without releasing your code.


The problem is that we don't know how Mongo will choose to exercise this brand new license, and how courts will rule on them. I've brought this change to our corporate counsel and they are advising we stay clear of it.


IP lawyer here :)

"If so, why can't an author make this part of the license?"

So let's separate out two questions implicit here:

Can you make this part of a license?

Would you win if you sued someone for violating it?

The answer to the first is clearly yes, you can license it however you want :-).

However, like most IP, in basically all countries there are limitations on how you are allowed to license things, to ensure the original goals of copyright are respected.

Those limitations are usually presented as defenses.

Van gave two examples of defenses.

There are others.

For example, patent misuse is a defense to patent infringement.

Here's a concrete example of patent misuse that may be easier to understand than copyright misuse:

You sell a thing that infringes my patent.

In order for you to avoid infringing my patent, I force you to pay royalties for 10 years (Rather than a smaller length of time).

But wait, the patent expires in 5 years!

Can I enforce this?

No. It's patent misuse. You cannot use your currently valid patent to force someone to pay royalties past the validity period of your patent.

Another example:

You have a product X that infringes my patent. I use my patent on X force you into an agreement to pay royalties on a product Y that doesn't infringe my patent.

Can i enforce this?

No. You shouldn't be able to use the patent on X to force me to pay royalties on something that doesn't use your patent.

To bring it back to Van's examples, the copyright misuse is similar to the patent misuse i just gave you.

You can't leverage your copyright on X to force me to do something with an unrelated thing.

The GPL and AGPL are very careful about this. The AGPL applies to modified versions (which are derivative works) and only extends to pieces that are derivative works. The GPL is the same - only the derivative works are touched. That is within the copyright rights of the thing that was AGPL/GPL'd.

How do you know it's unrelated to a given copyright?

If X could not claim any copyright rights over it, it's unrelated. This usually comes down to whether it's a derivative work not because the other rights are not very broad in coverage.

Here, the license is taking X, and saying "You must do something with unrelated thing Y, which is clearly not within the scope of copyright of X". So I am trying to use my copyright right in X to force you to do it. Note: No lawyer believes there is any reasonable argument that completely and totally independent piece of software X that does say, monitoring, is a derivative work.

So that's a good start on copyright misuse :)

(The other prong is about whether it restricts competition, which they already admit is their goal here)


I have a question about how derivative works are defined with respect to AGPL.

With the GPL, you couldn't distribute software that links (at runtime) to GPL software, without open-sourcing your software as well. This is because, linking another piece of software to a GPL'd binary means you're creating a "derived work". That's why they made the LGPL (the "lesser" public license) which allows being linked to from closed-source works, without being considered a derived work.

With AGPL, they seem to have gone the opposite way from LGPL: it seems to have extended the definition of "derived work" to include software that accesses the covered software over the network. If that's the case, doesn't that mean you just plain can't use MongoDB in the backend your own closed-source website (without open-sourcing your site's code?)


I think you're slightly off there. The AGPL doesn't apply to software accessing the AGPL licenced software over a network, it applies to the AGPL software that's being accessed. As in it applies when the software is being accessed over the network rather than when it's being distributed (as with the GPL). This is actually mentioned in the article.


I think you have this correct, as I understand it. Just to explicitly state the differences:

1. You can modify GPL code as much as you want, and as long as you don't distribute the software, you do not need to make the modifications available. If you distribute the software, you are required to make your code available.

2. The AGPL extends the definition of distributing the software to making the software available over the network. This means if you modify AGPL software and then make it available over the network (as SaaS, for example), then you are required to make your code available.


> The AGPL extends the definition of distributing the software to making the software available over the network

Doesn't this apply transitively? That is, I made MongoDB available over the network to my web tier (thus creating a derived work), and made my web tier available over the network to your browser (thus distributing it), thus, haven't I transitively made a derived work from MongoDB available?

I ask because this exact scenario seems to be what makes the company I work for so scared of AGPL. It's not necessarily cut and dry, but it's a scary enough possibility that we just ban it outright.


Runtime linking doesn't always equals derivative work. Some GPL enthusiasts would like it to be that way but it doesn't mean it is. As far as I know it's a murky legal issue. I forget the exact case but one counter-example was: you have proprietary library A. Someone makes a GPL implementation B with a compatible interface. You ship software C with instructions that users can use either library A or B. An example of this would be BLAS libraries, which have both proprietary and open-source versions. Software C is obviously not a derivative work of GPL library B.

Now, the risk that a court might decide your software is a GPL derivative because it links GPL software might be enough to dissuade your company from using GPL software altogether.

LGPL makes it explicit that you can link against the software without making your software GPL/LGPL so it removes that risk.

And that's not what the AGPL is about. It's not extending the definition of what a derived work is, that is completely outside the hands of the license, it's a matter of copyright law. The GPL says if you distribute GPL (and by extension GPL-derived software) you must distribute the sources too. The AGPL says if a user accesses AGPL (and by extension AGPL-derived software) over the network, you must distribute the sources to that user. It doesn't mean that if a user uses unrelated software to access AGPL software, that unrelated software is somehow derived from the AGPL software.


> I forget the exact case but one counter-example was: you have proprietary library A. Someone makes a GPL implementation B with a compatible interface. You ship software C with instructions that users can use either library A or B.

Are you referring to the discussion between the author of CLisp and Stallman about GNU Readline, by chance?

https://github.com/JoshCheek/clisp/blob/master/doc/Why-CLISP...


Also the only part of mongo that is limked is the driver, not tbe database product. All the drivers are licened under apache 2 license, which is permissive, and largly just demands preservation of copyrigths and trademarks. It does not mandate source distribution for derived (linked) products.


Let's hypothetically say that a court agrees that this is copyright misuse.

Where would that put existing MongoDB released under the SSPL? Surely not public domain, so where?


Depends on how well written/what court decides to do.

I'm going to short circuit a lot of nuanced case law and differences between jurisdictions/courts here to give a clear answer:

Usually these things are written so the clauses are severable.

The court would then most of the time just remove the invalid pieces and leave the rest intact.

If it is not severable, the contract stands or falls as a whole.

If it falls, nobody is a valid user (though surely would be given time to stop or for mongo to fix it).

Why?

The default state of copyright is that only the owner has the rights.

If you invalidate the contract/license granting you non-exclusive permission to those rights, you no longer have that permission at all. So you have no right to be using it.

note: Any such court decision would only apply to the relevant court jurisdiction (IE if it was a district court decision, it would only apply to the parties)

It would just be persuasive evidence to other courts.


Interesting thing about misuse, is that it prevents the enforcement of the copyright against even non-parties until the misuse has been dealt with.

Practically, that is probably dealt with via a blog post and a retreat to the AGPL, but still.


"Interesting thing about misuse, is that it prevents the enforcement of the copyright against even non-parties until the misuse has been dealt with."

Interesting. I've never delved that far into misuse but that makes sense. Is that piece a US specific thing or common in others?

As you say it would not have too much practical effect since it's curable trivially. You'd get a few hours of unrestricted mongo use, maybe, but I bet the official order would post-date the blog post fixing it :)


Probably US only, didn't look internationally.


Doesn't Unifi use this?


not as a service, but yes as a backend


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


Yes, but explicitly includes all the stuff needed to make and run the service.


GPL3 doesn't do that. You're thinking of AGPL.


How does the GPL3 have that intent? AGPL does, but GPL?


My understanding is that AGPL does only for that piece of software, not all layers above it?


> accused infringer would then, quite rightly, plead impracticability

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 wish the article had taken this question more seriously. Impracticability is a defense under contract, but a fundamental requirement in the US test is:

> "an occurrence of a condition, the nonoccurrence of which was a basic assumption of the contract"

Impracticability is not a defense against signing stupid or damaging contracts; it specifically releases a party when circumstances change such that a contract is no longer reasonable. Standard examples are things like the outbreak of war or a supply chain collapse, which don't render a contract literally impossible to fulfill but do place fulfillment outside the domain of any reasonable effort.

Defending against conditions which were already in place when a contract was signed is far harder, and even impossibility is not necessarily a defense if the impossibility is obvious at the time of signing. The only common defense I know of against conditions present at the time of signing is illegality, which of course comes up quite often with things like noncompete clauses.

The misuse complaint at least looks plausible, but I'm pretty baffled by the appeal to impracticability.


Here is the analysis: Let's think about the context where this would come up: A party ("Service") takes the SSPL'd MongoDB and implements a service. Service releases some code based on a good faith interpretation of the scope of the release necessary. There is a dispute between MongoDB and Service as to the scope of the necessary code release.

In the ensuing lawsuit, Service raises misuse and argues that the scope is ambiguous. Leaving aside the misuse argument, a court could either a) find for Service, thus restricting the scope of the code to be delivered, or b) find for MongoDB, thus giving rise to an immediate defense of frustration/impracticability, which would undo the contract.


Interesting, thanks very much. I hadn't realized that a new court interpretation of a contract could form the unforeseen circumstance for a defense.


Van is an IP lawyer, and has taken these things to court before.

I generally would trust his view on whether he thinks he could make out a defense or not.


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't run into issues.


MongoDB made some very sketchy, undocumented (or poorly documented) technical decisions in its early years that placed data at great risk.

It's better now, but very few things worry technical people more than a database that loses data. It's hard to get past that early impression.


early?

> This interpretation hinges on interpreting successful sub-majority writes as not necessarily successful: rather, a successful response is merely a suggestion that the write has probably occurred, or might later occur, or perhaps will occur, be visible to some clients, then un-occur, or perhaps nothing will happen whatsoever.

> We note that this remains MongoDB's default level of write safety.

- http://jepsen.io/analyses/mongodb-3-6-4


So a user selects the write safety level they wish. Ok.


Then again, so did MySQL. Do you remember the MySQL 3.x "MyISAM" days? No transactions, automatic truncation and type conversions, etc...


...and a significant portion of IT people still distrust MySQL.


... or they love it, like uber


MySQL still has some unsafe behaviours. Even if it were to fix them all, I still wouldn't use it or recommend it, on account of finding it difficult-to-impossible to trust the design and engineering behind it.


MySQL was very upfront about it, though. They always said that if you wanted that stuff, there are real RDBMS for that.


Quite easy, actually. Those that started using MongoDB in the last 5 years had little bias or negative experience, and are generally happy users.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: