Table of Contents
- Elastic is ‘Doubling Down on Open’
- The Licenses
- Elastic Vs AWS
- Following in MongoDB’s Footsteps
- Commercialisation of Open Source
- Source Available Licenses
- The ‘Fauxpen’ License
- Contention in the Software Commons
- What Does this Mean for the Future of Open Source Licenses?
Elasticsearch Moves to Source Available: A closer Look at Licensing
On the 14th of January 2021 Elastic’s founder and CEO, Shay Banon, announced that they were “doubling down on open” by changing the Elasticsearch and Kibana products from the Apache 2.0 license to the Server Side Public License (SSPL). This license change marked Elastic’s move from open source to a source available license (a type of proprietary license) for its Elasticsearch and Kibana products.
Elasticsearch is a search and analytics engine for all types of data and Kibana is its companion data visualisation dashboard. This lets users visualise data with charts and graphs in Elasticsearch.
The products are offered under a dual-licensing model. This means that users are given the choice to use Elasticsearch for free, subject to licensing restrictions, or to purchase Elastic’s commercial license and use the software how they wish.
However, Elastic have a unique take on the traditional dual licensing model as users are given the choice between two free of charge licenses: the new Elastic License 2.0 (ELv2) and the SSPL.
The Licenses
The Apache 2.0 license is an open source license that allows users to use the software as they wish as long as they provide the required notices.
Whereas both the ELv2 and SSPL are a type of proprietary license: source available. The ELv2 allows users to use, copy, distribute, make available, and prepare derivative works of the software but prohibits users from using the software to provide a managed service to others.
The SSPL allows users to use, modify and redistribute the software but to provide a service to others, you must publicly release any modifications as well as the source code of your management layers. Likely, organisations with intellectual property value in their software will not want to publicly share their source code in this way.
Elastic v AWS
According to Elastic, the motive behind this license change was to prevent companies from taking the Elasticsearch and Kibana products and providing them directly as a service without collaborating with Elastic. AWS has done exactly that with their Amazon Elasticsearch Service.
Shay Banon, Elastic’s founder and CEO, says:
“[AWS] have been doing things that we think are just NOT OK since 2015 and it has only gotten worse. If we don’t stand up to them now, as a successful company and leader in the market, who will?”
What this change means for AWS and any other cloud provider to offer Elasticsearch services is, that they would need to license under the SSPL and agree to publicly release any modifications as well as the source code of their management layers.
However, AWS have other plans. They responded to this announcement with plans to create and maintain an Apache 2.0 licensed fork of the Elastic products. Their fork will be based on the latest Apache licensed codebases: version 7.10.
Following in MongoDB’s Footsteps
MongoDB, an American software company, drafted the SSPL. They made the change from open source to proprietary back in 2018 when they changed their database license from the AGPLv3 to the SSPL.
With this change, MongoDB was addressing the same issue as Elastic. The change was made to stop cloud providers from using their code, as a basis for a service version of the database, without collaborating with MongoDB.
MongoDB’s license FAQ states:
“The reality is that once an open source project becomes interesting, it is too easy for large cloud vendors to capture all the value but contribute nothing back to the community…This change is also designed to make sure that companies who do run a publicly available MongoDB service… are giving back to the community”.
However, a difference between Elastic and MongoDB is the transparency MongoDB adopted in their license change. MongoDB’s CEO, Dev Ittycheria, stunned the community in a statement in which he said:
“[W]e didn’t open source it [their database] to get help from the community, to make the product better. We open sourced as a freemium strategy; to drive adoption”
Under the freemium business model, a company provides basic services/features for free for the user to try whilst also offering additional features at a premium, usually paid for, level. By offering the database at a basic level for free under the open source AGPLv3 license, MongoDB sought to build relationships with customers, eventually offering the premium features for an extra cost.
MongoDB’s reasoning for open sourcing their database was unlike many other open source organisations. They didn’t want anything back from the community. Their software innovation generally came from within its core engineering team rather than external contributions.
Since their license change, MongoDB openly refers to themselves as a source available organisation and are explicit to the fact they are no longer open source. Whereas, Elastic has not been so explicit with their continued use of the terms ‘free’ and ‘open’.
Commercialisation of Open Source Software
The commercialisation of open source has accelerated since Red Hat launched its paid support services model over 20 years ago. Since then, the open source community has explored various ways to monetise its products.
A bi-product of this acceleration was the launch of Commercial Open Source Software (‘COSS’) companies. COSS is a category of companies/business’ that commercialises open source technology.
There are various ways open source software companies have successfully approached the commercialisation of their products. These approaches can generally be grouped into five categories:
- Support Services
- Hosting
- Restrictive Licensing
- Open Core
- Hybrid Licensing
In the past 10 years, the most successful and frequently used approach is the Open Core model. Under this model, an open source project is the foundation (or ‘core’) from which the commercial product is built and licensed under a proprietary license.
Elasticsearch and MongoDB are open source projects which were commercialised under the open core model. Therefore, making Elastic and MongoDB both COSS companies.
When using the open core model, the hard task for COSS companies is striking the right balance between the open source ‘core’ and the proprietary code base. Under the open core model generally, the majority of the code base is open source.
Striking the right balance is important as this doesn’t change the nature of the software, it keeps it true to open source and supports the developer community whilst also increasing the sustainability and longevity of the COSS company.
Source Available Licenses
So, what exactly is a source available license? Source available licenses are a type of proprietary license that allows for source code to be viewed and in some cases modified and redistributed. However, they often fall short of meeting all the requirements of the Open Source Initiative’s open source definition.
The Commons Clause is another example of a source available license. Created by FOSSA, as an addendum to an open source software license, the Commons Clause prohibits commercial use of the software. Under the combined license the software is shifted to the source available model.
Redis Labs also made a licensing change to source available in 2018 by shifting some Redis Modules from the AGPL to a combination of Apache 2.0 and the Commons Clause.
In 2019 Cockroach Labs, announced that it was changing CockroachDB’s license from the open source Apache 2.0 license to a source available license; the Business Source License. This license is free to use but forbids users from offering a commercial version of CockroachDB as a service without buying a license.
Another example is the GitLab Enterprise Edition License (EE License). This license is exclusively used by GitLab’s commercial offering. They also offer a community edition of the software under the MIT license. The EE License makes their Enterprise Edition product proprietary, however, they make the source code of the enterprise edition public and allow users to modify the source code.
The ‘Fauxpen’ License
Elastic’s SSPL FAQ states the license is based on the GPLv3 and ‘is considered’ a copyleft license. However, copyleft licenses are a type of open source license and the SSPL has not been approved by the Open Source Initiative (OSI).
The OSI is a public organisation that is committed to defining, educating and raising awareness around open source software. MongoDB made several modifications in an attempt to get the SSPL license OSI approved. Eventually, they withdrew the SSPL when it became clear approval would not be obtained.
Elastic has also continued to use language such as “free” and “open” when referring to the license. As a result, they have been subjected to criticism. The OSI has branded the SSPL a “fauxpen” license.
The OSI say the ‘hallmark’ of these fauxpen licenses is that they allow a user to view the source code but do not allow other highly important rights protected by the open source definition. The OSI has declared that the SSPL violates OSD6, the right to make use of the program for any field of endeavour, as the license restricts Cloud providers from offering the software as a service.
Another commentator has said:
“Problems arise when non-standard open source licenses advertise that they are “based on” well known OSI approved licenses, which can lead to the assumption by developers that they use the same rules”.
Contention in the Software Commons
The fairness of the open source model has been a topical subject since MongoDB switched to the SSPL back in 2018. Now the debate is heating up following Elastic’s move to the source available model earlier this year.
Commercial open source companies have voiced their concerns and frustrations because cloud providers use their software as a basis for a service, free of charge, they profit fruitfully and do not contribute back to the community.
In response to AWS’s Elasticsearch Service, a commentator wrote:
“To be clear, this [AWS’s use of Elasticsearch] is not illegal. But we think it is wrong, and not conducive to sustainable open-source communities.”
Heather Meeker, a lawyer involved with drafting the SSPL, has said:
“With the rise of the cloud provider, a dynamic developed in which commercial open source companies became, effectively, off-balance sheet R&D shops for large cloud providers.”
On the other hand, external developers who contribute to open source projects equally feel frustration following licensing changes like Elastics.
The OSI issued a statement to clarify that the SSPL is not an open source license. The statement highlighted that when open source companies move to a proprietary model it has adverse effects on the software commons.
This is because external developers have donated their time and energy into open source projects, like Elasticsearch, with the understanding that their work was going towards the greater good, the public software commons. Instead, their contributions are now embedded in a proprietary product. Consequently, for developers to enjoy the ‘fruits of their labour’ they have to agree to the terms of a proprietary license or fork the software.
What Does This Mean for the Future of Open Source Licenses?
This is certainly not the end of the open source era. Although, one commentator, has said that we may see is an increase in the use of source available licenses. Particularly that,
“We will see projects starting as open source which will later transition into source available licenses when threatened by more operationally mature competitors.”
Heather Meeker has said:
“The industry is beginning to recognise the need for a paradigm that is fair to both users and developers and allows commercial developers to set a balance between the two, in a way that is more flexible than the open source model.”
Or perhaps, put simply by the OSI, these license changes we are seeing reflect the fact these software organisations’ business models are inconsistent with what open source licenses are designed to do. That in fact “their business desires are what proprietary licenses are designed for”.
Elasticsearch is a frequently used component and if it is being used as part of your service this licensing change will have affected your organisation and will require action. This highlights the need to consistently monitor what is in your software.
Source Code Control can provide a conformance review using Software Composition Analysis. This tool helps organisations build an inventory of Open Source Software components, libraries and frameworks that developers use to build an application. This analysis can also expressly identify each license and the copyright information in your software. As well as identifying security vulnerability information and operational information.
To find out more information contact us at [email protected]