
MongoDB switches up its open source license - zhuxuefeng1994
https://techcrunch.com/2018/10/16/mongodb-switches-up-its-open-source-license/
======
mrkurt
(Context: I worked on Compose/MongoHQ for a very long time. We were the first
to monetize MongoDB)

I'm sure people will get riled up about this, but it makes sense. Building a
business on an OSS database in a world of behemoth cloud providers is really
hard. It's clear Google and Amazon (and maybe even Azure) are comfy taking OSS
work, doing a ton of proprietary development on it, and leaving the companies
who did all the groundwork flailing in the wind.

These things are going to keep happening as long as mega tech companies (a)
use OSS to commoditize other companies' products and (b) exploit permissive
licenses to the max.

I don't want to live in a world where the only infrastructure software we have
access to is what the big companies deign to open source. Life is better when
small groups of devs can build and sustain critical infrastructure software.
We need more haproxies and redises and binds and (fill in blank).

That said, MongoDB has never figured out how to work with their ecosystem in a
way that's good for everyone. They've gone from trying to extort money from
smaller companies to undercutting them to this. And it's likely not gonna
change much this time, the world of "run a database as a service" is changing
I think, and being replaced with more generic tools that just so happen to
manage complex persistence well.

_Also_ I bet some random licensing folks are crapping their pants at IBM right
now. I'm ashamed at how funny that is.

~~~
oropolo
> It's clear Google and Amazon (and maybe even Azure) are comfy taking OSS
> work, doing a ton of proprietary development on it, and leaving the
> companies who did all the groundwork flailing in the wind.

Have you seen the degree of investment Microsoft has made lately in Open
Source? It's an upside-down world where Microsoft if a bigger champion -- and
funder -- of open source than a company like Google which was built on Open
Source software.

~~~
DannyBee
Here, i'll make a provocative statement:

Google has released roughly every meaningful patch it has made to the open
source software it was built on[1].

As for funding, that's definitely not true by the numbers last i looked (and
definitely was not true in the past).

Without concrete disagreements, this is just handwaving. So if you make some,
i'm happy to argue with real data.

[1] The only cases i can think of that this isn't true is when the Googler who
worked on it left before they got a chance to do that (and nobody has picked
it up since)

~~~
lacker
_Google has released roughly every meaningful patch it has made to the open
source software it was built on._

Chrome or Android seem like good counterexamples, where the software that most
people use (Chrome, or Android + Google Experience) is specifically kept in
two separate buckets, open source and closed source, so that Google can
strategically keep some parts open and some parts closed.

~~~
DannyBee
Err? They are certainly not useful counterexamples. That is open source
software Google made itself.

The original complaint was about taking other people's open source (mongodb)
without contributing back. Not "failing to release stuff it made itself".
That's a completely different thing.

Even there, what i said is still true: Google has released every meaningful
patch to the open source software it used in making Chrome/Android.

------
reacharavindh
At the outset, it sounds simple that MongoDB inc thinks why should some 3rd
party cloud provider (AWS, GCP, DO and the like) be allowed to run MongoDB as
a service and make money while MongoDB contributes the biggest part of the
open source project that is MongoDB.

But, it feels like yet another fallacy. What really is an open source project
then?

Say some developer X contributes to a project like MongoDB his/her open source
code so that they can one day run MongoDB as a service and make money. At that
time, he/she believe that status is true and submits their code. But, later,
after the project is mature, the major contributor easily changes license at
will, and the open source contributors walk away with nothing?

I'm not saying that MongoDB Inc, does not have the majority stake here. Just
wondering about whether it is a "bait & switch"esque move?

Imagine if all projects did the same... Say Docker? later on chooses to say
that you can use Docker for free but if you distribute your software through
repositories supported by the daemon, then you need to pay up.. Wouldnt that
be a loss for the contributors that are not working for the company?

~~~
k__
I had the feeling that AWS and Azure are pushing their own NoSQL solutions and
don't care much about MongoDB.

~~~
tannhaeuser
Azure offers Cosmos DB advertised as a drop-in for MongoDB. I'm guessing
Cosmos _is_ Mongo in disguise, though I don't know if it really is, and/or
whether MS has made a deal with Mongo or just think they can use the AGPL
version.

For the record: I'm not a big fan of Mongo (the DB) but I think MongoDB, Inc.
raises a valid point wrt. developers doing all the hard work including
community building and a million other things, while "cloud providers" get all
the money. This isn't sustainable, and we need a license which more clearly
says "if you make money with it, you need to give us some", rather than using
the bare AGPL license without further qualifications in the hope AGPL's
"freedom" aspirations have the indirect effect of forcing commercial users
and/or resellers to pay.

~~~
kstrauser
Did the MongoDB pay for their Linux distros? GCC? Git? How much are they
paying to the FOSS projects they used to build their software for sale?

~~~
pas
They probably report issues back and so on.

How much AWS shares its profits with GCC, qemu, etc? Not at all besides the
bare minimum that benefits them.

(And don't misunderstand me, I don't see Mongo as some kind of underdog here,
but making big money from software is hard, even if - or exactly because -
valuations - and funding - are in the sky.

And AWS is fundamentally a different kind of business than what open source
usually is. It has a compounded networks effects / economies of scale effects.
And on top of that it has a closed source management layer, but that is
largely irrelevant, except for Mongo in this case.)

------
vslira
I'm not an expert in licenses, could someone weight in and explain how the
AGPLv3 was being abused? Did the mentioned companies follow the spirit of the
license and were getting away with something the company didn't like or were
they just improperly distributing the software, regardless of licensing terms?
Also: "So while the SSPL isn’t all that different from the GNU GPLv3,(...)
[it] explicitly states that anybody who wants to offer MongoDB as a service
(..) needs to either get a commercial license or open source the service to
give back the community."

Doesn't AGPLv3 already require open sourcing server side implementations?

Thanks in advance

~~~
DannyBee
Speaking as a lawyer:

There was no abuse, there was only mongo not being able to make money in all
cases they wanted to. That's what they see as abuse. It isn't.

While they complain of bad actors, bad actors _always_ act bad. This will not
disincentivize them (they are also often in a lot of interesting jurisdictions
that would make it hard anyway).

Instead, this is really about making it completely unpalatable for _normal_
actors to not pay mongo in every single case.

Otherwise, one has to believe that mongo is going to go off and sue a bunch of
people now, which would be a horribly stupid business model.

~~~
mrkurt
Speaking as not a lawyer: there is lots of abuse of OSS infrastructure from
big tech corps — because the AGPL isn't equipped for everything-as-a-service
eating software licensing. If "abuse" were license violations, they wouldn't
have to use a new license.

Abuse is often legal.

~~~
DannyBee
What is your definition of "abuse"?

This feels a lot like when i hear about "GPL" abuse when it was specifically
not designed for what people think is abuse (and that's not my view but
stallman's).

Similarly, AGPL was _not_ designed to require every piece of software around a
piece of AGPL software to be open sourced.

Deliberately so. Not doing so is not "abuse".

You may have different goals, and that's actually fine! But it doesn't make
following the license and what it was meant for abuse.

I'll also point out: In the history of my work on open source, by _far_ the
largest legal abusers of open source are startups. By many orders of
magnitude. This is real abuse in the sense of clear license non-compliance. I
worked on M&A at a variety of companies that acquired all sorts of different
kind/stages of startups.

They _rarely_ are compliant with even simple notice licenses (IE don't bother
to post notices), let alone any of the more restrictive licenses.

Large corps often have legal departments that try to understand and consider
and figure out what to do, even if they do it wrong.

So to me, every time i hear "large company open source abusers" i kind of
laugh, because IMHO getting the startups to stop abusing open source would
have a _much_ more significant difference on OSS than getting 2 or 3 large
companies to stop "abusing" it.

~~~
mrkurt
Abuse is taking all the free candy at a doctor's office. It might just violate
a norm without breaking a law, but it's still abuse.

It's situational, but if you define abuse as "breaking a contract or law"
we're not going to agree on anything about this.

MongoDB has _always_ wanted to make money when other people make money
reselling their work. The AGPL doesn't really do what they needed, but their
intent has been clear since day one.

~~~
chaostheory
> Abuse is taking all the free candy at a doctor's office.

This is a bad analogy for software, since software is not a finite resource.
Anyone can make a near infinite number of copies.

Don't blame 3rd parties when you realized that an open source license is the
wrong license for your product.

~~~
mrkurt
It's bad analogy, but the candy bowl in this particular example is "revenue
available to companies selling this stuff". The cost to duplicate these things
is 0, but the available income is fixed.

~~~
chaostheory
I'm assuming you're not being sarcastic. Is there a monopoly on SAAS for
Mongo?

I don't think this takes away from MongoDB picking the wrong license and
business model.

------
DannyBee
FWIW: This license is almost certainly incompatible with GPLv3.

They struck the portion of section 13 that allowed for such combinations.

(You can see it in the redline they published
here:[https://webassets.mongodb.com/_com_assets/legal/SSPL-
compare...](https://webassets.mongodb.com/_com_assets/legal/SSPL-compared-to-
AGPL.pdf))

~~~
detuur
_Everyone is permitted to copy and distribute verbatim copies of this license
document, but changing it is not allowed._

Can someone enlighten me on the significance of this piece of text? Does it
mean you're not allowed to edit the license and publish it under the same
name, or does it effectively copyright the entire license text? I'm
gravitating towards the former since this is a case where the text was edited
but renamed, but I'd still like some clarity.

As an aside, is it even possible to copyright a license? There's a copyright
notice so isn't this technically plagiarism?

------
ReverseCold
I used to like permissive (OSI) licenses a lot more than restrictive licenses,
but now I like copyleft better (for my own projects) because…

1\. You’re still helping education, nonprofits, and individuals benefit from
your work.

2\. It’s still open source, so people will still be able to contribute and use
your work in their own projects.

3\. Companies that want to use your code to make money can do so, but only if
they also help out the other “worthy” causes by contributing changes back.

In fact, I'm consider something more radical like a YUMMY license (you make
money, I make money) - which has all the same benefits of being open source
and helping worthy causes, except at least you get to make money when someone
uses your work to do something that you might not even want, like selling ads.

~~~
Doctor_Fegg
I really like WTFPL as a permissive licence in these cases.

Small developers and companies without layers of lawyers will read the
licence, see that it says "do what the ---- you want", and use your code
accordingly.

Big companies with layers of lawyers will read the licence, blanch in terror,
and either refuse to use the software, or contact you for alternative terms.

Case in point: Google forbids use of the WTFPL.
[https://opensource.google.com/docs/thirdparty/licenses/#wtfp...](https://opensource.google.com/docs/thirdparty/licenses/#wtfpl-
not-allowed)

~~~
DannyBee
So i'm the one who forbid WTFPL at Google, and we forbid it mainly because
it's bad for developers, believe it or not.

We go over it in new googler training (and our reasoning is on the Google open
source policy site we publish:
[https://opensource.google.com/docs/thirdparty/licenses/#wtfp...](https://opensource.google.com/docs/thirdparty/licenses/#wtfpl-
not-allowed))

You are welcome to not (but if you go and look, it's completely consistent
with my viewpoints and history in OSS so ...).

I would love to live in a world where WTFPL is a good license, but we don't
live in that world, and wanting it to be so will not change that.

I can also tell you stories of companies we've acquired who had bad
experiences, FWIW.

So the "small companies" you think are being served, aren't.

~~~
Doctor_Fegg
I do understand your viewpoints. I just disagree that they're significant
enough in practice to outweigh the value I see in WTFPL.

The lack of a warranty disclaimer isn't an issue in practice; my readme just
says "WTFPL, no warranty". The vague rights grant isn't something I've seen as
an issue in analogous situations in case law.

More important, to me, is what WTFPL says about my code: I'm not precious
about it, I give it to you, I trust you to go do amazing things with it. It is
a very humble licence. It says life is too short to get precious about licence
wankery. Plus there's the side-effect that small companies and artisan
developers can use it, while behemoths like Google won't. These, in my view,
are all to the good.

I don't expect you to share that view, but for these reasons, WTFPL is a "good
licence" for me. OpenStreetMap thrived for years with a WTFPL-licensed editor
(I wrote/maintained it). No-one died, no-one got sued, and OSM became one of
only four worldwide geodatabases. The main reason the current editing software
isn't WTFPL (I started it but handed over to more talented developers pretty
quickly) is that Intel wanted to use it, went "WTF WTFPL", and asked the new
maintainer to change it. He did, but tagged the next release idiot-intel-
lawyers. I laughed.

(IANAL, though I have spent way too much time over the past 15 years studying
licenses and their applicability across different jurisdictions, again
principally in connection with OSM and with its - very successful - licence
change.)

~~~
DannyBee
"The lack of a warranty disclaimer isn't an issue in practice;"

There have in fact been developers sued (and they lost!) over this very issue
in analogous situations, so i'm not sure why you say this.

"my readme just says "WTFPL, no warranty". The vague rights grant isn't
something I've seen as an issue in analogous situations in case law."

I'm not sure where you looked. Judges have varied wildly in what they have
done in analogous situations.

We are nothing if not data driven. If we didn't have very good data that
suggests it is an issue, we wouldn't care.

~~~
Doctor_Fegg
If you could share some of that data, that would be helpful.

------
super3
What really should happen is that the large cloud companies (really just
Google, Amazon, and Azure) should be providing a portion of the revenue
generated to the open source projects. The open source companies would make
more features and drive more usage. Everybody wins. It makes no sense that the
large cloud providers make billions off OSS, and don't give something more
sustainable back. Classic tragedy of the commons.

Disclaimer: My company Storj is building a distributed Amazon S3 competitor
and we are actually partnered with MongoDB. We share revenue with MongoDB for
any customers they bring us.

~~~
swozey
Your 3 examples have a LOT of swes that work full time on open source/cncf
projects not to mention they're platinum members of CNCF/Linux Foundation,
etc. So I think that's a bit disingenuous. They're not funnelling billions
into those tunnels but a huge majority of contributors are Redhat, Google,
Coreos, Huawei, Alibaba, Intel and various other big names that definitely use
open source tech and provide a huge benefit to us that are consuming it. K8s
is moving so fast it's hard to even follow.

Kubernetes was donated to CNCF and there are a lot of Google SWEs working on
"removing Google" from the actual project to make it more cloud native.

I really have a hard time picturing the success of CNCF/etc without the big
names.

~~~
wmf
From a global perspective it looks pretty fair that some company uses a lot of
open source software and also contributes a lot. But it doesn't get anyone
paid. If you're toiling away unpaid on Redis or MongoDB or whatever, the fact
that Google gave the world k8s does not help you.

~~~
merb
> the fact that Google gave the world k8s does not help you.

so google should give everything away AND also need to pay to every open
source project, besides that smaller player don't?

sorry the world does not work like that. open source means giving and taking,
not only taking. google might not be an angel, however restricting them to pay
- OPEN SOURCE, non restrictive work - is just silly.

------
jamescun
I guess this explains why MLab submitted to MongoDB's acquisition after all
these years, let us buy you because we're killing your business model.

[https://blog.mlab.com/2018/10/mlab-is-becoming-a-part-of-
mon...](https://blog.mlab.com/2018/10/mlab-is-becoming-a-part-of-mongodb-inc/)

------
PeterZaitsev
In my opinion whenever SSPL is classified as Open Source license or not they
could have done better job rolling it out.

Making announcement and having all MongoDB Community Software change license
the same day for all current major versions (not just new major releases) is
not very friendly to users of such software

Many companies which are serious about their software licenses will need to
evaluate whenever they can use SSPL, in the meanwhile being left without
access to security updates... not a good place to be.

Though I suspect MongoDB would just like such companies to use Commercially
Licensed Enterprise Version and not deal with all these Open Source (or not)
license change

Advance Submission to OSI and validating it as Open Source License would
reduce the concerns of companies looking to use MongoDB Community as they
could rely on OSI's legal analyses rather than perform their own

------
nine_k
The meat of the change:

 _SSPL explicitly states that anybody who wants to offer MongoDB as a service
— or really any other software that uses this license — needs to either get a
commercial license or open source the service to give back the community._

Looks like a pretty straightforward extension of GPL principles, by replacing
the linking of licensed code to remotely calling the licensed code.

It can have _a lot_ of implications for service providers and commercial
developers alike, depending on the way commercial licenses will work. (Some DB
licenses have pretty stifling clauses, like Oracle's or MS SQL's.)

~~~
johncolanduoni
MongoDB was already under the AGPL (which adds the copyleft via network
provision) so I suspect there is a bigger difference than that.

~~~
nine_k
AGPL requires you to share the changes to the licensed software you make
available, that is, changes to the MongoDB itself.

It was like LGPL in the local case: you alter the library and make it
available through the software you link with it, so you have to share the
changes you've made to the library, but not the rest of the linked code.

With SSPL, it's like the full GPL in the local case: if you take the licensed
software, and link it (via rpc / network) to your other software, you must
share not only any changes you've made to the licensed part, but the whole
thing that uses it.

Another tricky question is where the border line is. If I write a wrapper that
interfaces with MongoDB and repackages its data, then makes them remotely
available to the rest of my service, do I only need to share the wrapper? If
not, and any network connection that substantially uses an SSPL piece counts,
then do I have to share my internal monitoring system? Am I even allowed to
connect closed-source data analysis tools to an SSPL database? Etc.

~~~
metheus
> if you take the licensed software, and link it (via rpc / network) to your
> other software, you must share not only any changes you've made to the
> licensed part, but the whole thing that uses it.

Slight modification makes this accurate to the SSPL: if you take the licensed
software, and link it (via rpc / network) to your other software _which you
use to offer the SSPL licensed software as a service_ , you must share...

> Another tricky question is where the border line is.

Ultimately the trigger of the SSPL is whether what you offer publicly is the
SSPL-licensed software as a service. It doesn't trigger the SSPL if you make
MongoDB available as a service to your application internals as long as what
you're making available publicly is not "a service the value of which entirely
or primarily derives from the value of the Program or modified version..."

~~~
nine_k
Playing a devil's advocate. Suppose somebody made a clean-room implementation
of a MongoDB driver that contacts MongoDB, then passes the data to a MongoDB-
compatible interface that shares no code with MongoDB. This wrapper is duly
shared. Can that guy then offer a SaaS MongoDB-compatible DB by exposing this
driver, connected to a real MongoDB, without a commercial license?

As we notice, all that SSPL would require to share is shared in this case.

Then a wholly-owned subsidiary could build various value-added services on top
of _that_ MongoDB-compatible thing without a commercial license. This of
course would fail if the wrapper would need to be licensed under SSPL, too.

~~~
metheus
The SSPL neatly sidesteps that workaround. It does not specify anything about
the provenance of code, or the extent to which code is shared with the
licensed software's code.

If you offer a service based on the licensed software, and the value of the
service being publicly provided entirely or primarily derives from the
licensed software, every bit of code -- the clean-room driver, the compatible
interface, the admin scripts, UI for management, etc. -- used to offer that
service must be made available under the SSPL.

------
vmbrasseur
Vice President of the Open Source Initiative here.

MongoDB submitted this new license for approval by OSI at the same time that
they announced that they'd relicensed all of their code. We wish they'd
started the process prior to the announcement, but what's done is done. The
result, however, is that at this moment, MongoDB is under a non-approved
license and therefore IS NOT OPEN SOURCE.

As the license review process only started this morning, there's no way to
estimate how long the process will take. There also is no guarantee that the
license will be found to obey the Open Source Definition, and therefore no
guarantee that it will be approved.

Hopefully this will all be resolved soon, but there are far too many question
marks around this license (and therefore also around any software using it)
right now. It's probably best to limit your legal risk by not upgrading to an
SSPL-licensed MongoDB at this point. The previous AGPL-licensed version should
always be available.

~~~
sam0x17
1\. The idea that OSI seriously thinks it gets to decide what counts as open
source is laughable. This is akin to Linux being released for the first time,
and Microsoft issuing a warning that they have not yet verified that Linux is
a "real" operating system, and to stay tuned for their final judgement. The
arrogance here is hilarious. I've been working in open source for years and
I've never, ever heard of OSI.

2\. All "open source" really means is that the source code is available in
some way/shape/form, with no implication whatsoever made about the license of
said code. "Free and open source" on the other hand implies a permissive
license.

3\. I don't know anything about the MongoDB license before or after these
changes, I just despise the tone of this message.

So to recap. OSI is just some random organization with no bearing on what
society decides open source is or isn't, and therefore what they say DOES NOT
MATTER.

~~~
joshsimmons
Open source is a term of art with an agreed upon definition, and it has been
for 20 years which, not-so-coincidentally, is also when the Open Source
Initiative was founded.

The fact that you've never heard of OSI means we've been doing our job well
enough that you've never needed to know about it.

The fact that you've never heard of OSI does NOT mean that it's not
legitimate, and frankly, that kind of rhetoric is just silly.

~~~
PuffinBlue
If this is held true and everyone agrees it, all this conversation/wider
thread has served to show is that the term has reached 'genericization'.

The OSI can claim/define what is wishes to but in practice it has lost
authorship of the 'open source' definition.

Just like Google/Xerox/Kleenex/Taser/Bubble
Wrap/Dumpster/Escalator/thermos/Chapstick/Frisbee/Photoshop et al.

~~~
sam0x17
That's exactly the point I was trying to make.

------
hendzen
Disclaimer: IANAL.

From MongoDB, Inc's POV, its fine to run MongoDB in-house for the purposes of
supporting some user-facing application. Coinbase would be a good example,
they make a consumer product that uses MongoDB as the storage backend.

What is definitely not allowed is selling fully hosted MongoDB instances. E.g.
([https://cloud.yandex.ru/docs/mdb/](https://cloud.yandex.ru/docs/mdb/)). To
do this you will need to open-source all the supporting infra/automation code
which will be a deal breaker in many cases.

The real grey area is a service like Parse or Firebase that is built on Mongo
but offers a Mongo-like DBaaS. Is it against the SSPL to build a service like
that? Or is MongoDB, Inc trying to force everyone to use its MongoDB Stitch
service [0]?

[0] -
[https://www.mongodb.com/cloud/stitch](https://www.mongodb.com/cloud/stitch)

~~~
merb
> To do this you will need to open-source all the supporting infra/automation
> code which will be a deal breaker in many cases.

it isn't actually I guess google runs their RDS on kubernetes anyway.

------
amirathi
None of OSI's Open Source licenses (including AGPL) protect creators financial
interest in the cloud first world. Period.

I want to issue "View and Internal Use License" for my work. Anyone can view
the source code, modify, and use the software for their own benefit as they
see fit. Under no circumstances can anyone sell/re-distribute/host the paid
version of software or any derivative thereof. Why can't OSI create such a
license?

I understand the spirit of OSI is to foster more usage of open source
software. I admire it. But probably a LOT of open source software is not
getting built in the world because it's not possible for everyone to spend few
months/years of their prime without any financial outcome (not even a
possibility of it).

I'm a developer who spent 3 FULL days reading up licenses for my indie project
[1] that I aim to make some money with. Not even a single license was adequate
to protect me from large teams/companies if the software were to become
popular. I resorted to only open sourcing a required critical library [2].

[1] [https://www.nurtch.com/](https://www.nurtch.com/)

[2] [https://github.com/Nurtch/rubix](https://github.com/Nurtch/rubix)

~~~
the_af
The license you describe, while definitely useful, is not open source by any
meaningful definition of the concept. I don't mean "not OSI open source", but
"not open source as the term has evolved". Similar licenses have been tried
(see Microsoft's Shared Source Initiative) and you can definitely devise one
yourself and no-one can stop you.

The "world" won't let you call your license open source for good reason: it's
not open source.

~~~
amirathi
> The "world" won't let you call your license open source for good reason

What is that good reason?

Is prohibiting commercialisation of my work not in the spirit of open source?
How is my "View and Internal Use License" bad for the open source ecosystem?

~~~
the_af
> Is prohibiting commercialisation of my work not in the spirit of open
> source?

Exactly, it's not.

> How is my "View and Internal Use License" bad for the open source ecosystem?

Whether it's bad is a value judgment I can't answer; it's not open source
because it forbids redistribution of the source.

~~~
amirathi
Do you not see any problem with that? Companies who are good at
commercialisation gets all the dough for work created by small group of
inventors. Is protecting inventors interest not important? Isn't this
negatively affecting the ecosystem where there's less motivation for inventors
to create open source software in the first place?

> it's not open source because it forbids redistribution of the source.

This can be solved easily. The "View and Internal Use License" can allow
redistribution under the same license (verbatim).

~~~
the_af
I'm not going to debate open source with you, because as you can imagine this
is a topic that's been debated for decades, and as any debate that mixes
philosophical and technical issues, it's definitely neither easy nor clear
cut.

Open source is mostly about _user rights_ (making things more confusing, a
_user_ is sometimes also a _developer_!). By restricting the users' right to
resell or redistribute the source code of your software, you are effectively
making it not open source. If you think an open source license is not in your
best interest because of these rights, it'd be totally understandable if you
decide not to use one.

> This can be solved easily. The "View and Internal Use License" can allow
> redistribution under the same license (verbatim).

I think you'll find once you add all the necessary provisions for adding users
rights, you'll end up with an open source license :) I'd be wary of saying
"this can be solved easily": if you follow any kind of debate about software
licenses, proprietary or otherwise, you'll see there's _nothing_ easy about
them. Any license that is more complex than "do whatever you want with this"
is probably not easy.

~~~
amirathi
> By restricting the users' right to resell or redistribute the source code of
> your software, you are effectively making it not open source.

Then the discussion Open Source ecosystem needs to have is whether "protecting
users' right to resell" is net positive or net negative for the ecosystem. And
answer could go either ways but that dialogue needs to happen.

Last major update amongst any of the popular OSS license was in 2007 to AGPL.
It's been 11 years and SaaS/Cloud world has changed a lot in this time. Maybe,
just maybe, it's time to review and see if we need an additional license
that's net positive for the ecosystem.

Just accepting current textbook definitions of Open Source and abiding by it
all our life seems too pedantic.

~~~
the_af
It's not the "current textbook definition" but a living consensus. This
"dialogue" you want begun decades ago and is still ongoing. I'm not sure why
you think otherwise. (If you want an even more difficult debate, there's the
"open source" vs "free/libre software" thing:
[https://www.gnu.org/philosophy/open-source-misses-the-
point....](https://www.gnu.org/philosophy/open-source-misses-the-
point.en.html))

> _Then the discussion Open Source ecosystem needs to have is whether
> "protecting users' right to resell" is net positive_

Well, reselling is not the most important aspect; it's a side-effect of
unrestricted users' rights. If you restrict users' rights (e.g. you forbid
reselling), open source becomes less appealing and not particularly different
to Microsoft's Shared Source and similar proprietary-but-you-can-see-the-
source licenses.

By the way, "net positive" is a tricky concept. Open source is in my opinion a
"net positive", but it involves some trade-offs. Proprietary licenses like the
one you seem to favor also have trade-offs.

> _it 's time to review and see if we need an additional license that's net
> positive for the ecosystem._

Which ecosystem is that?

To be honest, it seems to me you don't want an open source license. And that's
fine. Not sure why you want open source to change its meaning to what you
propose (which isn't new either), instead of simply accepting the license you
want/need is not open source.

------
manishsharan
This is a bad move and does not inspire confidence.

Instead of switching the license, they should have gone after companies that
were abusing the terms of GNU AGPLv3 license.

~~~
antirez
To legally fight in China pretending that something you can't see was modified
is... hard. IMHO the only wrong thing about this move is trying to get it OSI
approved, otherwise I can understand that they have concerns that do not apply
to most normal users. However one should boldly say we are moving away from an
OSS model, to a "available source" model where you retain _most_ rights.

~~~
kstrauser
How is those going to affect China? If the old enforcement methods didn’t work
with the previous sane-ish license, they certainly won’t work any better with
the new monstrosity.

~~~
antirez
Now you don't have to pretend that they changed something without having any
way to prove it. Now if the orchestration software is not open source, they
can't use it.

~~~
mbreese
They could just claim that their orchestration software is open-source
(potentially w/o stating what it is), or just publish a stub set of scripts
that plausibly work but that aren't actually used under the hood. I'm not sure
this really makes things all that much clearer.

------
ken
It's their code so (under current law) they can license it however they want.
I see some potential issues, though.

> "Inclusion of a covered work in an aggregate does not cause this License to
> apply to the other parts of the aggregate."

I don't see how to reconcile this with the new section 13, which seems to say
exactly the opposite. What does this section mean, now that section 13 was
completely changed?

> it has now submitted the SSPL for approval from the Open Source Initiative

IANAL but I don't see how it satisfies part 9 of the OSI Definition, or the
DFSG. As DannyBee already mentioned, it's also incompatible with other
existing open-source licenses. Why do they want to continue calling it "open
source"? It sounds like they really just want to be a proprietary database.

> For virtually all regular users who are currently using the community
> server, nothing changes because the changes to the license don’t apply to
> them.

Really? It's written in a way that sounds like it captures all _users_ under
the same umbrella as _resellers_. If I wrote a data analysis web app that
happened to use MongoDB (as one of my previous employers did), isn't that a
case of adding "user interfaces" (and "storage software and hosting software")
for it, meaning I'd need to provide source code for "all such that a user
could run an instance of the service using the Service Source Code you make
available"?

I can't find any _license_ pricing info on the MongoDB webpage, but some
googling turned up a whitepaper that puts MongoDB licensing at around $11,000
per server per year. That basically means MongoDB's own "cloud" services are
the only game in town. ("No, Mr Bond, I expect you to die.")

That means there's a single provider of this API, and you can't afford to run
your own server, so it's essentially cloud-only, and it might not be legally
compatible with other open-source software you want to use anyway. That's a
whole lot of risk you're asking me to take on. Is MongoDB so much better than
any free database, for any new users, that it's worth this risk?

~~~
rand0mthought
> IANAL but I don't see how it satisfies part 9 of the OSI Definition, or the
> DFSG. As DannyBee already mentioned, it's also incompatible with other
> existing open-source licenses. Why do they want to continue calling it "open
> source"? It sounds like they really just want to be a proprietary database.

They want to charge money and have control as a proprietary database. But they
want to keep a label "open source" purely for marketing purposes.

------
unethical_ban
I'm embarrassed by the lack of comprehension people have for the idea of the
OSI saying something isn't open source. The OSI has been around for a long
time, has a consistent track record of helping organize FOSS licenses and
create a framework/lexicon for this very purpose. They absolutely have the
right to say if something is open source or not, according to their rules,
just like anyone here gets to make their opinion heard on something. "Appeals
to authority" make sense when the authority is credible, and shortcuts having
to explain the four freedoms, etc.

\---

To the article: It sounds like the SSPL will eventually be OSI-OSS, but I
wonder if they couldn't have worked with GNU to create a new version of the
AGPL. Granted, GNU might take exception to the idea of "oka you don't have to
share the code, you just have to pay us" portion.

~~~
gfosco
I think it's more about the tone and the caps lock, than the exact words,
although you shouldn't be embarrassed if some people disagree and think the
phrase has been generalized. If anything, I think it might be embarrassing how
many "defenders" jumped in and prolonged this drama, instead of just
downvoting and moving on with their day. How's this for a conundrum: I support
the OSI being able to claim it isn't "open source" according to them, but I
think the top-level post by the VP was unprofessional and rightly called out.
(I have not commented elsewhere in this thread.)

------
zokier
The license is clearly based on (A)GPL which is copyrighted by FSF, and has
the following notice: "Everyone is permitted to copy and distribute verbatim
copies of this license document, but changing it is not allowed."

Does that mean that MongoDB is now infringing on FSF copyright of the license
text itself?

~~~
metheus
SSPL is based on the GPL, not the AGPL, so no, the SSPL isn't itself a
copyright infringement.

BTW, check out the "What specifically is different between the GPL and this
new license and what will it be called?" section of the FAQ:

[https://www.mongodb.com/licensing/server-side-public-
license...](https://www.mongodb.com/licensing/server-side-public-license/faq)

~~~
zokier
> SSPL is based on the GPL, not the AGPL, so no, the SSPL isn't itself a
> copyright infringement

I don't see how the distinction makes a difference here, both have the same
clause about changing not being allowed.

~~~
metheus
Oh, sorry, that was a non-sequitur. The actual reason is that text doesn't
mean you can't modify them and create new licenses, it means you can't modify
them and still call them A/GPL.

[https://www.gnu.org/licenses/gpl-
faq.en.html#ModifyGPL](https://www.gnu.org/licenses/gpl-faq.en.html#ModifyGPL)

------
jchw
People weren't "testing the boundaries" of AGPL. You need to know nearly
nothing about AGPL to understand this. The bottom line is, AGPL merely
requires you to publish your modifications. But if cloud providers are
offering essentially a vanilla MongoDB instance, there is no reason they are
compelled to buy a commercial license.

Still, I wonder where MongoDB actually wants the boundary drawn. Anyone that
tries to offer the MongoDB protocol as a service using the official code? Or
is it if I provide a database interface to a MongoDB instance? Or is it only
if the actual MongoDB interface from the MongoDB server is provided? I haven't
read their new license but I have a strong feeling that it won't be 100% clear
yet.

~~~
e12e
And will they break the protocol in order to break compatability with AGPL
forks?

~~~
jchw
This would be futile. The forks could still implement the protocol changes as
long as they didn't take code from upsteam to do so.

I believe there is also case law that supports the legality of reverse
engineering for interoperabilility as well. I wonder if that has implications
on this.

------
oropolo
This license seems to insure that MongoDB Inc either gets all source code to
Mongo-as-a-Service from their competitors (which they can use to make a better
service themselves) or they make money from all of their competitors through
commercial licensing. Perhaps Oracle is preparing to acquire MongoDB Inc and
this move is a prerequisite to acquisition?

------
oropolo
I might be reading this wrong, but doesn't this qualify as a "super viral"
license in that any code that in any way is part of the stack for hosting
Mongo as a Service __must __be open sourced as well? Granted, a company could
buy a commercial license to avoid this but if (for the sake of example) Azure
's Mongo hosting was using the open source license would this mean that
EVERYTHING that goes into Azure, down to Windows "Redstone" source code, would
need to be released?

~~~
e12e
I think this is what a few of the "new" db companies _thought_ the AGPL was
(neo4j comes to mind).

Not simply "if you write a new query parser and link it into our db, any SaaS
customers must get the modifications so the can continue running the service
for themselves if you go under.", but more "if manage to extract value by
hosting this software, you must give us a cut or all your code".

I guess there'll be a fork, like with matiadb/mysql?

------
shadowmint
details: [https://www.mongodb.com/press/mongodb-issues-new-server-
side...](https://www.mongodb.com/press/mongodb-issues-new-server-side-public-
license-for-mongodb-community-server)

actual license: [https://www.mongodb.com/licensing/server-side-public-
license](https://www.mongodb.com/licensing/server-side-public-license)

Typically, TC didn’t bother to even link to either. :/

------
kbumsik
I personally see why MongoDB switches its license and clarify their original
intention of using AGPL.

I even didn't know it was AGPL until now (I'm not MongoDB user). Because so
many people seem to use it as if it is Apache License or something free of
charge. I haven't see any warnings on AGPL and its implications in MongoDB
tutorials on the internet.

~~~
mrkurt
The drivers are all permissive OSS licenses. It's on purpose, they never
wanted to own applications that are built on top of MongoDB, but they never
wanted to give away the server bit either.

~~~
kbumsik
I meant people seem to install the server too, thinking that the server itself
it free. Most of MongoDB tutorials on the internet starts with "how to install
locally" without mentioning nothing about the license.

~~~
nepeckman
The server _is_ free. As long as you don't modify the server, you don't have
any obligations. If you do modify the server, you're only obligated to publish
the changes you made to the server. No one is at risk of violating the license
by installing it locally and using it in an application.

~~~
lacker
_The server _is_ free. As long as you don 't modify the server, you don't have
any obligations._

Well, that isn't true any more. If you start selling MongoDB functionality as
a service, you now have obligations, even if you didn't modify it.

~~~
nepeckman
Yeah good point, though even under this new license, you shouldn't face issues
for locally installing the server and using it in your application.

------
gregwebs
My reading of the below essentially says: you cannot offer MongoDB as a
(closed) SaaS (without purchasing a license). There will be debate though
about how far-reaching this clause is. Note that MongoDB as the copyright
holder is giving themselves a different license for running Atlas. I don't
know if this is the only change to the license, but the below is certainly not
part of the AGPL:

13\. Offering the Program as a Service. If you make the functionality of the
Program or a modified version available to third parties as a service, you
must make the Service Source Code available via network download to everyone
at no charge, under the terms of this License. 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,
offering a service the value of which entirely or primarily derives from the
value of the Program or modified version, or offering a service that
accomplishes for users the primary purpose of the Software or modified
version.

"Service Source Code" means the Corresponding Source for the Program or the
modified version, and the Corresponding Source for all programs that you use
to make the Program or modified version available as a service, including,
without limitation, management software, user interfaces, application program
interfaces, automation software, monitoring software, backup software, storage
software and hosting software, all such that a user could run an instance of
the service using the Service Source Code you make available.

------
mindcrime
My biggest problem with this is just that it contributes to "license
proliferation" even if OSI certifies it. It muddies the waters and makes OSS
licensing that much more confusing. In this regard, I'm fairly leery of it.

As for what they're trying to accomplish... it sounds like a slightly
different version of the AGPL (in spirit), and while I'm not the biggest fan
of the AGPL and similar licenses, it's not the abomination that the Common
Clause stuff was. This seems to just be saying "if you want to offer a MDaaS
(MongoDb as a Service), you have to release the source code to the entire
service". It's probably not a license I'd choose, but it's not exactly
unreasonable.

Disclaimer: I haven't read the entire license yet, so my comments above are
based on other people's summaries / the text of the article linked above. My
opinion is subject to change once I've had time to digest this fully.

------
xmichael999
The prohibition on providing the software as a service appears to conflict
with, or at least be trivially bypassed by, section 9 which states that to run
the software you don't have to accept the terms of the license. Section 9
conforms with the law as written: running the software, and making the copies
needed to run it, are explicitly not an infringement of copyright (USC Title
17 section 117(a)(1) [cornell.edu]). If I don't have to accept the license to
do something, I'm not bound by it's terms merely because I do that something.

[https://www.law.cornell.edu/uscode/text/17/117](https://www.law.cornell.edu/uscode/text/17/117)

------
mrahmadawais
As an open source dev, I think the new SSPL license of @MongoDB is
interesting. SaaS is the new black nowadays, I have seen too many companies
burnt down trying to support their OSS licensing with SaaS taking all the
benefit. SSPL can help #OpenSource.

I also think that SSPL can be very helpful if you want to open source your
SaaS. Most of the startups that I consult with are not interested in open
sourcing their actual SaaS software since they fear being ripped off.

So, what happens is that they end up not taking the benefit of open source.
With SSPL these SaaS companies will be able to open source their SaaS is
software to manage SaaS — without the fear of being misused by competition.

If the competition just takes their free software and makes money with SaaS
that hurts them instead of helping them since you can't make sure that other
SaaS players will actually contribute back to the software.

With SSPL, we get a safety net — companies either won't use it as a SaaS, will
pay to use it as a SaaS i.e. they'll help pay for open source software support
which is a very good business model and if not that, then they'll have to open
source their SaaS as well.

As a non-lawyer developer, it feels like GPL. GPL code that you fork should
remain GPL. Similarly, if SSPL code you use as a SaaS then you should keep
your SaaS as SSPL and open source it as well.

Peace! ️

------
pron
If SaaS vendors haven't opened their software that uses Mongo under AGPL then
I would assume that the additional software (which would count as another
"part of the aggregate" according to AGPL), then it must have been
substantial. In that case, how does one determine if one is "offering a
service the value of which entirely or primarily derives from the value of the
Program or modified version, or offering a service that accomplishes for users
the primary purpose of the Software or modified version"?

I assume that an online game that uses Mongo to store player data clearly does
not derive its value mostly from the database, but is the value of a PaaS
built on Mongo, with an elaborate UI and management services derived primarily
from the value of Mongo or not? Is the value of an online recipe management
service? In both cases I can see compelling arguments in either direction.

One could argue that if the value derived primarily from the DB, then very
little software would need to be added and open sourcing it would not be an
issue. That vendors don't open source their software shows that they believe
its value does _not_ come primarily from Mongo, and so they would be able to
continue using it under the new license, defeating Mongo's purpose.

------
sbr464
This question isn't directly associated with MongoDB, please forgive my lack
of OSS license expertise.

I was curious if exceptions were allowed under licenses like these. For
example, if a company releases a GPL licensed product, (or SSPL etc) and
wishes to create another product/service that they don't wish to open source,
but it's based on the GPL/SSPL codebase. Could they make exceptions or
separate license agreements to go around their own license choice? Would it be
different if it were a third party they would like to give this exception to?

In similar regard, would MongoDB have to prove that they are paying full
licenses/Enterprise agreements to themselves to be able to run Atlas (their
own cloud offering) and not open source Atlas? Or is there a self exclusion
allowed etc? Or would they just sell themselves the licenses for $0.01 cent to
get around the requirement?

Truly interested in this question.

Edit - and to clarify, not if the exception is stated directly in the license
like a new modified MIT etc, but inherent to the existing popular OSS
licenses.

~~~
Lazare
If I own a block of code, I can release it under as many licenses as I like,
even if those licenses would totally conflict, and then each one of my users
will need to track which license they received it under and adhere to those
terms (only). So yes, I can give Users 1, 4, and 5 a copy under the GPL, and
then users 2 and 3 a copy under some commercial license, user 6 under some GPL
incompatible copyleft license, no problem.

The key is where you say "wishes to create another product/service that they
don't wish to open source, but it's based on the GPL/SSPL codebase". You're
not creating it based on the GPL codebase, you're creating it on the codebase
_you own_. The fact you've previously licensed it under X, Y or Z licenses is
irrelevant; you can always release it again, in whole or in part, with
whatever license you like. (But of course, whatever you released under the GPL
is still out there, under the GPL; there's no take backs!) And you can also,
of course, use it yourself however you like.

The key is ownership. If you own the copyright on the code, you're fine. If
you don't, you must adhere strictly to the license which the actual owners
granted you. To the extent that MongoDB (the company) owns the copyright on
all the code, they're free to use it how they like, and release it as often as
they like under whatever licenses they like.

~~~
sbr464
Thanks for that detailed reply.

------
bad_user
I hope OSI and the FSF don’t approve their new “SSPL” license.

AGPL style licenses impose restrictions on usage, thus violating freedom 0 in
the Free Software’s definition or Open Source’s rule 6.

AGPL should have never been allowed, precisely because it opens the door for
commercial entities to eat their cake and have it too, being the kind of
license that can be effectively used to disallow commercial products built on
top.

In my opinion your own modifications that are never distributed (by the
copyright definition) represents mere usage. And we’re software developers
after all, personally I patch most of the libraries I end up using and some
patches I may contribute back, but I’m definitely not required by any license.

“Open Source” and “Free Software” have great sex appeal, I get it, but if you
can’t deal with competitors benefiting from your work, which is the whole
point of such an endeavor, then don’t do FOSS.

Go proprietary and be honest about it.

~~~
jahewson
> AGPL style licenses impose restrictions on usage

No, not in the commonly understood sense of "usage" as "field of endeavor". I
understand what you're getting at but anybody can use AGPL'd software for
anything. They just need to publish any modifications they make to said AGPL'd
software. It's a restriction, but not on "usage". Such a restriction would be
something like "you can't use this in the nuclear industry" or "you can't sell
this".

~~~
bad_user
For me usage is the ability to modify it for my purposes.

Writing a script that interacts with said software to enhance or modify its
behavior is as easy as clicking an UI button and I don't see a difference.

Also the "understood sense" is irrelevant. Usage is whatever you do with it
that's not _distribution_ in the sense defined by the copyright law.

The genius of the GPL licenses has been that they are just copyright licenses
handling distribution, but that don't impose any restriction on usage. This
was by design. Here's Richard Stallman's own take on "freedom 0":
[https://www.gnu.org/philosophy/programs-must-not-limit-
freed...](https://www.gnu.org/philosophy/programs-must-not-limit-freedom-to-
run.html)

> _" They just need to publish any modifications they make to said AGPL'd
> software"_

N.B. that's in fact a huge restriction, being a matter of costs too, because
"publishing any modifications" costs both time and money.

~~~
belorn
You can still modify it for my purposes so long all users who interacts with
it over a network has access to the modified source code. If the number of
users are you then modify away!

> Usage is whatever you do with it that's not distribution in the sense
> defined by the copyright law.

That is the tricky part. A video streaming site is considered distribution by
many copyright laws. There was a time where simply using a website was not
considered distribution, but then scope of copyright was extended and concepts
like "public performance" and "making available to the public" was applied to
works provided through web services.

GPLv3 however gives an additional permission that allow "interaction with a
user through a computer network", even if copyright law would forbid it.

~~~
bad_user
That's an interesting take on the matter.

Personally I agree with copyleft licenses for as long as they are just
restricting distribution as defined by copyright law. This because IMO there
needs to be a clear, lawful boundary for what FOSS licenses can and cannot
restrict.

Will look more into it.

------
jpalomaki
IIRC MySQL had a bit similar troubles with GPL license. They disliked the fact
that some companies shipped closed source software which in practice required
MySQL, but instead of getting the paid license, they relied on the open source
version.

Google revealed one relevant article:

According to C|net their vice president of marketing said in 2002: "There were
people misusing the GPL, using our server tightly coupled with their
applications, claiming the GPL didn't apply because the client libraries
weren't under the GPL, they were under the LGPL," [1]

According to the article, MySQL decided to sort out this issue by changing the
license of the client libraries from LGPL to GPL.

[1] [https://www.cnet.com/news/mysql-addresses-open-source-
licens...](https://www.cnet.com/news/mysql-addresses-open-source-license-
problem/)

------
emayljames
I predict a fork coming mongodb's way.

~~~
threeseed
MongoDB has already been forked 3,760 times on Github.

No need to thank me but I pressed the fork button again just to make your
prediction come true.

------
vbezhenar
They are hurting their own ecosystem, trying to get more money. Not a real
open source project, just proprietary software mimicking open source. Compare
to PostgreSQL, it's absurd to think that they would forbid using PostgreSQL as
a service.

------
kureikain
MongoDB gots lot of interesting features recently and probably got to a stable
line. They also have lot of product around MongoDB ecosystem:

\- Atlas to deploy \- Stitch to run serverless \- Chart for BI

So they basically want to protected their leverage, which make sense to me.

------
erlend_sh
It is still unclear to me how the release of any "Service Source Code" is
scoped. The license states:

> If you make the functionality of the Program or a modified version available
> to third parties as a service, you must make the Service Source Code
> available via network download to everyone at no charge, under the terms of
> this License

Would greatly appreciate it if someone could give an example of a MongoDB
service company and what parts of their proprietary code they would have to
release if they opted not to buy a commercial license .

~~~
grogers
> “Service Source Code” means the Corresponding Source for the Program or the
> modified version, and the Corresponding Source for all programs that you use
> to make the Program or modified version available as a service, including,
> without limitation...

It's as broad as it can be to make it essentially impossible to comply with
and force you to use the commercial license. You can't release the Linux
source under SSPL, but the OS would almost certainly qualify under this clause
(but IANAL). In the definitions it seems to exclude the kernel and "System
Libraries" but only if unmodified, it's still a but of a minefield.

------
beck5
The article references cloud providers, "especially in Asia", frustrating
MongoDb, does anyone know which companies these are or specifically what they
have done which other did not?

~~~
hendzen
Yandex is one example:
[https://cloud.yandex.ru/docs/mdb/](https://cloud.yandex.ru/docs/mdb/)

Probably the big public cloud providers in China (Alibaba etc) as well.

------
perseusprime11
"MongoDB is a bit miffed that some cloud providers — especially in Asia — are
taking its open-source code and offering a hosted commercial version of its
database to their users without playing by the open-source rules. To combat
this, MongoDB today announced it has issued a new software license, the Server
Side Public License (SSPL), that will apply to all new releases of its MongoDB
Community Server, as well as all patch fixes for prior versions."

That's how open source works. Isn't it?

------
exabrial
You assume this "Intellectual Property" or "Copyright" thing exists in China.
After working for a Chinese company, the concepts don't have an analog in
their culture. Actually the concept of licensure in general doesn't have a
good analog. They see open source as free and sort of brush off the strings
that are attached.

(this btw, should not be interpreted as bad mouthing them; I'm merely pointing
out a communication problem between two cultures).

------
gukspbk4gnnh
> some cloud providers — especially in Asia

Alibaba & Tencent have been offering managed MongoDB offerings for a while but
MongoDB, Inc. has historically not made any major investment in its own
managed offering (Atlas) for that market.

This license shift is aimed squarely at AWS, who is rumored to be ready to
announce/release their own MongoDB-compatible service at AWS re:Invent next
month.

~~~
nemo44x
What's the source of this rumor?

~~~
lacker
I have heard this from AWS reps for ages, for what it's worth.

------
thekozmo
I've written a blog about this: [https://www.scylladb.com/2018/10/22/the-dark-
side-of-mongodb...](https://www.scylladb.com/2018/10/22/the-dark-side-of-
mongodbs-new-license/) Spoiler: It's a big nono Disclosure: I'm ScyllaDB co-
founder

------
holografix
Is there an OSS license where it won’t allow other providers to offer the
original technology as a service and charge for it?

If I want to use MongoDB in my ecommerce app no worries. If I want to simply
use MongoDB offer some minimal improvement or added functionality, call it
ZongoDB and sell subscriptions... not so fine?

~~~
saurik
(With the caveat that I think what really matters here is "and hoard changes
and updates", not "make money at all":) The AGPL comes to mind, but I bet that
is slightly too viral? It is a hard problem: how do you legally differentiate
a web app built on top of MongoDB from a thin wrapper for MongoDB that
provides a minority different API from the backend (or might even simply be a
load balancer)?

~~~
metheus
"Software as a service" is a well understood concept, and on the strength of
that understanding, the SSPL is clear. (Although as with all things there are
edge cases, there aren't _more_ edge cases with the SSPL than with other
licenses.)

If your web app _uses_ MongoDB (or any SSPL licensed software) to provide a
value that is not substantially MongoDB itself, you are not making the
software available as a service. If your code facilitates making _MongoDB 's
features_ available to other users, you are providing MongoDB as a service and
are obligated to make all that code available under the SSPL.

------
tracker1
Likely a move since the purchase of mLab to eliminate competition in the
services space. Seems a lot like the recent changes with the direction of
Redis.

Hopefully this spurs some movement in supporting open database communities
better. PostgreSQL and RethinkDB being two that come to the front of my mind.

------
l2dy
> Making the functionality of the Program or modified version available to
> third parties as a service includes […], or offering a service that
> accomplishes for users the primary purpose of the Software or modified
> version.

Would this apply to independent implementations compatible with MongoDB?

------
jillesvangurp
IMHO a better move for them would have been to clear up the legal minefield
that comes with AGPL and move to a more business friendly license like the
Apache 2.0 or MIT license. These licenses are well understood and don't
cripple your users in any way.

I don't get why any business would want to scare their new users with a
license like the AGPL that I would argue is explicitly designed to create
legal uncertainty like that and popular with companies like Mongo primarily
for that reason (as opposed to some strong freedom related moral arguments).
Inventing your own license because the AGPL is giving your users to much
freedom sounds rather desperate (not to mention misguided).

Changing the license to Apache 2.0 might actually make them much more
attractive as an acquisition target for any of the big tech companies out
there looking to add something like mongo to their portfolio. I'd argue AGPL
is actually an obstacle for most of the bigger companies out there that have
existing business relations with their customers based on more business
friendly licenses.

It would also enable lots of people to experiment with using mongo without
legal worries and thus enable them to refocus their company around actually
creating value for their paying customers without alienating the vast majority
of non paying users with complicated licensing options.

Companies like Elastic (which recently did their IPO) are having plenty of
success with using the Apache 2.0 license without compromising on commercial
success. Their developer ecosystem includes lots of outsiders in the apache
community, the academic community, and users. The reason they are doing pretty
OK is that they have a decent monetization strategy that involves delivering
actual value to their customers: stuff their users want and are willing to pay
for. Stuff like proprietary add-ons (e.g. machine learning) on top of what
they ship for free, good support, training, cloud based hosting, consulting,
etc. We use their hosted Elastic cloud and I'd argue it is pretty good value.

------
pauldix
I don't think this really changes anything with MongoDB and how open or closed
it is in practice. This really is just MongoDB clarifying their original
intent with picking the AGPL. Basically, if you're going to offer MongoDB as a
service, you either need to make all your service's code freely available, or
you need a commercial relationship with MongoDB. This doesn't change anything
for users of the software that are building applications.

This is just another highlight of the cloud vendors making it very difficult
to build a business based on open source infrastructure software. Either you
pick an infectious license (like AGPL) or you go open core. Otherwise, if your
project gets popular, the cloud providers will offer it as a service, which
will eat into your revenue.

------
a012
Could this move of Mongodb inc. makes the comeback of the rethinkdb? I hope so

~~~
michaelcampbell
You seem like you know something about rethink. I do not, and couldn't find
this information but maybe you know?

One irritating feature of Mongo (and I suppose other db's too; orientdb does
this) is that once it grabs disk space, it never lets it go. It'll reuse that
space, but the OS will never see it again. (EG: If I store 10GB of stuff, and
delete 9GB of it, the OS still sees all 10GB of disk used).

Does rethink do this as well?

~~~
sbr464
You just need to iterate over the collections calling the compact command. You
can create a small script and schedule it.

------
qaq
I think long term model of Company opensourcing primary product will fail
outside of projects that are targeting niche too small for Azure/AWS/GCP to
monetize.

------
fareesh
Does MongoDB still suffer from data loss related issues? I checked out their
website and it seems to be fairly ubiquitous in usage

------
MrStonedOne
>MongoDB switches up its open source license

The correct term is forked. They forked the agpl and made modifications.

------
runciblespoon
“MongoDB switches up its open source license”

Is that the same as modify and/or improve?

------
thayne
Forgive my ignorance, but how is this different from the AGPL?

------
bkuhn
I posted my response on a blog post at:
[https://sfconservancy.org/blog/2018/oct/16/mongodb-
copyleft-...](https://sfconservancy.org/blog/2018/oct/16/mongodb-copyleft-
drafting/)

TL;DR: while vmbrasseur of OSI does say "what's done is done" in comments
here, I think the OSI shouldn't accept the proposal as submitted, and should
demand that licenses submitted them to have gone through a prior public
drafting process. This is particularly important for licenses whose stated
goal is to make fundamental changes to how copyleft works. GPLv3 and (even
better) copyleft-next made this the standard of how new license drafts are
done, and we should follow that standard.

~~~
vmbrasseur
My friend, the "what's done is done" was purely in reference to the fact that
the license was submitted for approval belatedly (IMO). My statement in no way
implied whether the license itself would be approved as it stands.

Now that the license has been submitted, folks can now analyse and discuss it,
openly. Any decision on the license will spring from those discussions and the
related actions (should any be needed) that MongoDB takes based on the
feedback they receive.

The proper place for that feedback is on the discussion thread on the review
mailing list. Statements on blogs and comments on Hacker News are good for
helping to frame that feedback, but aren't well placed to be included in a
cohesive conversation.

------
a13n
So what does this mean for IBM's Compose?

~~~
filoteo
Im wondering the same thing !

------
kolderman
What does "switches up" mean?

------
ousta
I guess next one that will do that - if this works- will be elasticsearch and
they will then have to fight amazon on this.

The risk being that if someone does a better job than MongoDB at creating
features for mongoDB they might loose their product as well playing that card.

