WTF Is an Open-Source License Anyway?

For something that’s supposed to make software development frictionless, open-source licenses generate a remarkable amount of heat and noise.

It’s almost 25 years since the term open source took off, and there has always been highly charged debate about what does and doesn’t qualify as open source. But the last few years have been particularly fraught as a generation of software firms forged in the open-source era cried foul when, they claimed, cloud giants began to hijack “their” projects.

Andrew Katz, CEO of open-source compliance consultancy Orcro, and a partner at law firm Moorcrofts LLP, describes the current situation with some understatement: “It’s a little bit fractured at the moment. I think what has in the past been a consensus is starting to deteriorate to a degree. And I think it’s a great pity.”

It was MongoDB Inc that got the ball rolling back in 2018, with the launch of its Server Side Public License (SSPL) for the MongoDB NoSQL database, which had previously been covered by the AGPL. This came after MongoDB Inc’s concerns about AWS offering the database as a service – and about a year after MongoDB’s IPO. It argued 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.”

MongoDB Inc said the SSPL would remove confusion about offering MongoDB as a service, and was “also designed to make sure that companies who do run a publicly available MongoDB as a service, or any software subject to the SSPL, are giving back to the community.”

Redis Ltd made a similar move with its Redis Source Available License for Redis Modules it developed. Other developers in the Redis community were free to apply their choice of license to modules they create.

But it was Elastic NV that really picked up the ball and threw it right back into AWS’s face. In a blog in January 2021, founder and CEO Shay Banon accused AWS, with its Amazon Elasticsearch Service, of “doing things that we think are just NOT OK since 2015 and it has only gotten worse.”

Banon claimed AWS had used “code that we believe was copied by a third party from our commercial code and provided it as part of the Open Distro project.” He also claimed the firm had found other examples of “ethically challenged behaviour” by AWS, in the shape of proprietary features serving as “inspiration” for the web giant’s own offering.

The upshot was a dual-license approach for Elastic’s products, using a combination of the SPPL pioneered by MongoDB and its own Elastic License v2. The stated aim is to prevent companies “taking our Elasticsearch and Kibana products and providing them directly as a service without collaborating with us.”

A license to chill?

Needless to say, Banon insisted that for customers, “This change most likely has zero effect on you, our users. It has no effect on our customers that engage with us either in cloud or on premises. Its goal, hopefully, is pretty clear.”

What is also clear, is that these novel license types are not open source. When it was developing its license, MongoDB Inc approached the Open-Source Initiative, the guardian of the definition of open source, to establish whether the SSPL could be classed as an open-source license. But, as OSI executive director Stefano Maffulli tells us, “It took very low scanning for us to review it and say it’s not.”

More importantly, Maffulli says these new licenses “remove that frictionless innovation” that has been at the core of open source’s success.

“They require your legal team to review them carefully before they can say ‘yes, you can use them, or no you cannot use them’,” he says. “They force you to go through a gatekeeper. And that’s really against the spirit, the letter of open source.”

Quite apart from having to worry about spirits, this creates real day-to-day issues for developers and their employers, says Katz. “Fundamentally, people are concerned about the direction of travel,” he says. “If they’ve committed themselves to particular infrastructure software that’s subject to one of these licenses, what is that going to mean over the course of 12, 18, 24, 48 months. Does that mean the investment they’ve made on these various assumptions is going to be problematic for them?”

Relying on open source software is virtually a given for a technology-based startup. But as Jonathan Symonds, COO of event management platform Venueserve, says, licensing uncertainty compounds the issues around integrating open source code into a startup’s own product.

When it comes to “realizing the business,” he says: “I've got to make sure that the IP and the product is all actually owned by the business, not by someone else if I'm going to exit or if I'm going to go raise money as well.”

Beyond the purely business issues, says Katz, there are “perception” issues for organizations. “If they describe themselves as being an open-source company, and they start to use parts of frameworks, databases, whatever, that are not strictly open source, then that can be an internal perceptual problem for their own developers who may be uncomfortable about that.” And these perceptual problems may extend to customers and other users.

There is also the fear that a given cloud providers’ position could change dramatically in the future, says Katz. “What dynamics are there that will prevent that from changing in a way that could be detrimental to them in the future? The marketplace works best when you’ve got a number of competing players and that their interests balance each other.”

And while the key cloud providers do indeed compete fiercely, it’s hardly an open market. There is a clear power imbalance between the handful of major cloud providers – who are themselves major software factories in their own right – and the vast majority of open-source software vendors, never mind end users.

There’s a problem upstream

From Katz’ perspective, there are two main schools of thought on how to address the situation. “Either we need to make sure that people can’t hide their improvements to the software in the cloud and we’re going to fix that by means of a license. And, you know, AGPL was an attempt to do that, but it’s a fairly widely misunderstood license. Then you start to look at licenses like SSPL and sort of Commons Clause and so on.”

The alternative, he continues, is to resume looking at the dynamics behind the way the software is developed. “So how can we make the benefits that you get from upstreaming continue to apply?”

This is easier to do in a world where a plurality of medium-sized cloud providers competes with each other, wanting to use projects, but finding that maintaining a project is too much for any one of them without the support of the wider community.

“My concern is that we have a market with a very small number of very large cloud providers,” says Katz, “They can effectively fork the software and can continue to afford to maintain it internally, and the economics and the benefits of upstreaming no longer necessarily apply to them.”

This is just a hunch, he adds.

But could someone step in and bring the warring parties together? Perhaps. But it’s not going to be OSI, says Maffulli.

Not that OSI doesn’t understand the position that Elastic and co are in. “I have sympathy. Absolutely. I do,” says Maffulli. “This tension between businesses and community, and within businesses themselves, has always existed. It’s not a new thing.”

Companies like Elastic and MongoDB had clearly benefitted from open source, he says. Now they find themselves in a situation where “They have a business model and it’s in direct competition with a few giant corporations. It’s hard to compete at that level, on those grounds. So, it’s fair that they had to change the licensing.”

But, he continues, “It’s not an open-source problem. It’s a business problem.”

And who should adjudicate business problems? Ultimately, says Maffulli, it’s the market.

Forked over

When it comes to new licenses, Katz says, it’s a question of really setting expectations, right at the outset. If a new license isn’t strictly open source, he says, “Make sure that you do not in any way, shape or form suggest that it is open source. Try not to confuse the issue by using confusing terminology. And really be totally honest and upfront about why you’re doing it.”

The fundamental question is what will keep “the community” vibrant: “We just don’t know the answers. And I think it’s going to vary very much from project to project. It’s going to require a lot of stewardship (fairly tricky stewardship) and we’re not going to know until some of these ideas duke it out in the marketplace.”

So, what is the marketplace saying?

Well, none of the organizations in question wanted to speak to us directly for this piece. Redis is a private company so it’s difficult to gauge what effect its license initiatives have had. MongoDB has barely mentioned the SSPL in its public communications since 2019. In the Summer, Elastic said it was “happy to see the level of community support for this change.”

So, let’s trust that it’s all working out for them. After all, trust is central to the whole debate here.

And trust – or at least a mutual accommodation – can break out in the strangest of places. AWS, it seems, has been working hard to consolidate its open-source credentials.

In July, AWS’ Open Source Blog name-checked Redis saying, while the two organizations “continue to compete for Redis workloads, we also partner closely to serve our mutual customers.” The piece helpfully pointed readers to a Redis page for Redis Enterprise Cloud on AWS. 

In October, AWS’s Open Source Blog carried a post from MongoDB discussing “the ways MongoDB and Amazon’s search teams have collaborated on Lucene to tailor it for our own needs while simultaneously improving the project for all.”

“This is only the beginning of our partnership,” the blog authors promised.

As for Elastic, back in January AWS wrote “Elastic knows what they’re doing is fishy… 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.”

In June, after AWS had completed the fork and renamed its Elasticsearch service OpenSearch, Elastic wrote that “We’re happy to move past the confusion, knowing our users will no longer be misled or have a bad experience because the products are not the same.”

Not exactly burying the hatchet, but it has continued to work with other parts of the web services giant, becoming certified as an AWS ISV Workload Migration Program Partner as recently as November.

Elastic’s website still carries that blog in which Banon describes AWS as “ethically challenged”. This, presumably, is why Elastic chose Alibaba Cloud, the Chinese web giant, as its ecosystem partner of the year.