Live data from Hacker News

Licensing changes to Elasticsearch and Kibana

elastic.co

31–40 of 378 posts

Re: Licensing changes to Elasticsearch and Kibana

#32
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,…

As far as I can tell, Timescale is not like the others, their shift was to make the formerly proprietary enterprise only code source available. Remarkably they went MORE open rather than less (as it the case for all the others).

You have to give them respect for approaching things differently.

Re: Licensing changes to Elasticsearch and Kibana

#33
post #27
post #12

"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…

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

Re: Licensing changes to Elasticsearch and Kibana

#34
post #12

"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 proprietary license. Because it seems you're damned if you do and damned if you don't. At least commercial closed source products don't attract this kind of criticism.

Re: Licensing changes to Elasticsearch and Kibana

#35
Here's the actual change:

> Starting with the upcoming Elastic 7.11 release, we will be moving the Apache 2.0-licensed code of Elasticsearch and Kibana to be dual licensed under SSPL and the Elastic License, giving users the choice of which license to apply.

So starting with 7.11 no parts of Elasticsearch will be released under an open source license.

They aren't making everything SSPL, though. Their paid features continue to be only available under the Elastic License.

Re: Licensing changes to Elasticsearch and Kibana

#36
post #35

Here's the actual change: > Starting with the upcoming Elastic 7.11 release, we will be moving the Apache 2.0-licensed code of Elasticsearch and Kibana to be dual licensed under SSPL and the Elastic License, giving users the choice of which license to apply. So starting with 7.11 no parts of Elasticsearch will be released under an open source license. They aren't making everything SSPL, though. Their paid features co…

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_open-so...

Re: Licensing changes to Elasticsearch and Kibana

#37
post #34
post #12

"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…

Agreed, if their hosted cloud services and premium features aren't viable as a business, and they don't have any intention to develop this software without a profit, then they shouldn't have positioned themselves as a free-and-open-source product in the first place.

Re: Licensing changes to Elasticsearch and Kibana

#38
post #32
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,…

As far as I can tell, Timescale is not like the others, their shift was to make the formerly proprietary enterprise only code source available. Remarkably they went MORE open rather than less (as it the case for all the others). You have to give them respect for approaching things differently.

I don't think it's really that different. Elastic did that same thing about three years ago when they made all of their enterprise-only features source-available (https://www.elastic.co/blog/doubling-down-on-open). Timescale also made their enterprise features free of charge, but that's a business decision rather than a question of licensing. It's because their revenue model is based completely on their managed cloud offering while Elastic still gets non-trivial revenue from selling their enterprise features to customers who want them.

Re: Licensing changes to Elasticsearch and Kibana

#39
post #31
post #8

The article loads for ~10 sec, shows for a split second and then the screen becomes empty. I'm using a moderately old browser (FF 61.0.1) but come on, how hard it is to display some text?

an updated version of firefox loads fast without issue

I'm sure it does. Maybe it is unreasonable to expect a blog to be readable on a 2 years old browser, but it looks like it took some serious effort this time.

Re: Licensing changes to Elasticsearch and Kibana

#40

I wonder where this leaves the AWS-sponsored Open Distro for Elasticsearch? ( https://opendistro.github.io/for-elasticsearch/ ) Seems to me that they have no choice but to hard fork off of the last Apache-licensed release of Elasticsearch et al

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 makes available the code that they use to orchestrate and manage that service. Assuming that that code is sufficiently uncoupled from other systems, they could perhaps do exactly that. It would certainly be an entertaining counter-move from AWS.

Post reply on HN