Live data from Hacker News

MongoDB's Server Side Public License Is Likely Unenforceable

processmechanics.com

171–180 of 245 posts

Re: MongoDB's Server Side Public License Is Likely Unenforceable

#171
post #84

Remind me of that one time when they went berserk on every tooling vendor using the name « Mongo » in their product name : RoboMongo,MongoGUI etc... they all received a legal notice to remove the name mongo from their product. This was probably one of the most evil thing have seen in the open source industry . Most of those vendors were open source with paid premium features or donation. After receiving their legal n…

I have absolutely no problem with trademarks as long as they're used as consumer protection.

For example, there's the whole uBlock vs uBlock Origin thing, where uBlock Origin is the good one run by the original maintainer, and uBlock is run by people who had nothing to do with the original project.

https://en.wikipedia.org/wiki/UBlock_Origin

Trademarks can be used offensively, and few cases were more offensive than the Linux trademark dispute back in the 1990s, when William R. Della Croce, Jr., someone with nothing to do with the Linux kernel or anything else of value, acquired the trademark to "Linux" in September 1995 and began to demand royalties from the people who did useful things with their time. It took a court case to dislodge him.

https://en.wikipedia.org/wiki/Linux_Mark_Institute

https://www.linuxjournal.com/article/2559

What Mongo did was meaningfully better than what Della Croce did, and closer to the spirit of "prevent people from confusing products and thinking stuff is from the original development team when it isn't", but I can see how it would be an unpleasant shock in the Open Source world which, sadly, usually doesn't know or do a damned thing about trademarks until some asshole forces the issue.

Re: MongoDB's Server Side Public License Is Likely Unenforceable

#172
post #109
post #82

Earlier quoted context omitted.

Postgres HA: https://www.postgresql.org/docs/9.5/static/high-availability...

This is not what I called HA or horizontal scaling. Have a look at what MongoDB or Cassandra do.

You're technically correct, but this case study was really eye-opening to me: http://blog.sagemath.com/2017/02/09/rethinkdb-vs-postgres.ht... They migrated from a RethinkDB cluster (similar to MongoDB) to a single Postgres server and the result was faster. And a single server is very large today, like 48 cores and 384 GB RAM.

And speaking of Postgres HA management, master promotion, etc. there are several tools like https://github.com/sorintlab/stolon available.

Re: MongoDB's Server Side Public License Is Likely Unenforceable

#173

Earlier quoted context omitted.

Performance is definitely an important aspect, but coming from a background working at smaller companies, bootstrapping time and development time are a factor as well -- and while Postgres is easy to set up if you're familiar with it (and I dare say it makes DB design fairly straightforward), Mongo and other NoSQLs are pretty objectively easier to just get working if you aren't fluent in relational databases.

No offense, but if you don't know how to design/develop a database schema, making it easier to shoot yourself in the foot by using NoSQL database is not the answer.

None taken. And I agree -- but database design is inherently different under SQL and non-/noSQL. Constraints and relationships may be modelled completely differently in either case.

Re: MongoDB's Server Side Public License Is Likely Unenforceable

#174

Earlier quoted context omitted.

I think you're slightly off there. The AGPL doesn't apply to software accessing the AGPL licenced software over a network, it applies to the AGPL software that's being accessed. As in it applies when the software is being accessed over the network rather than when it's being distributed (as with the GPL). This is actually mentioned in the article.

I think you have this correct, as I understand it. Just to explicitly state the differences: 1. You can modify GPL code as much as you want, and as long as you don't distribute the software, you do not need to make the modifications available. If you distribute the software, you are required to make your code available. 2. The AGPL extends the definition of distributing the software to making the software available o…

> The AGPL extends the definition of distributing the software to making the software available over the network

Doesn't this apply transitively? That is, I made MongoDB available over the network to my web tier (thus creating a derived work), and made my web tier available over the network to your browser (thus distributing it), thus, haven't I transitively made a derived work from MongoDB available?

I ask because this exact scenario seems to be what makes the company I work for so scared of AGPL. It's not necessarily cut and dry, but it's a scary enough possibility that we just ban it outright.

Re: MongoDB's Server Side Public License Is Likely Unenforceable

#175
post #113

Earlier quoted context omitted.

>MongoDB probably feels they have reached critical mass so it does not matter any more... They have become a new standard and they are aware of it. Just look at any bootcamps for devs this days , it’s basically always JS + MongoDB. Not Postgres or MySQL , Mongo. Mongo has become the new MySQL for a lot of devs these days. It’s often the only DBMS they know... These move is somewhat coherent with what others are doing…

> Just look at any bootcamps for devs this days , it’s basically always JS + MongoDB. Not Postgres or MySQL , Mongo. The online classes love Firebase. :-D But yeah, I had to explain to a bootcamp dev a few weeks ago what Postgres was. I felt rather sad.

I am a bootcamp dev (still in it) and I can confirm that its all node + mongo. I know what postgres is but obviously dont know anything about it technically. I am struggling to understand what this license change means for someone like myself who is building a web app with mongo...

Re: MongoDB's Server Side Public License Is Likely Unenforceable

#176

I don't understand the line of reasoning. Can anyone give me a lay explanation? My understanding of the license change is basically "if you use MongoDB to support any site, all software higher in the stack needs to be released as well". Is that accurate? If so, why can't an author make this part of the license?

That's not correct, the license only says if you make SSPL licensed software itself available as a service, you have to release the service code under the SSPL. Using the licensed software to build anything else at all is ok to do without releasing your code.

The problem is that we don't know how Mongo will choose to exercise this brand new license, and how courts will rule on them. I've brought this change to our corporate counsel and they are advising we stay clear of it.

Re: MongoDB's Server Side Public License Is Likely Unenforceable

#177
post #154

Earlier quoted context omitted.

Unless you're operating at Google/FB/Twitter/etc scale, this is not a problem most of us face IRL. We need to stop pretending we have these problems at 99% of the places we work at. Most of us don't. We don't need 1,000 microservices, Kubernetes, Docker, and a terribly unreliable NoSQL database like MongoDb (there are better, more optimal solutions for those companies than MongoDb (Cassandra being one of them.))

The fact that someone has to manually promote a slave as master is a big operational cost. The people that actually use PG at scale have to write a lot of tools / plumbing to overcome those issues, the same "issues" that were solved by most NoSQL solution, horizontal scaling, HA, shards re-balancing ect ...

> The fact that someone has to manually promote a slave as master is a big operational cost.

It doesn't need to be manual, only in a layer above/outside PostgreSQL. There are solutions that automate leader elections for any secondary-promotable-to-primary system (not just PostgreSQL), just not built into PostgreSQL.

We looked for about two years, on and off, to setup smoother, less-manual HA for our PostgreSQL setup. We ended up writing some, as you say, "tools / plumbing to overcome those issues". By far, though, the most time we spent on it was been spent in reading, testing, and getting to understand how things work.

After everything, unfortunately, no other system fit our requirements. Many came close in their marketing copy, but on closer look, every system had caveats. Ultimately, PostgreSQL is the only system I could still trust to do the right thing. In fact, the solid foundation that Postgres provides is why I can trust third-party layers (similar to Stolon and Patron) to focus on the job of switchover correctly without losing or otherwise messing with my data. In fact, I can even switch which tool I use, without it affecting my data.

The little plumbing we've written over Pg's built-in replication allows us to horizontally scale using logical replication and assuredly have HA using physical replication. At the end of the day, any shop that does anything important with data at scale needs to know how their data is actually being treated, irrespective of what the marketing promises. Hell, even when the data-store does not blatantly lie to you about keeping your data safe or uncorrupted, you can lose data due to bad use of tooling or explicitly-set unsafe configuration. "I'll just use this; it'll solve all my problems!" is rarely a thing to blindly believe when dealing with important data.

Re: MongoDB's Server Side Public License Is Likely Unenforceable

#178

Earlier quoted context omitted.

MongoDB made some very sketchy, undocumented (or poorly documented) technical decisions in its early years that placed data at great risk. It's better now, but very few things worry technical people more than a database that loses data. It's hard to get past that early impression.

Then again, so did MySQL. Do you remember the MySQL 3.x "MyISAM" days? No transactions, automatic truncation and type conversions, etc...

MySQL still has some unsafe behaviours. Even if it were to fix them all, I still wouldn't use it or recommend it, on account of finding it difficult-to-impossible to trust the design and engineering behind it.

Re: MongoDB's Server Side Public License Is Likely Unenforceable

#179

Yeah, I'm not necessarily opposed to the general spirit of what they're trying to do here, but this license just doesn't make sense in practice. Now that I've had more time to look at it, I'd really recommend that everybody stay the f%!# away from MongoDB. This bit in particular really hits the nail on the head: Let's assume that it is ok somehow to pass forward other open source software, solving that problem. What…

After spending some time reviewing this licencse the only conclusion I come to is that this license is malicious...let me explain

Let say you are a young startup building a cool SaaS solution. E.g. A data analytics solution. If you make heavy use of MongoDB it is very possible that down the line the good folks at MongoDB come calling since "the value of your SaaS derives primarily from MongoDB..." So at that point you have two options - buy a license from MongoDB or open source your work (which they can conveniently leverage at no cost).

Either way if you are SaaS solution doing anything data related I would not use MongoDB having read this license.

Re: MongoDB's Server Side Public License Is Likely Unenforceable

#180

Yeah, I'm not necessarily opposed to the general spirit of what they're trying to do here, but this license just doesn't make sense in practice. Now that I've had more time to look at it, I'd really recommend that everybody stay the f%!# away from MongoDB. This bit in particular really hits the nail on the head: Let's assume that it is ok somehow to pass forward other open source software, solving that problem. What…

After spending some time reviewing this licencse the only conclusion I come to is that this license is malicious...let me explain Let say you are a young startup building a cool SaaS solution. E.g. A data analytics solution. If you make heavy use of MongoDB it is very possible that down the line the good folks at MongoDB come calling since "the value of your SaaS derives primarily from MongoDB..." So at that point yo…

the value of your SaaS derives primarily from MongoDB

If that were true they could switch to Postgres and become 200x as valuable overnight.

Post reply on HN