
MongoDB's Server Side Public License Is Likely Unenforceable - willlll
https://www.processmechanics.com/2018/10/18/the-server-side-public-license-is-flawed/
======
mindcrime
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.

~~~
bayareasguy
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 :)

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

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

~~~
chrisweekly
weary (tired) -> wary (concerned)

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

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

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

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

~~~
pritambaral
> w-ah-ry

I've always heard it pronounced way-ree.

~~~
acct1771
Ware-ee?

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

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

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

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

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

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

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

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

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

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

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

~~~
msla
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](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://en.wikipedia.org/wiki/Linux_Mark_Institute)

[https://www.linuxjournal.com/article/2559](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.

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

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

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

------
PeterZaitsev
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...](https://www.percona.com/blog/2018/10/24/poll-mongodb-license-
change/)

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

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

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

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

~~~
village-idiot
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.

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

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

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

~~~
PinkMilkshake
And taps are just zero-length swipes!

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

~~~
51lver
> 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.

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

~~~
51lver
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.

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

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

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

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

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

~~~
metheus
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...](https://www.mongodb.com/blog/post/mongodb-now-released-under-the-
server-side-public-license)

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?

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

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

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

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

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

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

~~~
anticensor
I will then create _Anticensor 's_ Public License, stating everything
interacting with said work must be licensed under the same license.

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

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

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

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

~~~
mushi
Who’s their single largest user?

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

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

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

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

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

~~~
VanL
This would significantly ameliorate the problem.

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

~~~
DannyBee
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"

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

~~~
DannyBee
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 :)

------
polynomial
Sincere question: who is actually using MongoDB these days?

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

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

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

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

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

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

------
GiorgioG
Use Postgres, problem solved.

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

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

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

~~~
bgdam
Postgres HA: [https://www.postgresql.org/docs/9.5/static/high-
availability...](https://www.postgresql.org/docs/9.5/static/high-
availability.html)

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

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

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

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

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

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

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

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

------
ianamartin
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!"

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

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

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

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

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

[https://news.ycombinator.com/item?id=18229452](https://news.ycombinator.com/item?id=18229452)
[https://news.ycombinator.com/item?id=18229013](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...](https://www.mongodb.com/licensing/server-side-public-license/faq).
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.

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

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

~~~
metheus
No apologies required! If we see this question come up a lot we can add it to
the FAQ.

MongoDB does not release the stack for Atlas, our SaaS. That's possible
because we own the copyright to the source code -- we don't have to issue the
software to ourselves.

The blog post we published announcing the change covers this, as well as our
motivations and expectations in a lot of detail:

[https://www.mongodb.com/blog/post/mongodb-now-released-
under...](https://www.mongodb.com/blog/post/mongodb-now-released-under-the-
server-side-public-license)

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

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

There's a big difference between a piece of free software being vital to your
codebase and you simply selling that free software as-a-service.

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

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

~~~
nevi-me
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).

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

~~~
michaelcampbell
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".

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

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

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

------
jason46
Doesn't Unifi use this?

~~~
specto
not as a service, but yes as a backend

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

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

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

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

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

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

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

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

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

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

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

~~~
merb
... or they love it, like uber

