In February 2021, Elastic released its software offerings under a new license, the Elastic License 2.0. With this move, a significant suite of software, including Elasticsearch and Kibana, was changed to a new, open and streamlined license model. How and why did this come about, and what does it mean?
Elastic's new license is the culmination of a strong trend in licensing best practices for companies with open development models. It is not an open source license, but it aims to set the minimum limitations necessary to strike a fair balance between freedom to use, share and change the software, and preventing actions that will harm the community.
UNIX, Linux, Free Software, and Open Source
To understand the new trend in licensing represented by Elastic License 2.0, it helps to understand how it grew out of the open source licensing movement.
The open source or free software movement sprung from concerns by developers over the privatization and forking of software. The spark for these concerns was UNIX, the most popular operating system of its day. For years, UNIX was licensed under very generous terms, because its developer, AT&T Bell Labs, was prohibited by law from profiting from its research projects, which included UNIX and the C language, under a 1956 consent decree.1 Academics, researchers and developers began sharing their changes and improvements, and UNIX soon became a leader in operating system functionality. Once the consent decree was lifted in 1983, AT&T began licensing it under conventional commercial terms, which did not allow sharing of changes. UNIX splintered into many incompatible "flavors," and its licensees were no longer able to collaborate.
The free software movement, and the open source movement that followed, arose in reaction to this privatization of UNIX, and sought to prevent the closing of infrastructure software from ever happening again. While the movement centered on Linux, the free software alternative to UNIX, it soon developed into a larger movement based on the philosophy that all software should be free – free as in free speech, if not as in free beer. Some of the pillars for this movement were access to source code, and the right to make and share improvements and changes. These principles were embodied in the GNU General Public License (GPL), which requires distributors of binaries to share the corresponding source code.
Over time, and with the help of the internet boom and bust of the early 2000s, open source licensing became ever more popular. And while some of its licenses, like the GPL, were novel and complex, and caused some consternation over legal concerns, they paved the way for businesses to collaborate. Over the period after 2000, open source – and the collaboration it enabled – was accepted wholeheartedly by the entire technology sector. Today, open source is the backbone of e-commerce, and businesses regularly collaborate on software infrastructure.
The Break in the Clouds and AGPL
Licenses like GPL require the sharing of changes. But they impose source code sharing conditions only with distribution of binaries. They allow making and using of "private copies" with no requirement to share changes. This worked well to compel sharing, in the days when most software was distributed on-premises. But beginning in the early 2000s, software began its move to the public clouds. It was no longer necessary to distribute any software -- customers could use the software without getting a local copy of it.
As cloud services became big business, this shift in paradigm created a tension between the expectations of the open source community and businesses like Amazon Web Services (AWS). Cloud services providers did not have any legal compulsion to share their improvements. Ironically, this was sometimes called the "Google Loophole," because of Google's well-known reliance on Linux to power its search service. It was ironic because Google – and many of the other top cloud providers such as IBM – already contributed heavily to the open source community, and Linux in particular. The free software community reacted to this, in part, by creating an alternative form of GPL called Affero GPL (AGPL). AGPL 3.0 is nearly identical to GPL 3.0, but with a Remote Network Interaction clause that says: "[I]f you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network … an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software…." This new license was intended to compel cloud services providers to share their source code improvements, just as GPL had done, so successfully, for Linux distros.
AGPL and Dual Licensing
AGPL was controversial from its first release. During the GPL 3.0 drafting process, culminating in that license being released in 2007, one faction wanted to change GPL to a network copyleft model. Instead, the community decided to keep the "loophole" in GPL 3.0, and several months later, released AGPL as an alternative to close it. But AGPL was not widely adopted. Moreover, the unchallenged "killer app" for the license was MongoDB, an extremely popular distributed database product. Although AGPL was difficult for private companies to understand and accept at first, most users never changed nor offered the software as a service, so they were able to make a reasoned determination to use the software under AGPL.
MongoDB used AGPL as one path of a "dual licensing" business model, in which the software was available under the licensee's choice of two licenses: AGPL or a negotiated commercial software license. Those who did not wish to comply with the requirements of AGPL – or did not wish to engage in the legal analysis to figure out whether they could comply – chose the commercial license path. This business model had been pioneered by MySQL, using a variant of GPL. But as time progressed, AGPL became the license of choice for dual licensing. MongoDB was quite successful with this licensing model. AGPL worked for dual licensing because it was the strongest copyleft license in common use, and therefore most useful to drive commercial negotiations. But the drafters of AGPL criticized this use of the license, calling the business model a toxic shakedown. Still, the license's source code sharing conditions were not enough to discourage commercial use on a massive scale in a way that gave nothing back to the developer or user community.
Strip-mining
Much as the move to the clouds had "broken" the GPL model, as the 2010s progressed, advances in cloud computing began to put pressure on the AGPL dual licensing model. This time the problem was different: the scope of GPL, or AGPL, only extended as far as one single program executable. This "feature" was purposely designed into GPL, on the theory that a copyright license could dictate the terms for a single copyrightable work only. GPL therefore has source code sharing requirements for derivative works, but not collective works. The line between these two under the law is so unclear as to be in the mind of the beholder, but as GPL had gained popularity, strong industry practice had grown up around defining a single program as one executable process. The Free Software Foundation had long enunciated these principles in its FAQ on the GPL.
However, as cloud services advanced, two things happened. First, software engineering became more focused on cloud deployment. Whereas cloud providers once had to improve or adapt the software to run it in a cloud environment, advances in software engineering made existing open source software more "plug and play" for cloud providers. Then, cloud providers began to innovate outside the main executable. They developed additional software to manage, monitor and deploy software, and these innovations drove business to cloud services. Even AGPL did nothing to compel sharing these improvements.
So, a dynamic developed in which commercial open source companies became, effectively, off-balance sheet R&D shops for large cloud providers. The problem was particularly stark for "platform software" or middleware – software that sits below the top layer application and above the operating system, in the computing stack. This category of software is essential to modern computing, and very useful for cloud deployment.
At this point, an outcry against use of open source software by cloud providers was raised in the business world. In a watershed manifesto in 2018, Salil Deshpande of Bain Capital wrote, "To be clear, this is not illegal. But we think it is wrong, and not conducive to sustainable open-source communities." Another commentator wrote, "AWS is striking at the Achilles' heel of open source: lifting the work of others, and renting access to it." The problem was that using software in this way was allowed by all the major open source licenses.
Commercial open source companies, and their investors, were chafing under the limits of what the open source model could do. No license at their disposal – not GPL, not AGPL – could use the copyright law to compel the cloud providers to share. Moreover, cloud providers with huge customer bases had "sticky" relationships – software could be added at the touch of a virtual button on platforms like AWS, Azure, or Google Cloud. Some developers offered their own cloud services, but found it too difficult to compete with the large providers who were using their software for free. Even when the developer's services were better, there were transaction costs to engaging a new service provider, as opposed to just "checking the box" to add a software suite to their existing cloud account.
The SSPL and Source Available Licensing
In 2018, the industry reached a breakpoint. As AWS continued to gain popularity hosting open source platform software, the developers began to take action. What happened next was a quick domino effect of license changes.
Companies reacted to the strip-mining problem by going down two different roads: an ultra-strong network copyleft license, and a limited source available code license. Neither of these categories were well defined prior to that time. Both were intended to support a dual licensing model, like those that had helped build MySQL and MongoDB.
The ultra-strong copyleft approach was championed by MongoDB, which released its Server Side Public License or SSPL in 2018. The SSPL was almost identical to AGPL, but expanded the scope of AGPL's Remote Network Interaction to say:
13. Offering the Program as a Service.
If you make the functionality of the Program or a modified version available to third parties as a service, you must make the Service Source Code available via network download to everyone at no charge, under the terms of this License. Making the functionality of the Program or modified version available to third parties as a service includes, without limitation, enabling third parties to interact with the functionality of the Program or modified version remotely through a computer network, offering a service the value of which entirely or primarily derives from the value of the Program or modified version, or offering a service that accomplishes for users the primary purpose of the Program or modified version.
"Service Source Code" means the Corresponding Source for the Program or the modified version, and the Corresponding Source for all programs that you use to make the Program or modified version available as a service, including, without limitation, management software, user interfaces, application program interfaces, automation software, monitoring software, backup software, storage software and hosting software, all such that a user could run an instance of the service using the Service Source Code you make available. [emphasis added].
This license was written to craft an open source solution to the strip-mining problem. Its source code sharing requirements are much broader than those of AGPL. The breadth of these requirements was designed to work similarly to the requirements of GPL for distributed software. MongoDB continued under a dual licensing model, with its software available under SSPL or negotiated commercial terms.
MongoDB submitted SSPL for approval to the Open Source Initiative (OSI). After months of great controversy, the license was withdrawn from the approval process, but MongoDB continues to use the SSPL for the open source option of its dual licensing model. The discussion on why this license did or did not fit the open source definition was complex, but fitting the definition was not the only criterion, and in sum, it was unclear whether a license with this breadth of sharing requirements would "guarantee software freedom."
Others followed a different path. Some companies adopted the Commons Clause, which was spearheaded by Salil Deshpande, and others crafted their own licenses, such as Redis, Confluent, and CockroachDB – as well as Elastic, with its Elastic License 1.0 . Unlike SSPL, the licenses were never intended to meet the open source definition. Instead, they had a limitation specifically aimed at the strip-mining use.
Why are these separate paths? It has to do with something called Freedom Zero: "The freedom to run the program as you wish, for any purpose." 2
The main characteristic of an open source or free software license is that it contains no license restrictions or limitations.3 Compare typical commercial software licenses. End user licenses like the ones you click-to-accept for personal use only allow you to use software, and not to change or distribute it. Enterprise licenses set limits on the number of users, or servers, or physical locations that can make use of the software, and require companies to audit their use. But open source licenses do not contain any such limitations. So, perhaps counterintuitively, limitations like non-commercial use are by definition not open source – even if the source code is provided free of charge.
That means that any license limitation takes a license outside the open source category.
All of the licenses that were released in the wave of relicensing that took place in 2018 and forward have roughly similar limitations. While each has its own terms, they all focus on allowing users to use the software free of charge, while prohibiting the use of the software to provide a competing hosted service.
The Elastic License 2.0
In early 2021, Elasticsearch blazed a trail by following both of these paths. It made its suite of software available under two free choices: the SSPL, and the new Elastic License 2.0 (ELv2).
The new Elastic 2.0 License is short (just over one page), written in plain language, and allows almost all of the freedoms of an open source license. Recipients of the software can use, change, and redistribute the software freely. Even if you have never read a software license before, it's worth reading.
It has two key limitations:
You may not provide the software to third parties as a hosted or managed service, where the service provides users with access to any substantial set of the features or functionality of the software.
You may not move, change, disable, or circumvent the license key functionality in the software, and you may not remove or obscure any functionality in the software that is protected by the license key.
The first limitation is focused on addressing the strip-mining problem. By including this limitation, the license does not authorize this behavior, and so using the software in violation of this limitation would infringe the rights in the software.
The second limitation is intended to prohibit hacking the software license key. Such limitations have long been common in software licenses, but their use in source available licenses is just beginning. These provisions allow developers to run paid services that interact with the software, or save some of the software components for paid features.
The other terms of the license are very straightforward, and should be familiar to anyone who has read an open source license.
Why Dual Licensing?
In offering users a choice between SSPL and the Elastic License, Elasticsearch took an unusual path. Today, many companies use an "open core" model, and indeed, Elasticsearch had previously used this model as well. The difference between the two can be subtle. Open core models offer core software under an open source license, most often a permissive license like Apache 2.0. They then offer additional features -- usually those useful to deploy across an enterprise at scale -- under limited licenses or only as a service. But with its new license, Elasticsearch stuck with a dual licensing model, where the same software is available under two different licenses. This model was pioneered by MySQL, and usually uses a copyleft license, like GPL, AGPL, or SSPL, as the free licensing choice. This model has waned in popularity in recent years, mainly due to the tension between open source licensing and cloud services.
Elastic's choice was even more unusual in that it offered the choice of two free-of-charge licenses: SSPL and Elastic License 2.0. Dual licensing usually offers only one free option. By making this unique choice, Elasticsearch has underscored its flexibility in making the software available free of charge to almost all users.
Elastic License 2.0 and the State of the Art in Licensing
Elasticsearch moved to its new licensing model in order to remain as open as possible, while preserving a sustainable business model that was fair to both users and developers. In doing so, it echoes the goals of other participants in the source-available movement, and its sought input from its peers in creating the license.
As outlined in its FAQ on the license change, Elastic's license change is expected to impact none of its customer base, and few community users. Most users build applications on top of Elastic's software, and are not in the business of "providing the software to third parties as a hosted or managed Service."
Making a Better License
In addition, by devoting the resources to draft the Elastic License 2.0, Elastic sought to advance the state of the art in license drafting. In a sense, source available licensing has been around as long as software. In fact, binary only licensing was a product of the PC/Mac platform standardization of the 1980s; before that time, almost all software was licensed in source code format. But the form and means of deployment of the licenses has changed greatly over time.
Elastic License 2.0 is the culmination of that trend. In form, it has adopted some of the most popular features of open source licensing: simple and intuitive drafting, and template licensing. Its license key preservation provision also easily enables vendors to use the license for software that has both free and paid features.
Like the fractured incompatible versions of proprietary UNIX decades ago, proprietary licensing is a crazy quilt of custom terms and conditions. Even a simple end user license for the average consumer software product is usually so long and arcane that it is inexplicable to most users. Jokes abound about no one reading them. But most of this complexity is unnecessary. This was one of the lessons of open source licensing, particularly permissive licenses: a simple set of rules of the road should be enough, and the more comprehensible they are, the more likely users can respect them.
The Elastic License 2.0 is not only short, simple, and comprehensible, it is also available for others to use as a template . Since the anti-strip-mining debate began, there has been a growing demand for simple, understandable licenses with reasonable restrictions, deployed in a frictionless manner. But most small software companies do not have the resources to draft their own agreements. So unsurprisingly, many software startups are looking to licenses like Elastic 2.0 and the Confluent Community License as models that they can adopt.
This category has become so popular now that one initiative, Fair Code, has created a standard for it. It says:
Fair-code is not a software license. It describes a software model where software:
- is generally free to use and can be distributed by anybody
- has its source code openly available
- can be extended by anybody in public and private communities
- is commercially restricted by its authors
While this initiative is in very early stages, it is clear that the industry is beginning to recognize 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. One commentator has gone so far as to call the recent developments in licensing the "after open source era." But in truth, source available licensing usually goes hand in hand with open source licensing, as business and licensing models continue to develop. So, the two models are complements rather than strict substitutes.
There are other standardized licensing options. In 2020, a group of lawyers started the PolyForm Project, to draft a suite of template source available licenses. These licenses were peer-reviewed by lawyers experienced in both open source and proprietary licensing. Like Creative Commons for open content licensing, it provides a menu of options such as non-commercial, evaluation only, and anti-competition licenses. All of them, like the Elastic License 2.0, are free of charge, provide access to source code, and grant the necessary patent licenses. PolyForm Perimeter and PolyForm Shield are similar to their progenitors like the Confluent Community License, and Elastic 2.0 has followed this trend, advancing the available options.
If you have questions or want to read more, here are some resources:
"The rise of open source IPOs" https://coss.media/rise-of-the-open-source-ipo/. This article tracks some of the spectacular business successes of open source companies.
"The After Open Source Era Has Started" https://monetize.substack.com/p/open-source-eras . This article discusses the sea change represented by companies moving to source available licenses.
US House of Representatives Committee on the Judiciary's report on investigation into competition in digital markets, spearheaded by the Subcommittee on Antitrust, Commercial and Administrative Law. https://www.documentcloud.org/documents/7222836-Investigation-of-Competition-in-Digital-Markets.html. Note the mention of Elasticsearch on page 326.
Note: The drafting of this white paper represents my personal views. However, I would like to note that the work to write it was funded in part by Elastic.
1 "Modification of Final Judgment," August 24, 1982, filed in case 82-0192, United States of America v. Western Electric Company, Incorporated, and American Telephone and Telegraph Company, U.S. District Court for the District of Columbia web.archive.org/web/20060827191354/members.cox.
2 The Free Software Definition is similar to the Open Source Definition, but shorter and clearer.
3 Open source licenses can contain conditions, such as notices or source code sharing. But these are not limitations that tell you what you cannot do with software, they only require that if you elect to do certain things, you also must do others.
Top comments (0)