Planned change of license to SSPL

I think the planned change from Apache 2 to SSPL for ES and Kibana will not just motivate myself to seriously look for other solutions.
(see https://www.elastic.co/blog/licensing-change)

SSPL seems to be extremely restrictive, even more so than AGPL3 and as far as I understand may even make some projects impossible if components of the service have an incompatible license (which would not have been a problem so far).

This is especially a problem for projects where a free service is provided via ES as such projects cannot afford a commercial license and may be unable to use the SSPL license because of license incompatibilities and/or IP restrictions.

Here is an article on the move: https://anonymoushash.vmbrasseur.com/2021/01/14/elasticsearch-and-kibana-are-now-business-risks

https://webassets.mongodb.com/_com_assets/legal/SSPL-compared-to-AGPL.pdf is a comparison between AGPL and SSPL.
The core differences being the Preamble and Section 13.

We are dual licensing for this reason, and will still be releasing the code as open, and tonnes of functionality as free.

if you have specific examples or concerns then we have an FAQ - https://www.elastic.co/pricing/faq/licensing - that should help, or we're happy to answer things here too.

I'm very concerned about this too.

Making the functionality of the Program or modified version available to third parties as a service includes, without limitation, enabling third parties to interact with the functionality of the Program or modified version remotely through a computer network, offering a service the value of which entirely or primarily derives from the value of the Program or modified version, or offering a service that accomplishes for users the primary purpose of the Program or modified version.

"Interacting with the functionality of the program" is a very broad description, and sounds like if an end user does anything that touches an elasticsearch API then it's triggered.

The FAQ clarifies this:

I'm a user, how does this affect me?

If you download and use our default distribution of Elasticsearch and Kibana, nothing changes for you. Our default distribution continues to be free and open under the Elastic License, as it has been for nearly the last three years. If you build applications on top of Elasticsearch, nothing changes for you. Our client libraries continue to be licensed under Apache 2.0. If you use plugins on top of Elasticsearch or Kibana, nothing changes for you.

But my understanding is that one agrees to a license, not to a license+faq combination.

I love Elasticsearch and believe that you have good intent here, just looking to protect yourselves from AWS launching a separate Elasticsearch service. If the FAQ is meant to modify the license by excluding that condition then please consider using a different license that doesn't make us depend on your good will.

1 Like

The SSPL seems to be designed to give the impression of being open-source while being so restrictive and vague, that hardly anyone can risk using it.

To me there are two main issues: first the vagueness of "a service the value of which entirely or primarily derives from the value of the Program or modified version". This is so fuzzy that it can mean anything.

Second, the requirement to publish the complete "work" under the SSPL, when parts of the work may be modifications of open source code published under a different, incompatible license.

None of us has the time or money to hire a lawyer to figure out the risks here, so the general agreement is to just stay away as far as possible.

I have talked with people from several academic institutions and they all agree they will try everything to stay away from that license, initially staying with the current version and hoping for a fork.

Speaking of forks, there already seems to be an initiative to accomplish this, see https://logz.io/blog/open-source-elasticsearch-doubling-down/

1 Like

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.