Earlier quoted context omitted.
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.
Excellent point.
Licensing changes to Elasticsearch and Kibana
361–370 of 378 posts
Re: Licensing changes to Elasticsearch and Kibana
#362Earlier quoted context omitted.
more like the difference between GPL and Affero GPL. https://en.wikipedia.org/wiki/Affero_General_Public_License
I'm not sure that I can't follow them all :(
Long but may be helpful: https://www.oreilly.com/library/view/understanding-open-sour...
Not an expert but usually F/OSS licenses are mainly about:
- Patent grants (either grants patent-use or doesn't)
- Copyleft (should modifications be open sourced. ex: AGPL is the strongest FOSS copyleft, whilst SSPL builds on it to make it even more stronger)
- Copyright (owners who are licensing the code)
- Warranty and Liability
- Terms of use (ex: FOSS licenses don't enforce restrictions on commercial use like CommonsClause does)
Re: Licensing changes to Elasticsearch and Kibana
#363Earlier quoted context omitted.
Remember when Google argued that Oracle shouldn’t be allowed to sue over using the Java API because SUN had said it was fine? That’s the same legal argument as the FAQ issue. It’s called equitable estoppel.
Yeah, that is what happens when one turns down the opportunity to own Java.
Are you saying Google did that? Any links?
Re: Licensing changes to Elasticsearch and Kibana
#364Earlier quoted context omitted.
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".
It seems unclear what you mean by 2 and 3 being false - plenty of folks want those things.
About 3: I want software patents to not exist also if I get a good patent, so GGP's "everyone" is inaccurate.
(But I guess I'd taken Elastic's approach and switched to SSPL)
About 2: i replied here: https://news.ycombinator.com/item?id=25798359
Re: Licensing changes to Elasticsearch and Kibana
#365Earlier quoted context omitted.
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.
Here's a way to build true e2e encryption apps that can be, to some extent, censored:
NLP locally in the phone -- an AI that slightly understand what the user writes -- and if it's (I'm oversimplifying) like "kill all ...", then the AI bricks the phone.
Otherwise it's e2e as usual.
Re: Licensing changes to Elasticsearch and Kibana
#366Earlier quoted context omitted.
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?
ok, i'm stupid
> Sonic is integrated in all Crisp search products on the Crisp platform. It is used to index half a billion objects on a $5/mth 1-vCPU SSD cloud server (as of 2019). Crisp users use it to search in their messages, conversations, contacts, helpdesk articles and more.
Re: Licensing changes to Elasticsearch and Kibana
#367Earlier quoted context omitted.
Seems like you know a thing or two about this — are all the reports I see about companies leaking tons and tons of data through improperly configured elastic search instances something using the aws’s offering would fix (or even ES’s hosted offering)? I don’t really know much about the field, but if AWs’s single contribution were to be “we made it really hard to screw up the configuration and leak all your data”, I’d…
> Seems like you know a thing or two about this — are all the reports I see about companies leaking tons and tons of data through improperly configured elastic search instances something using the aws’s offering would fix (or even ES’s hosted offering) The primary issue that leads to that is that the stock open source elasticsearch distribution (APL licenced) does come with no security at all. It even used to be the…
Hm. So Elastic releases a neutered version of their product that leads to countless PII leaks, AWS provides a FOSS plug-in to fix that, then Elastic turns around and says AWS is leaching off their product and not contributing back to the community and implements a licensing change to prevent them from working together in the future? I can’t help but side with the AWS folks on this one —- I get wanting to make money, but insecure-by-default services are inexcusable, especially when it’s expected that they’ll contain PII.
Re: Licensing changes to Elasticsearch and Kibana
#368It's just a change to make sure that those who resell ES as a service share their code. We use AWS's ES. And, as far as I'm concerned they already open-source their version. SSPL is actually helping the open-source community here
From the link: > The SSPL allows free and unrestricted use, as well as modification, with the simple requirement that if you provide the product as a service, you must also publicly release any modifications as well as the source code of your management layers under SSPL. Not a lawyer, but I think AWS fall foul of "as well as the source code of your management layers" because they have a massive amount of closed sour…
> they have a massive amount of closed source stuff running behind their ES service
GPL licenses are not SSPL compatible, so it would likely still be impossible to comply even if their ES service was entirely open source.
Re: Licensing changes to Elasticsearch and Kibana
#369wow, 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,…
> at grafana labs we are closely following these developments, and are constantly wrestling with decisions around what is best for our own licensing strategy.
It would be great to see a list of pros and cons for approaches taken by ElasticSearch, MongoDB, TimescaleDB regarding licensing.
BTW, we at VictoriaMetrics do not plan to change license for published source code. All the VictoriaMetrics source code is published under Apache 2.0 license [1].
[1] https://github.com/VictoriaMetrics/VictoriaMetrics/blob/mast...
Re: Licensing changes to Elasticsearch and Kibana
#370Earlier quoted context omitted.
Both the Debian Free Software Guidelines[1] and the GNU Free Software Definition proscribe limiting fields of endeavor. The OSD[3] borrows heavily from the DFSG. I remember reading (alas, I can't find my source) a spokesperson for the OSI admitting to the existence of licenses that meet the OSD that they don't want to be OSI-approved because they don't add enough value versus the cost of proliferation of licenses tha…
These definitions were written a long ago, in a time when cloud computing wasn't even a buzzword yet. But I read them and couldn't find anything addressing fields of endeavor. GNU's "four essential freedoms", which imho are a little naive in retrospect, don't say anything about this. They say anyone should be able to "sell copies", but SSPL doesn't disallow this either. Debian obviously didn't address it either. They…
> GNU's "four essential freedoms", which imho are a little naive in retrospect, don't say anything about this.
"The freedom to run the program as you wish, for any purpose."
That clearly includes purpose of running the progam as a cloud service and profiting from selling it SaaS-style to third parties.