
MongoDB removed from RHEL 8 beta due to license - vbezhenar
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8-beta/html/8.0_beta_release_notes/new-features#web_servers_databases_dynamic_languages_2
======
giancarlostoro
It seems[0] the new MongoDB license is basically non-free and it would make no
sense to include it in RHEL8. I hope Debian and other distros follow suit as a
result if they come in agreement. It's sad that the license change all resorts
to greed basically, as if Oracle took over MongoDB.

If I were to ever use a NoSQL database for a new project I'd aim for MIT /
2-clause BSD based projects instead. PostgreSQL has no issue being BSD-like
licensed (all this time I thought it was BSD or MIT, turns out it's a similar
license instead). It saddens me RethinkDB couldn't compete more with MongoDB.

[0]:
[https://news.ycombinator.com/item?id=18919728](https://news.ycombinator.com/item?id=18919728)

~~~
merlynn
Michael from MongoDB here... Greed? You realize that anyone can still view,
download, use, develop, modify and do everything they could do prior to the
change - right? The only difference is that if they decide to offer the
licensed software as a public service they must release the other components
of the service under the same license.

~~~
jayofdoom
Honestly, from my perspective the problem is more the timing. If MongoDB had
always been licensed this way, companies could make informed decisions about
what product to use. Instead, you pulled a license bait and switch --
attracted people with a free-as-in-freedom license, then switched it for one
that was less free after adoption picked up. That's not behavior I'd
personally support as someone who has a career because of free software, and I
wouldn't support it professionally because of the immense risk a company takes
on when adopting a piece of software for long-term use -- like a DB.

~~~
karmakaze
As you may know there are different senses of 'free' at work here. How you're
using it is as 'freedom to use'. The other is 'freedom of the source code
information' which is to say that derivative works must also be released into
the open. Open-source now has these two competing views. I would complain if
software that was MIT licensed switched to a GPL one as it's switching camps.
I would complain less if a GPL one switched to AGPL. I agree that it's best to
choose the license that matches your beliefs from the start. We must also
accept that a change in license is a distinct possibility and that we are free
to fork.

------
hannob
Anyone surprised?

Of course you can choose a non-free license for your code, but it comes with
consequences. One of them is that Linux distributions that value free licenses
will no longer act as your distributor.

~~~
viach
This comment sounds like RHEL's license is more 'free' than Mongo's, which is
not the case, imho.

~~~
ergo14
Really? It's so non-free that you have CentOS.

~~~
bubblethink
Yes, but as a customer of RH, you are not allowed to distribute RH's binaries,
or they will terminate your contract. That is also against the spirit of the
GPL, although not necessarily the letter. You can take the source, remove the
branding, recompile, and redistribute, which is similar to what CentOS
does/used to. However, the GPL allows the former too. i.e., You can straight
up distribute the binaries under GPL.

~~~
timdierks
This is simply not true: it's explicitly not the intent of the GPL, and
furthermore the GPL is clearly a contract which explicitly spells out its
intent, not a vague document whose spirit needs to be interpreted.

~~~
bubblethink
It is explicit in the freedoms it grants you, one of which being the freedom
to distribute copies. The intent is pretty clear. The RH workaround to that is
that if you exercise this freedom, they will not do business with you in the
future. You got to exercise your freedom, but only once. The GPL doesn't have
recourse for that.

~~~
Frondo
You _can_ redistribute the source, and that's what really matters. No one ever
made any claims to redistributing binaries, and that's neither the letter nor
the spirit of th GPL.

The GPL is about user freedom, which relies on source code. The whole thing
came about because Richard only had access to binaries for that printer.

And it makes sense that RedHat wouldn't want you to distribute their
binaries...who's to say you didn't backdoor them? That's their name on the
line, too.

~~~
bubblethink
>You can redistribute the source, and that's what really matters. No one ever
made any claims to redistributing binaries

From [https://www.gnu.org/philosophy/free-
sw.en.html](https://www.gnu.org/philosophy/free-sw.en.html):

"Freedom to distribute (freedoms 2 and 3) means you are free to redistribute
copies, either with or without modifications, either gratis or charging a fee
for distribution, to anyone anywhere. Being free to do these things means
(among other things) that you do not have to ask or pay for permission to do
so. ..... The freedom to redistribute copies must include binary or executable
forms of the program, as well as source code, for both modified and unmodified
versions. "

------
preinheimer
This seems like a non-issue to me...?

The installation instructions I've always followed for MongoDB start with
importing a key, and adding their official repo to my source list. I'm a
debian user, but their redhat installation instructions are similar:
[https://docs.mongodb.com/manual/tutorial/install-mongodb-
on-...](https://docs.mongodb.com/manual/tutorial/install-mongodb-on-red-hat/)

I guess it will be a small speed bump for people experimenting their first
time, but I've never had any concerns about using a vendor provided source for
packages (third party provided ones are a different story.)

~~~
pilif
_> The installation instructions I've always followed for MongoDB start with
importing a key, and adding their official repo to my source list._

Going with the maintainer's repo means that you trust the maintainer with
providing security updates for the version you have installed or you trust
them with providing a useable upgrade path.

If you go with a distro package, you will get both the benefits of security
updates for the lifetime of the OS itself and the benefits of the underlying
software not changing.

Of course it also means that you don't get new features for the lifetime of
the OS.

So depending on your target usage of MongoDB, you either would want to go with
the OS packages (if MongoDB is just a dependency of a dependency and you don't
really care about its functionality aside of it being there) or with the
vendor packages (if you're directly depending on MongoDB and you're willing to
keep up to date with feature releases).

But even then, sometimes a vendor's official response to a security problem is
"run apt-get upgrade to update to the latest major release" at a time when you
really don't have the time to read the release notes and adopt your software
to the changes in the new version.

Other vendors still provide maintenance for older releases, so it really
depends on the vendor, whereas if you go with the OS packages, none of this
matters.

Also, in this particular case, there's also the licensing issue to consider. I
don't know whether it's safe for a company offering some service and/or
application over the web to use current versions of MongoDB without paying for
a license.

~~~
iqy
>Going with the maintainer's repo means that you trust the maintainer with
providing security updates for the version you have installed or you trust
them with providing a useable upgrade path.

Why should that be a problem if you use the official repo, handled by MongoDB
themselves?

~~~
pilif
Because as I said later in my post, sometimes a vendor's response to a
security issue is "please update to the latest major release".

Let's say you're using version 1.1 of some software and you're hit by a
remotely exploitable unauthenticated RCE.

You want to patch it, but the vendor says that the only fix is to update to
2.0.

How quickly can you adjust your software to work with that major release that
might contain non-backwards compatible changes? Are you going to be quicker
than the time it takes malware authors to write bots to hit that RCE?

There's also a second example which is automated updates: Our infrastructure
automatically applies OS package updates via `apt-get`.

Thanks to Debian only ever updating packages for security reasons and only
very rarely shipping new bugs, this is an actually workable practice.

But once you start adding 3rd party vendors who, for example, believe that
once puppet 4 is released it's totally safe to just publish puppet 4 as a
replacement of puppet 3 previously in the 3rd party repo, this becomes a very
dangerous practice.

~~~
chrisseaton
How does this work? How are RedHat able to reach into any of the thousands of
projects in their repository and fix bugs and vulnerabilities? How do they
have people on staff who understand all those codebases and algorithms?

Do RedHat support engineers get tickets like 'bug in the energy minimisation
algorithm of GraphViz - go in, learn that field of computer science, and fix
it'?

~~~
quantummkv
It is the upstream vendor that issues fixes. What RedHat does is that it takes
the commits that fix the bug and merge them into their forks and release.

~~~
chrisseaton
> It is the upstream vendor that issues fixes.

So if you have a bug in a RedHat package, and you're paying $100k a year
RedHat support contract, all they really do is open a GH issue with the
upstream to ask them to fix it? And then you just wait hoping they fix it so
RedHat can cherry pick it?

~~~
myWindoonn
We don't know. I'm going to tell you a short story, though.

Rumor has it that KMS[1] was developed entirely because a deep-pocketed RH
customer was annoyed that their workstations showed a fraction of a second of
the boot/init log, and wanted a more seamlessly-graphical boot.

This feature was not universally welcomed by the kernel community. It excluded
BSD cousins and frustrated nVidia and AMD/ATI. I remember standing next to the
DRM/KMS maintainer while Linus yelled at us.

RH absolutely will interact with upstream on behalf of their customers. They
don't just "open a GH issue"; they present designs, code, rationale, and
evidence to upstream. I wonder whether this is something that Oracle does, but
it doesn't sound like it.

[1]
[https://en.wikipedia.org/wiki/Direct_Rendering_Manager#Kerne...](https://en.wikipedia.org/wiki/Direct_Rendering_Manager#Kernel_Mode_Setting)

------
amenod
I am really torn about this news. On one hand MongoDB's change of license is a
clear attempt to discriminate against a set of users, so it is clearly non-
free. On the other hand I know it is really difficult to make a sustainable
business by developing an opensource product, especially since there are
companies (like Amazon) who will take successful opensource projects and offer
them as a service, or simply offer a compatible service (which is what Amazon
did now). Discriminating against such uses doesn't seem wrong to me since they
clearly harm the creators and maintainers in their effort to actually make
some income from the project.

There is a really limited set of options for opensource companies and I have
yet to see an opensource product that would bring their creators enough money
to sustain it on aything else than their goodwill. RedHat doesn't count,
because they packaged other people's opensource and sold the package to
enterprise. They did contribute back and even started and maintained some of
the projects (which makes them "good guys" in my eyes), but any other
opensource project will have difficulties replicating that success.

EDIT: I would really appreciate discussion instead of (down)votes.

~~~
kstrauser
PostgreSQL is used much more widely than MongoDB, and has a much freer
license. Lots of people make money developing and supporting PostgreSQL.

I also content that MongoDB built their project on top of a mountain of Free
Software. It rings a little hollow to me when they complain that others are
making money from using their software, when the MongoDB team is also making
money from using others' software. Last I checked, they weren't a major
contributor to the Linux kernel, or GNU, or GCC, or Emacs/Vim, or...

~~~
threeseed
> Last I checked, they weren't a major contributor to the Linux kernel, or
> GNU, or GCC, or Emacs/Vim

MongoDB only needs the Linux kernel/GNU/GCC when it's running or compiling on
Linux. On OSX and Windows it uses other toolchains.

And your point goes against the entire spirit of open source. No one should be
forced to contribute back to open source less they be criticised by the
community.

~~~
kstrauser
> MongoDB only needs the Linux kernel/GNU/GCC when it's running or compiling
> on Linux.

Good call. They should also be contributing back to those toolchains.

> No one should be forced to contribute back to open source less they be
> criticised by the community.

That right there is what we call irony. This is precisely what Mongo is trying
to do.

~~~
bb611
That's not really what they're trying to do.

What they're trying to do is make it so challenging to host MongoDB as a
service that cloud providers can't do it. They implemented it with an absurd
requirement forcing contributions to open source, but the intent is not to
improve open source, it's to end regain market control.

~~~
kstrauser
I totally agree. I’m convinced of it. The license shenanigans are just the
means to that end.

------
hardwaresofton
Somewhat orthogonal but I wonder if this is one of those times where people in
forums like these can see further ahead than the usual stock market actors
can? $MDB seems to be unaffected by this news (and the DocumentDB news as
well).

Maybe I've overestimating, but this looks like it will be a blow to
accessibility of Mongo -- or maybe it will only be RHEL since they're focused
on commercial applications?

[EDIT] - I was incorrect/didn't look closely enough, the DocumentDB
annoucement seems to be correlated with a 20%+ dip around January 8th.

~~~
cmsj
If RHEL is dropping something for license reasons, you can be pretty sure that
others will too: [https://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=915537#15](https://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=915537#15)

------
ehayes
It's a little ironic because Red Hat invested in MongoDB several times:
[https://www.crunchbase.com/organization/red-
hat/investments/...](https://www.crunchbase.com/organization/red-
hat/investments/investments_list)

------
sascha_sl
MongoDB is the reason I don't contribute (outside of work) to any copyleft
project that asks for copyright assignment anymore.

~~~
kemitchell
[https://www.gnu.org/licenses/why-
assign.en.html](https://www.gnu.org/licenses/why-assign.en.html)

~~~
sascha_sl
This is not why most projects do copyright assignment.

I'd trust very few entities to have pure intentions when asking for this.

~~~
kemitchell
Companies that unify intellectual property in projects under their stewardship
typically take contributor license agreements, rather than assignments. For
more on that:

[https://writing.kemitchell.com/2018/01/06/CLAs-Are-Not-a-
Sha...](https://writing.kemitchell.com/2018/01/06/CLAs-Are-Not-a-Sham.html)

------
zachruss92
I'm not super surprised that RHEL removed Mongo because of the licensing
change. I don't completely understand why people getting upset about the
licensing, however.

As far as I know, MongoDB is still open source. If you are a hosting provider
offering "MongoDB as a Service" the provider then needs to pay a licensing fee
to Mongo. This seems ok to me, with the logic that MongoDB is a business that
needs to make money.

I am not an expert in licensing, but how is this any different than paying for
a license of RHEL vs using CentOS? I'm genuinely curious as to how this is
against open source beliefs.

~~~
e1ven
It is not generally considered Open Source.

The new license was rejected by the OSI, which is generally regarded as the
defacto arbitrator of if something is OSS or not. It was also rejected by Red
Hat and Debian as being not open source.

There are various issues with the license, including the scope of what they
considered tainted. You could read the mailing list archives on the subject,
or there appears to be a summary at
[https://opensource.stackexchange.com/a/7523](https://opensource.stackexchange.com/a/7523)

The newly submitted v2 of the license hasn't resolved (m)any of the problems
that the OSI has raised, and isn't expected to be approved either.

~~~
kemitchell
OSI has not rejected SSPL, v1 or v2. Mongo substituted for v2 in review, and
v2 is still in debate.

To my knowledge, OSI has never affirmatively rejected a license. A proposal to
change its process to include rejection, which came up during SSPL review,
remains pending.

------
karolist
MongoDB is a strange company. I've downloaded their Compass software to
visualise some throwaway JSON I had loaded in Mongo, gave my real email and
here's the emails I was sent before I blocked their marketing account
(allegedly someone named Alena)

day 0 "Regarding your interest in MongoDB"

day +1 "Alena with MongoDB in reply to your interest"

day +3 "Alena with MongoDB making sure you're all set"

day +7 "Alena from MongoDB reaching out"

day +10 "Checking in from MongoDB"

At which point I was completely speechless about this dumb spammy marketing
attempt and just blocked the sender. Really guys?

"I want to touch base with you again to see if we could provide you with
additional information regarding our enterprise edition of MongoDB that you
downloaded.

Are you available to set up a call to learn more?"

What the hell is that I never downloaded "enterprise MongoDB", it was Compass.

I will never use anything from MongoDB, thanks Alena.

~~~
stingraycharles
This is a common practice, it's called "Drip Marketing", "Nurturing" or a few
more other variations. It's completely automated, and it sounds like some
template / tagging gone wrong.

Lots of companies do it, and it's fairly effective.

------
nnq
...why would almost anyone using MongoDB _care at all_ if it's included in a
distro's set of default packages?!

Don't we all _always_ install software from repositories hosted by third
parties? As long as the Mongo devs keep supporting RHEL, I'd see no problem
for actual _direct users_ of it. And SSPL sounds like a pretty good and
sensible thing.

~~~
nolok
It may or may not matter for Ubuntu or Debian or most other distros, but the
kind of users/companies/customers that insist on using RHEL very much care
about it.

The whole point of using RHEL is that it has full support, why pay the premium
for it if you then include non supported gears into it anyway.

------
zzzcpan
MongoDB, Redis, CockroachDB and anyone else interested should join efforts
with Kyle and adopt his similar to SSPL, but neutral and cleaner copyleft
Shared Component License [1]. This should help clear up any confusion people
have and avoid providing excuses for removing packages due to the license.

[1] [https://github.com/kemitchell/shared-component-
license](https://github.com/kemitchell/shared-component-license)

~~~
yarrel
That's not a free software license though.

~~~
kemitchell
I'm not sure what reason you have in mind.

FSF and OSI are split on "private changes": whether a copyleft license can
_require_ distribution of changes. OSI approved Plan 9, RPL, and Open Watcom,
all of which require this in at least some scenarios. FSF rejects those
license.

I don't understand why FSF takes that position. More on that:
[https://writing.kemitchell.com/2018/09/17/Private-
Changes.ht...](https://writing.kemitchell.com/2018/09/17/Private-Changes.html)

------
pytyper2
Good, Mongo is rarely the right database.

~~~
TimMurnaghan
Absolutely. My characterization of Mongo is that it's the back end choice of
front end developers. The only possible justification for it could be time to
MVP (and that's being kind). It's bad for all of the reasons that back-end
people make back-end choices - non-functional requirements like operability,
clustering, etc.

Hopefully this is the start of it being removed from any infrastructure uses.
I spun up an openstack instance the other day and was horrified to find Mongo
in there.

~~~
threeseed
Actually the NFRs are one of the best parts of MongoDB.

It is by far one of the easiest databases to administer, clustering is orders
of magnitude easer than say PostgreSQL and it can be the fastest database by
far for certain use cases e.g. cell level updates. Can you be more specific
about what in particular is deficient ?

And if you look at their customers most of them aren't using it for front end
work. Likewise I find it to be quite popular in the Data Analytics/Science
space as a store of analytical features and for 360 entity views.

~~~
tracker1
Agreed to an extent. It does have its' place and is definitely very easy to
use if you have a limited number of collections, mostly distinct in use and
have deeply structured objects.

The ease of clustering is pretty nice for either replica sets or basic
sharding, but sharding + redundancy isn't great, and if you happen to have a
majority of nodes offline it may never catch/sync up right again which may
require bringing on/off new nodes or the whole thing down and restoring from
backup.

About 4-5 years ago when a bulk of Azure went down, I experienced this, and it
wasn't fun to say the least. Fortunately it was mainly a replica of primary
data source for search/display for mostly-read scenarios and was easier to re-
replicate the records from SQL in the end. If I were to do it again, I'd
probably reach for Elastic first.

It can be very good for some use cases and less than good for others. The
clustering is absolutely easier than anything but RethinkDB (in the box) and
SQL Server (break out your checkbook) in my opinion.

------
rjkennedy98
Doesn't Red Hat have a huge financial stake in MongoDB? Seems weird to do this
if that's the case.

------
kemitchell
I recently published a sketch of a plain-language license generalizing the
SSPL approach. Feedback of all kinds welcome!

[https://github.com/kemitchell/shared-component-
license](https://github.com/kemitchell/shared-component-license)

At a minimum, I think my language can make the issues clearer. Folks don't
want to wade 12 sections deep into AGPLv3, much less a path to AGPLv3. I can't
blame them.

------
crb002
MDB stock is tanking. Hilarious knowing that some of the institutional
investors are forcing MDB down the throats of their IT staff.
[https://fintel.io/so/us/mdb](https://fintel.io/so/us/mdb)

------
avar
It looks like it is, but is there any official word that the SSPL is
proprietary? As far as I know MongoDB claims it isn't, and it hasn't been
reviewed officially by either the FSF or the OSI. Is it in license purgatory?

~~~
dankohn1
Bruce Perens feels “it manifests a lot of ignorance about Open Source and
utter contempt for our community.”

[https://opensource.org/LicenseReview122018](https://opensource.org/LicenseReview122018)

~~~
latk
That Perens quote refers specifically to Sunil Deshpande's article about the
SSPL and Open Source, not to the SSPL itself. But it's not far off either way…

The reaction on the OSI's license-review list is more varied. Lawrence Rosen
and Ken Mitchell argue that the license should be approved. Everyone else is
criticizing that it clearly violates the spirit of Open Source software (no
discrimination against fields of endeavour!), and that the license is too
broad and too vague in the critical section (Rosen agrees with the latter
part). Carlo Piana points out that the goal of the license seems to be to
create so much legal uncertainty that any serious user would be forced to buy
a proprietary license from MongoDB.

~~~
kemitchell
I also criticize the way SSPL was drafted. The legal talent they have can do
far better. The choice to patch AGPL cuffed them.

Here's me announcing an attempt at a plain-language, SSPL-style license from
scratch:

[https://writing.kemitchell.com/2019/01/12/Shared-
Component-L...](https://writing.kemitchell.com/2019/01/12/Shared-Component-
License.html)

The latest license text is at:

[https://github.com/kemitchell/shared-component-
license](https://github.com/kemitchell/shared-component-license)

------
manishsharan
Is any OSS project working on MongoDB API layer for FoundationDB ?

~~~
jsty
The document layer offers this: [https://www.foundationdb.org/blog/announcing-
document-layer/](https://www.foundationdb.org/blog/announcing-document-layer/)

------
gandutraveler
Off topic . But since we are talking about DBs. What's the default go-to
choice of DB now a days?

------
tracker1
Redis is still there, didn't they do something similar?

~~~
dvirsky
No, just a few modules changes license (and were removed from distros). Redis
itself remains BSD.

------
nwmcsween
This is rich coming from Redhat that does shady things with subscription
license agreements and open-source software.

~~~
jhall1468
Nothing Redhat does is shady. There's nothing wrong with license agreements
for closed source software, or even license-agreements that support open
source software. The latter is how open source companies make money.

~~~
nwmcsween
The license agreements restrict use of the work on top of the GPL, same as
mongo does..

~~~
jhall1468
No, the Mongo license explicitly forbids cloud providers from using the
software without open sourcing the entire stack. Unless you have an example of
Red Hat doing the same, I'd retract the statement.

~~~
nwmcsween
And the Redhat service license restricts redistribution of the binaries and
modifications or you get blacklisted and cannot get any updates

