I'm astonished at all the comments that vilify MongoDB Inc and then talk about moving to AWS's MongoDB clone. What sort of twisted world are we living in where a company makes a service, tries to sell the service, and then are lambasted when they try to prevent a competitor from copying it wholesale?
Cloud providers have been able to stand on the shoulders of giants, profiting immensely from millions of lines of open source code while giving little of it back, and we seem to be largely fine with this. Will we be fine depending on their services when the cloud providers become the new Oracle, free to raise prices extravagantly when we have no other choice?
If MongoDB Inc can't compete in the enterprise cloud market simply because they are not AWS (as mentioned by threeseed), what should their business model be? Licensing to cloud providers would have been ideal, but the response from AWS in this case wasn't encouraging. By boycotting MongoDB in this case are we telling future innovators that their work will simply be stolen and resold for profit if it gets popular? That scares me a lot more than some project changing their license.
We live in the world where we can see a bait and switch for what it is.
MongoDB was advertised as being Open Source and Free Software, distributed under an OSI-compliant and FSF-compliant license. Now they are trying to eat their cake and have it too.
> "then are lambasted when they try to prevent a competitor from copying it wholesale?"
Because that's not what open source is about. Open source is about contributing to the commons, such that your competitors can make a profit from your work.
If your competitors aren't able to do that, then the software is not open source. Period. And in this case, we should point out that MongoDB Inc by owning the copyright doesn't have to play by the same rules, they aren't beholden to the same rules as everyone else.
> "If MongoDB Inc can't compete in the enterprise cloud market simply because they are not AWS (as mentioned by threeseed), what should their business model be?"
Why the fuck should we care what their business model would be? That's for them to figure out.
But if they sell something as open source and they close source it, then we, the schmucks that bought into it, will point out that MongoDB is no longer open source and treat it as a proprietary piece that comes with the caveats of proprietary software, like lock in, etc.
So I hope somebody forks MongoDB from the version when it was open source.
Not only that, MongoDB accepted code contributions from the community under the pretense that their software was open source. They then used the copyright assignment that they required from all contributors to make it non-open-source when they did this license change.
And anyone that sent in patches benefited from it. What's your point?
Cloud providers are now barred from using new MongoDB versions.
Is that fair? Well, the developers (a company) made a choice. They want the revenue from the support/monitoring business, AWS is eating their lunch. So either they completely change their business or try to somehow stop AWS et al. from doing that.
Since MongoDB just recently released 4.x with distributed transactions, it made sense to do the license change thing. Otherwise no one would care (and anyone stuck on AWS would just continue to use whatever 3.x compatible AWS provided).
And still, it's likely that AWS will continue to offer their non-feature-parity fork for quite some time.
So, in that sense anyone who cares or cared for AGPL MongoDB tech should have advocated for this license change a lot sooner.
People invest in open source when they believe in its continuity.
No, people sending patches are not necessarily benefiting from it. Patches can be very expensive and it can be cheaper to pay for actual support with a proprietary solution that's at least honest about its nature and won't pull a bait and switch on you.
> So I hope somebody forks MongoDB from the version where it was open source.
To what end? Why should we use a fork that's supported by a few people when we can still use the Community Edition that's from the horse's mouth? The idea of forking things for the fun of it actually perpetuates the problem that we already have with OSS.
We want to get things for free, use them to make money, but still expect support for new features and bug fixes. This is worse when someone does this in their 'free time'.
Let's discuss the merits of forking from when it was open source. Percona has a fork, or is it not fit for purpose as they also adopted the SSPL thing?
Wait, how has a fork of MongoDB also adopted MongoDB's evil license? How are they able to take contributions from MongoDB and package them under the same license? Do they share the source code internally, or do they upstream changes that are in the open?
> Why the fuck should we care what their business model would be? That's for them to figure out.
Isn't restricting Amazon and others from profiting from their efforts part of figuring out this business model?
> But if they sell something as open source and they close source it, then we, the schmucks that bought into it, will point out that MongoDB is no longer open source and treat it as a proprietary piece that comes with the caveats of proprietary software, lock in, etc.
Did MongoDB sell you their product as open-source? Which specific product? Was it the Community database, or the Enterprise one?
Your argument lacks substance, because you're responding to someone who's asking why people are moving to another closed source product, one whose source code you can't even inspect.
The idea of free software is that user can (and have the right to) modify it in any way one wants. If I found a bug in free software, I can fix it by myself or wait for someone else to fix it, or pay someone to make a fix. That's the way it works.
It's likely that the outrage is from people who don't use MongoDB. A lot of my things rely on the Community Edition. Even with the SSPL, I'm still eagerly waiting a few more weeks to upgrade to 4.2, and take advantage of some of what's new.
If I found a bug, and was adventurous to fix it, I can still open a JIRA and submit a PR to the project ...
The license is no longer OSI approved, so how do you know what you're allowed or not allowed to do?
How do you know that what's keeping AWS from using it isn't also creating a problem from you?
Have you consulted with a lawyer?
That's one benefit of using actual Open Source. You have a definition that all licenses have to comply with, such that developers know exactly the set of freedoms that's common between all of them.
Once you step out of that definition, you're on your own. So you know, I wouldn't take legal advice from random people on HN, you might run into problems.
You're outsourcing your thinking to an organisation that's looking at specific definitions. Might be better to read the licensee and compare it with the previous one.
I can really recommend you to look at Free Software Foundation website[1]. In a nutshell: free software is like "free will", not "free lunch". It gives users four essential freedoms: to run it any way one wants, to study and modify source code, to redistribute copies and particulary redistribute modified copies[2].
As you can see, "open source" give s only half of those freedoms: to study code, it is not mandadory that you actually can modify it.
So, not all opens source software is free. Check out licence comparison and approvals page at Wikipedia.[3]
Thank you for the link. I was actually unaware of this organization. I was thinking that "open source" is more like a figure of speech, not ideology like "Free Software"
At the same time, we see a MongoDB example: a software, which definitely is open source, but also definitely is non-free.
Free software: free for modification, expansion or forking. Possibly free for profit (BSD license)
Source Available: Source is available but under restrictions. Locked room source viewing under NDA to confirm there aren't vulnerabilities for example.
I hope somebody forks MongoDB from the version when it was open source.
That no one has done that already suggests that no one thinks it’s worth doing. And it isn’t, Postgres is properly free, and more than surpasses Mongo in all aspects.
Coming from Rethink and Mongo I don't like SQL. I don't want rows at all, or documentation that assumes a table model. Having a JSON data type doesn't mean you're a document store.
Can someone explain to me what the license changes are? From what I saw, they just strengthened the AGPLv3 a bit, and it seems to me like a better license. Sure, more restrictive, but in the right direction (like the GPL is more restrictive towards having to share than the MIT license is).
> Open source is about contributing to the commons, such that your competitors can make a profit from your work. If your competitors aren't able to do that, then the software is not open source. Period.
This kind of first order reasoning is nice, but the reality of software economics is a tad bit more complex. The assumption that the market is large, that the commons helps everybody sort of equally are not true in a lot of sectors. Namely, as IT transforms itself a lot of things become almost zero-marginal-cost. Starting a new server? Setting up a new database? Backup/Snapshot? Load balancing? Scaling? Just click that AWS web console shit, and you're good to go. And this out-competes the others.
I'm not saying that changing licenses is super-A-OK, but the fact is the license was never good in the first place, because it failed to take into account what will happen when AWS starts to offer MongoDB.
Furthermore, I have no problem with anyone holding the view that MongoDB should then compete with AWS, and/or focus on on-premise computing, and/or slowly pivot away from building MongoDB itself to whatever. But anyone holding this view should recognize the aforementioned reality that cloud computing is happening, IT is not just a hydra, it's an ouroboros too, it's eating itself.
> "The assumption that the market is large, that the commons helps everybody sort of equally are not true in a lot of sectors."
Not sure what we are talking about, personally I don't make that assumption, although I recognize that others might.
Yes, roads and highways help big companies more than they help small companies. That doesn't mean that smaller companies don't benefit from the existence of roads and highways.
> "the fact is the license was never good in the first place, because it failed to take into account what will happen when AWS starts to offer MongoDB"
Without that license, let's be honest, MongoDB wouldn't have gotten popular in the first place. MongoDB has been plagued by technical issues too and without it being open source, one of the carrots being used, MongoDB wouldn't have been a blip on anyone's radar.
So this is a conundrum and I understand the reasons why MongoDB Inc has switched, I do, but I just don't care.
Because the nature of the thing has changed — and for example I would now need a lawyer to find if my own product is safe or not with an on-premises MongoDB solution, because I can no longer rely on OSI's definition to tell me if my use is OK or not. And yes, we've got random opinions on the Internet about what you can and cannot do, but that's not valid legal advice.
And even if my use of MongoDB is OK for now, who's to say they won't change the license again in the future to something even more abhorrent. This means that for me going forward is that MongoDB is no longer reliable from a legal standpoint.
I think companies experimenting with licenses like the AGPL are trying to suss out what open source means in the cloud age. When the GPL came to be and software ran on people's computers, there was no way to distribute software that didn't trigger the distribution clause and require modifications to be available under the same license. With the cloud, there is: cloud companies can and do host all sorts of GPL'd software, make modifications, do whatever they want and are under no obligation to release any of that because running a service was not accounted for at the time the GPL was created.
MongoDB Inc's license switch may earn them some hate but I think the bigger issue is what license terms will open source contributors be comfortable with? What license captures the same spirit as the GPL, should that spirit still be desired, as software moves to the cloud? When every piece of functionality, no matter how trivial, can be used by a cloud provider to bolster their closed ecosystem, are the developers that created that software comfortable with a license that allows providers to do so without giving back?
AWS et al. are committing no violation here of course, they are taking advantage of a market opportunity to offer hosted software, some open source and some not. The market is overwhelmingly saying that they value the convenience of having all of these services available at the click of a button and that the closed source nature and potential for Oracle-style vendor lock-in is not a concern.
There's certainly value there and some folks may feel perfectly comfortable contributing to such an ecosystem, as is their right. Others may desire a more reciprocating agreement, and perhaps the AGPL is a first step towards such a license. I think we as software engineers need to recognize just how high we're standing on the giant's shoulders and put some thought towards helping a community that is trying to adjust to the new cloud reality. "Fuck you give me your stuff for free" is unwarranted and not likely to encourage contribution.
The "spirit of the GPL" is invoked a lot here, however you have to consider that...
MongoDB Inc does NOT play by the same rules as everyone else because they own the copyright.
When a piece of software is useful on its own and survives, without dual licensing from the copyright holder, then and only then we can talk about the spirit of the GPL.
Also people here seem to be confused. The GPL is a super permissive license because it allows you to use it for whatever purpose. You can use it for commercial purposes, you can use it for controlling sharks with lasers to conquer the world, you can use it in combination with any other software or hardware package, doesn't matter. This was by design.
The GPL is just a copyright license, not an EULA and that's part of its genius.
Now you can say that this company or that have been circumventing GPL, but I think that AGPL licenses have been an abomination, a scurge on this industry, only used to lure developers into dual licensing deals and having nothing to do with actual Free Software.
And now we are seeing the effect of allowing AGPL. For one I see an entire forum of really smart individuals that don't really know what the spirit of GPL is, yet we talk about it.
> Without that license, let's be honest, MongoDB wouldn't have gotten popular in the first place
MongoDB with its current license - in my opinion - would have gotten just as popular as it is now.
Yes, the legal questions are real, and were MongoDB just starting up they would work with OSI and experts to clarify things, they would put up a FAQ and so on to get people to trust them.
I guess my definition of open source is that you can read the source so you theoretically know what you're getting or if things don't go the way you want you can figure out why.
This means that open source could theoretically be free as in Mel Gibson shouting but not free as in money found in between the cushions of your couch.
That said I dislike MongoDB but for various other reasons.
Then you've misunderstood what "open source" means. The term "open source" was invented specifically to describe software with the following properties (among others) [1]:
~~~
1. Free Redistribution
The license shall not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license shall not require a royalty or other fee for such sale.
[...]
3. Derived Works
The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software.
~~~
Any software which doesn't meet those criteria isn't open-source.
there's a bunch of stuff on HN currently about not believing everything you're told and fake memories and such, but anyway I could swear that this has not always been the exact definition - that this definition, and the referenced site, have sort of taken over the definition and applied an extreme version of the term.
I believe this because I also believe there used to be two terms open source, and free, that these were distinct, and that all things that were open source were not necessarily free or vice versa. But it seems to me with the above definition that all things which are open source must then be free although all things that are free still do not need to be open source.
on edit: clarified I was referring to HN in first use of the term "site"
I’m confused. I believed the story of Open Source software begins in the 50s and 60s when early OS was essentially free, and the beasts software ran on was the profit center.
The culture for free open source software (and its benefits) was prevalent. But by the 70s companies we’re changing their attitude about this IP. I’m a reaction to increased restrictions Richard Stallman founded the GNU project in 1983.
Is there an Other World theory where this was not the case?
As far as I understand, the parent's doubt is about the _definition_ of "open source":
> I could swear that this has not always been the exact definition
> I believe this because I also believe there used to be two terms open source, and free, that these were distinct, and that all things that were open source were not necessarily free or vice versa.
In this perspective, the history, as reported, matches: originally, there was a "free software" concept and movement (the formal definition was given in 1986), then, in 1998, the "open source" term was coined.
> For example, “Open Watcom” is nonfree because its license does not allow making a modified version and using it privately.
The parent's doubt has verified grounds.
However, there's confusion, because it seems that the "Open Source Definition" is _now_ closer to "Free software" than it was when Stallman expressed his opinion: by that time, Open Watcom qualified as "Open source", but nowadays, based on the "Open Source Definition", it wouldn't.
Isn’t the parent not mistaken in their belief? Early softwares was free because no one cared or saw the value, until the technology evolved. Then companies saw the value, and locked it down (is it important to recognize those peeps we’re the mega-corps of the time like AT&T, not the scrappy peeps we call our peers today). Then academics couldn’t do their work, without violating growing property rights restrictions.
We’re not talking about the proverbial ‘historical house in private hands’—can we look around at this excellent example of early Frank Lloyd Wright house in Chicago. We’re talking about ownership and control for profit.
Mongo wants to wiggle out of the bind they find themselves in. Does anyone else feel this discussion is starting to feel like ‘workshopping’ the legal definitions entrepreneurs and coders can both agree on?
Maybe the parent is asking as a curiosity—Isn’t there also a second origin story about inspection without rights?
But, in the context of the original post’s topic of Mongo and the pickle they’re in, I reserve my normally generous nature, lest I find myself the cuckolded against my own interests.
There seems to be a curious spate of discussions lately about legal use, copyright, and trademark.
Google patenting some machine learning techniques [1] here on HN.
On a Philosophy Podcast I listen to there is an interview with on a legal scholar on his work defending plagiarism [2]
And for the record I am an ardent advocate of FOSS. I believe Mongo is in a pickle, and they should do the right thing to honor the spirit of OSS. And if they can’t, then they should surrender the property to someone who can.
The question is whether Open Source has always been synonymous with free, I do not believe it has I just believe it has historically been strongly correlated but I could be wrong. However using the OSI as evidence of the original meaning of the term doesn't strike me as at all authoritative, especially as the OSI has all sorts of conditions that I do not believe were in any original definition of the term.
as I am not a prescriptivist in language as a general rule it may be that I should alter my usage of the term to follow OSI usage, but then I feel that a useful term is needed for software where you can inspect the source as needed - perhaps inspectable source.
> I believe this because I also believe there used to be two terms open source, and free, that these were distinct, and that all things that were open source were not necessarily free or vice versa.
There are certainly ideological differences between the two; but I think it's primarily in terms of focus. The FSF primarily aims at promoting "software freedom" as an end in itself; RMS claims that it is unethical to give people software but prevent them from sharing or modifying it. As such, they much prefer to use copyright law to promote "software freedom", by things like the GPL and AGPL. But (as I understand it), since more permissive licenses like BSD or MIT licenses do allow the "four freedoms", they consider them "free software" (albeit second-class, because unlike copyleft licenses, they don't fight to keep derivatives "free").
"Open source" was meant to focus more on the benefits of the open, collaborative software development model, without denigrating proprietary software; and, in particular, to be more palatable to large companies. As such, permissive licenses (BSD, MIT, Apache, &c) are considered just as valid as copyleft licenses (GPL, APL, &c).
But saying, "You're not allowed to run a service using our software because it might compete with us" is Right Out.
well often when I read the source of a library (or tool or framework or what term we wish to use), even one that I am free to modify the source of, I will see that the way I thought I was going to solve my problem was not the way to do it and I will need to alter my code not the code of the library.
In a few occasions I see that I need to alter the library, if I do not have the rights to do that then I would probably end up dropping the library as being inadequate to the task.
In some occasions I have seen that I would like to get rid of the library but I am generally not allowed to by other business decisions, in those cases I have always been able to find some hack that allows me to do what I need to even if it goes against the preconceptions of the used library. I then make extensive comments in my code explaining why, probably referring to the other solutions I would prefer to use and explaining why I was unable to do so.
I have no pity for MongoDB, they chose to license their stuff open source. Which means they should have no problem with people profiting from their work, that's the spirit of FOSS.
Of course, this is just one of the many so called "open source" companies that chose open source because they thought it would get them more users but in reality don't care much about FOSS.
- There is nothing wrong with Proprietary software. MongoDB is vilified because they built community on the assumption what this software will be Open Source. Because of this many spend a lot of their own time helping to promote MongoDB and one day MongoDB changed their license. Amazon's DocumentDB makes no Open Source promises
- Your competitors can copy your software is one of the downsides of having your software Open Source. You however may get much better adoption curve in return.
- This is not MongoDB boycott. If repository promises to its users it will only contain Open Source software and MongoDB is not any more it naturally has to be removed. Keeping it will mean breaking promise to repository users
- MongoDB can't compete with AWS is quite far fetched statement. Competing with AWS could possibly slowed MongoDB growth of course.
> I'm astonished at all the comments that vilify MongoDB Inc and then talk about moving to AWS's MongoDB clone. What sort of twisted world are we living in where a company makes a service, tries to sell the service, and then are lambasted when they try to prevent a competitor from copying it wholesale?
The bait and switch strategy is deceptive. It's aim is to milk customers to give some money back the the VCs. But this license minefield is user-hostile.
Users don't like companies exhibiting hostile behavior towards them. Simple.
They didn't use an Open Source license with the intention of getting popular and then pulling the rug out from underneath users.
They tried to make their money by offering their tech as a service and found that they couldn't compete against the resources of large cloud providers who were happily profiting off of their (and the community's) hard work.
> They tried to make their money by offering their tech as a service and found that they couldn't compete against the resources of large cloud providers who were happily profiting off of their (and the community's) hard work.
And now the community's hard work is licensed under a new and restrictive license which, due to legal constraints, cannot be used in entreprise setups.
And now the community's hard work is licensed under a new
and restrictive license which, due to legal constraints,
cannot be used in entreprise setups.
Sure it can. It is fairly narrow in that it targets reselling it as-a-service. Many large companies are still running MongoDB for enterprise workloads, the SSPL does not change that.
> lambasted when they try to prevent a competitor from copying it wholesale?
I feel like if just cannot be repeated enough: You control which license your software is supplied under! If you want to create open source software, you have to live by that decision and follow the license. You can’t slap an open license on the software and complain when people “abuse” the fact that it’s open.
I think the parent is referring to MongoDB's hosted db-as-a-service offering. They make their money from that and they are being beaten by large cloud providers also offering the same thing at less cost.
One in which OSI obviously is paid by cloud vendors to denounce alternative licenses, lobbies for developers to be treated like kattle open for abuse, yet portrays themselves as representing developers, and bogusly claims ownership of the term "Open Source", contributing to monopolization and the weaponization of developer's work for surveillance a la Android.
The OSI has a clear definition for what they deem "Open Source" that hasn't changed since it was written down '98, based on the Debian project's Free Software guidelines. This was all long before cloud vendors could have payed them for anything. And they have, as far as I know, a very non-bogus claim on the term as they coined it to distinguish their (less strict) definition from FSF's "Free Software" term.
Every time I run `brew update` (or perhaps _any_ brew command), I make 6 requests to "https://downloads.mongodb.org/current.json" (one for each version of the formula), and one request to get the SHA for mongdb-shell?
This defaults the whole point of a formula - metadata describing an installable. If that .json file is compromised in any way then suddenly you are downloading anything from _anywhere_ with no checks. By embedding the hash and the download URL in the formula, like literally every other formula does, the download will fail if the release is modified. And there is a git audit trail of any formula modifications.
I inherited a MongoDB Ruby (Mongoid) stack that was a terrible choice for the data stored (i.e. relational data). Actually, I'm not really sure why Mongoid exists at all.
After several years of pain e.g. cursor timeouts (even when supposedly disabled), iterating over the same document multiple times in the one query etc. and of course no transactions (since added). I eventually migrated to PSQL (using some custom scripts) and everything is so much easier to maintain, much more stable and much faster.
We're still using MongoDB for our analytics though, as it's inherently unstructured non-relational data, so MongoDB does actually do an okay job. Well, except for the run away memory usage which leads to k8s killing the DB server for violating memory constraints every so often. Yes, MongoDB itself is configured with memory constraints, it seems WiredTiger ignores them.
Licensing was considered, however honestly MongoDB itself is (or at least was) so bad that licensing wasn't the primary motivating factor.
EDIT: Just to clarify, most of our data is relational, however we do have some unstructured data in PSQL stored in JSONB columns. They work a treat and in some cases have complex indexes on them - they far out-perform anything MongoDB was able to offer us.
I wouldn't go as far as saying it's an anti-pattern. However, doing it properly is extremely difficult.
Why do we do it? Cost saving. It's that simple. For your information, I wouldn't say we do it "properly" either. We do a decent job though.
Basically, for us (and many other businesses) DBs are not the bottle-neck. Our business model facilitates a heap of static content that's served (via a CDN) without even hitting the DB. When the DB is used, it's 99% read-only; except for the analytics which aren't business critical.
Sounds not that cost-saving for me when you mention that your not critical DB OOM-crashes here and there. How much do you saving, like $150/year on dedicated host?
You're assuming that I'm just talking about hosting costs. I'm not.
Maintaining VPS infrastructure just to run a DB is a huge amount of overhead. More so, when the DB crashes and/or wildly consumes memory. You need disk/memory monitoring, logging, process monitoring, availability monitoring etc. What if the VPS itself goes down? What automated system is going to spin it back up?
A self-managed VPS DIY solution is substantially more expensive to maintain than using well-established tooling like k8s. These are all already solved problems. Not just that, it's a standardised work-flow with the rest of our infrastructure i.e. no manual futzing around with VPC etc. to get our cluster and externally managed VPS talking to each other.
For us, a DIY solution was never even on the cards. It was either a fully managed service or what we have now.
However, fully managed services don't just cost more per month. There's frequently additional development overhead, as the offerings are "off the shelf" software and not necessarily easily customised. For example, right now our PSQL deployment is running a custom PSQL extension that seamlessly handles BSON (MongoDB) Object IDs, semantically converting them to UUIDs. Thus, post-migration from MongoDB, application code isn't riddled with code handling legacy IDs.
Monthly service provider fees are but one consideration when performing costings.
EDIT: It's probably also worth noting that our entire infrastructure, including DBs, can be spun up as a k8s cluster on a developer's work machine in one command. We of course also have a staging environment, which mimics production. Development also ought to mimic production as closely as possible (but still be debuggable).
actually it works quite well when done correctly.
basically k8s is less of an container solution and more like a "scheduling" solution. so it's actually way less painfull than setting up your own db.
A lot of companies got lured into using mongodb because it was so developer friendly. It cost nothing and it was easy bring in the back door and alleviated the need for thought.
Then their sales people started coming around and asking for insane sums of money (like $10,000 per instance per year plus 100% markup on hardware to run in AWS - support is extra). They were worried about amazon and others offering a better so next they changed the license.
If it had been SQL it would have been easy to drop in another database. But Mongodb is so different from anything else that you need a major rewrite to get away from it. Postgres has some similiar functionality but it’s not drop in. Amazon has a more or less public beta of DocumentDB which as far as I can tell is a mongodb compatible interface to aurora backend - it works but doesn’t have the polish of RDS yet.
Well there is pl/sql for instance that oracle has, migration costs would be too high for most people. We use pl/sql extensively at work, I cannot even imagine the effort(time/money/people) it would take to migrate from oracle.
I feel like you’re imagining that SQL is more of a standard interface than it actually is. No two relational databases are quite the same and you’ll be stuck combing through your entire app looking for obscure syntax usage that depends on Oracle specific extensions or quirks.
There’s no incentive to not extend or try to improve SQL semantics because for proprietary databases it increases lock-in which is good for sales and for OSS databases the extensions are genuinely positive and increase developer productivity and you don’t feel bad about locking your users in because it’s OSS.
We tried to do a migration from Sql Server to Postgres.
Even went as far as building a parser/compiler to transform Sql. Certain things are just too difficult to handle.
1. Sql Server supports arbitrary sql statements in queries. Postgres does not.
2. Data types are not the same.
3. Feature sets at the 'interface edge' between the client library and the engine differ. For example, Sql Server queries can return an arbitrary number of results.
It's true that Mongo uses a custom language, but with Mongo - you are unlikely to have any significant business logic in your data layer.
Also their API surface is relatively simple.
For example, FoundationDB has a layer that mimics the Mongo API. Amazon has one as well.
If you are correct then your consultancy can stand to make hundreds of millions and save companies billions on their Oracle instances!
More likely, though, is that Oracle users use Oracle-specific flavors of SQL in lots of legacy apps that no one wants to touch, and rely on the support contracts for continued assistance in keeping the database performant for its query load.
Relational/SQL databases still follow the same fundamental data model and query language, despite the differences in SQL syntax. I will argue migration is still easier. Just avoid stored procedures which complex logic, since these are essentially proprietary programming languages.
Maybe I'm misunderstanding, but I thought the new license is just about offering MongoDB as a service by itself. But if you're making any other sort of website and use MongoDB as a database, you can still install it and use it for free.
If the companies got lured into using MongoDB as a service, then I understand that prices could increase and companies could be in a pickle. But if companies got lured into using MongoDB as software, I don't see how they could have a problem.
You're correct, the new license only prevents AWS and other cloud from running the MongoDB software itself as a managed service unless they open-source their entire platform (although, as we see with DocumentDB, they can legally implement the API without the license coming into effect).
The parent comment states "their sales people started coming around and asking for insane sums of money" but I can't find any reference to this.
This was my understanding of the license as well. I read through the block and it very clearly suggested only selling the database as a service was not okay. Using the database as a data store should be fine.
If MongoDB really is sending salespeople to make claims against companies who they convinced to use their OSS database as a data-store, than they are indeed abusing their license and no one should use their database or support their company.
From what I read of the license, that shouldn't be the case though.
The fact that mongo was willing to screw over one set of users makes me worry they'd be willing to screw over all their users. It's a risk I wouldn't take, especially when there are so many other (arguably better) options out there.
I wouldn't choose mongo for many reasons, but this licensing change isn't one of them. It's in line with the general spirit of the GPL: if you're going to stand on the shoulders of giants, you should allow others to stand on your shoulders.
The only major change to the license is in adapting to the rise of cloud services.
The GPL is only a copyright license. The GPL DOES NOT impose restrictions on usage, where "usage" vs "distribution" gets defined by copyright law itself.
That's one of GPL's biggest strengths.
Also successful software packages that are GPL are GPL for everyone. You don't have a mother company that can bypass the GPL due to them owning the copyright. And when you do it's usually a scam that people can smell.
You can't say about a license change that it is in the "spirit of GPL" when the mother company, MongoDB Inc, doesn't have to play by the same rules as everyone else.
So I'm sorry, but when you're talking about the "spirit of GPL", you don't know what you're talking about.
The FAQ for the license change very clearly indicates that your reading is what was intended. Question #4 particularly contains the complete text of the section that was altered, and it's hard to see how they could have left themselves any room to penalize regular users.
But Mongodb is so different from anything else that you need a major rewrite to get away from it.
Well actually....
One corner case. If you are using Mongo with the Mongo Linq driver in C#, you can switch it out for an RDMS without changing too much code with just a little foresight.
A lot of people have difficulty trying to organize complex hierarchical data into rows and columns. A lot of places make you go through a dba to create or change a database which rubs power users the wrong way - and admittedly most of the dbas I’ve worked with are a lot more concerned with making backups fast then in your applications performance. Mongodb doesn’t make you do any of that. It doesn’t make you have authentication either. I think that’s a big reason why it got so popular.
I think it’s funny that web devs pretty much abandoned hierarchical databases since they are the OG database style.
I think it’s just going to take somebody shaking the cobwebs off of their X.500 manuals and making the query syntax and schemas a little more ergonomic for them to come back en vogue.
It’s one thing to have the ability to mold your DB to model hierarchical data but have your DB engine support it non-awkwardly might be a game changer. People are already used to apps needing a DB, cache, queues, S3, filesystem, service discovery, that adding one more thing would hardly break the bank.
Database versioning and migrations are a pain. I’ve tried both home grown and commercial database systems to make database changes part of the CI/CD process. I haven’t found one that I liked.
When I did implement a system with C#/Mongo, I fell in love with changing my database schema just by changing my C# objects. With the C# driver you can include a Dictionary as part of your object to round trip unmapped fields.
Not to mention that after you go through all of your modeling and figuring out your aggregate roots, you can just store the entire object graph with one .Add and the entire object is stored atomically without having to worry about transactions, table locks, etc.
Unlike with an RDMS where your beautiful aggregate root has to constantly be composed and decomposed.
Because we had data that fit better in a non relational store. We stored data that created from user generated forms and we loaded data back into those forms.
Why use a relational store? If you’re working with a system that will only be read and written by an object based language? Why keep converting back and forth between a relational model and an object oriented model?
In C#
var seniorMales = from c in context.Customers
where c.Age > 65 && c.Sex == “M”
Would be translated at runtime to either MongoQuery, Sql, a foreach loop, etc depending on what “context” represented.
You get autocomplete and compile time checks.
When you want to add an record to your Mongo collection, you work with strongly typed
IMongoCollection<Customer>
And the compiler will ensure that your collection stays consistent.
> Why use a relational store? If you’re working with a system that will only be read and written by an object based language? Why keep converting back and forth between a relational model and an object oriented model?
Well I can't tell you what the right choice in your system is, but in the general case I think going with a relational model by default generally makes sense because it's rather future proof. By that I mean a relational model gives you the most flexibility in the future to evolve your system in ways you couldn't/didn't anticipate when the system was initially designed.
I think you got it backwards. A relational schema change is required and probably a data reindex or reload when you change a data model so relational is the least flexible as opposed to something like Mongo nosql?
How do you propose that you query a filesystem? In this context, we are referring to a “document” as a structured JSON document. You still have a semi known structure with fields that you can index and query.
A schema change can handle changes needed to existing data, if you don't do that then sure Mongo is easier, but then you've broken data in your system.
I worked on a project with similar requirements. I just serialized the data with protobufs, encrypted it, and stashed it in S3. It was sensitive data so this also had the advantage of being easy to secure and audit.
No point using a relational db for that kind of thing.
The problematic part with PostgresSQL JSONB is modifying a JSONB column content. In any case, we totally replace the old content by a new one. So, the update operations turn to the complex queries that can lose the content. You can avoid this by performing the full JSON reorganization before the persistent operation.
You still don’t have the richness of MongoQuery and the aggregation framework and the tooling around working with JSON data isn’t there. Let alone the native driver support.
Anything that you can store in object database you can normalize and store in an RDMS. ORMs have been translating relational models back and forth to object models for decades.
In the case of Mongo, you just create one object containing other objects, lists, arrays etc and the driver serializes it to a JSON like structure and stores it as is in the collection.
In the case of an RDMS, you create your C# classes to model your tables and relationships.
The driver translates the LINQ to the appropriate query language.
>If it had been SQL it would have been easy to drop in another database.
Hahaha. No.
If anything, migrating from something like Mongo might possibly be easier. Because it's non-relational, you probably have very little business logic in your database layer.
Unlike with Sql.
And even though Sql has a standard syntax, beyond vanilla CRUD queries, there are many differences. Even if 2 engines support the same synatx, the idiomatic way of doing something will differ.
(For example, cursors in Sql Server is extremely slow, whereas its a perfectly acceptable way of doing list operations in Postgres)
I guess it could be both, but I consider them to be two completely separate issues, and referring to them together as "the mongoDB trap" without any further clarification is quite confusing to me. It could easily lead to misunderstanding, and people "answering" the question with only partial answers.
The company made a terrible product so it is no surprise if they are a terrible company too. That's the trap: using a terrible product made by a terrible company.
I believe I saw you present at UtahJS a few years back. I was very impressed with your presentation about JavaScript performance. I think think about that talk every once in a while.
So you're saying MongoDB is good software, but not quite as good as yours. And you're saying the license is bad. Did you migrate away before or after the license change?
Could you elaborate on how companies are hurt by the license?
I am neither for MongoDB or for any famous ABC or XYZ DB. But before I make my decision to change to any other DB, i evaluate my using my own conscience and not depend upon bashing of any X DB on the internet.
I had the opportunity to redesign the architectures of few productions running apps because of this superstition "Companies are falling due to MongoDB, lets switch to another DB"
Every single time, as an architect I have found that developers are just being fancy about their first-hand experience with some other database and they are unable to think in new direction which MongoDB is built for.
Following are the things most people miss:
1. MongoDB is not safe/secure. Anyone can hack it -> the default configuration were not optimized in previous MongoDB version but it doesn't mean it lacked User security API.
2. MongoDB does not support JOINs or query API just sucks -> No, it doesn't. First, You need to learn about denormalization and schema handling. Second, MongoDB supports JOIN semantics such as $lookup & $graphLookup. Third, it supports ElasticSearch like text searching capabilities and scoring. Fourth, it supports data aggregation pipelines with various ways to compose the data transforming operations including above 2.
3. It does not have triggers like RDBMS -> It has "change streams" which is more flexible than Trigger. This feature also enables multiple application servers in microservice architecture to use MongoDB as a central store. Want a custom ETL streaming pipeline? You got it.
4. It does not scale like ABC or XYZ DB -> Again understand point #2. Also, look into docs how distributed sharding works across replica sets. Spend some quality time figuring out what should be the KeyField to be used for distributed sharding of Data.
5. Licencing sucks -> Have you understood the whole project cost and complexity ? Have you actually looked at all the terms and conditions or are you just a big fan of OSS and for that you can support any stupid alternative?
As someone with several years of experience with both RDBs and mongodb, I totally agree with everything you said.
Also, you got downvoted by the same people that upvoted the stackoverflow post on the problems of downvoting on technical problems on the internet.
People might not like or know the technology and are guided by older tech gurus from the previous generation such as Edgar Frank "Ted" Codd, although he was a genius, now the market is much larger and there's a lot more use cases.
Additionally, most people know RDBs such as mysql and that's what they are comfortable with, i.e. can't get out of their comfort zone and give an honest and good try to something else or don't even have time.
Also it's what's taught in courses as superior to non relational databases.
I would not change our MongoDB clusters for Postgres/MySQL/etc even if I could do it with a single command. In this case it's not relational data though, for a large business relational model I would stick with RDBs.
If you are looking for a document store there aren't many alternatives. And one of the positive elements of MongoDB has been that they acknowledged their many issues and have over the years been fixing them one by one. Whilst alternatives have largely been stagnating.
And I am still yet to find any database that even comes close to its single tuple update speed.
1) No that's not what AWS did at all. They implemented the MongoDB API on top of their own storage layer. It doesn't use PostgreSQL.
2) Of course. But MongoDB is orders of magnitude faster in some cases, has better horizontal scalability capabilities, better drivers and some nicer semantics e.g. around streaming.
I spend somewhere around $30-40k / yr on AWS (EC2) for a 3 member replica set.
I evaluated DocumentDB and price wasn’t the issue (at our scale, the price is OK).
Main blocker is that it’s locked at Mongo 3.4 API compatibility, which is several major versions behind. But worse, their implementation of the 3.4 API is incomplete, so while they advertise “Mongo Compatible”, it really isn’t a drop in replacement.
I work in the enterprise and we spend tens of millions a year with AWS.
Our Security, Cloud Engineering and Finance teams understand VPC, IAM, Costs etc back to front and so when you add a new AWS product they know how to manage, secure, finance and support it. And of course there is no Procurement process with adding a new AWS product.
With a managed MongoDB (even though it's on AWS) you need to get buy in from dozens of people and go a vendor comparison to get through Procurement. It's why for many companies AWS dominates and in the future could well end up owning everything under the application layer.
This still doesn't sound like a good reason to pay AWS instead of MongoDB. Didn't your Security, Cloud Engineering and Finance teams have no understanding of AWS at some point? Why can't they start to 'understand' how a managed MongoDB works, and give buy-in?
There's a common saying we have in our consulting circles, that "Processes should support business, but business decisions shouldn't be made because of lack of processes".
We had a large local bank choose not to pursue a good opportunity because "our procurement process takes too long". This instead of investing in fixing the procurement process.
If your choice is between (1) get MongoDB support from AWS and (2) get MongoDB support direct from MongoDB, the fact that Security, Cloud engineering and Finance know AWS and how to work in their environment seems to be the obvious choice. The difference between (1) and (2) is probably minimal enough to make the existing relationship with AWS meaningful. I don’t know enough about the costs of the two, but it’s possible that the incremental cost for adding it to AWS was cheaper.
My point is that those support functions' lack of understanding of realms outside of AWS shouldn't be the sole motivator for not using a technology.
What happens if a company that uses Software A has good motivation to use B, but their support functions don't understand B? Aren't the support functions supposed to improve by seeking to understand B, even at the initial inconvenience of time and resources?
In a .gov environment, we literally paid 5x more for certain services because the contract terms demanded were too costly or onerous for OEMs to handle. So everything funneled through middlemen of dubious value, who basically borrowed money, pushed paper and carried insurance for a vig that pushed up the price.
The procurement people were very happy, because they got their three bids that varied less than 1%.
I certainly don’t disagree with you on principle. It’s just a bad example in this specific case because A is roughly equivalent to B in this case.
Also, Amazon doesn’t have the same reputation as Google for killing products, so it’s a pretty safe bet. And AWS will be around for quite a long time. The financial stability of MongoDB (the company) isn’t as guaranteed.
Maybe the parent’s company’s processes did work in this case.
They're roughly equivalent, but what if B costs a tenth of A?
It's not about the safety of the bet, because from an OSS perspective, the issue seems to be that many are moving away from MongoDB to something even more opaque. I don't follow AWS, but do they publish a roadmap of planned changes in their document DB?
Does Google have a reputation for killing Enterprise products? I thought it was just consumer products that they offer for "free" that are subject to getting the axe.
Unfortunately that’s typical in enterprises. Procurement staffers are typically not technologists, rather they are contract wranglers, responsible for setting terms with vendors that have longevity, references, willing to negotiate, approved by security, are provably better than at least two comparable competitors, etc. If you want to sell to enterprises you have to bend the knee to their procurement team.
I would love to see open source developers and companies supported because it's not really tenable to replace all the open source we rely on - we probably need 20 million lines of open source to serve a HTML page. If we were actually enabling and empowering open source developers, and especially the people learning, it would be awesome. Enabling people like Torvalds and Stallman to grow into their role of writing stuff that benefits billions of people.
But we can do Hunger Games too. There's no wrong answers.
Define production and define HTTP3. The beauty of open source is that you can be already serving pages using QUIC and TLS1.3 while the standard is being finalised.
For my side project/startup (volunteer management and organisation for NGOs and political campaigns) I fell right into the trap.
I'm not enough of a DB person to know if it was Mongo, or the ORM I was using (Waterline), but my data is extremely structured and relational. Once I switched over to Knex/Objection with a Postgres DB, everything went much smoother. The transition, though, took around two months, was hell, and I almost turned back many times.
Yes, in addition they apparently use a pretty outdated version of it. (Several people mentioned this on a related HN thread that I'm having trouble locating.)
I understand the removal of non-OSS-compliant software from core distributions, and see little controversy in that, as it's the risk of changing a license.
What I don't understand is the many people who are talking about AWS' replacement being a solution for people migrating from MongoDB.
From the comments, it seems:
- it's expensive to use. Someone spent $15 for 2KB data over 3 days [https://news.ycombinator.com/item?id=20862196]
- it's only compatible with MongoDB 3.4, which seems not to be enough for some people.
What are the reasons to move to AWS' very offering that MongoDB (and others) are trying to prevent from making money off their investment? Is it a feeling of 'betrayal' that the license has now changed?
So, did the change to their Server License thing result in people having to pay for the Community Edition?
Is the move from MongoDB because it's incompatible with one's data needs (in which case, why didn't one do enough research)?
Why move to AWS' offering instead of 'supporting' these companies? If AWS and Azure thought to create MongoDB Compatible abstraction layers, then surely they saw something useful/good in parts of the database? Then why punish the companies that innovated in creating these technologies?
Lastly, the idea that companies will be fully-OSS and make money from unicorn dust fails once those holding these opinions are on the driver's seat. How many foundations do you donate to, that support the OSS that you use?
The current trend of continuing to want things for free from companies, but being willing to spend an extra fee for a 'managed service' from a cloud provider will hurt a lot of otherwise innovative companies in the coming decade.
If people accept that what MongoDB did with its license is acceptable because the OSS model failed for them, then the viability and future of the OSS model might come into question.
People tend to come to believe something organically and then later cherry-pick facts and observations that back those beliefs up. So even if MongoDB did what it had to do, or did what would otherwise be morally defensible in the most popular moral frameworks (as I personally believe to be the case), people who have a personal or emotional stake in the future of OSS will be looking outwardly for a villain. If it failed, it must be a failure of someone who crossed OSS. MongoDB seems the only choice for a villain in that regard.
Rationally, MongoDB's decision made sense because of the real actual threat of AWS and others offering alternatives (at various levels of baking) that seek to undermine MongoDB.
If this is the path that we choose to take, we'll see more companies go back to the closed source model (which MongoDB hasn't gone in).
Serious question: can someone explain why the server side public license is not an open source license, with specific reference to AGPL? Is it because of the provision forcing the source code release of auxillary software used to run the software as a service? As far as I can tell, it meets the FSF's free software definition and the only that seems questionable in the OSI's open source definition is point 9.
> “Service Source Code” means the Corresponding Source for the Program or the modified version, and the Corresponding Source for all programs that you use to make the Program or modified version available as a service, including, without limitation, management software, user interfaces, application program interfaces, automation software, monitoring software, backup software, storage software and hosting software, all such that a user could run an instance of the service using the Service Source Code you make available.
Article 13 requires you make the source code of only vaguely related software available. So if you use a proprietary backup system, or someone else is doing your hosting stack, you can't use the license without breaching.
Having to either own your entire stack or only using FOSS for the entire stack doesn't really fit the "freedom" part of open source.
Section 13 of the mongodb license notes that all supporting software must use that license. That impacts everything in your stack. Consider kernel drivers, javascript libraries in your UI, and everything in between. Use Ansible to manage you stuff? That won't work with this license.
The goal of this license isn't to get all the "Service Source Code" under the license. They know that the people who would run a service don't have that within their power.
Instead, the goal of the license is to force many folks to have to purchase a separate license from the SSPL. The whole point of the license is to limit freedoms.
Since it's literally impossible to comply with the article 13 of SSPL, MongoDB's license definitely doesn't give its users freedom 0[1], as defined by FSF.
[1] - The freedom to run the program as you wish, for any purpose
When you are offering MongoDB as a service, article 13 requires you to release the source code of everything you're using to host your MongoDB instance under the terms of SSPL.
In practice, it's impossible because you aren't the copyright holder of your kernel, firmware, webserver etc. so you can't change their license to SSPL.
As far as I understand, you could redistribute BSD under the SSPL, since the BSD license doesn't prevent relicensing as long as you keep the BSD license as well.
And besides, there's a difference between the practical impossibility of building a kernel and the idea of the actual impossibility of complying with the license terms.
That said, I think the argument that the SSPL makes it difficult enough to use the software (due to the bookkeeping requirements of tracking every piece of software that interacts with the SSPL software) has some merit.
> can someone explain why the server side public license is not an open source license
Depends on what you think 'open source' licence means. The source is literally openly available. There are just some extra restrictions on what you can do with it. The FSF and the OSI don't own what 'open source' means, of course - the term predates them and comes from intelligence.
> The FSF and the OSI don't own what 'open source' means, of course - the term predates them and comes from intelligence.
Ref please?
The FSF was certainly around pushing for "free software" long before "open source" was commonly used to refer to copyleft / permissive licenses. And the sole purpose for OSI's existence is exactly to define what is and is not "open source".
In any case, it is very important to define terminology and protect its use. The goal of "open source" is certainly not to simply let people look at the source, but to let people use the source in certain ways. People have thought long and hard about exactly what the minimum standards are to consider something "free software" or "open source".
> We have discovered that there is virtually no chance that the U.S. Patent and Trademark Office would register the mark "open source"; the mark is too descriptive
While ESR's link establishes precedence, it doesn't actually tell me what it means in an intelligence context.
From Wikipedia [1]:
> Open-source intelligence (OSINT) is data collected from publicly available sources to be used in an intelligence context.
IOW, the "source" in "open-source context" isn't actually talking about "source" as in "source code", but "source" as in "source of information". Not really related.
Whether or not they could trademark the term, when people in our community say "open source", they specifically mean something which matches OSI or FSF's definitions.
> IOW, the "source" in "open-source context" isn't actually talking about "source" as in "source code", but "source" as in "source of information". Not really related.
ESR says specifically that it's related - he says the relation is a 'feature' of the name, even.
ESR was the president of the OSI when it published the Open Source Definition and applied for the trademark. Justifying a weaker definition can’t be why he called it a feature.
What you're describing is source-available. If that was the only criteria for an open source license, then there would be tons of additional proprietary software we'd have to classify as open source -- Unreal Engine, for example.
Regardless, the word isn't really the important part of Homebrew's decision. Whatever you want to call it, Homebrew has decided it can't include MongoDB in its repository while guaranteeing the freedoms of its users. A semantic debate over the meaning of 'open source' won't change that.
That doesn't mean the semantic debate is useless, but regardless of where you fall on that debate, MongoDB's license does not guarantee freedom 0 of the FSF's definition, and that's going to effect which open source organizations are willing to distribute or build on top of MongoDB. You should expect platforms like Homebrew that care about freedom 0 to continue to abandon MongoDB.
Anybody using their personal definition of the term, rather than an OSI or FSF compatible definition and without bothering to explicitly state their personal definition upfront, is wasting everybody else's time and being a pain in the ass.
Undisclosed personal definitions are an unnecessary impediment to mutual understanding.
> The FSF and the OSI don't own what 'open source' means, of course - the term predates them and comes from intelligence.
You are misinformed, at best.
1. FSF predates the term "open source", that much is true.
2. OSI coined the term "open source." And FSF has has always had issues with that.
3. OSI, on their front page, above the fold, advertises their mission as stewarding the definition of "open source". Again, FSF isn't so keen on that.
In any case, if you want to come up with your own definition of "open source" you are asking to be the third person in a three-way fight. Good luck with that.
Anyway, I have not looked at MongoDB's license. If it is too restrictive for the taste of this or that distro, then I guess it has achieved MongoDB's objective.
Can somebody tell me what is wrong is SSPL? I just don't understand what this hostility is all about. A company creates a crucial infrastructure component which is a database, open sources it, everybody can use it for free, cloud vendors started just installing it on their servers or making clones of it and making profit off it, everybody is using a component that took years and millions of dollars to develop but the company that created it cannot even get profit from its own product. I just can't understand why would a company open sources its products if this is the result. The product is free to use, but for profit entities using this product MUST pay the maker if they are using it as a SaaS which is a zero effort operation.
This just doesn't happen in any other industry, if you go to a baker, you must pay for the bread, you can't in most cases even ask how this bread was made or know for sure that price was fair or not, and mind you this is just slice of bread, while in technology it takes years of experience and knowledge just to create something as crucial as a database, and yet people expect everything to be free, very liberal licensing to even profit from the product without sharing it with the original maker. I don't even like or even respect MongoDB as a database, but the amount of hostility towards anybody trying to make money off a FREE and OPEN SOURCE complex software is totally beyond me.
The only hostility is because people are trying to continue to push MongoDB as Open Source. It's fine for MongoDB to be proprietary, lots of good software is proprietary. It's just not Open Source.
To your baker analogy, I don't have any objection to a baker withholding their recipe. But if a bunch of bakers want to share recipes, and they form a special supermarket where only these recipe-included products will be sold, why is it considered hostility for them to exclude a product that doesn't make its recipe freely available?
Nobody's being mean to MongoDB. Even with Homebrew, MongoDB can still distribute its own source. It's just that MonboDB doesn't belong in the same store aisle that they used to be in. People are only getting ticked that MongoDB is trying to position itself as some kind of open source savior, that its advocating that MongoDB should still be allowed into the recipe-included bakery chain, even though it's not following the same rules.
If I run a vegan bakery and I don't include sausages, that's not me being mean to the meat industry. If I run an Open Source repository and I don't include proprietary software, then what part of that is hostile?
Software licensed under the SSPL is not “free” in either sense of the word. It’s not free as in beer, because I must pay to use it. It’s not free as in speech, because it violates Freedom 0 of the four fundamental freedoms [1]: I can’t run it as I wish, for any purpose.
More practically, MongoDB offers their own managed hosting service. Are they paying the Linux Foundation for the OS they’re almost certainly running? How about nginx / HAProxy / Let’s Encrypt / whatever else they’re using in their stack? This isn’t to say that there’s anything wrong with charging for software, but it’s pretty hypocritical to point their finger at others for profiting off free software whilst doing so themselves.
afaik the user doesn't pay for MongoDB, you can use it freely, read the code, modify; if I understand correctly SSPL is basically AGPL/GPL but with clause that cloud vendors that want to use this product to provide a SaaS version must pay to the maker. I don't think this is any unfair esepcially if this project was made from scratch by the maker and not a fork off another OSS project.
Cloud vendors are "users", too. I'm not saying it's fair or unfair, just that it's not free. MongoDB is of course within their rights to charge to use their software, but they're not somehow being exploited by those who profit from it without paying — after they offered it for free! — when they themselves profit off the labor of the same people without compensating them.
Put another way: Amazon is a corporate member of the Linux Foundation. Why is it okay for MongoDB to profit off Amazon's labor without paying, but not vice versa?
Okay, what if I want to offer total freedom to users but not for other competing companies? There is no single license that can protect a company that creates a FOSS product. It's just ridiculous that a company creates a product for free and another uses it as is and sells it for profit by just "hosting" it. Esepcially for the case of a database, the only way to make money is by having managed service or licesning it to cloud vendors. I can't think of any other way of monetizing such a product
For the case of Amazon sponsoring linux, it's in the very interest of Amazon that Linux stays alive and active because all their billions from AWS comes by running linux kernel as infrastructure, not to mention having the advantage to influence the components being added and maintained that result directly in more profit for them. Linux foundation is totally different in its structure and goals from a for-profit company like Mongo.
> Esepcially for the case of a database, the only way to make money is by having managed service or licesning it to cloud vendors. I can't think of any other way of monetizing such a product
What about charging all their users? It's worked out fine for Oracle.
The current licensing scheme is fine, too. Again: no one has any issue with Mongo charging their users! It's just not open source software.
> For the case of Amazon sponsoring linux, it's because the very interest of Amazon that Linux stays alive and active because all their billions from AWS comes by running linux kernel as infrastructure, not to mention having the advantage to influence the components being added and maintained that result directly in more profit for them.
The question remains, though: why is it acceptable for Mongo to profit off Amazon's open-source contributions without compensating them (or at least donating to the projects themselves), but not vice versa?
> Linux foundation is totally different in its structure and goals from a for-profit company like Mongo.
I don't understand your point here. Mongo isn't owed anything extra just because they've decided to structure themselves as a for-profit company.
I don't think your baker metaphor holds up though, because a major component of open source software is that people outside of the companies support it.
A better metaphor would be if the bakery had started by using volunteers to create all the recipes, and then the baker decided that people could only use those recipes if they followed his terms so that the baker could stop other bakeries from competing. This obviously upsets the people who contributed to the recipes thinking they would be open for anyone to use.
Mongo started as an open source project, used that openness to build community (and indeed their product itself), and then pulled the rug out from under everyone to gain a competitive advantage.
If MongoDB started as a community OSS then I am wrong in this case, but about other open-source companies companies that want to protect their rights in not getting exploited by other for-profit entities that might use the product and profit from it? even AGPL guaranties nothing in most real-world cases.
Well here's the question- how are they getting exploited? If I release code for people to use for free, and people use it, where's the exploitation?
I can understand why some people would not choose to give their code away for free, but trying to be both open source while having the benefits of being closed source seems like they are trying to exploit the open source community.
this is totally beyond me. So a company making a profit from a product made by another company by just hosting it is not exploitation? Does this happen in any industry? A company that makes product for free and another takes it as is and sells it is not an exploitation?
It isn't exploitation because it is literally part of the definition of open source that other people can use and profit off of the work. Linux has made more than one company rich- do we think Red Hat is exploiting Linux?
It's also unfair to pretend that companies who are setting up managed services are universally not contributing back- by open sourcing their code MongoDB has been able to benefit off of the issues that these other companies have found, often without having to do more than review a pull request.
There are benefits of open sourcing your code, just as their are downsides. Companies like MongoDB can't have their cake and eat it to- by closing their source code like they have they are exploiting the open source community. They spent years taking the benefits of the community, with the community having given them these benefits with the assumption that the community would be able to benefit from the openness of their code. MongoDB deciding to no longer offer a true open source option for their software is exploitative and a slap in the face to every open source developer.
If someone were promoting a cause--say a business just trying to get the word out there about their new offering--were sitting at a table with a box that said "free mugs", would you consider it exploitative to take the entire box of free mugs, scrub off the company's logo, and begin selling them to people? Would you at least say that it's kind of scummy, or at the very least ethically questionable?
Being technically within the bounds of your agreement and being exploitative are not even close to mutually exclusive.
>It's also unfair to pretend that companies who are setting up managed services are universally not contributing back- by open sourcing their code MongoDB has been able to benefit off of the issues that these other companies have found, often without having to do more than review a pull request.
It's also unfair to pretend that you know for certain that the benefit of this exchange was significantly in favor of MongoDB compared to the detriment they experienced from having their work repurposed.
It is not a good defense of OSS to say that this is working as intended.
But it is working as intended. The point of open source is that I can do whatever I want with the source code — no ifs, ands or buts.
Your mug analogy isn’t great. Mugs are finite in number and cost money to produce, whereas software is infinitely and freely distributable. Google running a managed MongoDB service doesn’t directly impact Mongo’s bottom line.
Furthermore, Mongo’s own managed service almost certainly runs Linux in its infrastructure. Google is one of the largest contributors to the Linux kernel, whereas Mongo makes no notable contributions. Why is it okay for Mongo to profit off Google’s open source labor without compensating them, but not vice versa?
Software is only free to infinitely distribute so long as people are willing and able to make it. That's where the money comes in. There is zero marginal cost of production but there is very real upfront cost that must be recouped. It's not magic. You'll notice that quite a lot of software has historically been sold for actual money, and still is. So I think the mug comparison is quite apt, even if we'd rather it weren't.
MongoDBs use of Linux is not adversarial to Google and does not make it impossible (or even slightly difficult) for Google to benefit. In that situation, it definitely feels like the "rising tide lifts all boats" situation that OSS was intended to create. If MongoDB's use of Linux was somehow adversarial and somehow significantly affected Google's bottom line, you can bet your ass Google would change how it uses and contributes to Linux.
I don't think this is a consistent argument. In your first paragraph you say there's an upfront cost to developing software that must be recouped, whereas in the second you say that MongoDB's use of Linux is okay because it's not adversarial to Google. But how does that help Google recoup the upfront cost? They’re taking advantage of Google’s upfront investment without compensating them for it.
Cloud vendors' use of MongoDB is also only adversarial because MongoDB chose this particular business model. They could have charged all users like Microsoft and Oracle, released separate community and enterprise editions like MySQL, or charged for support like SQLite. It's fine that MongoDB wants to monetize this way, but it doesn't mean that anyone has to accommodate them.
I also want to say that I'm not opposed to people charging for software! It's just that MongoDB seems to want to reap the benefits of being open source, while still restricting how people can use their software.
>I don't think this is a consistent argument. In your first paragraph you say there's an upfront cost to developing software that must be recouped, whereas in the second you say that MongoDB's use of Linux is okay because it's not adversarial to Google. But how does that help Google recoup the upfront cost?
Nothing helps them recoup this. Open source is a public good, IMO. It doesn't benefit the creator nearly as much as those who can consume it. I'm not trying to say I think it's okay one way or another that Google isn't making money on its Linux contributions. I'm saying Google is okay with their position because no one is using their contribution to the public good against them, and they would have made those contributions to the Linux codebase anyway (because it benefits them to do so) so why not help everyone? Again, rising tide lifts all boats kind of thing. That's the difference here. Google wants Linux to be better because it makes their platform better. But Linux being better is not the product they offer. And the world having a better Linux doesn't undermine their product. At least, not in the same way that offering MongoDB managed infra for cheaper than Mongo can undermines Mongo's product.
I think you're trying to say fair is fair, and the license must be applied evenly and consistently or your reneging on the deal. Which I think we can all agree on. Where we differ is that I think it's okay to change your license if it's killing you.
I'm even okay with changing your license (although I understand why people who made contributions to what they thought would continue to be an open source project would be mad). All I'm saying is, MongoDB is no longer "open source" in the same sense that Linux/nginx/MySQL/etc are. It's not a slight against MongoDB that — for example — Homebrew would remove them from their core package repository, which only includes software with OSI-approved licenses.
The other sticking point for me is the idea that it's "exploitative" for cloud vendors to run managed MongoDB instances without paying them. MongoDB has existed for over a decade, but their own managed service only came out in 2016 — before that, they offered an enterprise version and support. So were cloud vendors offering a managed MongoDB before still exploiting them? Or did it only become exploitative once MongoDB decided to enter that market, too?
That behavior also falls directly in line with Canonical's intended distribution of Ubuntu and the business model that surrounds it. Not quite apples to apples.
I, too, don't understand the hostility...It's not like they pulled parts of the code out and closed it (looking at you, Elastic), or even have "enterprise" paid features - they just want to prevent AWS et al. from hugely profiting off of their work, which is, in the long term, bad for everyone involved except partially AWS who would have to pay to sell it, thus keeping the development going...I'd expect this to be something that OS community would stand behind, as long as it's very defined and narrow-scoped like it seems it is to me...If anyone could give more color to explain the reasons for hostility, I'd be grateful
I have a question: has anyone simply forked MongoDB from the time just before the license change? Owners of open source software can change the license, but can they change the license of old code?
IANAL, but this happens fairly often within the community. My loose understanding is that code released under the AGPL remains licensed under the AGPL; the license can't just be retroactively revoked like that. The company may require that active forks adopt a new name and branding due to trademark disputes, but this is a different matter not covered by the license.
I was not able to find an active fork; the closest thing I'm finding so far is here, but it hasn't seen any activity for 7 months:
Very cool, thank you. It seems like the original AGPL license should have worked for companies like MongoDB. But, their company, they can do what they like and lose users.
With MongoDB's license there is another reason to migrate away from it. I migrated an app from MongoDB to postgres. I ended up just using a varchar to store the IDs. The Mongo style IDs are in addition to an integer primary key, so joins happen with integers, but every time a user is shown the IDs, in the URLs, it's a BSON ID. It hasn't caused any issues, performance or otherwise, but there are thousands rather than millions of records. It's because of Django, not postgres, that I decided to use varchars to store the IDs rather than bytes or integers. Django is flexible but there are always tradeoffs from going outside the framework. Finally, and this is my favorite thing about how I went about it: all BSON ids have the column name of "id" and all integer primary keys have the column name of "pk", whether or not they have a BSON ID (through tables don't need their IDs exposed to the API).
PostgreSQL do have a variable unlimited length datatype : text. AFAIK, Varchar is internally a subtype that bound the text type. So in extreme situations you might even get a very slight performance advantage using text instead of varchar.
MongoDB changed their licensed from an open source license to one that has restrictions specifically aimed at busting up Mongo (the company)'s competitors who offer managed MongoDB services.
These restrictions mean it is no longer an open source project. It is also worrying for a lot of people that mongo was willing to change license terms like this, as it means they may be willing to do so in the future if it brings them more money.
Since mongo has reached the point where they're competing on license terms, not on service or via their product, mongodb may not be the best choice for someone starting a new project. At this point lots of other options exist, with stable and open source solutions like postgres having document store features built in as well. In fact for a lot of use cases postgres already performs much better than mongodb, leaving the real question to be why anyone would choose to use mongodb at this point.
Following the links here: "mongodb and mongodb@3.6 do not build from source anymore" -> "We gave up on this as we have no clue on how to fix the build, or it would take too much time."
> It is also worrying for a lot of people that mongo was willing to change license terms like this, as it means they may be willing to do so in the future if it brings them more money.
Ultimately this is only a worry for people who choose software that is apparently not good enough right now, but hope it will become good enough in the future.
It's a worry for people who choose software that they need to work in the future full stop. As someone else pointed out elsewhere in the thread, this is being removed partly because the previous open source version of MongoDB no longer builds from source, apparently due to some change to the toolchain or libraries. Normally you'd upgrade or backport upstream's fix, but that's no longer possible in a situation like this.
> Mongo provides you computer code packed into a tarball and forbids you from profiting from new code derived from it by your own work. Is this ethical?
I don't have any problems with it ethically: if they did the work and own the copyrights, they can make whatever conditions they want as far as I'm concerned. It's just not open source.
It also gives you source code but attaches some pretty significant conditions that in most cases would prevent you from profiting from new code derived from it.
only if your source of profit is obtained by restricting the customer from being able to use your code in any way they see fit (including modifying it).
If someone can undercut you so easily then your products are overpriced. I would not say this is "not so great for commercial businesses" just because the GPL does not make an effort to prop up phony business models.
Or they can undercut you because you made your core competency freely available. It cost you a great deal of time and money to make, and it cost then nearly nothing to use. However, while you were pouring time and labor into developing the product, they were doing the same with infrastructure that could support managed offerings of your product and products like yours (without necessarily ever having to do any real innovation or takin on any risk themselves!). Voila, you were undercut without being overpriced.
They are if the way you monitize your platform is by offering it as a managed service, as is the case with MongoDB. Company A spends 75% of it's resources developing a product and 25% on a platform, Company B spent 75% of Company A's budget just on its platform and uses A's product for free. Who will most likely have a better platform that they can offer at lower cost?
In the AWS case, Amazon already spent many multiples of MongoDB budget on their platform, so they were easily able to undercut.
You’re asking one of the right questions for this Mongo post’s debates. I can’t say what the right answer is, as it’s an ethics and beliefs debate, but you’re definitely asking a relevant question.
A lot of people advocate PostgreSQL as a replacement. Why not elasticsearch? It’s also a document store with a good history.
At a previous job I shipped Mongo as the store (under AGPL) because at the time the replication story for PGSQL was too complex compared to mongo. But I reached a point where I was going to replace Mongo with elasticsearch and get rid of Solr at the same time.
For a long time, the only reason ElasticSearch was not the ugly duckling of distributed systems was because MongoDB existed. It does not have a good history at all. There was a time that Elastic even claimed that it beat the CAP theorem, which always makes me chuckle when I'm reminded of it, and historically they also have been quite vague about the distributed properties (and shortcomings) of ES.
It works fine as a secondary datastore when you would benefit from all of the implemented search functions, but I wouldn't trust it for consistency (so I guess in a way it is a replacement for mongo \s)
Not only that but having operated ES clusters before, it's a tricky thing to manage, and depending on your workload they can be very resource hungry.
PostgreSQL is very solid though, and will scale well for the majority of people. I highly recommend this over ES, not to mention it does have some search features too, you should check them out.
Depends on the version of elasticsearch you’re running and the use-case. If you’re running a single index with a well-defined schema, I think elasticsearch works very well. If you need many indices and can’t have a defined scheme, then it can be tough.
I work on a team at Target that provides a log aggregation product and we’re finding that a single index with a well-defined schema used to troubleshoot applications via logs is very easy to manage and scale. We support some legacy patterns like “index per application” that are a pain in the ass to manage.
Just to provide some context, we manage about 40 clusters that range from a few data nodes to about 160 data nodes with the majority falling in the 16-60 node ballpark. We don’t have a problem with data loss due to elasticsearch, generally speaking.
I asked myself this a few years ago and went to see who had thought of it first. At the time, the prevailing opinion was that this was a bad idea. Elasticsearch had no ACID data integrity guarantees at all at the time.
My mongodb knowledge is probably a bit out-of-date here. It didn’t have them either when I was using it. Multi-document ACID would have been really useful, is that a feature now? That would be one data point against elasticsearch.
I've run into some weird issues in the past with data types changing by themselves, but it may have been user error: in any case being able to reindex from scratch fixed the problem.
Just as an anecdote to the jepsen test findings, I’ve used elasticsearch at two jobs as a primary datasource and haven’t had data loss as mentioned in the tests. The tests are, at this point, pretty old and I’ve found that newer versions are pretty good at controlling data loss.
As a counterpoint, mongo also still has some outstanding issues with jepsen tests, but they are working on being compliant. Honestly, as far as resiliency, I’m not sure either has solved the problem perfectly.
I may have a project coming up that will include a document store component. It's in-house, with the maximum number of simultaneous users under 15, so scalability that way isn't a concern.
However, the number of documents is large, and for some documents previous versions will have to be stored, as well.
With Mongo out, do you have any suggestions? Is PostgreSQL the best option here? I'm fairly new to this space.
I do like this, millions of record, prime fields in the table, then a jsonb column as the document-store. Just add a row for a new version. And extracting detail from jsonb is pretty easy, usable in SqL queries and materialized views
I just recently deployed a cockroachdb, and have been very happy with the results. For my use case, the JSONB columns are fantastic, and has much less deploy and admin overhead than Postgres.
Can’t we trace a clear line that says: “Here is my new tech. It’s FOSS you can access the code and use it for free to build other technologies with it. You may not simply provide my tech as a service and charge money for that’s my biz model”
Example:
Here’s a fantastic new mixing machine. You can make your own for free and use it in other applications such as making smoothies or cakes. You may not start an industrial mixing biz and charge money for it. That’s my biz model.
My current thinking is to consider postgres as the default choice, especially for an MVP. It can handle just about any MVP-level scenario and helps you avoid over-engineering.
But if you really do need NoSQL to deal with scalability or more advanced requirements, I like DynamoDB. I like it not because it’s user-friendly (it’s not very), but because its limitations are very clear and out-front, and if you try to do something it’s not suited for, you’ll quickly realize it’s hopeless.
Mongo is the opposite—it gives you the impression that you can use it for all kinds of things, and it feels easy in the beginning. But without careful planning, it will lead you merrily into awful traps, because its underlying limitations are glossed and patched over by the api rather than being made explicit.
IMO the use case for mongodb in its heyday was great support for schema-less storage, which was perceived as a way to give your team velocity. And also great support for operating a cluster over primary keys.
(The performance story vs SQL is overstated -- a lot of their early benchmarks were from tuning down safety margins like fsync. You can do that in SQL DBs too).
postgres has pretty good json support these days and mysql is getting there (managed mysql tends to lag a version).
asked this on a sqllite thread before but: anyone know a single file nosqldb that has good python bindings. i know I could just write to json or something but I'd like something that supports queries. right now I'm using MongoDB and it's completely Overkill
It depends on what you mean when you say you want it to "support queries", but then also ask for a "nosqldb". It really depends on whether you want a full query grammar (in that case, why not SQL?), or if a key/value store is enough.
I use lmdb pretty extensively. It is single-file (well, it has a lock file) key/value store, can be read-from/written-to by multiple processes, and embeds nicely. It has Python bindings, but I've only used it from C.
The extension is included in the standard sqlite [amalgamation](https://www.sqlite.org/amalgamation.html), hence it's basically always available (ie you'd have to manually disable it) (ime).
It's worth noting that sqlite's typing is very flexible, so you probably want to add a `check (data is null or json_valid(data) = 1)` to ensure the data is _actually_ valid json.
You can then index based on json queries, eg `create index some_index on something((json_extract(data, '$.someField')))` and then do an indexed query, eg `select * from something where json_extract(data, '$.someField') = 'blah'`.
In our experience it's all working quite well :-)
(Groking json_each and json_tree took a few goes, but now is working well (eg we join onto json_each to allow a row "labels" containing a list of label (rather than a one-to-many table join for something_labels)).)
Has anyone actually used json-based queries in PG in a nontrivial way, and had a good experience? I looked into it but the SQL syntax for doing json operations was crazy complicated, and I had trouble finding an ORM that did a good job of simplifying it.
Yeah, I don't mind it. Oftentimes when you want to manipulate JSON, you'll embed a raw snippet of PG-specific SQL into the query you're building with your ORM. I do wish the operators were a little more ergonomic though. One of these days I'll print out the list and stick it to my monitor.
What kind of non-trivial use cases do you have. I've found you generally just need to pick out a field using the JSON syntax, then you can use all of the normal SQL tools for fancier stuff...
For millions plus rows, the queries get crazy slow. If your jsonb field contains lot of data, JOINs on toast storage tables takes chunk of the query times.
My 2 cents: Best to keep data normalized and in separate columns. If you gotta keep data in jsonb, keep only the data that you don't need to query on. Anything you need to query, you better put it as a column. You'll thank me later.
I mean I'd argue if you're questioning it then you should get out because you A) already perceive enough risk that you consider it questionable and B) It sounds like you're sticking with it because you already have it and it's been a winner historically. But that doesn't mean you should stick with it :P
Can't tell you whether to sell or not, but I think there are going to be plenty of companies struggling under Mongo DB for a while (I work for one: we know it sucks, dislike using it, don't have the significant resources needed to get off. And the product is still growing rapidly, so we're getting more locked-in).
At this point I think it's a coin-toss whether we move to an RDBMS or try to use their newish JSON Schema support (and other features) to achieve some sanity.
And, to be fair, Mongo's hosted management console is really good, the support has been excellent, and since we switched over to their hosted solution I don't think we've had a single problem that wasn't of our own making.
They report earnings on Wednesday. We'll see if the license change had an impact on revenue.
My guess is it won't have a big impact, because customers who care about the license being open source probably wouldn't have been paying MongoDB in the first place.
Cloud providers have been able to stand on the shoulders of giants, profiting immensely from millions of lines of open source code while giving little of it back, and we seem to be largely fine with this. Will we be fine depending on their services when the cloud providers become the new Oracle, free to raise prices extravagantly when we have no other choice?
If MongoDB Inc can't compete in the enterprise cloud market simply because they are not AWS (as mentioned by threeseed), what should their business model be? Licensing to cloud providers would have been ideal, but the response from AWS in this case wasn't encouraging. By boycotting MongoDB in this case are we telling future innovators that their work will simply be stolen and resold for profit if it gets popular? That scares me a lot more than some project changing their license.