In a play to convert users of their open source projects into paying customers, today Elastic announced that they are changing the license of both Elasticsearch and Kibana from the open source Apache v2 license to Server Side Public License (SSPL). If your organisation uses the open source versions of either Elasticsearch or Kibana in its products or projects, it is now at risk of being forced to release its intellectual property under terms dictated by another.
If you’re not yet aware of the SSPL, you can catch up here. As licenses go, it’s pretty problematic from a business perspective. Every IP lawyer to whom I’ve showed the text of the SSPL has been rather alarmed before they even reach the end of it. Basically, it’s a hostile proprietary license masquerading in open source clothing. By using an SSPL project in your code, you are agreeing that if you provide an online service using that code then you will release not only that code but also the code for every supporting piece of software, all under the SSPL. It’s not a stretch to interpret the wording of the license as requiring users of the SSPL’d software therefore to release the code for everything straight down to the bare metal. There are those who will point to the FAQ for the SSPL and claim that the license isn’t interpreted in that way because the FAQ says so. Unfortunately, when you agree to a license you are agreeing to the text of that license document and not to a FAQ. If the text of that license document is ambiguous, then so are your rights and responsibilities under that license. Should your compliance to that license come before a judge, it’s their interpretation of those rights and responsibilities that will hold sway. This ambiguity puts your organisation at risk.
In its announcement, Elastic claims that this is simply a change of open source license. In one way they’re correct: they’re changing the license away from the open source Apache v2 license. However they are changing to what can best be described as a proprietary source available license, not to an open source one. MongoDB, the originators of SSPL, requested that Open Source Initiative (OSI) (the standards body that maintains the Open Source Definition and certifies licenses as open source) certify the SSPL as such. After a great deal of discussion among the panel of legal, licensing, and open source experts, MongoDB withdrew the SSPL from consideration as an open source license, as it appeared highly unlikely it would be certified as open source. That SSPL is not an open source license is no longer in dispute. That ship has sailed. If you have a problem with this, I suggest you take it up with OSI. As for Elastic’s public and verifiably false claim that SSPL is an open source license, it’s my hope that OSI will have a conversation with them and make a public statement of their own shortly.
No, this is a business decision, not an ideological one. Elastic made a business decision to change to this hostile proprietary license to give them a way to
extortinfluence users to become customers. Without a great deal more strategic information about Elastic’s business and operations none of us are qualified to judge whether it’s the correct decision, but the decision itself is valid. They are allowed to make this sort of strategic move for their company.
However, you and your organisation have now also been forced into a business decision. If your organisation uses the Apache v2 licensed Elasticsearch or Kibana in its projects or products, it must now assume that it is at risk one way or another. It can upgrade to version 7.11 of these projects, thereby accepting the terms of SSPL and potentially also being required to release the code for its entire stack (a great deal of which it will not have the copyright over and will be unable to release, thereby potentially being in violation of SSPL). It can remain on version 7.10, but then it will no longer receive future updates, including important security fixes, thereby taking on another sort of risk. It could choose to pay for a Gold+ license for the software, but it’s unlikely that the budget is prepared for this sort of unexpected expense. And finally it can rearchitect its project or product, replacing Elasticsearch and/or Kibana with alternatives. Frankly, considering today’s unfriendly move by Elastic, putting some space between it and your organisation may be the safest alternative in the long run, but it will come with its own considerable price tag in time and other potential opportunity and switching costs.
The one thing your organisation cannot afford to do is ignore this. It’s time to call a meeting with your legal, software development, product, finance, and strategy teams to start to figure out the best option for you.
For more information on relicensing moves like this, please see The problem with Amazon and Open Source isn’t Amazon.
Judging from the bandwidth usage stats on my hosting service, people seem to appreciate this post. Thank you for that. If you’d like me to provide corporate open source strategy for your company, please drop me an email. I’ll soon be kicking my job search into high gear after Juniper laid off its open source team last year. Contacting me now makes it more likely your company will be in consideration for my next role.