4 ms·

This feels restrictive, especially in comparison to Postgresql. Where you have projects like CockroachDB which utilize the Postgresql wire protocol because of h

This feels restrictive, especially in comparison to Postgresql. Where you have projects like CockroachDB which utilize the Postgresql wire protocol because of how well documented it is.

toomuchtodo 5y ago
PostgreSQL is organized as a non profit [1], Mongo is a for profit enterprise attempting to stem cloud providers from providing a wire protocol compatible service without compensating them for their work [2]. [1] https://www.postgresql.org/about/donate/ https://www.postgresql.org/about/donate/ ("PostgreSQL is an affiliated project of Software in the Public Interest. Funds donated to PostgreSQL are used to sponsor general PostgreSQL efforts. These funds are managed by the Fund raising group.") [2] https://www.computerweekly.com/news/252455700/AWS-pushes-Mongo-DB-compatible-alternative-as-licences-change https://www.computerweekly.com/news/252455700/AWS-pushes-Mon... ("AWS pushes MongoDB compatible alternative as licences change")
- Spivak 5y ago
  If the courts enforce this then this is basically death to adversarial interoperability.
tyingq 5y ago
I assume that's the idea, to try and stop AWS from keeping their "Aurora Like" version of Mongo updated. See https://aws.amazon.com/documentdb/ https://aws.amazon.com/documentdb/
jrockway 5y ago
I think if you know your product is good, you're not too worried about someone developing a drop-in replacement for it. The opposite is also true.
- Yoric 5y ago
  It is my understanding that AWS very nearly killed ElasticSearch. If I were [working at] MongoDB, I wouldn't want that to happen to my product, either.
  - jrockway 5y ago
    I'm perfectly OK with the "you can't run this code as a service" licenses, but when you get to restricting the spec about the wire format, I think other factors are at play. Like, if Amazon wants to spend millions of dollars writing their own version of MongoDB that is drop-in compatible for existing MongoDB applications, that is great for customers. You, the customer, now have two choice -- options when things don't work out with one implementation. When you use license agreements to restrict that ability, I think it's a statement about the quality of your product -- you think Amazon can do it better than you, so you're going to use the legal system to prevent them from trying. As a database user, that is a signal for me to stay away. It means that when I'm having a scaling emergency there is only one way to fix it -- give most of my revenue to one company. That's scary. Yes, Amazon did almost kill Elasticsearch. I sometimes wonder if the set of circumstances translates 1:1 to other companies. The products have similar names -- AWS has the Elastic Compute Cloud, and then there's this Elastic Search. That's not their product? Nope, just an unfortunate naming choice. And, Elasticsearch was particularly difficult to run at the time, so a hosted option was clearly valuable. And finally, Elasticsearch had a lot of company-killing problems: basically not doing what it said it did. https://aphyr.com/posts/317-call-me-maybe-elasticsearch https://aphyr.com/posts/317-call-me-maybe-elasticsearch At the time, Elasticsearch was losing acknowledged writes. That's a company killer if your only product is a database.
hodgesrm 5y ago
It's useful to compare MongoDB's text with another vendor known for restrictive licensing, namely Oracle. Here's the legalese on the MySQL internals documentation. It has restrictions on dissemination but not actual use. https://dev.mysql.com/doc/internals/en/preface.html https://dev.mysql.com/doc/internals/en/preface.html It does not restrict you from building applications that derive knowledge from MySQL internals documentation.

This feels restrictive, especially in comparison to Postgresql. Where you have projects like CockroachDB which utilize the Postgresql wire protocol because of how well documented it is.

toomuchtodo 5y ago

PostgreSQL is organized as a non profit [1], Mongo is a for profit enterprise attempting to stem cloud providers from providing a wire protocol compatible service without compensating them for their work [2]. [1] https://www.postgresql.org/about/donate/ https://www.postgresql.org/about/donate/ ("PostgreSQL is an affiliated project of Software in the Public Interest. Funds donated to PostgreSQL are used to sponsor general PostgreSQL efforts. These funds are managed by the Fund raising group.") [2] https://www.computerweekly.com/news/252455700/AWS-pushes-Mongo-DB-compatible-alternative-as-licences-change https://www.computerweekly.com/news/252455700/AWS-pushes-Mon... ("AWS pushes MongoDB compatible alternative as licences change")

Spivak 5y ago
If the courts enforce this then this is basically death to adversarial interoperability.

tyingq 5y ago

I assume that's the idea, to try and stop AWS from keeping their "Aurora Like" version of Mongo updated. See https://aws.amazon.com/documentdb/ https://aws.amazon.com/documentdb/

jrockway 5y ago

I think if you know your product is good, you're not too worried about someone developing a drop-in replacement for it. The opposite is also true.

Yoric 5y ago
It is my understanding that AWS very nearly killed ElasticSearch. If I were [working at] MongoDB, I wouldn't want that to happen to my product, either.
- jrockway 5y ago
  I'm perfectly OK with the "you can't run this code as a service" licenses, but when you get to restricting the spec about the wire format, I think other factors are at play. Like, if Amazon wants to spend millions of dollars writing their own version of MongoDB that is drop-in compatible for existing MongoDB applications, that is great for customers. You, the customer, now have two choice -- options when things don't work out with one implementation. When you use license agreements to restrict that ability, I think it's a statement about the quality of your product -- you think Amazon can do it better than you, so you're going to use the legal system to prevent them from trying. As a database user, that is a signal for me to stay away. It means that when I'm having a scaling emergency there is only one way to fix it -- give most of my revenue to one company. That's scary. Yes, Amazon did almost kill Elasticsearch. I sometimes wonder if the set of circumstances translates 1:1 to other companies. The products have similar names -- AWS has the Elastic Compute Cloud, and then there's this Elastic Search. That's not their product? Nope, just an unfortunate naming choice. And, Elasticsearch was particularly difficult to run at the time, so a hosted option was clearly valuable. And finally, Elasticsearch had a lot of company-killing problems: basically not doing what it said it did. https://aphyr.com/posts/317-call-me-maybe-elasticsearch https://aphyr.com/posts/317-call-me-maybe-elasticsearch At the time, Elasticsearch was losing acknowledged writes. That's a company killer if your only product is a database.

hodgesrm 5y ago

It's useful to compare MongoDB's text with another vendor known for restrictive licensing, namely Oracle. Here's the legalese on the MySQL internals documentation. It has restrictions on dissemination but not actual use. https://dev.mysql.com/doc/internals/en/preface.html https://dev.mysql.com/doc/internals/en/preface.html It does not restrict you from building applications that derive knowledge from MySQL internals documentation.