211–220 of 378 posts
What does it mean for Elasticsearch Service on AWS?
AWS doesn't offer any version with new licenses.
Then they fork the project, and none of the improvements AWS makes to the fork gets pushed upstream to ES. Which only hurts Elasticsearch as a project.
ES can take their ball and go home. But they're doing so to their own detriment.
Earlier quoted context omitted.
Some observations: (1) It's interesting how much of the reasoning/argumentation for these restrictive licenses ultimately comes down to a more articulate form of "but that's not fair!". I also wonder how much the implicit beliefs that "unrestrained capitalism is a bad thing", "markets naturally lead towards monopolies", "antitrust law is legitimately necessary", etc are impacting peoples' reasoning here. (2) If they…
> 2) If they can't actually compete and provide superior value to whatever managed offering Amazon can scrounge together, that's actually their fault. The sad-funny thing is that elastics hosted cloud offering is clearly superior to AWS’ hosted elasticsearch in pretty much all regards.
If I'm spending $100k/mo on my logging stack, and it's falling over frequently (which in AWS-land means multiple days of back and forth, opening tickets etc), I'd way rather pay $120k/mo for something that actually works.
Earlier quoted context omitted.
Or they could, you know, just respect the new license and publish their changes and part of their "secret sauce". I bet it would be anyway tightly coupled to other AWS internal services so nobody would get hurt in the process. Edit: fixed typo
what layers would they have to show? All of them up to bare metal? This is madness, should you be able to show your UEFI firmware? Should the server's out-of-band-mangement firmware be available as well? The license is plain vague.
And it's ES that's forcing AWS to do this.
> This change in source code licensing has no impact on the overwhelming majority of our user community How come? If you switch open source to proprietary software (as much source-available as it may be), there's a significant impact: a % of users won't use proprietary software; those who may will not find this software packaged on package managers; derivatives and companion projects may stop being developed. Where's…
I assume if you run ES in your own datacenter or you use SaaS, you will be fine! I guess they target AWS but not AWS users...
If there's a policy for open source-only usage, you will definitely be affected.
If there will be a diminished number of contributors (which won't like to contribute if it is not open source) and ecosystem (that will stop developing/growing being a proprietary project), you will be affected too.
And you're not AWS in either them.
Here's the actual change: > Starting with the upcoming Elastic 7.11 release, we will be moving the Apache 2.0-licensed code of Elasticsearch and Kibana to be dual licensed under SSPL and the Elastic License, giving users the choice of which license to apply. So starting with 7.11 no parts of Elasticsearch will be released under an open source license. They aren't making everything SSPL, though. Their paid features co…
SSPL is based on the GNU AFFERO GENERAL PUBLIC LICENSE https://webassets.mongodb.com/_com_assets/legal/SSPL-compare... So apart from adding the cloud non-compete clause (don't offer Elastic as a Service) there are many more restrictions added compared to Apache 2. For example I think linking can only happen with GPL3 code and it is copylefted instead of permissive https://en.wikipedia.org/wiki/Comparison_of_free_and_…
Both permissive and copyleft licenses play important roles in the Open Source ecosystem. Different story are proprietary licenses.
I wonder how many people contributed to Elastic which do not work for Elastic.co ? Those folks have reasonably counted on having fruits of their labor to be available under Apache 2.0 and now they only get to use them with SSPL restrictions
I raised precisely this concern a week ago: https://news.ycombinator.com/item?id=25631073 my intention there was (and still is) to learn how other HNers think of this. In there I got the response about how the precise version to which people contributed, was and will always be Open Source, regardless of what happens to future derivations of that code. I'm not sure I bought that reasoning, though... you put it better…
Well, you can argue the spirit all day, but in practice, permissive licenses mean what they mean. Once a version is released with that license it stays that way, but subsequent versions can have a new license.
Basically, you do keep the fruits of your labor - you get Elasticsearch 7.10 and all previous versions. But you have no right to Elasticsearch 7.11.
Note: In practice I agree it's a dick move to go to a more restrictive license, and I strongly disagree with Elastic's decision to do so. It's just a greedy move that won't even make them more money in the long run because it will cripple the momentum ES has.
Earlier quoted context omitted.
AFAIRemember, RedHat dropped MongoDB because of "controversial SSPL" > So essentially, anyone is free to modify MongoDB. It’s only when you offer MongoDB as a commercial service that the conditions of the SSPL state that you must open source the entire service. https://hub.packtpub.com/mongodb-withdraws-controversial-ser... Is this a difference like GPLv2 and GPLv3? Does this means that AWS now must open internal ser…
more like the difference between GPL and Affero GPL. https://en.wikipedia.org/wiki/Affero_General_Public_License
Earlier quoted context omitted.
Elastic contributes massively to Lucene, so this is a false dichotomy
And guess what, when a corporation uses Elasticsearch in a serious way they will inevitably end up contributing back. It's actually easier to just get a change merged upstream rather than to manage a whole fork, unless the upstream is really hard to get patches merged with. The whole narrative of "company X is offering Elasticsearch as a service and not contributing back!" is ridiculous. First of all, the whole point…
The thing is "really hard to get patches merged" is a fuzzy barrier. There are many, many example of what most would consider reasonably maintainers where companies just don't contribute back. Even in breach of GPL.
Earlier quoted context omitted.
I wish it would be explained that way
It can be, they just chose not to (with ulterior motives or not, I cannot say.) For my side project, I am using a dual-licensed MIT/Apache (your choice) but with an exclusion which prohibits companies like AWS from offering it alone as a service. Here's a copy of the (quite human-readable) license: https://gist.github.com/slimsag/2164520b9e249fbae4e08e2bdf6e...
Earlier quoted context omitted.
AFAIRemember, RedHat dropped MongoDB because of "controversial SSPL" > So essentially, anyone is free to modify MongoDB. It’s only when you offer MongoDB as a commercial service that the conditions of the SSPL state that you must open source the entire service. https://hub.packtpub.com/mongodb-withdraws-controversial-ser... Is this a difference like GPLv2 and GPLv3? Does this means that AWS now must open internal ser…
AWS wouldn't, I presume, touch the 7.11 dual-licensed Elasticsearch release with a ten-foot pole. They would have to hard-fork it here on, or Gold+ partner with Elastic.co to sell Elasticsearch Service under the relatively more permissive Elastic License .