Live data from Hacker News

Licensing changes to Elasticsearch and Kibana

elastic.co

181–190 of 378 posts

Re: Licensing changes to Elasticsearch and Kibana

#181

Earlier quoted context omitted.

Yes, it is not. But who cares? What I care about as a user is repairability: * can I inspect source and build it myself? * can I fix it? * can I share modifications with others? Many of the new "cloud protection licenses" offer this, yet they are (by definition) not opensource.

I think this is the right way to look at things, after all, these were the orignal "why" arguments in favour of open source. If we can get the same benefits while also protecting open products from megacorps like AWS, that's a better licence than a true open source licence

> If we can get the same benefits while also protecting open products from megacorps like AWS, that's a better licence than a true open source licence

That's your opinion, of course. IMO, there's a type of magic that happens when software is under a truly non-restrictive license. You get a level of quality and reliability in the software that is unmatched by what you get with any proprietary equivalent.

Unfortunately, most people don't really believe in FOSS. And that's okay. But boy am I getting frustrated with these companies that are happy to preach about how "open source" is amazing, until someone else is making some profit with their software and then suddenly the (extremely vague) restrictive licenses start rolling out.

Re: Licensing changes to Elasticsearch and Kibana

#183
post #27

Earlier quoted context omitted.

Elasticsearch couldn't exist without the open source Lucene project which is at its core. Lucene is licensed under the permissive Apache license which is why Elastic is able to release proprietary paid modules that link with it. Now they are closing the same holes that they themselves used to create their product. Contributing back is definitely the last thing on their minds.

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 of free software is that somebody somewhere is going to be making money with that software, and that's okay, regardless of contribution. Second of all, in practice companies like Elastic will always exaggerate the extent to which corporations aren't "contributing back".

What they really mean is Amazon isn't contributing financially to Elastic Co. That's what they're pissed about, and that's why they clearly wish they were actually in the business of proprietary software (which they now are)

Re: Licensing changes to Elasticsearch and Kibana

#184
post #64

In my mind, this strongly constrasts with the words [0] of WordPress founder Matt Mullenweg. He says they want to own roughly 5% of the WordPress market, and instead of growing their share of the pie, grow the pie itself. [0] https://fs.blog/knowledge-project/matt-mullenweg/

That's great for Matt, but other companies like Elastic can't afford to go from >50% to 5% of their market.

Re: Licensing changes to Elasticsearch and Kibana

#185

The way I understand it, AWS has been creating derivative products that don't work very well based on ELK. AWS has also not been contributing back to the community anything, while raking in the millions for https://aws.amazon.com/elasticsearch-service/the-elk-stack/ Many elastic pros recommend not using the AWS version because it doesn't operate properly. While I am pro OSS I can understand why a company based on OSS…

Disclosure: I work for AWS, but I do not work directly on Elasticsearch related services.

Elasticsearch is/was an "upstream" for Open Distro for Elasticsearch (which is a distribution / collection of software). As an "upstream", changes to the core Apache 2.0 licensed software was sent as pull requests to Elastic, which are usually merged. It isn't correct to say that AWS has not been contributing to the upstream Elasticsearch code under an Apache 2.0 license (and, also, signing the CLA to boot, which allows Elastic to relicense AWS contributions under SSPL).

Here's a sample of PRs from AWS developers that I could find:

https://github.com/elastic/elasticsearch/pull/61400 https://github.com/elastic/elasticsearch/pull/59563 https://github.com/elastic/elasticsearch/pull/57271 https://github.com/elastic/elasticsearch/pull/53643

Re: Licensing changes to Elasticsearch and Kibana

#186
post #68
post #61

Luckily there are faster and smaller alternatives in Rust for the ElasticSearch - Toshi[1], Meili[2] and Sonic[3]. In the age of Rust there is no need to use JVMs overhead. [1] https://github.com/toshi-search/Toshi [2] https://github.com/meilisearch/MeiliSearch [3] https://github.com/valeriansaliou/sonic

Adding Typesense to the list as an easier-to-use alternative to ElasticSearch: https://github.com/typesense/typesense One thing to point out though is that Typesense, MeiliSearch (and Algolia) are designed for Instant Search experiences, and so hold the entire index in memory. So for petabyte scale data (like logs) it might be wasteful (and expensive) to store that size of data in memory. This is where ElasticSearch…

Do you really have to spam your project on every thread even remotely related?

Re: Licensing changes to Elasticsearch and Kibana

#187
post #162

This is an alarmist headline. The SSPL license to which they are switching only requires your code to be open sourced if you are providing Elasticsearch itself as a service. This change is directed at cloud providers who take open source software and then provide them as a service for payment without contributing to the project. If you are using Elasticsearch on your backend to build search-enabled products or websit…

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.

Re: Licensing changes to Elasticsearch and Kibana

#188

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

> 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

While i hate the change, that isn't true. They have access to their changes in the current and older versions of Elastic. You can lock yourself to the current version forever and create your own bug fixes.

Re: Licensing changes to Elasticsearch and Kibana

#189

Earlier quoted context omitted.

You are being too cynical. Their argument is, more charitably: "We built this, we released it for free. Our business model is professional support and hosted services. In order for us, the creators of this software, to continue building it, we cannot allow megacorporations to freely spin up a loss-leading competitive service and cut us out."

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.

Post reply on HN