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.
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?
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.
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.
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.
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.
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.
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.
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" .
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 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.
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.
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.
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!!!".
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).
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.
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).
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.
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 ?
I'm thinking of trying out ArangoDB next. OrientDB is just riddled with bug and their docs are lack luster.
Postgres is great, mysql works... You really need to exhaust them before you go to random.db.
Can you be more specific about what makes it immature ?
I would definitely do that if I had a use case.
It also offers recursive left outer joins with $graphLookup.
Of course, I'm not a MongoDB fan for many, many reasons so I'm quite biased.
For those who haven't seen it: https://www.youtube.com/watch?v=b2F-DItXtZs
You can't run it using closed source management software to offer MongoDB as a service.
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.
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...
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.
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?
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.
AGPL is a totally different beast.
Uh? Of course you can. What kind of scenario are you envisioning that makes running a GPLed software not legal?
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.
> 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.
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.
Bruce Perens sees it as N/A for a narrower reason: http://lists.opensource.org/pipermail/license-review_lists.o...
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.
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".
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."
I have never used systemd, even though since 1999 I am GNU user.
There are many distributions without systemd:
and I am using Hyperbola GNU/Linux-libre the fully free GNU operating system distribution:
The game just started!
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"
It's still GPL and you still get the full code, hence CentOS. The benefit to licensed RHEL is the support.
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
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.
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.
"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. "
It should be same source code by which binaries have been made.
» The freedom to redistribute copies so you can help others (freedom 2).
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?
See clause #1: https://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html
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.)
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.
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)
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.
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.
Why should that be a problem if you use the official repo, handled by MongoDB themselves?
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.
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'?
Hopefully they still send patches upstream to the original projects.
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?
Rumor has it that KMS 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.
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.
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)
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.
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...
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.
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.
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.
That makes absolutely no sense.
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" . And Amazon is listed among sponsors , 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?
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  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  and even Elastic  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.
 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....
 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.
 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.
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.
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.
I'd trust very few entities to have pure intentions when asking for this.
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.
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.
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.
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.
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.
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.
Lots of companies do it, and it's fairly effective.
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.
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.
That being said, I strongly recommend that folks interested in the license watch the repo, release-only if they prefer. I will tag prereleases.
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...
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.
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.
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.
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.
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.
Here's me announcing an attempt at a plain-language, SSPL-style license from scratch:
The latest license text is at:
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.
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.
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!
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.