MongoDB removed from RHEL 8 beta due to license | Hacker News Reader

MongoDB removed from RHEL 8 beta due to license

access.redhat.com

382 pointsvbezhenar222 comments

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

I’ll never understand why we collectively wag our fingers at individuals or companies that try to keep the likes of Amazon from building a profitable service off of their hard work then contribute back little-to-nothing. Would redis, mongodb and dgraph have even considered alternate licensing if companies like Amazon had thrown them a minuscule amount of funding and patches? We can’t know because they didn’t. And then we sneer at them for having the audacity to try to stay open but stop these giants from using them and throwing them away.

This kind of aggressive behavior toward these people trying to stop their own destruction at the hands of the biggest and most profitable companies in the world makes me wonder what the hell is wrong with our industry. This could easily be any of us. It might be any of us in the future. What do we gain by consolidating control in 3-4 different giants? What are we achieving with such a black and white view of what constitutes open source or not?

You can point at Amazon all you like, but this isn’t Open Source or Free Software.

If you want to prevent others from using your “hard work”, then go with a proprietary license, but don’t pretend your proprietary license is FOSS because that’s hypocritical and many of us care about the guaranteed freedoms of FOSS, including making money off of other people’s hard work.

MongoDB is trying to eat their cake and have it too and I have no sympathy for that. New versions of MongoDB are no longer Open Source and that should be known, because it won in the marketplace by being FOSS and now is the time to consider alternatives.

This is what it is all about; you believe in software to be free in a RMS kind of way or it is just a marketing gimmick. If you want software to be free, you do not care what Amazon does with it. That is clearly not MongoDB. They used FOSS as marketing tool and timed it well (it was a horrible shitshow of a product but many drank the koolaid; no idea what it is now, I will never touch it again) and now have to please investors. That is fine but let us not put this on ‘the big corporates’ please.

People are tired of restrictions, regardless of whether they are the ones targeted. The behavior is not aggressive in any sense and these types of restrictions are worked around predictably. You are making the mistake of confusing the intent of the changes with the reality as though the opposers favor the giants. In reality, something free for everyone might be misused and that's ok because of the size of the benefits. Free software needs to stop trying to pick and choose winners, because what they want to happen rarely does.

So I agree with what you said but I also agree that it should be removed from RHEL and Debian.

It's totally within MongoDB's rights to change their license to combat unfair behavior from giant cloud providers. And its totally fair for distros to remove Mongo because of the license change.

The bigger concern should be that databases like MongoDB and Redis are part of an older breed. The newest databases, built to handle the most demanding load, like DynamoDB, Aurora, or CloudSpanner, are intimately tied to the cloud providers they're deployed on, for legitimately necessary reasons. As the world gets more complex and demanding, this old model of "I've got a server, lets put a database on it" just doesn't scale, even including these "web scale" NoSQL databases like MongoDB.

No one beside AWS (or Google or Microsoft) is even capable of building databases to meet these new challenges. For now.

Cost plays into this as well. DocumentDB is so cheap because it is built on the Aurora storage engine, which in turn is intimately tied to the infrastructure. MongoDB Atlas can't compete with that. They have to charge you more because they can still point to the servers that your database is running on. An Aurora database might be spread across a dozen different servers and services within AWS, taking up just bits and pieces of processing on each; the parts of Aurora that need lots of storage are on machines optimized for that, the parts that need compute are on machines optimized for that, they're all connected with terabits of networking, and those pennies of savings turn into hundreds of dollars at scale which they can pass on to their customers.

Google did the SAME THING years ago with Cloud Memorystore, which exposes a Redis API. Microsoft did the same thing with CosmosDB, which exposes a MongoDB API (among others). Why? Its because the fundamental tech that MongoDB built isn't good. MongoDB is so unbelievably uninteresting to Amazon. Why would they even want to contribute back to it? If they adopted MongoDB wholesale, they and their customers would be worse-off for it. The only people that would win is MongoDB.

But they are interested in the API, because that's what their customers are using.

The license is a red herring. The real reason Amazon did this is the tech. They now have the Aurora storage engine and DynamoDB, which they can put any API they want on top of and it'll be cheaper, more performant, more resilient to failure, and easier to scale than taking "Database of the month X", throwing it on an EC2 instance, and calling it Managed.

And the reason why we're seeing this centralization is because Amazon made the investment in Infrastructure while MongoDB just wanted to build a cool database. Didn't Alan Kay warn us that if you care about the software, you have to care about the hardware? Did we really believe that this only applies to consumer experiences? Amazon didn't. And that's why they're winning.

>But they are interested in the API, because that's what their customers are using.

The API is very much a part of the product. It's effectively the UI for the service.

Small companies like Mongo and Elastic can't compete on scale but they can compete on interface design.

If it's ok for the giant providers to just take their interface design and rip it wholesale then you are cutting off the market for new database engines.

Aurora and DynamoDB have been around for ages. If it's objectively superior, then why did they feel the need to make a MongoDB compatibility layer?

Because despite being 'superior', people were still using MongoDB.

A database engine is more than just the backend. The developer-facing side is just as important - if not more so.

> then you are cutting off the market for new database engines

No, you're really, really not. There is plenty of opportunity for innovation still.

Should basic APIs be considered intellectual property we'd be in for some real trouble as an industry.

> And then we sneer at them for having the audacity to try to stay open but stop these giants from using them and throwing them away.

I'm sneering at the bait and switch. For what it's worth, MongoDB may have taken away business from more competent competitors that were upfront about being commercial projects. Given the nature of the database space, this has certainly been the case.

I think there's an echo?

https://news.ycombinator.com/item?id=18690666

I think it's the third time I've said it. I suppose I could rewrite it each time like school children copying Wikipedia to avoid a call out like this but it hardly seems like a productive use of my time.

> It's sad that the license change all resorts to greed basically, as if Oracle took over MongoDB.

It's essentially "we convinced the stock market that our company tripled in value over the course of a year, and now we have to tell them what business model is behind this value growth" [1].

[1] https://finance.yahoo.com/quote/MDB/?guccounter=1

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.

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.

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.

Yeah but both free software and open source are well defined terms MongoDB doesn't have power to redefine (sorry guys). It's good to be principled because then you make fewer arbitrary decisions along the way. Your new license isn't free nor open; it's just a custom proprietary license that allows people see the source code and fork; just like freeware software can be "for gratis" but it's never "free software" or "open source". So, MongoDB is definitely proprietary software now. And it didn't used to be proprietary, and I think it's definitely a valid question whether this relicensing has something to do with greed. In the meanwhile, Debian and other free-only distros (e.g. GNU distros) should not include MongoDB.

I'm under the impression that everything in the paragraph above is objective and not subjective. I do not claim it is definitely greed, but since MongoDB did a completely arbitrary move to make license favoring them, it's valid to ask this question. My subjective opinion is that MongoDB committed suicide and they'll be forgotten in a few years time.

I also work for MongoDB.

I respect your opinion about whether the SSPL is free or open, but it is not one that is uniformly shared by the OSI, as evidenced by the discussion currently underway in the license-approval mailing list. Many have argued in its favor. On that basis, some of your assertions in paragraph one are subjective.

Not that there’s anything wrong with subjectivity! I think it is valid to ask the question of whether the move was motivated by greed... it’s even understandable why people would default to that conclusion. (I wish that weren’t the case, but I’m not naive.)

Since you’re asking, I will give you my answer: the SSPL was created to make it viable for open source projects that are largely or completely funded by a single entity to remain funded in an era of large cloud vendors. While it is about revenue, it is not about greed.

The proof of the pudding is in the tasting, and I won’t ask you to just buy my claim. Just keep your eyes open for a conspicuous absence of MongoDB strong-arming community MongoDB users into buying commercial licenses.

As far as including MongoDB in Debian et al, goes, we absolutely respect process and principles. We’re waiting to see what the feedback from the OSI is.

Businesses have to survive in a competitive market, I get it, you don't have to apologize for it and it's not greed, it's just how the market works.

That said, you did not work with OSI or the FSF before changing the license. And your company is not the only contributor to MongoDB, you have third party contributors as well, who did not have a say in it, because of the copyright attribution that you require.

In other words, you did not collaborate with OSI or the FSF and you screwed your contributors.

It's good that you're now waiting on feedback from OSI, but the damage to the FOSS ecosystem was already done.

I appreciate your comment about how the market works, thanks for that.

You certainly have a point about our not working with the OSI prior to issuing the SSPL. All other things being equal, we would like to have, but as a publicly traded company it's just not responsible to announce "we will be changing our license... to... something... we'll get back to you on what that'll be... sometime."

We weren't happy about it, but we're doing the best we can given the constraints. We're all grownups, and accept that one of the consequences is that some in the OSS community feel betrayed by that change, but we ask that you let our actions going forward, not the worst suspicions of those most predisposed to judge us harshly, determine what you think of our dedication to OSS and our community.

As for non-employee contributors to the MongoDB codebase (who account for about 3% of the codebase), I think we should credit them with the same adult responsibility for their actions as we hold MongoDB to. Their contributions were made in full knowledge of the attribution requirement, and we have no reason to believe -- and no evidence -- that they resent anything MongoDB as a company has done.

>It is difficult to get a man to understand something, when his salary depends upon his not understanding it.

I'd say I'm surprised that some people are attacking your license, which overall forces providers to increase user freedom, but I remember the 90s and 00s when the GPL/AGPL was being attacked as a non-free (as in freedom) license - "How can it respect freedom when it FORCES me to release my source code?"

The same people today go on about how great the CC licenses are when they have the NC-SA, which I've been using for my artistic projects since it came out.

Do you have a Stallman like wall of text about defending users freedoms? Because there are enough people who would read it and understand what you're doing once they get past the FUD of "It's proprietary!!!".

Because such things are "necessary" when it provides benefit: access to software/CC stock photography/imagery/fonts.

And less so when it impinges on the ability to make profit from it (leaving aside the argument about "no-one says you can't make money from open source software" - of course you can, but the business model is a little less... convenient... so they fault the license, not anything else).

Just FYI, a few years ago, I went through the due diligence process for an acquisition. The AGPL on MongoDB (at the time) was the single biggest sticking point for the lawyers. I had to do a lot of work to demonstrate that we had sufficient separation that our proprietary IP wasn't at risk due to the license. This was complicated by the fact that I was a major contributor to one of the drivers and the maintainer of one of the popular ODMs.

I would not make the choice to build a startup on MongoDB today given the expansion of the license's virality. Even if my business model wasn't in the SSPL's immediate crosshairs, the direction the license is moving gives me no confidence that MongoDB won't make my life harder down the road. It's just not worth the eventual headache. Lawyers make things hard enough, I'm not going to take on any more legal exposure than I absolutely need to in order to ship my product.

Nonsense. The AGPL is a pretty nasty license to begin with, but this new license makes your software nearly useless.

For example: prior to this change, people could develop an extension to MongoDB which combined MongoDB with some GPLv3 software, and they could then freely redistribute that combined work.

Now they cannot.

MongoDB may as well be Oracle as far as most developers will care now (that isn't a compliment).

The SSPLv2, currently under review by the OSI, does not have this property.

As a counterpoint to all the flack that you're getting here, I admire the way that you're trying to create a license that is still in the spirit of reciprocity of Free Software and Open Source (if "maximally viral", beyond the limits of copyleft as it was initially envisioned), but compatible with what you perceive the economic realities to be, and how you're maintaining a dialogue with the community (at OSI).

Having read the license it seems like (in MongoDB context) a license where the GPL virality is more explicitly stated to include service mangement sofware. One could already argue that this software is "derived" if it depends on and extents MongoDB.

Couldn't you get in contact with the EFF and work on a more general, more viral form of AGPL, and treat the current license as more of a stop-gap measure? With those viral licenses it is really important to have only a few, so that they are compatible.

Not sure about the EFF but I know that MongoDB has submitted the SSPL to the OSI and has already taken feedback from that process.

But it's one less freedom I have. Say I contribute to MongoDB heavily and want to get into the Mongo as a service business, will I be able to without having to pay for the freedom to do it? It's a crippled form of freedom when some things are free as in free beer, and others aren't. I preferred the AGPL because it was explicit about sharing code if you change anything on the server-side.

If I offer MongoDB as a cloud service with a homegrown web interface (e.g. mLab) then I am required to release my web interface?

Yes.

For me the problem isn't so much the license as the change felt somewhat like a bait and switch. After you became popular you changed the license to be more favorable to you, which is always a sketchy move.

There are several closed licenses which allow you to do that. Mongodb now uses one of those closed licenses.

The wording is so vague that this license is incredibly toxic, no one in their right mind would consider using it.

Seriously, is that all you IP lawyers can come up with ?

Thanks for finally giving Amazon the kick it needed to implement your API. We finally don't have to manage a mongodb cluster anymore.

I suppose but it might be interesting to note that you didn't have to wait for Amazon for that. A lot of people don't know that there exists a fully managed offering from MongoDB. It's called Atlas... not trying to sell here - just informing people that may read your comment and think it was a valid motivation for Amazon to create their DocumentDB offering. Atlas has existed for 2 years.

Isn't this covered by the AGPL already?

I had hopes for MongoDB back 10 years ago, but it just let me down.

I'm thinking of trying out ArangoDB next. OrientDB is just riddled with bug and their docs are lack luster.

Why not pick a mature database software, learn to use it properly, and just get on with life? Why would you risk _anything_ to immature databases?d

Exactly. What is the super secret use case that a DB that might shut down in 3 years give you, over the tried and true?

Postgres is great, mysql works... You really need to exhaust them before you go to random.db.

For S&Gs.

It's a 9 year old database.

Can you be more specific about what makes it immature ?

9 years _is_ immature when you're talking about systems that will store data and operate for decades, with various components being upgraded over that time.

Compared to some other databases out there, MongoDB is a baby. These others... are not even born.

Pretty sure that they were referring to ArangoDB and OrientDB as being immature, not MongoDB...

I only migrated companies away from it. I prefer reliable data stores. Postgres + Riak always got my back, 15years, 8 years in production respectively.

Isn't riak dead?

Why would it be?

Because Basho, the company that developed it, is dead?

https://www.theregister.co.uk/2017/07/31/end_of_the_road_for...

Basho was bought and Riak is being developed by the new owner.

I was under the impression that it's no longer being developed.

Even if it was not it would be still good for a KV store.

Do you believe that a software can be complete at all?

It ain't a new cool Javascript library. Databases are hard. Many tried, many failed. Don't play around.

But MongoDB is only 9 yo!

I guess so. I wrote some tutorials back in 2010 https://web.archive.org/web/20100604100310/http://www.dealta...

https://web.archive.org/web/20100725142105/http://www.dealta...

I'd suggest to try the latest FoundationDB MongoDB layer.

I would definitely do that if I had a use case.

Does it offer relationships handling? That's the big downfall of MongoDB for me.

Mongo offers outer left joins through $lookup, now even with sub-queries.

https://docs.mongodb.com/manual/reference/operator/aggregati...

It also offers recursive left outer joins with $graphLookup.

I would have to take a look at that to see if resolves the issues I saw from back then.

There are no explicit foreign key relationships though if that is what you mean ?

I know there was a way to "link" records, but do to do anything with them, you had to pull all the data back into your app and manually filter and process records.

That's not been true for awhile. You use the aggregation framework with the $lookup stage to do an outer left join.

db.employees.aggregate([{ $lookup: { from: "departments", localField: "departmentName", foreignField: "departmentName", as: "managers" } }]);

You can do nested joins as well. However deeply nested joins in MongoDB is probably an anti-pattern.

IMO, MongoDB was suss from the very start. They made claims and overpromised (though I might be a little unfair in that others jumped on this bandwagon more heavily), so removing MongoDB from RHEL is not necessarily a bad thing.

Of course, I'm not a MongoDB fan for many, many reasons so I'm quite biased.

The webscale video was our absolute favorite in one of Amazon's systems engineering team for a long time.

That's the case for many engineering teams.

For those who haven't seen it: https://www.youtube.com/watch?v=b2F-DItXtZs

still one of my favorites

I don't see the rationale for their claims that the license is non-free? There's nothing discriminatory on the face of it. Plenty of acknowledgedly free licenses make commercial users uncomfortable (e.g. the AGPL).

"The freedom to run the program as you wish, for any purpose" (freedom 0)

You can't run it using closed source management software to offer MongoDB as a service.

By that logic the GPL is also non-free, since you can't run a GPL program embedded in a closed-source management program.

Yes, you can. You have obligations if you distribute it. Even the AGPL simply gives you obligations.

There have been arguments about whether the AGPL is discriminatory, and those have been mostly waved away (wrongly, i think, but c'est la vie).

In that vein, SSPL is arguably a free license. It simply changes when obligations to distribute source occur.

Compare to the the commons clause, which is not a free license - it says you have no right to sell the software as a service at all.

I completely agree. I would only add that there have also been arguments about whether GPLv2 is discriminatory, though they also feel long behind us now.

In case it's interesting, here's my standard reference link on nondiscrimination under OSD 5 and 6: https://writing.kemitchell.com/2018/11/05/OSD-Copyleft-Regul...

There is always a case in which all license will be discriminatory when it comes to "specific fields of endeavor". If the endeavor is to break copyright then a copyright license can't permit that. To take a example, permissive licenses do not allow someone to take full ownership of the copyright of someone else work.

As such the Open Source Definition with the phrase "specific field of endeavor" is limited to cover areas which don't involve copyright law. For many reasons, including copyright law itself, it can not grant that which would be the most broad definition of nondiscrimination.

You own sentence shows the relevant difference: "embedded". The GPL license has always stopped at the OS process boundary. You can essentially do whatever you want with a GPL program as long as you interact with it over standard OS mechanisms, rather than direct modification; you're still obligated to distribute source but it's source that is already publicly available, so there's no proprietary interest in it. Mongo's does not. Neither does the AGPL, to show this isn't new.

> The GPL license has always stopped at the OS process boundary. You can essentially do whatever you want with a GPL program as long as you interact with it over standard OS mechanisms, rather than direct modification

Not strictly the case according to the FSF's FAQ; the GPL applies to anything that integrates deeply enough with the covered program to constitute a "derivative work" under copyright law, which is not necessarily the process boundary.

> Neither does the AGPL, to show this isn't new.

Indeed - so what is RedHat's rationale for permitting AGPL but disallowing this MongoDB license?

Red Hat Legal feels that AGPL stops at the tarball boundary, and the preamble isn't binding[0](2009).

[0]https://www.redhat.com/archives/fedora-infrastructure-list/2...

> The GPL license has always stopped at the OS process boundary

No, it stops at the copyright law boundary of derivative work.

Whether or not a court would find that to be equivalent to an OS process boundary probably varies by jurisdiction and detailed facts of particular cases.

You absolutely can run GPL software embedeeded however you feel. You can't distribute it without meeting the conditions, however (and some database software providers think distribution within a company counts as distribution, so there's that)

AGPL is a totally different beast.

> you can't run a GPL program embedded in a closed-source management program

Uh? Of course you can. What kind of scenario are you envisioning that makes running a GPLed software not legal?

AGPL doesn't target specific users of the software, it affects all users regardless of how they use it.

We're specifically talking about GPL.

And in the parent post in the thread I mentioned the AGPL vs the SSPL. I was adding a contrast of the AGPL vs SSPL.

You can run it. The four freedoms refer to the freedoms when you receive the software.

You can use GPL software within non-free management software within your company without problems.

What you cannot do with the GPL software is distribute it as non-free. That is all.

But how you run it for yourself, from yourself, that is up to you.

From the Open Source Definition:

> 9. License Must Not Restrict Other Software

> The license must not place restrictions on other software that is distributed along with the licensed software. For example, the license must not insist that all other programs distributed on the same medium must be open-source software.

Does the MondoDB license run afoul of that?

My limited understanding is that the problematic part of the new MondoDB license is a clause that says that if you offer MongoDB as a service, you have to make source for it and all software involved in that offering (such as control panels, management interfaces, and so on) available for download.

That doesn't sound like it would be incompatible with section 9 of the OSD, as section 9 covers software whose distribution imposes restrictions on other software. MondoDB's license is imposing a condition based on usage, not distribution, of MongoDB.

If MongoDB's license does not satisfy the OSD, I think it is probably section 6 that it conflicts with:

> 6. No Discrimination Against Fields of Endeavor

> The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research.

"Other software" also includes "control panels, management interfaces, and so on".

It's very hard to read OSD 9 in context to prohibit SSPL. https://writing.kemitchell.com/2018/11/05/OSD-Copyleft-Regul...

Bruce Perens sees it as N/A for a narrower reason: http://lists.opensource.org/pipermail/license-review_lists.o...

Thank you for linking to the e-mail from Tom Callaway.

Well, distros will follow through. One such example could be the rise of `systemd`; once it was adopted by Fedora/RHEL it was game over for `init`.

That's a somewhat different situation: they take different levels of purity test on licensing (not to mention falling under different legal considerations depending on where the developers reside) but adding or removing Mongo has little ripple effect for anyone who doesn't use it. If they don't ship it, the people who were using it will switch to Mongo's main YUM repo and nobody else will notice.

In contrast, changing the init system affects every package which runs a daemon and systemd does more than most of the alternatives so supporting multiple init systems is a substantial amount of extra work which is unlikely to attract corresponding volunteer assistance or result in any user-visible benefits.

Well, yes, you're very much right on that regard, and as others mentioned, the 'official installation instructions' were always using Mongo's official repo, so it's a different case.

But I still feel that Red Hat has pull with the Linux industry, and others might make their decisions based on "what's RHEL up to".

> others might make their decisions based on "what's RHEL up to".

Looking at systemd from one angle might lead one to think that, but I viewed it from a different angle. It's obvious from the different distros that have replaced the SysVinit system that they were looking for something it wasn't providing. Systemd apparently provided enough of those capabilities to be viewed favorably by some distros, or they looked at the extra capabilities and decided that even if they didn't like aspects of it, it was important to support them to compete.

I'm sure Redhat did evangelize it, but I doubt it went along the lines of "hey, we're Redhat, you want to be doing what we're doing." Instead I think it was more like "Hey, we built this cool new thing. Let me tell you about all the new things it has to offer, and how it solves these problems you've had."

… and we have $x worth of development time solving problems which you have with your current init system. It's not like distributions have an unlimited pot of money, and this isn't something which really sets them apart from other distributions. Ubuntu had been developing their own but switched to systemd years ago and that's generally been either unnoticeable or noticed only in that you don't have to spend time working around Upstart limitations. It's hard to make the case that they'd have been better off spending that money duplicating effort for something which will have almost no impact.

Interesting to realize that also now means “what’s IBM up to”; which carries its own weight, positive or negative.

Not quite. Systemd sucks: https://suckless.org/sucks/systemd/

I have never used systemd, even though since 1999 I am GNU user.

There are many distributions without systemd: http://without-systemd.org/wiki/index.php/Linux_distribution...

and I am using Hyperbola GNU/Linux-libre the fully free GNU operating system distribution: https://www.hyperbola.info

The game just started!

If the new MongoDB licence is non-free, the chances that Debian will include that software in their repos are nil.

We're at 3.4 right now, but there's concern that shipping any non-SSPL-licensed version is unsustainable for the lifetime of a Debian release.

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916107

They will probably keep the last version before the license change for a while, and probably add minor community-sourced patches.

The next version of ubuntu will include mongdb version "3.6.9+really3.6.8+90~g8e540c0b6d" which you can see means "last commit before the license change"

I can foresee the day when that version of MongoDB is advertised/discussed as having "AWS Document DB compatibility" (rather than today's converse).

I think Debian would keep it around, probably, but it'll be punted out of the main repos and in to the ones designated for non-free software. Impact on the end user will likely be minimal. They'll still be able to apt-get install it as before.

AFAIK there's non-free repo in Debian. Not sure how they compared to main repo in terms of maintaining.

But RHEL is not free. So... can’t this be included then only used after the user sets up a license?

RHEL is free software. It's not free of charge though.

The difference is generally not understood on a lot people. Its freedom, not price.

It is an issue of English language that cannot cover it. Turkish, my mother tongue, has six counterparts for them: ücretsiz "unpaid", bedava "gratis", hür "unrestricted (person)", özgür "free (freedom)", serbest "unrestricted, accessible (thing)", beleş "price-free (as in, you ought not to expect much out of it)"

It's 100% free, you can use CentOS which is identical to RHEL and provided by Redhat.

While it's true CentOS is free and exactly the same (minus a few packages that needed to change RHEL to CentOS), RHEL is exclusively a licensed distribution and is a commercial product.

> RHEL is exclusively a licensed distribution

It's still GPL and you still get the full code, hence CentOS. The benefit to licensed RHEL is the support.

Free does not mean non-commercial in this case. Free software can be sold and it would remain free as long as all the source code is made available to the buyer and they are allowed to modify it to their needs.

RHEL source code is free. You pay for the RHEL value adds like a compiled version of RHEL and support. If you want a compiled version of RHEL for free, then go with CentOS.

RHEL is free (use CentOS or Fedora)

Support is not free. If you want software updates, security patches, bug fixes, or somebody to call when shit hits the fan you pay Red Hat.

If not CentOS/Fedora use the same source codes

Yeah free software but you need to purchase a support agreement is what I was getting at. In any case you could get around this by just running it in a container, no?

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.

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

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

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.

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.

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.

In reading that, the GPL is working as it should.

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.

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

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

Free software binaries are freely redistributable. Source code need not be provided with binaries as long as there is offered method on how to get the sources. Thus free software binaries can be copied and distributed as many times as one wishes, and without source code, as long as there is access to source code, for example, by writing a letter with the request or by providing the download link.

It should be same source code by which binaries have been made.

Yes, it does seem against the spirit of freedom 2.

» The freedom to redistribute copies so you can help others (freedom 2).

https://www.gnu.org/philosophy/free-sw.en.html

But it seems strange to even think that Red Hat would do anything that violates the idea of free software. Surely there must be about angle to it that we have not considered?

They don't want you redistributing something called Redhat Enterprise Linux after you backdoor it?

Distribution of binaries is allowed. It is another matter and subject on how to properly use trademarks.

Right, I remember this coming up with Iceweasel because of Firefox trademarks.

https://lwn.net/Articles/676799/

That is a different argument for a different set of circumstances pertaining to modification. To contrast, you could be a Canonical customer, and distribute the ubuntu DVDs and mirror their repos to your heart's content. You can't if you are a RH customer.

How's that any different from: compiling from source with malicious modifications and then branding the resulting binaries with "RedHat"?

GPL very explicitly refers to the right to distribute source code. It is not concerned with binaries. That was an explicit choice since the license spirit is about user freedom which concerns access to sources and modifying sources.

See clause #1: https://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html

Thanks. Following that, section 3 goes on to say "copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form". So it doesn't seem to preclude re-distribution of binaries, as long as you follow the terms.

Care to elaborate? We're talking GPL and other standard OSS licenses.

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

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

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

Any serious deployment know that one should never deploy mysql / mongodb / postgress with the default maintainer repo.

Serious: WHY?

It's either not in the base repo / unmaintained quickly. I remember running MySQL on Debian / CentOS couple of years ago it was a joke how old the versions were.

You should always use the official repo ( with provided RPM / deb ) for that kind of app.

Example for CentOS 7.x:

yum info mysql-connector-java.noarch

Name : mysql-connector-java Arch : noarch Epoch : 1 Version : 5.1.25 Release : 3.el7 Size : 1.3 M Repo : base/7/x86_64 Summary : Official JDBC driver for MySQL

Quick look at when was this released: https://dev.mysql.com/doc/relnotes/connector-j/5.1/en/news-5...

(2013-05-01) Almost 6 years old.

Latest official version for 5.1.x was released 5 month ago: Changes in MySQL Connector/J 5.1.47 (2018-08-17)

Yeah but the point is, from a practical standpoint, nothing has changed. You were doing that before if you were using MongoDB + RHEL, so you'll still be doing that now.

No. Before I could use the OS built-in MongoDB and get 10 years worth of security update for that version.

Now I need to fetch the version packaged by MongoDB of which I don’t know the release cycles and years of included support.

Plus, it’s an additional subscription cost and per-server license.

Michael from MongoDB here. Are you assuming RedHat is patching MongoDB at a rate more frequently than MongoDB itself - not the case. Also, there is NO additional cost per-server-license for MongoDB Community. You should know that you can simply subscribe to the latest version (as well as older versions) of maintained packages for various os's and distributions... and these are available at no charge. More information: https://docs.mongodb.com/manual/tutorial/install-mongodb-on-...

Could? Yes. Did you? Probably not.

It's not how MongoDB teaches: https://docs.mongodb.com/manual/tutorial/install-mongodb-on-...

And it's a blatant lie to say you don't know the supportability of MongoDB, as they publish it directly on their site: https://www.mongodb.com/support-policy

This means nothing, practically. It's grandstanding, and it's annoying. Stop.

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

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.

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

IIRC Redhat is a downstream consumer of many projects. And they have their own repositories and format (RPM). So yes, they do fix bugs in their copies and employee people who know, or can learn, the critical packages.

Hopefully they still send patches upstream to the original projects.

Yes, that is exactly how it works. Provided the bug reporter has a support contract and enough clout.

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.

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

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

Backporting fixes (and fixes ONLY, not new features, and new bugs, with new incompatabilities) onto an older version of software that comes in RHEL is not trivial.

They have the core repo and other less/un-supported repos/channels. They'll support everything in the main repo.

It's a matter of scaling. If your job is "I want to run MongoDB," then it makes sense to track MongoDB's repo. If your job is "I want to run 100 different applications," then tracking 100 upstream repos (and dealing with their usually 80%-competent jobs of handling library dependencies, etc.) is no fun.

I happen to be in the latter position. Developers at both my employer and my previous employers generally cannot just install whatever they want, mostly for longevity/support reasons (at my current employer there's a way for developers to import outside code into the monorepo, which means just this week I'm cleaning up Node 0.10 and Go 1.3 from the monorepo...). They go through a team that builds them a system they can use. And that team strongly prefers to get software from our Linux distro than from third parties, because every single team has their own preferred third parties to get software from.

I do agree that for a shop that's running a single big web application with Mongo as the backend, they're probably installing it from upstream (and happier with that), but that's not the only use case.

because a lot of people have support contracts with red hat

now they'll be forced to also have one with mongodb (if their deployment is critical enough to already have red hat support they'll probably just caugh up the money)

It could have consequences for other Open-Source software using MongoDB: if they rely on a database system that distributions can't include, they also won't be included.

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.

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

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

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

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.

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

So if I build an application on Linux I should be contributing back to Linux, GCC, Clang, CMake and the hundreds or thousands of libraries I use.

That makes absolutely no sense.

If you’re building your application on Linux and complaining that other make money off it (in accordance with your license), then yes, I absolutely expect that you better be supporting all the people whose work you’re building off of.

> ... Lots of people make money developing and supporting PostgreSQL.

Postgres is definitely an actively developed and very useful project, but I must admit I have no idea how the development is financed. It seems there is a non-profit collecting donations, for example EnterpriseDB seems to employ "key community members" [0]. And Amazon is listed among sponsors [1], though it is weird that they are so low on the list (from my limited experience most cloud use of Postgres is via RDS @ AWS).

So basically donations?

[0] https://www.enterprisedb.com/enterprisedb-community-particip... [1] https://appdevelopermagazine.com/why-citus-data-is--donating...

> 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

It may not be wrong, but it does stand in opposition to the definition of Open Source and Free Software (at least as defined by bodies that RedHat and many others see as authoritative on that subject).

So perhaps we could call MongoDB what it is - a proprietary software with shared code license that lets you run their code for free in some scenarios. I think that wouldn't sell to the investors and VCs as well as open source though, and would make it harder to build a community around.

And then we haven't even touched on the CLA required to make contributions to the project - I have no idea how many people and companies contributed changes or fixes to MongoDB, but they must be pretty happy right now.

Does that mean you can't have a business built around an open source project? It does seem that way to me, especially if we talk about something that scales in a number of employees and revenue. I do think that you could bootstrap a small, consultancy-style business, built around your open source technology, but definitely not something that VCs would drool over.

Also, on a related note, I'd like to add something that's rough around the edges and I'm sure someone else could make a much better case of it, but well, here I go.

There has always been a discussion on Free Software vs. Open Source [1] where the advocates of Free Software are arguing that Open Source does not protect freedom of the users (and communities) while Open Source advocates opposed that view with argument that Open Source is even more free and pure than Free Software. In my opinion, the recent changes made by MongoDB, Redis Labs [2] and even Elastic [3] show that without ethics backing the movement, the movement itself is in danger of having its core believes changed. If some software can't be made in a spirit of Free Software (or even Open Source) then perhaps it should be made as proprietary software with shared code license - it's not as cool, and perhaps will make the adoption harder, but at least it's more sincere.

[1] For example, see Stallman's "Why Open Source misses the point of Free Software" article https://www.gnu.org/philosophy/open-source-misses-the-point....

[2] Calling their non-free licenses "Apache-2 + Common Clause" is a pretty disingenuous move, and the only reason why I see it less bad than what Mongo did being the fact that it only affects a subset of previously-closed extensions IIRC.

[3] Their announcement on x-pack did not call it open source, however the entire press release was full of "open source" this and "open source" - it felt like they tried really hard to ride the Open Source train without actually riding it.

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.

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

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

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

It's a fair point to make: mandatory copyright transfer in combination with copyleft means the copyright holder can at any moment decide to change the license. Not retroactively of course, but you'd be left with the choice to fork, to buy a license, or abandon the product. None of those are great options for anyone serious about making a contribution.

Copyleft can work great but it works better if the copyright stays with the original authors. This makes it impractical to re-license because you need all copyright holders to agree to that, which in the case of most OSS projects is virtually impossible. Imagine tracking down everyone who ever contributed to Linux. Not going to happen. And as Oracle has learned the hard way, forking is what happens if you mess up. Copyleft serves users of the software.

IMHO the long term success of OSS projects requires a diverse community of contributors. If a project has value, people and companies will step up to keep it going. Companies don't last forever and their fortunes or priorities might change. Having copyright transfers basically means one company calls all the shots and if it suffers, their software and its wider community suffers. This dis-incentivizes externals to contribute; weakens the community; and can become a problem for projects being long term sustainable or indeed profitable as most of the burden of maintenance is for the sole copyright holder.

Of course it's not too late for MongoDB to swallow their pride and fix this PR disaster. Lets be frank, all this negative news around their product has got to be unpleasant for them and their shareholders. At least, I doubt that they expected or wanted this to happen and I think they should be bracing for more bad news when e.g. some of their big accounts start eyeing competing products because of this mess. The fix is obvious: move the other way and go with a business and customer friendly license (Apache 2.0 seems to be popular for this) combined with closed source components/add ons for commercial customers.

Eh. I still trust the FSF to get this basically right.

https://www.gnu.org/licenses/why-assign.en.html

This is not why most projects do copyright assignment.

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

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

Care to elaborate?

If you have a project that accepts code from outside contributors, you can only re-license the project iff you have a copyright assignment from all of the outside contributors.

This is because by default, new code from an outside contributor is only granted to the original project under the original license and the copyright is owned by the contributor. If the company managing the project wants to change the license, they would need to contact each contributor and get a new license (unlikely), or remove the code from the project (equally unlikely). However, if the company only accepts patches or code that also includes a copyright assignment, the company can change the license to whatever they want without any input from their contributors.

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.

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

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.

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.

You're free to offer RHEL as a service without paying a fee. Most people do it through CentOS, but that's not a requirement of the GPL license; you have every right to copy the exact RHEL source code, build it, and run the resulting blob as a service for customers. The only things you can't do are call it "Red Hat" and use the Red Hat logo.

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.

To me, those are two contradictory statements. The software is not open-source if its license restricts the purposes for which it can be used, QED.

SSPL does not prohibit any kind of use. Section 13 attaches a copyleft condition to use in provision of the software as a hosted service.

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.

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.

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

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.

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

Thanks for this mention! However, folks should be aware that it's very early days for that form. I only published my draft this week. I'm receiving first feedback now. Several commits to master per day.

That being said, I strongly recommend that folks interested in the license watch the repo, release-only if they prefer. I will tag prereleases.

That's not a free software license though.

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

Good, Mongo is rarely the right database.

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.

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.

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.

The only time it was recommended to me was by a new NodeJS developer, I then explained ACID concepts around multiple transactions, they were floored. This was about 4 years ago, maybe mongo has matured?

Michael from MongoDB here... Yep - MongoDB has continued to mature. Modern MongoDB supports multi-document ACID transactions if that's what you're asking. More information here - https://www.mongodb.com/blog/post/mongodb-multi-document-aci...

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

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

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.

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

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?

Seems redhat lawyers have reviewed it, here's the announcement wrt fedora: https://lists.fedoraproject.org/archives/list/devel@lists.fe...

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

https://opensource.org/LicenseReview122018

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.

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

The latest license text is at:

https://github.com/kemitchell/shared-component-license

Thanks for the insightful summary.

I don't know if it can be called free. But section 13 of the SSPL is certainly incompatible to RHEL's distribution model, or any other linux distribution I know of.

In particular it requires you to license "the Corresponding Source for all programs that you use to make the Program or modified version available as a service" under the SSPL. That naturally includes the linux kernel which is licensed under the GPL - and cannot be simply relicensed.

But they don't make it available as a service. They distribute binaries and perhaps source code.

Free software must be free for all its users. The most common example of this is a license that restrict fields of endeavor.

E.g. I could make a license exactly like the GPL except with a clause saying fuzzy2 on HN can't use my software without paying me.

Even though RedHat and Debian aren't fuzzy2 on HN, and 99.99...% (or 100%) of their users aren't that user either, they'd still refuse to distribute it. That license would be non-free.

I think the parent was commenting that since Red Hat did not offer a service, there is no legal restriction in distributing the code. In other words, if Red Hat decided to change its stance on distributing only free software, they could do so legally. I'm glad they didn't, but I think the parent is correct.

Edit: Usually don't complain about down votes, but I'd be happy to hear why the parent is incorrect if I've got it wrong. Are they not legally able to distribute for some reason?

Re-Edit: I read the initial query incorrectly. Yes, the parent's post is unrelated to the query. Sorry!

There is plenty of non-free software that a distro can legally distribute.

They still usually don't, because it would break the automatically trouble-free property of their distribution. If users have to check the license of software before using them, there is little point in packaging all of it together and automatically installing, so there is little point on making a distro at all.

If I understood that message correctly, it seems that Debian decided to remove MongoDB from its main repository as well: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=915537#15

It's really not clear to me as he kind of backtracked in the next message by saying that he was writing under the role in the FTP team, rather than as Project Leader of Debian. My interpretation of that is that it is his opinion, but not a statement of policy. I'd be pretty surprised if they allow SSPL in Debian, but I don't think this is the statement that disallows it.

The FTP team is the body that ordinarily makes binding policy decisions about licenses in Debian. It's not typically the project leader's job, so I read this statement as saying "despite the .signature, I'm speaking in my role as a member of the FTP team, not the project leader overruling the FTP team."

The FTP team performs a license check before a package is moved into the archive, so they do get to decide what goes in and what doesn’t.

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

The document layer offers this: https://www.foundationdb.org/blog/announcing-document-layer/

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

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

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

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

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.

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

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.

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

Reply on news.ycombinator.com