Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Licensing changes to Elasticsearch and Kibana

elastic.co

Post reply on HN
Print view View original

251–260 of 378 posts

Re: Licensing changes to Elasticsearch and Kibana

#251

Post by whateveracct »

postalrat wrote: post #106
xvilka wrote: 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

I didn't realize rust and the jvm solve the same problem.

Low-level programmers talking about "JVM overhead" betray their own lack of understanding.

Rust and C and manual memory management have overhead too.

Re: Licensing changes to Elasticsearch and Kibana

#252

Post by matthewmacleod »

isatty wrote: post #244
matthewmacleod wrote: post #134

Earlier quoted context omitted.

I highly doubt anybody chooses an explicitly free and open source license without intending to offer their software to users under the terms of that license.

I wouldn't be so sure about that. Thinking "is this software going to be resold by Amazon" is not high up on the priority list for someone who is just working on a hobby project/releasing that project under a permissive license. Sure, this is a non problem for 99.99+% of the population and it's a relatively new "problem", but it's fair to retroactively change the license because it's within their rights.

Important to note though that they are not retroactively changing anything. The license for old code was and remains Apache and can be used under those terms.

Elastic are of course entirely entitled to change the license to whatever they feel like, including closing the source entirely for future development. But they made the choice at an earlier stage to release the code under a permissive licence - that was a choice to allow others to do what they want with the software, not just “what you want so long as it doesn’t infringe on our business model”. They are free to change their mind on that, but it’s not like it’s an unexpected, unfair, or unpredictable outcome.

Re: Licensing changes to Elasticsearch and Kibana

#253

Post by mike_d »

veselin wrote: post #127
matthewmacleod wrote: post #116

Earlier quoted context omitted.

Of course, they should "encourage" Amazon not to steal their product and business model. Right. It is not possible to steal something from someone who deliberately and freely offers that thing to you.

I highly doubt elastic intended to offer it for free to the cloud providers from the start. They wanted to offer it for free to end users. This is why I expect new products will now start with these more restrictive licenses.

Everyone wants to open source their code until someone else makes a billion dollars of it. Everyone wants censorship resistant end to end encryption until terrorists use it. Everyone wants software patents to not exist until they get issued a really good one.

This is a classic case of trying to put the genie back in the bottle.

Re: Licensing changes to Elasticsearch and Kibana

#254

Post by ecnahc515 »

Aeolun wrote: post #230
jnwatson wrote: post #221

Earlier quoted context omitted.

The problem is that nobody buys AWS ElasticSearch because of quality. They buy it because they already have AWS approved as a vendor and a blank check to spend on it.

Yeah, so they’re not really competing with Elastic right? If I already have an AWS environment I’m never going to use an Elastic hosted service, since it’d be outside my VPC. I really don’t understand how that business model works.

If you have an AWS env, and they have no comparable alternative, you may be forced to look outside AWS, eg: to Elatic's SaaS offering. But in many cases, if AWS has a comparable offering, you simply don't bother looking outside.

It's similar to bundling tactic of Microsoft, and other big vendors. By bundling MS Teams with other things, no one has to "buy" Teams, they already get it for "free" (well, it's no extra cost beyond what they would be paying for Office or whatever already), so why "buy" Slack when you have a similar chat tool for "free".

Re: Licensing changes to Elasticsearch and Kibana

#255

Post by ecnahc515 »

mcintyre1994 wrote: post #202
__blockcipher__ wrote: post #176

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…

Wouldn’t getting logs from some AWS service into Elastic’s hosted service (or anything not in AWS) be really expensive at scale though?

I believe they have an option so you can peer your VPC to their hosted offering's VPC, so logs from within your VPC don't have the typical expensive AWS internet egress/ingress costs.

Re: Licensing changes to Elasticsearch and Kibana

#256

Post by sfifs »

matthewowen wrote: post #131
ignoramous wrote: post #98

Earlier quoted context omitted.

TFA explains why Elasticsearch switching to SSPL is indeed a cause for concern. Money quotes: > Basically, it’s a hostile proprietary license masquerading in open source clothing. By using an SSPL project in your code, you are agreeing that if you provide an online service using that code then you will release not only that code but also the code for every supporting piece of software, all under the SSPL. > It’s not…

How true is this, in practice? I hear software folks say this sort of thing somewhat frequently, but I haven't heard it from a _legal_ person. And my general sense and understanding is that although an FAQ style clarification is not _perfect_, it _does_ carry non-trivial weight. Judges are not totally capricious people making arbitrary decisions: the notion that in a dispute they would just cast aside one party's _cl…

> How true is this, in practice? I hear software folks say this sort of thing somewhat frequently, but I haven't heard it from a _legal_ person.

As a business person, I'd prefer to avoid the legal expense and risk to find out the hard way later on. Who knows who'll manage ElasticCo 5 years down the line and whether their motivation may be to milk their IP through litigation. Do you really want to be the guinea pig? The smart business move would be to either license explicitly OR stick to the Apache 2.0 version and plan a migration off ElasticSearch

Re: Licensing changes to Elasticsearch and Kibana

#257

Post by pabs3 »

Areading314 wrote: post #82

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…

Hmm, the Apache httpd folks didn't complain when web hosting services around the world started making money offering web hosting using it, without modifying it nor contributing back financially.

Re: Licensing changes to Elasticsearch and Kibana

#258

Post by ecnahc515 »

nopzor wrote: post #2

wow, this is super interesting, but i can't say i'm surprised by this move. the landscape has really evolved over the last few years for companies trying to build a business around open source. at grafana labs we are closely following these developments, and are constantly wrestling with decisions around what is best for our own licensing strategy. all of our peers (eg. mongodb, elastic, redis, confluent, cockroach,…

Ive been interested in the licenses that are restrictive with a time period (eg: 6 months-1 year) after which they become FOSS (Apache2/MIT), eg BSL. I think it's a reasonable approach, but I think the restrictive license still needs to be quite permissive for it to make me happy. I haven't quite found one yet that sat well with me.

Re: Licensing changes to Elasticsearch and Kibana

#259

Post by rudolph9 »

ignoramous wrote: post #98
Areading314 wrote: post #82

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…

TFA explains why Elasticsearch switching to SSPL is indeed a cause for concern. Money quotes: > Basically, it’s a hostile proprietary license masquerading in open source clothing. By using an SSPL project in your code, you are agreeing that if you provide an online service using that code then you will release not only that code but also the code for every supporting piece of software, all under the SSPL. > It’s not…

Isn’t it a dual license, and the existing license isn’t going away?

Re: Licensing changes to Elasticsearch and Kibana

#260

Post by sfifs »

Areading314 wrote: post #82

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…

I wonder if non-ElasticCo contributors to Elastic Search who disagree with the SSPL license change can sue to have their contributions removed. Could even be a class action lawsuit if quite a few contributors disagree.
Post reply on HN