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

341–350 of 378 posts

Re: Licensing changes to Elasticsearch and Kibana

#341

Post by erezsh »

ignoramous wrote: post #309
erezsh wrote: post #289

Earlier quoted context omitted.

As someone who writes open-source, I'm always happy to see other developers use my code to build cool stuff, and I expect nothing in return. I'm also happy to see small start-ups rise faster by using my software. But if those theoretical start-ups, whose business wouldn't exist without my software, grew to dozens of employees, made millions of dollars, and still I wouldn't see a nickel.. That's when I would start to…

I write F/OSS full-time. AWS does / did contribute patches to Elasticsearch. The problem Elasticsearch has is, AWS shares none of the gigantic profits it makes from its Elasticsearch Service, which is a double whammy because it cannibalizes Elastic's own SaaS offering. > To conclude, that sounds like false equivalency to me. It does matter who is using it for free and profiting. You mean to say, Facebook must share a…

> AWS does / did contribute patches to Elasticsearch.

That's a meaningless statement, since it could just as well mean that they contributed back 2 hours of work.

> * is okay to switch to SSPL ???

Yes, absolutely. Why not?

The article you linked doesn't mention anything about foundations. But let's agree not every open-source project can become one.

Re: Licensing changes to Elasticsearch and Kibana

#342

Post by Pet_Ant »

npiit wrote: post #24
Pet_Ant wrote: post #3

I hope that SSPL becomes the standard for companies so that at least it becomes a known entity instead of a proliferation of bespoke licenses: like if CockroachDB moved to it as well. Personally, I'd rather see a more aggressive AGPL where REST calls are considered linking and trigger virality and I believe that would meet the definition of open source by the OSI while preserving the value of the commercial version.

>Personally, I'd rather see a more aggressive AGPL where REST calls are considered linking and trigger virality That's why I never understood the point of SSPL. Is this exactly what AGPLv3 is supposed to be for?

IANAL

I believe AGPL expands the definition of distribution not of linking. So if GCC was AGPL and I made a web page where you could upload source code and then download the binary, that would count as "distributing" GCC and thus I would have to make the changes I made available (because privately made change to GPL code do not have to be shared if the binaries aren't shared).

Re: Licensing changes to Elasticsearch and Kibana

#343

Post by erezsh »

jrochkind1 wrote: post #296
erezsh wrote: post #292

Earlier quoted context omitted.

I can answer that. The OSI doesn't approve any license that "discriminates on fields of endeavor", which means you are not allowed to prevent cloud providers from competing with you with your own product. Premium sponsors of the OSI include AWS, Google and Microsoft.

Thanks. What about the SSPL is considered discriminating against a field of endeavor? The AGPL is OSI-approved, and as I understand it also has a requirement "that if you provide the product as a service to others, you must also publicly release any modifications". (Possibly not "as well as the source code of your management layers", but that addition doesn't seem to post any additional problems related to "restricti…

The AGPL is easy to circumvent.

MongoDB already answered all these questions when they created the SSPL in the first place: https://www.mongodb.com/licensing/server-side-public-license...

(iirc they also wrote a lengthy blog post about it)

Re: Licensing changes to Elasticsearch and Kibana

#344

Post by 9dev »

cutemonster wrote: post #291
mike_d wrote: post #253

Earlier quoted context omitted.

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.

Number 2 and 3 are false. Edit: I want e2e encryption but not censorship resistant, not when it starts getting used for inciting to violence. Search for eg "WhatsApp lynch mobs" or "Facebook Myanmar genocide".

By very definition, it cannot be "end to end" encryption if it isn't encrypted from one end to another.

Re: Licensing changes to Elasticsearch and Kibana

#345

Post by confiq »

nanagojo wrote: post #246
confiq wrote: post #175

Earlier quoted context omitted.

> https://github.com/valeriansaliou/sonic This is actually very interesting project. Do we have some benchmark that sonic works on huge scale with lot of data?

I assume you find their own benchmarks not conclusive enough? https://github.com/valeriansaliou/sonic#how-fast--lightweigh... they also claim > It is used to index half a billion objects on a $5/mth 1-vCPU SSD cloud server (as of 2019)

hmm, maybe I should ask, do we have somebody who is using this on production with huge amount of data?

Re: Licensing changes to Elasticsearch and Kibana

#346

Post by confiq »

ignoramous wrote: post #328
confiq wrote: post #320

Earlier quoted context omitted.

I've just checked, you are right! Correct me if I'm wrong, AWS ES service still uses ES free licence but they've re-written the plugins so they won't use ES and pay ES fee? With new licence, AWS won't be able to use ES as SaaS?

As things stand: Yes, to both your questions.

there is this twitter user that claims that non-elastic employees can't contribute[1]. I wish somebody could summarise this romance between AWS vs Elastic for simpler people because I can't catch up :(

[1] https://twitter.com/_msw_/status/1349939801445658624

Re: Licensing changes to Elasticsearch and Kibana

#347

Post by ensignavenger »

halbritt wrote: post #301
bigiain wrote: post #270

Earlier quoted context omitted.

I can get at least a couple of person-weeks worth of dev done for the cost of sending the email that results in attempting to convince the lawyers of _anything_. I wouldn't even ask for a legal review of this new Elastic License, if I thought I could tear it out for less than 2 dev-months of effort.

Well, what, then? SOLR?

Amazon's Open Distro for ElasticSearch is still an open source fork of Elastic Search, so ironically Amazon may be the saviors of Open Source Elastic Search.

Re: Licensing changes to Elasticsearch and Kibana

#348

Post by _J_Phi_F_ »

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

Good for us to be in the age of 0.01% marketshare Rust where probably 80% of the software runs on the shabby JVM.

Too bad we're talking about software license here.

Re: Licensing changes to Elasticsearch and Kibana

#349

Post by _J_Phi_F_ »

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.

According to the Rust evangelists only Rust solves problems - and it solves all the problems in the world, while C/C++, Java, Go or C# just create problems.
Post reply on HN