|Please note: Since we initially published this blog, we completed our review and announced updates to the Elastic License.|
- Our on-prem or Elastic Cloud customers will not be impacted.
- The vast majority of our users will not be impacted.
- The folks who take our products and sell them directly as a service will be impacted, such as the Amazon Elasticsearch Service.
If you're using the products or building an application on top of Elasticsearch and Kibana, our intent is that you won't be impacted. We have been updating our FAQ continuously, based on the questions we’ve been seeing, but if you have any questions that aren’t yet addressed, please reach out to us at firstname.lastname@example.org.
We also wanted to clarify how the dual license works. We moved the Apache 2.0 licensed source code of Elasticsearch and Kibana to be dual licensed under the Elastic License and SSPL. You choose which license to use:
- SSPL is well known - millions of people use MongoDB under this license today. We chose this license as an option to make the decision easy for the millions of developers using MongoDB. SSPL, a copyleft license based on GPL, aims to provide many of the freedoms of open source, though it is not an OSI approved license and is not considered open source.
- Elastic License is also well known - If you use our default distribution, as millions of others and 90%+ of our downloads over the past 3 years, you already use it and there is no change for you. It is source-available and allows free use, with none of the copyleft aspects of SSPL. The Elastic License does not allow taking the product and directly selling it as a service, like Amazon Elasticsearch Service, redistributing the products, hack the source code to grant yourself access to our paid features without a subscription, or the use of modified versions in production.
The future of the Elastic License
As noted in our FAQ and based on the feedback so far, we're considering ways to further simplify the Elastic License. Our goals align well with the spirit of the BSL, created by MariaDB and also used by CockroachDB, who “... believe[s] this is the best way to balance the needs of the business with our commitment to Open Source” in their excellent blog about their decision to take this approach.
The BSL, endorsed by the OSI founder Bruce Perens, is a simple, parameterized license, which each company can customize to match their needs. It provides the right to copy, modify, create derivative works, redistribute, as long as the "additional rights" parameters are met. We are evaluating an additional rights grant that would allow production use, with only 3 simple limitations:
- You may not use the licensed work to provide an "Elasticsearch/Kibana as a Service" offering.
- You may not hack the software to enable our paid features without a subscription.
- You may not remove, replace or hide the Elastic branding and trademarks from the product. (e.g. do not replace logos, etc).
Then after a period of time, typically 3-4 years, but not more than 5 years, the restrictions lapse, and the source code automatically converts to an Open Source license, in our case Apache 2.0.
To be clear, BSL is not an OSI approved license.
We’re taking our time to get this right - ideally offering a single license that covers both our free and paid features while still being as open as possible is delicate. Especially if it means the code becomes open source after 3-4 years. If we can achieve it safely, we can provide more freedoms for our commercial features, and a simple, single license for our distribution. This is the kind of challenge that is worth working hard for. We are worried about it being abused, from you know who :), so bear with us.
If we decide it is not the right approach, we will consider splitting it into a BSL-based Elastic Community License for our free features and a simplified Elastic License for our paid features.
Our intent is to finalize it by our next release, 7.11, as we mentioned in the blog post, so we would like your feedback! Let us know if this approach would work for your use-case at email@example.com.