Elastic has stretched the patience of many in open source - but is there room for a third way?
Elastic's move to proprietary licensing for cloud providers has reignited the argument about what's fair when it comes to monetising open source software
Elastic's licensing changes have reignited the debate about monetising open source in the age of cloud. Is the move the sign of a failed business model, or is a licensing third way inevitable and even necessary? We take the pulse of the industry.
In 2018, a minor earthquake rattled the flourishing world of open source software, as Redis Labs, MongoDB and Confluent separately announced changes in the way their core software would be licensed. These changes, they said, were to prevent predatory cloud services providers from co-opting their products and reselling them as a service, as they saw it making money from other people's graft without putting enough back. In a nutshell, under the new terms it was still fine to use the core products, but cloud providers seeking to monetise them would have to pay.
For a time it seemed that the aftershocks could open up a major rift, but when MongoDB failed to achieve open source certification from the Open Source Initiative (OSI) for its new Server Side Public License (SSPL) licence, the dust seemed to settle. MongoDB, Redis Labs and Confluent all continued to grow while competing cloud services by the likes of AWS were also prospering. Not everyone was happy, exactly, but the energy had been taken out of the rebellion.
Until last month that is, when Elastic announced in a blog post entitled Doubling down on open: "We are moving our Apache 2.0-licensed source code in Elasticsearch and Kibana to be dual licensed under Server Side Public License (SSPL) and the Elastic License", it said, adding:
"With the shift to SaaS as a delivery model, some cloud service providers have taken advantage of open source products by providing them as a service, without contributing back. This diverts funds that would have been reinvested into the product and hurts users and the community."
Elastic snaps
Elasticsearch and Kibana are widely used by many enterprises both individually and as part of the ELK stack. They are also offered as managed cloud services by Elastic and third party providers. All parties seemed to be doing well out of this arrangement (Elastic revenues grew 43 per cent in the most recent quarter, driven substantially by the Elastic Cloud managed service) and to many the timing of Elastic's move was curious.
We made the change to protect our brand and products because we felt that Amazon's behaviour was unacceptable - Steve Kearns, Elastic
Steve Kearns, VP product management at Elastic told Computing the motivation was righting a wrong, rather than a business strategy. "We're proud of our success - or the legal use of our Apache 2.0 code. We made the change to protect our brand and products because we felt that Amazon's behaviour was unacceptable, including misuse of our trademarks and false claims of a partnership to launch and promote their service."
The company continues to have "strong partnerships and commercial relationships" with other cloud providers, Kearns insisted, adding that "none of these relationships are impacted by the licence changes". Elastic Cloud will remain in the AWS Marketplace and Elastic will continue to invest in that relationship, he said, as well as with other smaller CSPs.
Commercialising open source has never been easy and, whatever its rights and wrongs, the Elastic case has reopened the debate about what is 'fair' in open source when it comes to monetising a community's combined efforts. Cloud has significantly broadened the reach of open source projects, but the power of the big cloud provider gives them an outsized say.
Open source software has always existed on a licensing spectrum from the restrictive (e.g. GPL where any software based on a GPL component must itself be released under an open source licence), to the permissive (e.g MIT with few restrictions on how the code can be used). Over recent years permissive licences have become more popular as enterprise open source software has become ubiquitous with developers accustomed to mix and match libraries ‘off the shelf'. The move by Elastic and others represents something of a reversal, and some fear it will be detrimental for open source software as a whole.
Let's be really clear - it's a move from open to proprietary as a consequence of a failed business model decision - Amanda Brock, OpenUK
"Permissive licensing is a kind of open source licensing. That's not what we are seeing here," said Amanda Brock, CEO of OpenUK, a not-for-profit which advocates for open technology. "Let's be really clear - its' a move from open to proprietary as a consequence of a failed business model decision.
"Elastic should have thought their revenue model through up front. By the time the team made the decision to open source their code, the platform economy existed and their decisions to open source ought to have been aligned to an appropriate business model."
Brock added. "We have to remember open source is a licensing model and a social movement not a business plan."
Tomer Levy, CEO of cloud observability platform vendor Logz.io which offers services based on Elasticsearch and Kibana, is taking direct action. In response to Elastic's move, Logz.io together with MSP Aiven and - rather significantly - AWS, Logz.io has just forked the software to create a new Apache-2-licensed open source product.
Did Levy have any sympathy for Elastic, given that it's hard to compete with the might of the hyperscalers?
"Of course I have sympathy for them and I think they have made an enormous contribution to the open source community and a lot of companies have built successful products the top of a Elasticsearch. I do understand their fear of [cloud providers]."
"But that's where my sympathy ends. I think it's a very disappointing step that they took. I think there's the wrong way to fight or to compete in the market."
The right way, Levy suggests, would be for Elastic to focus on its areas of expertise: "They're the domain experts in search and they could just build better products. Assume someone's going to take this open source code and deliver it in multiple ways. Make sure you have a better product and a better service."
For Elastic, Kearns said that the fork had been anticipated and that Elastic would indeed be pursuing its own path: "It's important to note that Elasticsearch and Kibana are already quite differentiated from what the fork will provide," he said, listing a raft of features he claimed "Amazon's fork" won't provide.
Balkanisation threat
It's notable that all the projects that have so far opted to relicense in this way are controlled by single companies. Generally these firms are backed by venture capital, and VC inevitably looks for exit options. This has always created a certain ideological tension.
Open source success should ultimately be based on expanding the community, Levy maintains, saying he'd locked horns with Elastic on the community issue too.
"We've tried to contribute multiple times, and it's really impossible. Eventually they had this CLA [contributor licence agreement] that you had to sign, you literally had to study all these documents. I think this product was really led by one commercial company and it became a marketing tool for them."
The fork will be community effort, he insisted. "It's not an AWS project or a Logz.io project. There's a group around it, not a single entity."
In addition to the disruption caused by Elastic's decision - Elasticsearch being a major pillar of his business - Levy fears a Balkanisation of open source with an increasing amount of proprietary in the mix.
If Elastic do it, other companies will say, 'Oh, they did it and they got away with it' - Tomer Levy, Logz.io
"Elastic is really a kind of poster child of open source. If they do it, other companies will say, 'Oh, they did it and they got away with it, I will do it as well', and this can really change the industry completely."
Elastic is perfectly within its rights to make these changes, Brock said. But it goes against the spirit of openness.
"My criticism isn't so much the move as the blog post title Doubling down on open which, at least to me, implies that company is being even more open.
"SSPL is proprietary, that's simply what it is. Code is either open source or it is not. If it's not under an OSI approved licence and compliant with the Open Source Definition, despite having publicly available source code, it is not open source."
This matters because developers need to trust that the code they are using isn't going to be subject to ad hoc licensing changes. Will this code still be usable in 12 months time? Will the company that wrote it be acquired with the possibility of legal action against those using the code for free, perhaps for many years (see SCO Linux)? Foundations like Apache exist to prevent this sort of abuse: keeping the trademark with the Foundation prevents creative interpretation of licensing terms.
Matt Yonkovit, head of open source strategy at database consultancy Percona, is another who fears what such moves could mean for the ethos of open source.
"The latest licensing change from Elastic highlights the difference in motive for many in the open source space. There are companies who truly believe in the power of being open, and there are others who join the game because they spot a business opportunity. Whilst the latter may start out as open, eventually shareholders take over and the business opts for the route that generates the most revenue," Yonkovit said.
Why would I contribute to MongoDB or Elastic when my work is just going to be packaged up and sold on? - Mat Yonkovit, Percona
"This issue isn't just about users having to pay to access the software, it has a knock-on effect for innovation as a whole. As a developer, why would I contribute to MongoDB or Elastic when my work is just going to be packaged up and sold on for their benefit? Instead, I'll invest my time contributing to true open source projects like Kubernetes or Linux, where it's a level playing field and everyone contributing benefits."
Yonkovit concluded: "Ultimately, SSPL breaks the link between a project and the community's ability to contribute, which kills innovation."
Dries Buytaert is CEO of Acquia, a company formed with VC funding to monetise his creation Drupal, which itself remains very much a community-based project. Unsurprisingly his response, when asked about the issue prior to the Elastic decision, was nuanced.
"It's complex. I get it there's a lack of fairness in a way, they do 90 per cent of the work and then others come around that didn't build the software and they get the benefit. I guess that's unfair. At the same time, these are healthy companies, you know, some of the fastest growing technology companies, and they benefit from other open source projects that they use."
Buytaert pointed out that Elasticsearch itself is built on the Apache Lucene search project.
A third way
But of course not everyone sees it this way, citing again the disproportionate power and reach of the hyperscalers. Asked for comment, MongoDB directed us to a series of tweets from CEO Dev Ittycheria.
"In 2018, we introduced a new, groundbreaking OS license called SSPL because we believed it was critical for the software industry to have a thriving open source ecosystem.
Cloud providers would take the software, offer it as a service and create enormous value while giving nothing back to the community - Dev Ittycheria, MongoDB
"We observed an unfortunate trend, where once an open source project became popular, cloud providers would take the software, offer it as a service and create enormous value while giving nothing back to the community.
"We did not think this was fair and worried that if companies believed they could not build a viable business as an OS company they would abandon OS, materially harming the ecosystem.
"There was some pushback on our decision, speculation that people would stop using MongoDB due to this change, that our business would be in trouble. 2 years later, our software was downloaded over 55M times last year - more than in the first 10 years of the company's history.
"I'm pleased to see @elastic announce today that their OS software will be using the SSPL source-available license going forward, for the same reasons we did in 2018."
We also asked Confluent and Redis for comment but they had not responded at time of publication.
Elastic themselves pointed to the Fair-Code project, which they said has listed SSPL.
They are the efforts of developers to financially benefit from code they've written, and there's nothing wrong with that - Matt Assay
More sympathy for Elastic's position arrived from a perhaps unexpected source. Matt Assay, principal at Elastic's bête noire AWS, believes it's time to revisit the idea of "shared source", a licensing scheme originally dreamed up by Microsoft two decades ago as an answer to the then-novel open source concept. In shared source, code is open - as in visible - but its uses are restricted. To be clear, he's not advocating Microsoft's licence in itself, but rather the general idea.
"I don't think we should normalise such licences as ‘open source' because they're not," he wrote in an article for Infoworld, qualifying his perspective as that of open source practitioner rather than an AWS employee.
"But we also shouldn't demonise them. They are the efforts of developers to financially benefit from code they've written, and there's nothing wrong with that."
In Assay's suggested third way, "SSPL becomes ‘shared source, but not with cloud providers."
"The heart of the problem is about who gets to profit from open source software. To help resolve that problem, we just might need new licensing," he concluded.