Hacker News Reader

Comment by sciurus | Hacker News Reader

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.

View on HN

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

What will this entail for when you're building Elastic Plugins?

> This change does not affect how you build or license plugins to Elasticsearch or Kibana. For the avoidance of doubt, building a plugin to be used in Elasticsearch or Kibana does not constitute a derivative work, and will not have any impact on how you license the source code of your plugin.

- https://www.elastic.co/pricing/faq/licensing#im-building-plu...

FAQ is not the license, it's their rosy interpretation.

I'd say that similarly to Common Law where rights always come paired with counterpart obligations; the "restrictions" added by GPL vs Apache come with counterpart advantages: they keep forks open source (vs proprietary) and favor contributions feeding back to the OS Community. I believe we should consider them altogether: disadvantages and advantages.

Both permissive and copyleft licenses play important roles in the Open Source ecosystem. Different story are proprietary licenses.

This doesn't add non-compete clause.

I'm wondering how this affects the distribution of x-pack. From what I'm reading, the new Free model probably includes it and we have to turn it off if we don't want it? I wish there was still an x-pack free distribution in this model.

Since the entire Elasticsearch codebase is now under SSPL, there's no more distinction between the former Apache-2 code and the x-pack code.

There are still proprietary modules only available under the Elastic License just as before.

However it seems that they will be moving the free modules which were previously only licensed under Elastic License to be licensed under SSPL instead.

At least, that is what this graph seems to be indicating to me. https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce...

You're right -- it's only the free "X-pack Basic" code that will now be available under SSPL. But that does mean that all Elasticsearch distributions will now include the former "X-pack Basic" features.

That seems to be what they are suggesting by making the "free" box in the 3rd column span both the "free" and "free/basic" tiers of the previous columns.

Unless they plan to make those modules paid which were previously free, which I doubt

Yes, I understand that, but what I would like is a distribution without any x-pack code. I don't want to have to figure out how to turn off and remove x-pack. What I'm concerned about is that it's another vector for security vulnerabilities that I don't need.

Reply on news.ycombinator.com