Earlier quoted context omitted.
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_…
What will this entail for when you're building Elastic Plugins?
Licensing changes to Elasticsearch and Kibana
71–80 of 378 posts
Re: Licensing changes to Elasticsearch and Kibana
#72Earlier quoted context omitted.
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_…
What will this entail for when you're building Elastic Plugins?
- https://www.elastic.co/pricing/faq/licensing#im-building-plu...
Re: Licensing changes to Elasticsearch and Kibana
#73Earlier quoted context omitted.
It means that any “derivative work” will need to also open the management layer under SSPL. The management layer is AWS, so this puts OpenDistro in a tight spot. I’m not sure forking would work - as Elasticsearch evolves Amazon would not be able to copy features anymore. In the search space, this would be a very hard pill to swallow.
The source code for the various components that make up Open Distro is already freely available under an Apache 2.0 license. This change will have zero direct impact on Open Distro. The SSPL restrictions apply when the licensed software is used to provide a service. It is the AWS Elasticsearch Service that will be directly impacted. It will be limited to Elasticsearch 7.10.x as a foundation. Unless of course AWS make…
Re: Licensing changes to Elasticsearch and Kibana
#74Earlier quoted context omitted.
It means that any “derivative work” will need to also open the management layer under SSPL. The management layer is AWS, so this puts OpenDistro in a tight spot. I’m not sure forking would work - as Elasticsearch evolves Amazon would not be able to copy features anymore. In the search space, this would be a very hard pill to swallow.
The source code for the various components that make up Open Distro is already freely available under an Apache 2.0 license. This change will have zero direct impact on Open Distro. The SSPL restrictions apply when the licensed software is used to provide a service. It is the AWS Elasticsearch Service that will be directly impacted. It will be limited to Elasticsearch 7.10.x as a foundation. Unless of course AWS make…
IMO, the SSPL's cloud provision is a "Japanese No", it is so wide in possible interpretation, that only the Eclipse foundation could actually provide such a service.
Re: Licensing changes to Elasticsearch and Kibana
#75Luckily 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…
Re: Licensing changes to Elasticsearch and Kibana
#76Re: Licensing changes to Elasticsearch and Kibana
#77"protection against public cloud providers offering open source products as a service without contributing back". I have no issue with whatever license they choose, but let's be honest, its not about contributing back to these projects, its inserting a poison pill clause that they know cloud providers can't meet. Specifically, by contributing back they mean, per the license: "If you make the functionality of the Prog…
What do you expect them to do though? If they want to be viable as a business they need to place some restrictions so they can have a monopoly on some aspect in order to derive profit. If they're not viable as a business, they die and nobody benefits from that. It's this kind of all or nothing criticism that has made me rethink open source. I'm releasing a product this year, and it's going to start under a proprietar…
Re: Licensing changes to Elasticsearch and Kibana
#78So how is Elastic going to fare if Lucene makes a similar switch?
That can't really happen. While Elasticsearch was previously released under the Apache 2.0 license, it was still "owned" by Elastic. Lucene on the other hand, is "owned" by the Apache Software Foundation (ASF). While companies can build products based on Lucene, which they release under their own choice of License, they cannot change the Lucene license itself. Only the ASF can do that. Another example of this is Kafk…
Re: Licensing changes to Elasticsearch and Kibana
#79I can understand the motivation - AWS' approach, particularly to elastic, has been pretty awful, and migrating away from Apache/GPL/MIT is like a coming of age for the big databases (Mongo, Cockroach, Elastic...) - but calling the article 'Doubling Down on Open' stretches credibility. Be honest, treat us like adults and cut all the 'we're doing this to remain open' crap. You are a public company who wants to increase…