Hacker News Reader

Comment by 015a | Hacker News Reader

Users don't generally care that the source is available for the purposes of reading it, or even modifying it. They care that the source is available because its a signal of their freedom to use the software how they wish; whether that's hosting with Elastic, hosting with AWS, or hosting it themselves.

Any license which restricts a user's ability to use the software how they wish is no open source license. And the OSI has so far supported this; the SSPL is not an OSI approved license, despite being submitted for approval by MongoDB then retracted a year later.

View on HN

> Any license which restricts a user's ability to use the software how they wish is no open source license

That's the thing though. The only thing (from my naive understanding) that SSPL limits is a business (Like Amazon) from offering Elasticsearch as a service. If an organization (Like Amazon) wanted to use Elasticsearch internally (to say, power some part of their shopping platform), they are free to do so with this license.

It's essentially protecting Elastic's business model, which quite honestly, should be the bare minimum offered by any open source product.

There's nothing wrong with using a licensing model like the one you describe. If don't want Amazon to use your software, then license it as such, whatever. However, that software is not open source.

Furthermore, if you change a project which is open source, to a licensing model which is not, it's a dick move.

It's not important if the needs of the business are "reasonable", we could argue about that but it's beside the point. Open source has no relationship with the requirements of your business. It has a specific meaning, and if you betray those principles, you betray the people who trusted you on those terms.

There are plenty closed-source (or rather not-open-source) source-available licenses and software.

https://www.wikiwand.com/en/Source-available_software

> Any license which restricts a user's ability to use the software how they wish is no open source license.

Then is AGPL not open source? It has requirments/restrictions on modified privative usage/distribution.

AGPL does not restrict how you use the software, rather, it requires that you offer the same freedoms to your users as the original license offered to you. You can sell AGPL'd software.

> AGPL does not restrict how you use the software, rather, it requires that you offer the same freedoms to your users as the original license offered to you. You can sell AGPL'd software.

But doesn't SSPL allow you to offer ElasticSearch-as-a-Service as long as you contribute the source code that makes it work? Many have commented on how that requirement is a no-go for AWS however they are not a priori forbidden by the license from doing so.

Elastic explicitly addresses the question of open source in their FAQ:

https://www.elastic.co/pricing/faq/licensing#does-this-mean-...

Mongo has tried to get the OSI to approve it, but ultimately withdraw the license. The precise semantics of how much or how little the license diverges from the requirements of open source is an interesting topic for another time. For one, no other license, copyleft or otherwise, extends your obligations to software which is not actually a derivative work, which if nothing else requires a novel interpretation of the OSD. For now, though, I'd rather focus on the conclusion: this license does not qualify as open source, and that betrays those who choose to use or contribute to Elastic on the basis of its open source nature. They didn't get on board with the project in order to see how a dubious new license would hold up under scrutiny. This change was made for dubiously-justified commercial reasons on the false presumption that Elastic has the sole right to exploit Elasticsearch (and Kibana) for profit, software that they have shared ownership over (including in terms of copyright) with the broader community. They were allowed to do this, by the letter of the law, but it is fucked up regardless.

> For one, no other license, copyleft or otherwise, extends your obligations to software which is not actually a derivative work, which if nothing else requires a novel interpretation of the OSD.

Copyfarleft[1] has been discussed for almost a decade now and has spinoffs like Copyfair[2].

> The precise semantics of how much or how little the license diverges from the requirements of open source is an interesting topic for another time.

There is definitely a gray area there but the comment I originally replied to naively equated open source with the more permissive licenses.

> They were allowed to do this, by the letter of the law, but it is fucked up regardless.

I am not convinced that "it is fucked up".

[1]: http://wiki.p2pfoundation.net/Copyfarleft

[2]: http://wiki.p2pfoundation.net/Copyfair

>Copyfarleft[1] has been discussed for almost a decade now and has spinoffs like Copyfair[2].

But not in the context of open source. At no point have any of these licenses made a successful bid for qualification under the OSD.

The only criticism I would levy is that those licenses haven't been polished by time nor copyright-license-experienced lawyers.

Their recognition from FSF/OSI is not their goal and and argumnt can be made that copyfarleft / copyfair pushes the boundaries of open/free/libre source software so they might not pursue recognition from the get go.

I don't think that these licenses are relevant. If we can agree that they are not open source, then we can agree to the point I'm trying to make: changing from an open-source to a non-open-source license is a significant change which, when done without the consent of the community, is wrong.

I don't agree that they are not open source, I only agreed that it is a gray area and even on the previous comment mentioned that it is "pushing the boundaries". For eg, I maintain an "awesome-copyfarleft" list: https://github.com/LibreCybernetics/awesome-copyfarleft

> changing from an open-source to a non-open-source license is a significant change which, when done without the consent of the community, is wrong.

I don't think consensus is possible and even a 2/3 supermajority on a license change seems out of reach. I can imagine some are pushing for permissive licenses like MIT/BSD, others for GPL/AGPL, others to remain as Apache 2.0, etc.

>I don't agree that they are not open source

Sorry, you are simply wrong on this matter. It's not a subjective issue, it s a statement of fact that these licenses are not open source. There was a recent attempt to change this within the OSI, which badly failed.

>I don't think consensus is possible and even a 2/3 supermajority on a license change seems out of reach. I can imagine some are pushing for permissive licenses like MIT/BSD, others for GPL/AGPL, others to remain as Apache 2.0, etc.

Correct. That doesn't mean that they can choose to change the license anyway. That means that changing the license is not right in the first place.

> That doesn't mean that they can choose to change the license anyway.

Under Apache 2.0 and as they did retaining the contributions as Apache 2.0 they can though. As far as I have seen there havent been any legal challenges to the licensing change on this comment section.

> That means that changing the license is not right in the first place.

This is a non sequitur though, the premise that precedes it (that "they can't change the license (legally or under the terms of Apache 2.0)") is false.

> That doesn't mean that they can choose to change the license anyway.

I have already repeatedly stated that they were within their legal rights, including in one of my replies to you. I assumed this was a given. When I said they "can't", I did not mean "can't (legally do this)", but "can't (do this in good concience)."

Do you have anything else to add?

Not forbidden, but SSPL goes beyond AGPL in a key way by defining the source that must be released as wider, including any code necessary to offer the covered code as a service, such as user interfaces, backup mechanisms, provisioning etc. That might indeed be more than AWS is willing to do

Its also worth saying, at least in Mongo's case, AWS's managed offering (DocumentDB) is not, in any way except the API, MongoDB. Internally its based on Aurora. But, by my understanding, the SSPL also covers MongoDB's API, so this is why DocumentDB has not attained anything higher than 3.6 compatibility (and even its 3.6 compatibility is ish, but that's not for legal reasons by my understanding).

Amazon definitely doesn't want to open source Aurora. Not only is it a massive moat for their cloud, its an extremely powerful database, but there's enough evidence to conclude that its so internal-AWS-reliant that it would be almost useless to anyone not running on AWS.

And by the other hand it is more lax on what must be open source in case of non-ElasticSearch-as-aService usage.

So from my PoV it is overall more lax than AGPL. (Definitely more lax for non ElasticSearch-as-a-Service providers)

It does, in theory.

But in practice, there are zero options for managed hosting of MongoDB 4.0+ outside of Atlas that I'm aware of (and we looked, everywhere). By my understanding, from speaking with some sales/product engineers at third-party companies which previously hosted MongoDB or currently host 3.6, the terms of the SSPL are so vague that its effectively a card that reads "you can host MongoDB, but if you become a threat to Mongo's business, we'll find a reason to sue you, and we'll win". So, no one does managed hosting anymore, or they're still on 3.6 with no intention of upgrading.

Its possible that, if a hosting provider were to try and meet the terms of the SSPL, and succeed in doing that, and get some kind of validation of that success from Mongo or Elastic, then some form of precedent could be reached and that would increase confidence in the SSPL being defensible from a vendor standpoint. But, that never happened with Mongo. Maybe it'll happen with ES, given ES is far more popular.

Another possibility is that those managed hosting providers could obtain another license for Mongo. (Dual licensing between (A)GPL and a commercial license does happen, for example with Qt framework)

Reply on news.ycombinator.com