Hacker News Reader

Comment by Thaxll | Hacker News Reader

"However, as time passed, MongoDB abandoned its open-source roots; changing the license to SSPL - making it unusable for many open source and early-stage commercial projects."

This is not true, you can use MongoDB for commercial projects as long as you don't sell MongoDB services, but internally you're free to use it as your regular DB.

https://www.mongodb.com/licensing/server-side-public-license...

View on HN

I was talking to the VP of Engineering at a company that got acquired by [top 10 VC/PE firm].

Apparently the firm put the company through the wringer (and more than likely bumped down their valuation during the transaction) over MongoDB’s licensing.

I have a feeling in this specific case, [top ten firm] probably found some technicality in MongoDB’s licensing that allowed them to use as negotiating leverage to bump the price down during the transaction.

Licensing is important. You especially don’t want ambiguous licenses that give lawyers wiggle room to make absurd nonsensical arguments, which unfortunately is very common even with reputable investors and firms.

Edit: Removed name of firm for legal reasons. Email me if you want specifics. bp@brandonpaton.com

In case anybody wonders, the firm in question was a16z.

It actually isn’t, but it’s a firm with similar name recognition.

Sequoia?

The SSPL is a murky license of questionable validity. The SSPL text itself is an unlicensed plagiarism of the AGPL [1]. The abuse of copyright law[2] that the SSPL explicitly demands might make it neither a valid license nor a valid contract [3]. What happens when the license covering your use of certain software turns out to be invalid? Well, in the eyes of the law, its as if you never had a license in the first place.

That's a lot of legal risk for your commercial project.

1: https://lists.opensource.org/pipermail/license-review_lists....

2: https://lists.opensource.org/pipermail/license-review_lists....

3: https://www.processmechanics.com/2018/10/18/the-server-side-...

Copyright misuse, as per one of your links, is a defense to an infringement claim that is recognized under certain conditions in part but not all of the US - it does not invalidate the license, it invalidates the licensor’s lawsuit.

But yes, it’s still a mess of a license that creates a lot of legal uncertainty for potential licensees, especially if a particular court decides that the copyright misuse defense doesn’t apply but that unclean hands does apply to the licensee for taking a license without intent to comply (e.g. because of having already concluded that compliance was impracticable or impossible).

Definitely best to avoid the SSPL and software licensed under it.

It's a little more complicated than than just having to refrain from selling MongoDB services. There is a good page which summarizes the problem with SSPL. [1] SSPL is crafted in a way that it very hard to tell whether you comply with the license or not, especially if you run it as part of a cloud hosted solution.

[1]: www.ssplisbad.com

This page is pretty wrong on a whole lot of points, and doesn't even go into enough detail on any of its claims to comprehend how it got there.

They seem to present a reasonable well thought out argument. I'd be interested in hearing a counter more nuanced than "nuh uh."

I mean, that's fundamentally what the website did. Claims without evidence can be dismissed without evidence. However, without any justification for the belief the author apparently has, the author asserts you cannot even expose MongoDB's API as part of your own application within the terms of SSPL, and that is neither in the letter nor spirit of the license terms, which solely relates to selling the software in question (MongoDB here) as a service offering principally as itself.

The author, of course, relies on the claimed vagueness of the license as an excuse to take every claim to the most ridiculous extent possible, even though no reasonable person would believe anything claimed here, such as the suggestion that it might entail you release the source code for your computer's BIOS.

In a section with truly atrocious spelling and grammar, the author asserts that somehow this kills real competitors (even though real competitors would presumably have their own actual product offering, not just re-ship a product offered by the SSPL software developer at a predatory pricing rate only made possible through monopolist behavior). They then make the ridiculous claim that this entirely removes the ability for the customer to choose their cloud provider. Meanwhile, in the land of reality, between either forks or licensing agreements, there is plenty of competition, but the developers have an opportunity to sustain development instead of all of the profit being skimmed off by Amazon, who contributes nothing back and does none of the work. Having to raise their prices above the original developers' due to license fees, of course, doesn't even remove the value add for choosing AWS, where the benefits are bringing it into the same datacenter and platform as the rest of your other cloud needs.

The author then tries to villainize software companies using SSPL by pointing out how many thousands of employees and how many millions in revenue they have, without acknowledging that the sole benefactor of making SSPL look bad is Amazon, which brings in hundreds of billions of dollars of revenue and has over 1.5 million employees.

This train wreck is then finished up with their suggestions that these companies should just remain unsustainable and rely entirely on business models for open source we all know don't work very well.

I would say the author is arguably wasting their $10 a year domain registration on this garbage article, but considering the lack of public attribution present, I assume Amazon's paying for it.

> Claims without evidence can be dismissed without evidence.

> considering the lack of public attribution present, I assume Amazon's paying for it.

Well, that was a wild ride.

Hah. I will grant you that one. :D

Though I am absolutely fine with you dismissing my parting shot on those grounds indeed.

That condition is not in the spirit or commonly accepted definition of open source.

“Open source” tends to be a spectrum.

For example, many consider GPL to be a great OSS license, but it’s restrictive enough that some BSD projects try to avoid it.

It tends to be a spectrum, but the various, sometimes very different licenses adopted by the OSI still have something in common - the open source values laid out in the Open Source Definition. [1] SSPL did not comply with this requirement, as it discriminate against specific users or use cases. I think it is in the interest of everyone to draw the line somewhere.

[1]: https://opensource.org/osd/

Open source licenses might be a spectrum but it's likely that the legal reality isn't. Like the famous double split experiment there's probably no spectrum and only a couple of buckets of legal validity.

As far as the buckets go, I still believe there is a pretty large spectrum.

BSD vs GPL vs LGPL are pretty dramatically different, and there are many in-between that might satisfy the definition of “open-source” at face value.

BSD would not be OSS by this definition, as it has no clause against discrimination of people.

OSS is IMO a very subjective term. There is a massive gray area surrounding open-sourcing derivative works, etc. and other stipulations.

Why not?

I will never understand why Mongo and Elastic get so much hate when all the did was to try to protect themselves from AWS parasites.

I guess having yourself exploited and ultimately destroyed by monopolist overlords is the moral choice or something? Or do boots just taste good?

I am not sure if any hate is warranted, but it is true that coming up with a new license which does not comply with open source licenses, and proceeding to call it open source definitely did not help to create sympathy. There is nothing wrong with releasing something under a proprietary license but calling this license change "Doubling down on open source" is damaging.

https://logz.io/blog/open-source-elasticsearch-doubling-down...

We would never touch that though. The lawyers don’t really grok the beginning and the end of the limitations. We can pick up mit, Apache, mpl, bsd and in some cases gpl (inc v3). Probably some more but agpl and such are off limits even though we will never actually sell it as a service as such.

The keyword here is "Internally" however if you want to "embedd" MongoDB in your Open Source Product then resulting Bundle will not be Open Source as SSPL is not Open Souce license

Reply on news.ycombinator.com