images
figures
Blog

The Implications of Elasticsearch and Kibana License Change from Apache 2.0 to SSPL

Admin Globaldots
10.02.2021
image 6 Min read
DevOps as a Service

This blog explains the license change move by elastic.co for Elasticsearch and Kibana, its implications on the opensource community and what it means for the companies that are already using it.

Introduction

Elasticsearch over the past years has been the industry standard opensource software in the field of search because of its lightning-fast searching and very strong querying capabilities. Elasticsearch and Kibana is part of elastic.co’s famous ELK (Elasticsearch, Logstash and Kibana) stack or on a higher level, a paramount part of the entire Elastic Stack, that comprises of other tools such as Metricbeat, Filebeat, Heartbeat etc, apart from your normal ELK. Until now Elasticsearch and Kibana were under the Apache 2.0 license which made this software completely opensource. However recently elastic.co changed that license from Apache 2.0 to SSPL (Server Side Public License).

Image for post
Image Source: elastic.co

“Apache License 2.0 allows users of the software to distribute, modify, or otherwise use software for any purpose, as long as the user complies with the license terms. The terms state that users can’t remove existing copyright, patent, trademarks and attribution notices.”

Under this license, the stack was adopted by many companies and heavily regarded and used in the software development community. Such a tool stack encouraged thousands of open-source developers to contribute to the cause and make the software even more prominent in the market. Along with this stack, it’s underlying search engine “Lucene” also received heavy support from the opensource community, many contributions are made to Lucene by individual developers as well as the engineers of elastic.co and other companies such as AWS, in order to enhance the underlying technology on which Elasticsearch has been built.

The new SSPL (Server Side Public License) license adopted by elastic.co was introduced by Mongodb Inc in the year 2018 when they faced a similar situation. It is based on the GPL3 license with an additional clause that would basically stop other companies from using the software as they own product directly, it can be used internally within the company but can’t be offered directly as a service to others.

Why the License change?

A while ago elastic.co filed a lawsuit against floragunn GmbH, the makers of Search Guard, a security plugin for Elasticsearch and Kibana, with a claim of a multi-year pattern of copying elastic’s proprietary code. The lawsuit later on also included some other companies and software such as Open Distro for Elasticsearch by AWS, Amazon Elasticsearch ServiceObjectRocket for Elasticsearch, and IBM Cloud Databases for Elasticsearch.

Note: The truth of the matter and the actual decision of the lawsuit is something that is out of the scope of this blog and something which would be handled by the governing bodies.

But in short, the license change can be considered as a result of the situation mentioned above and also to prevent companies from using elastic.co’s products and selling these directly products as their own. This statement is explained below in detail as to what “direct” means and what use cases would it affect.

Who will be affected and who won’t be affected by this License change?

The scenario-based explanation below provides details about what companies would be affected by this license change and what use cases of Elasticsearch and Kibana are permitted under this newly adopted SSPL license.

A company that has hosted and is using Elasticsearch as a database for their products and using it to query and display the products on their dashboards:

Image for post

This license change to SSPL is not going to affect any company that is using Elasticsearch as its database and storing and querying data. They can continue using it exactly how they were using it earlier without any issues in the future by this transition from Apache 2.0 to SSPL.

Eg: E-commerce websites that your Elasticsearch as their main database and its querying functionality for searching.

A company that has hosted Elasticsearch and Kibana and has incorporated a Kibana dashboard inside their SAAS application:

Image for post

If these companies are using the default distribution of Elasticsearch and Kibana, that distribution is already covered under Elastic License. The Elastic License is entirely free to use including all its basic features. If using this distribution a Kibana dashboard or Elasticsearch is embedded in the SAAS application it is free to use and won’t cause you any issue as long as the main value of your product is derived from your SAAS application and Kibana dashboards are just an add on feature to your product and to your Primary UI.

Eg: Log analytics companies that have their platform with their own Primary UI views and sections. Kibana is embedded inside one of these sections.

A company that has hosted Elasticsearch and Kibana and is providing them as a direct product to its customers and not as an ad on to its own product:

Image for post

Any company that is using Elasticsearch and Kibana this way WILL BE AFFECTED by this license change and won’t be able to continue doing so going forward. This scenario means that you have hosted Elasticsearch and Kibana on your own and are selling elastic.co’s product as your own product which is not permitted under the new SSPL license.

A company that is using “AWS (Amazon Web Services) Elasticsearch Service” for any use case:

Image Source: AWS Docs

Technically the new license change would have affected any company that was doing this BUT AWS has handled this for now. AWS will retain all the AWS Elasticsearch Service plans as before and nothing will change for their customers. They have forked the Elasticsearch’s public repository and has decided to support it on their own. This being said, going forward all the future versions of AWS Elasticsearch Service that would be available for use after the current one would be the forked Elascticsearch’s version that is being maintained by AWS and not by elastic.co itself, you can think about this scenario as — going forward Elasticsearch would be having 2 separate versions/distributions, one managed by AWS under the same old Apache 2.0 license and the other managed by elastic.co under their Elastic and SSPL license.

A company that is using “Open Distro for Elasticsearch”

Open Distro for Elasticsearch is a value-added distribution of Elasticsearch that is completely opensource under the Apache 2.0 license and is supported by AWS and contains some additional features such as advanced securityevent monitoring & alerting, Performance Analytics, etc similar to the ones provided by elastic.co but elastic.co’s advanced features won’t be available in the free distribution under their new SSPL license. This scenario is similar to the one mentioned above, going forward any company that is using “Open Distro for Elasticsearch” would be using AWS’s version of Elasticsearch as it will be derived from their fork of the original Elasticsearch repository. So for future versions, you won’t get the features created in the elastic.co’s original repository and would only get features that are created in AWS’s Elasticsearch fork.

What about Lucene? The core search library on which Elasticsearch is built

Lucene is on Apache 2.0 license and would remain on the same license in the future as well. It is open to contributions for anyone and is completely opensource. Both the elastic.co’s Elasticsearch, as well as AWS’s Forked Elasticsearch, will continue using Lucene internally and nothing will change in that regard, as Lucene is a completely separate entity.

Key Takeaways:

  1. Elasticsearch and Kibana have moved away from Apache 2.0 license and are now on the SSPL license.
  2. AWS has forked Elasticsearch repository and will continue building on their forked version and maintaining it under the Apache 2.0 license.
  3. Contributions can be made on any of the above by any developer in the world based on their personal preference.
  4. If you aren’t using Elasticsearch right now but want to use it going forward, then the best approach would be to compare both the options from an efficiency and pricing perspective and only then make a decision regarding which one you want to choose.

Comments

0 comments

There’s more to see

slider item
DevOps as a Service

AWS NAT Gateway and High-Availability NAT Instances with Auto-Scaling

Francesco Altomare

The basics of AWS Virtual Private Cloud (VPC), NAT Gateway, NAT Instances, and the working of a High-Availability version of NAT instance deployment.

Read more
slider item
DevOps as a Service

How the Traditional CI/CD Pipeline Might Be Killing Efficiency

Steven Puddephatt 26.10.20

How the Traditional CI/CD Pipeline Might Be Killing Efficiency – A developer’s blog about the debugging process and how to optimize it.

Read more
slider item
DevOps as a Service

What is DevOps and How You Can Benefit from It?

Admin Globaldots 17.12.14

What is DevOps and How You Can Benefit from It?

Read more

Unlock Your Cloud Potential

Schedule a call with our experts. Discover new technology and get recommendations to improve your performance.
Contact us
figure figure figure figure figure