Shots fired in disputes over OSS-as-a-Service

Cloud services are the great disruptor of both IT organizations and vendors, and wrapping open source software around a service is the latest flashpoint.

The open source development model has proven to be an incredible incubator of innovative software by democratizing and distributing the conception, design, implementation and debugging of new titles, advantages that were thoroughly explored more than two decades ago in the book, The Cathedral and the Bazaar.

Although open source has since been adopted, encouraged and sponsored by every major software company, its origins were decidedly non-commercial with utopian overtones of liberating code from the tyranny of proprietary shackles. The earliest open source projects, notably Gnu Emacs and other tools from the Gnu Project, embraced this idealistic ethos with a restrictive, comprehensive license, GPL, that applies to derivative work using the code. 

Such copyleft licenses ran head-on into organizations seeking to commercialize, improve and distribute open source software, leading some projects to adopt more permissive terms such as the Apache or MIT licenses. Permissive licenses provided the flexibility needed to spawn a thriving ecosystem in which the creators of an open source project support and commercialize their work by selling a premium product with added features and on-call support. This two-tiered system mostly satisfied developers investing their time for the good of the community and investors providing the resources to expand and polish a product that otherwise might not be suitable for enterprise use. The cloud-ification of open source software into a rentable service has upset this delicate balance by jeopardizing the income of the commercial open source companies.

AWS takes most of the fire

As the oldest and largest cloud provider, AWS is often a trend-setter and was undoubtedly the leader in wrapping open source applications as a service. It wasn't long before developers were accusing AWS of open source exploitation: reaping the benefits of community-developed software, while not contributing enough back to the project ecosystem. The initial choices for AWS open source-based services, Elasticsearch and MongoDB, only complicated matters since these had already been commercialized by their founding developers and grown into viable software businesses. By bundling these applications into a supported, scalable usage-based service, AWS was accused of cannibalizing the business of those that created and largely sustained the software. Elastic led the backlash, accusing AWS of exploiting open source licenses crafted for installable software, not rentable services, to the detriment of companies that built support services and value-added products around open source code. 

A report last fall by the US House Subcommittee on Antitrust, Commercial and Administrative Law of the Committee on the Judiciary entitled Investigation of Competition in Digital Markets Majority Staff Report and Recommendations provides the best summary of the issues. While the entire discussion is worth reading, here are the highlights (pp. 326-327) (emphasis added):

As cloud computing grew in popularity, open-source software vendors began offering versions of their software on the AWS Marketplace, where application developers could easily integrate the software. Market participants explain that AWS was able to use the data collected on their customers, including usage metrics, to learn which third-party software was performing well and ultimately to create their own proprietary version offered as a managed service. Creating a “knock-off” version of software was particularly easy when the product was using an open source license, which provides more visibility to the underlying code.

"In interviews with Subcommittee staff, market participants repeatedly said that AWS relied on innovations from open-source software communities to gain dominance. A venture capitalist told Subcommittee staff that 'open-source is critical for AWS getting market power. They’re standing on the shoulders of giants and they’re not paying the giants.' 

AWS counters freeloader claims with examples of additions it has made to various products. Developers on those projects dispute the significance by noting that AWS's contributions are typically meant to improve the integration with the AWS management console or its other services, not general-purpose improvements to the underlying software. The House report zeros in on the controversy created by AWS Elasticsearch:

An example frequently cited by market participants is Amazon Elasticsearch Service (AESS), a tool for searching and analyzing data, and a first-party product listed on the AWS Management Console...According to public reporting, within a year of introducing the product, Amazon was generating more money from its replica of Elasticsearch than Elasticsearch itself was generating. One key advantage that Amazon’s 'knock-off' had was that Amazon had given it superior placement in AWS  Management Console. Additionally, as described in the Elasticsearch vs Amazon case, AWS can name their open-source 'knock-off' products in a way that can mislead customers into believing that the 'knock-off' product is sponsored by the open-source software vendor.

Ironically, Elastic initially welcomed the cloud by making the software available via the AWS Marketplace, but once AWS turned Elasticsearch into a service, the company began emphasizing differences between their two products. As the House report says, the nearly identical naming makes the OSS project, AWS service and commercial product hard for customers to distinguish:

The Subcommittee’s investigation uncovered evidence relating to numerous instances in which Amazon has offered proprietary managed services based on knock-offs of open-source code. One open-source market participant interviewed by Subcommittee staff said that because of this conduct, the benefits of open source 'weren’t accruing to [the] open-source community. People were feeling, we develop all this work and then some large company comes and monetizes that.' MongoDB, a document-based database, has similarly commented 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.' 

The final quote from a MongoDB spokesperson highlights the issue which ultimately led Elastic to change its licensing terms last week.

Latest salvo - new legalese

Last week, Elastic announced a change to a bifurcated license structure, with an Apache 2.0-derivative Elastic license for developers and enterprise customers and Service Side Public License (SSPL) for cloud service providers. As Elastic describes it (emphsis added):

SSPL is a source-available license created by MongoDB to embody the principles of open source while providing protection against public cloud providers offering open source products as a service without contributing back. The SSPL allows free and unrestricted use and modification, with the simple requirement that if you provide the product as a service to others, you must also publicly release any modifications as well as the source code of your management layers under SSPL.

However, the Open Source Initiative roundly criticizes SSPL calling it "fauxpen source," writing (emphasis added):

The hallmark of a fauxpen source license is that those who made the switch claim that their product continues to remain “open” under the new license, but the new license actually has taken away user rights. The license du jour is the Server Side Public License. This license was submitted to the Open Source Initiative for approval but later withdrawn by the license steward when it became clear that the license would not be approved.

AWS responded with an open source version of the nuclear option, a fork, writing,

In order to ensure open source versions of both packages remain available and well supported, including in our own offerings, we are announcing today that AWS will step up to create and maintain a ALv2-licensed fork of open source Elasticsearch and Kibana.

AWS knew such licensing blowback was a possibility and was prepared, "When AWS decides to offer a service based on an open source project, we ensure that we are equipped and prepared to maintain it ourselves if necessary." It takes a final shot at Elastic that illustrates the irreconcilable differences between a company built to profit from an enhanced version of an open source project and a cloud provider selling a managed service based on the same core code (emphasis added):

Elastic knows what they’re doing is fishy. The community has told them this (e.g., see Brasseur, Quinn, DeVault, and Jacob). It’s also why they felt the need to write an additional blustery blog (on top of their initial license change blog) to try to explain their actions as 'AWS made us do it.' Most folks aren’t fooled. We didn’t make them do anything. They believe that restricting their license will lock others out of offering managed Elasticsearch services, which will let Elastic build a bigger business. Elastic has a right to change their license, but they should also step up and own their own decision.

My take

In turning open source projects into a cloud service, we see AWS abiding by the letter of open source licenses, but abusing its communitarian spirit. Indeed, it's another example of AWS executing the sharp-elbowed competitive playbook that made parent Amazon a retail giant. For example, Amazon uses shopping data to identify hot third-party products and categories only to swoop in and undercut competitors with Amazon-branded copies. As the House report details, AWS uses similar usage metrics to identify opportunities for new services by identifying software products customers frequently install from its Marketplace onto EC2 instances. It's a classic example of Amazon's customer focus since the services relieve AWS users from the overhead of installing, optimizing and updating a complicated piece of software.

The conflict arises because most of these open source applications have already been commercialized by the originators and primary contributors to the projects. These developers and their VC investors argue that they are entitled to reap the benefits of the unpaid hard work they sewed in creating the initial project and maturing it to the point of viability on production systems. Unfortunately for them, their business model is built on an assumption that is no longer true: that enterprises will primarily purchase and operate installed software on owned and self-managed hardware. The broad availability and adoption of rentable cloud services sidesteps this model and turns the 'good enough' but still hard-to-manage open source versions of these projects into a preferable alternative to purchased commercial products.

There is no reconciling the competitive conflict between a company like Elastic and AWS, and AWS doesn't appear to be violating the licenses of open source projects it service-izes (Trademark disputes are another matter). However, the company could earn itself goodwill with the developer community by acknowledging their contributions and only using forks as a last resort. AWS should throw developers like this a bone by working with them (perhaps even hiring them), not ignoring their hard work while simultaneously profiting from it.