Fast-moving development organizations use open-source software to avoid re-inventing the wheel and relying on large communities. But while there are mind-blowing examples of open-source companies who've revolutionized industries (e.g., Linux or Kubernetes), or instances that show the model's vulnerability (e.g., https://heartbleed.com/), conflicts often arise when open-source ideals come up against commercial interests. Recent changes announced by Elastic, the company behind Elasticsearch and Kibana, is another such example of an open-source software developer changing its core strategy and forcing engineering managers to reassess a company's license usage.
By shifting from Apache 2.0 to a dual licensing model under Server Side Public License (SSPL) and the Elastic License, Elastic is pushing back at cloud service providers who unfairly profit off its source code without contributing to the open-source community in return. This makes sense, and while I appreciate Elastic’s open communication and their challenges in a fast-growing market, analysis at {anonymous =>'hash'}; emphasizes correctly that these license changes pose significant risks for organizations with services and products based on either the Apache 2.0-licensed Elasticsearch or Kibana.
In particular, Elastic's new dual license structure forces enterprises to choose between one of two licenses when upgrading to 7.11 – neither of which is open source in the eyes of the Open Source Initiative (OPI). The Elastic License makes default distributions of Elastic products free to use but not for a directly provided service. SSPL, on the other hand, is required for enterprises which leverage the products for sale as a service within their own (e.g., Amazon Elasticsearch Service). Those building applications on top of Elasticsearch or Kibana can continue doing so for free but must accept the Elastic License.
To Elastic's credit, they are exploring additional rights to the Elastic License in line with MariaDB's Business Source License agreement. Still, SSPL's vendor lock-in strategies make what should be a run-of-the-mill technical change for engineering managers a severe dilemma. Refusing to accept Elastic's licensing changes due to SSPL's proprietary agreements means remaining on unsupported technology and taking on technical, financial, and legal risk. At its worse, this route will force enterprises to open-source a significant part of theirr technology stack.
For more information, I encourage you to read Elastic's recent clarifications on its licensing announcement.
How engineering managers ensure open source license compliance
Even if this situation isn't relevant to your company, it demonstrates the importance of asking and getting data-driven answers to questions like:
- How to track which open-source licenses are in use without adding overhead to your development organization
- How to achieve joint understandings with your legal team on handling dual-licensing or other such aspects that are unique to the way your software is run and deployed
- How to reach a transparent alignment with business stakeholders to identify the right choices on open-source licenses, involving them in discussions on technology and legal risk, and determine whether to pay for extended support or invest time to move away from a solution like ElasticSearch or Kibana
LeanIX Microservice Intelligence is a perfect vehicle for leveraging existing toolchains, such as the CI/CD pipeline or Kubernetes, to create an automatic documentation of self-developed software. At last year’s EA Connect Days, I gave a presentation alongside Per Bernhardt, LeanIX Engineering Manager, on how LeanIX uses Microservices Intelligence to embrace governance and trade-offs in its very own software development. Microservices Intelligence can easily extract open-source libraries from your CI/CD pipeline (e.g., by utilizing Mavens', npm's, or Gradle’s dependency resolution mechanisms) for sharing with stakeholders inside or outside a development organization.
