3 ms·

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 d

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.

sytse 6y ago
SSPL is based on the GNU AFFERO GENERAL PUBLIC LICENSE https://webassets.mongodb.com/_com_assets/legal/SSPL-compared-to-AGPL.pdf 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-source_software_licences#General_comparison https://en.wikipedia.org/wiki/Comparison_of_free_and_open-so...
- worldsayshi 6y ago
  What will this entail for when you're building Elastic Plugins?
  - deleted 6y ago
    [deleted]
  - brasetvik 6y ago
    > 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-plugins-for-elasticsearch-or-kibana-how-does-this-change-affect-me https://www.elastic.co/pricing/faq/licensing#im-building-plu...
    - z77dj3kl 6y ago
      FAQ is not the license, it's their rosy interpretation.
- ahachete 6y ago
  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.
- Paul-ish 6y ago
  This doesn't add non-compete clause.
craigching 6y ago
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.
- dhd415 6y ago
  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.
  - shawnz 6y ago
    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/blte5c15e1ca58ce7a0/5fff41e749cfff488f0f72d9/chart-scrn.jpg https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce...
    - dhd415 6y ago
      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.
      - shawnz 6y ago
        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
  - craigching 6y ago
    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.

sytse 6y ago

SSPL is based on the GNU AFFERO GENERAL PUBLIC LICENSE https://webassets.mongodb.com/_com_assets/legal/SSPL-compared-to-AGPL.pdf 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-source_software_licences#General_comparison https://en.wikipedia.org/wiki/Comparison_of_free_and_open-so...

worldsayshi 6y ago
What will this entail for when you're building Elastic Plugins?
- deleted 6y ago
  [deleted]
- brasetvik 6y ago
  > 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-plugins-for-elasticsearch-or-kibana-how-does-this-change-affect-me https://www.elastic.co/pricing/faq/licensing#im-building-plu...
  - z77dj3kl 6y ago
    FAQ is not the license, it's their rosy interpretation.
ahachete 6y ago
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.
Paul-ish 6y ago
This doesn't add non-compete clause.

craigching 6y ago

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.

dhd415 6y ago
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.
- shawnz 6y ago
  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/blte5c15e1ca58ce7a0/5fff41e749cfff488f0f72d9/chart-scrn.jpg https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce...
  - dhd415 6y ago
    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.
    - shawnz 6y ago
      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
- craigching 6y ago
  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.