Elasticsearch license change. What does this mean for you and which version should you choose?
Last updated: February 1st, 2021
The long and short of it is that Elastic is changing its licensing. As of its upcoming 7.11 release, it will be switching to an SSPL license and Elasticsearch and Kibana will no longer be open source. Amazon will be creating a fork that will continue to be open source.
This announcement has left many people confused and wondering how to proceed. We put together a rundown of what Elasticsearch might look like in the future, and what you should do now that the licenses are changing.
Short-term Elasticsearch changes
In the short term, there is a lot of FUD (fear, uncertainty and doubt), but if you’re not a managed service provider or offering ES/Kibana as service, you probably don’t need to do anything*. If you’re already using Elasticsearch, whether self-hosted or with a managed service, you can stay where you are and keep working as you’ve worked until now.
To make sure you’re where you should be at every stage, read the considerations below.
Long-term Elasticsearch changes
In the long term, Elastic will likely begin to “dry up” the free tier it’s promising and Elasticsearch will become a proprietary product. Most new features will not be available in the open source version, as we’ve already seen happen since they launched the X-Pack. Its offering will become more similar to Splunk and other proprietary solutions.
Elastic has always prided itself on the holiness of open source features and stressed in their announcement that they will continue to protect and prioritize them. However, as they’ve already demonstrated with their latest announcement, circumstances change, and their promises are not always kept. While less will be available as open source and on the free tier, the paid product will probably be state-of-the-art Elasticsearch. Its features will go and become more and more innovative and incredible.
With AWS launching a fork of Elasticsearch and Kibana, an open source version of each will remain available, but whether the fork will function and thrive remains to be seen. Many companies have been working on a fork for Kibana, but no one has contributed significant code to Elasticsearch. No one has the experience building and maintaining it as Elastic does.
On the other hand, many companies have built managed services for Elasticsearch logging and security and will have no other option but the fork. If they work together with AWS, who are certainly strong and capable, we may see a fully functioning fork in the future.
We probably won’t be seeing many mini forks though, because creating and maintaining one will be challenging and resource exhausting. AWS is probably the only company that could sustain one. If they do, will they follow in Elastic’s footsteps and make it proprietary as well? They may. Everyone else will just have to fend for themselves.
In 3 or 4 years, there will be 2 separate and distinct products with feature sets that will become more and more differentiated over time. The “fork” won’t remain a fork for long. This means that when choosing among the different options, users will have more considerations and features to deliberate over. For example, we can look at Kibana and Grafana – 2 great, distinct products, with Grafana starting originally as a Kibana fork.
Whether you’ve been using Elasticsearch for years, or you’re new to it and have only just begun considering using it, here’s what you need to know about the different options available to you: Elastic SSPL, AWS’s Open Distro, and the future AWS fork.
Comparing free versions of Elastic vs. Open Distro vs. AWS Fork
|Elastic license |
|AWS Open Distro |
until ES V7.9
|AWS Fork + Open Distro (predicted)|
|What it is||Elasticsearch||Plugins on top of Elasticsearch, likely maintained on the fork only for future versions||Fork of Elasticsearch 7.10|
|License||SSPL or Elastic||Apache-2.0 / Open source||Apache-2.0 / Open source|
|Support||Documentations + forums||Documentations + forums||Documentations + forums|
What you should do next
1. Stick with Elasticsearch.
Even with all of the confusion and the changes ahead, there’s no better alternative. Whether you are just starting with Elasticsearch or have been working with it for many years, the considerations that make it the best option for your use case are still the same and you should stick to it.
Moving between the AWS fork and Elastic won’t be complicated in the near future. Later down the line, moving between them will probably be similar to moving between other databases such as Solr and Elastic – painful, but totally doable.
The best thing to do now is keep up with the changes in the field and reassess accordingly.
2. Consider moving your Elasticsearch to self-hosted.
A word to the wise – you should always be in control, especially when the field is shifting as it is right now.
People often choose managed services by default when they’re starting with Elasticsearch. Managed services do have several benefits and are great for small scale or non-mission critical use cases. However, support is limited and you’re often left to solve issues and optimize performance on your own.
Avoid vendor lock-in by keeping your software self-hosted. This will give you the power to migrate easily, if and when you want to. You don’t want to find yourself locked into a proprietary edition that isn’t right for you.
We believe that the market is lacking self-management tools at the moment. Users should be able to operate Elasticsearch on their own, while staying self-hosted, without needing to pay an enterprise license to have access to tools that ensure smoother performance.
*This is solely our opinion and interpretation of the situation. We take no legal responsibility for any of the mentioned licenses and their usability. The information provided on this website does not, and is not intended to, constitute legal advice; instead, all information, content, and materials available on this site are for general informational purposes only.