Elasticsearch and the SSPL

Recently, Elastic Co. made the decision to relicense its products, moving them from the Apache 2 license to the Server Side Public License. There is a lot of history and a lot of important context leading up to this change, and the change itself caused a huge stir online. Everyone, myself included, has thoughts on this change.

But first, a little bit of that history and context. There are a number of software shops out there that run on what is called an “Open Core” business model, in which some core piece of their product is available as Free and/or Open Source Software, but the company sells premium features as propriety addons. I could write a whole separate post about Open Core and the issues I have with it, but for the purpose of this discussion it only matters to establish the fact that these companies maintain some piece of software that is - or was - truly open source. Examples of Open Core companies include Elasticsearch, Redis Labs, MongoDB, and (formerly) Chef.

Eventually, the Open Core model became threatened by PaaS and IaaS providers such as Amazon Web Services and Microsoft Azure. Amazon, for example, took the open source version of Elasticsearch, and began offering it as a hosted service in AWS. This meant that companies already paying for AWS could spin up ES clusters in the same infrastructure, likely for little additional cost, rather than having to pay Elasic themselves for one of their own hosted offerings.

But hey, what about those premium features that Elastic sells? Features like …. basic authentication and encryption¹? Amazon solved that problem too. They began to provide their own implementations of Elastic’s premium features and provided them to AWS users for no additional cost. They even released their their own modified variant of ES, complete with these features, as an open source, Apache 2 Licensed distribution.

The sum total of these developments is that, thanks to Amazon, there was increasingly less and less reasons to pay Elastic for, well, anything. Similar things were happen to MongoDB and Redis, and eventually they all got fed up with it. These vendors all made the same argument - namely, that it was unfair that these vendors put tons of hard work into their products, only to have a megacorp like Amazon take them and use them to make crap loads of money - without paying anything back in return.

Thus began their attempts to find ways to lock Amazon and others out. For example, in 2018 Redis relicensed some of their addon plugins to use the Apache 2 License w/ Commons Clause. Later, in 2019, they relicensed again to the Redis Source Available license. Both licenses essentially say “you can do what you want with this code as long as you aren’t providing it as a service in a cloud, like those jerks at Amazon”. Neither of them are Open Source based on the definition established by the OSI, and the Commons Clause in particular was extremely vague about what would and wouldn’t constitute a violation. People were wary, but it didn’t stop Redis from pushing forward.

Around the same time, MongoDB relicensed their product under the Server Side Public License, another new license of their own creation.

The SSPL is a bit different from the Commons Clause. It doesn’t strictly prohibit use of the licensed software in any scenario. Rather, it states that if you provide the software to others as a service - like Amazon would - you have to provide the source code for any “supporting software” used to help host it. What constitutes “supporting software”? According to the text of the license itself, that would be:

… 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.

The SSPL is often described as the Gnu Affero Public License on steroids. It is a copyleft license that is so extreme, it asks you to open source code that you may not own, control, or have a copyright on. I say “may” because a lot of critics believe the license’s wording is too vague to be certain as to what software you would or would not have to open up. An argument could be made that providing Mongo as a service would force you to open source everything from your Operating System to the firmware in your BIOS. Some commenters wondered whether the license was even enforceable. This prompted responses from MongoDB developers who promised that this was not the intention of the license, and that you would only have to open up just enough of your tooling to make it your Mongo-as-a-service offering runnable on anyone’s dev box. However, as VM Brasseur puts (so eloquently) puts it:

There are those who will point to the FAQ for the SSPL and claim that the license isn’t interpreted in that way because the FAQ says so. Unfortunately, when you agree to a license you are agreeing to the text of that license document and not to a FAQ. If the text of that license document is ambiguous, then so are your rights and responsibilities under that license. Should your compliance to that license come before a judge, it’s their interpretation of those rights and responsibilities that will hold sway. This ambiguity puts your organisation at risk.

So that’s the crux of the SSPL. It doesn’t sound great from this angle. In the time since the switch, Mongo gave up on their attempts to have the SSPL certified as Open Source by the OSI, and both Red Hat and Debian removed MongoDB from their software repositories over its use of the license.

And yet, despite all of these developments, Elastic decided that this was still the best license to go forward with, and all the same arguments about Mongo are being dug up and thrown around regarding Elastic. The fact that these concerns remain concerns years after the introduction of the SSPL means that either:

The license hasn’t been tweaked to eliminate any of its vagueness.
No one has gone to court over an SSPL violation, meaning no legal precedent has been set.
Concerns regarding the license have been sorted out, and the readership over at Hacker News is just exceedingly dumb.
Some combination of the above.

My Take

As a general rule, I tend to dislike the hyper-rational mentality that is so commonly espoused in the tech sector. This biting critique of Hacker News users describes my feelings better than I ever could (I’ve tweaked the following quote a bit, as the author of N-Gate likes to use weird names and labels for people that don’t make sense out of context):

[People] who hold opinions so strongly that they can no longer tell them apart from facts, and [People] who are convinced that the only proper ethical compass is one you build from first principles; a consistent moral code, asserts [Hackernews users], is based entirely on pedantic adherence to logical structure. If the resulting construct directly leads to human misery, at least you’re not a hypocrite!

Anyway, despite saying all that, I do believe that the rational argument against Elastic and Mongo is perfectly valid in this case, especially when combined with a supplementary argument that is based not in reason, but in morality and emotion (phew! now I can sleep better at night).

The rational argument is simple - what Amazon has done is in now way against the law, or even the spirit of the Apache 2 License. That last part is important - they aren’t in the clear due to some minor loophole that no one ever considered. It is a fundamental concept of both Open Source and Free Software. In fact, when I was in undergrad in the early 2000’s, it is one of the first questions I asked when I learned about FLOSS. The answer I was given was clear - people who release software under MIT and Apache-esque licenses are 100% aware that someone could take their code and make millions with it, and they are okay with that. To restrict that would be a violation of the true spirit of Open Source.

At least, that was how everyone felt in theory. In practice, there hadn’t been many examples of anyone making millions in revenue by taking someone’s Open Source work and in some way selling it. Now that that is happening, we are starting to see companies like Elastic and MongoDB show their true colors.

VM Brasseur again with the perfect summation:

These projects are not being relicensed to protect them from Amazon. Claiming that they are is at best naive and at worst wilfully lying. These companies are relicensing projects to cover for the fact that they are ignorant of how to run a successful business. They knowingly released their secret sauce under permissive licenses and have discovered that doing so means that competitors can create more compelling product offerings based upon the same technology. This is entirely in accordance not only with the licenses that these companies knowingly chose, but also with a competitive market. The only problem with this is that it came as a surprise to these “open source” companies and now they’re reacting poorly.

And that brings me to the supplementary argument - Elastic (and MongoDB too) is not a nice company, and they are only an underdog relative to Amazon:

This is a company that, for years, locked away something as simple as SSL Support behind a paid-for plugin, with no easy hooks one could use to add in the functionality themselves.
Elasticsearch the software was released in 2010. Elastic the company was founded in 2012. If the company's founders told me that they never intended to make a business out of their tool when they first launched it, I wouldn't believe them. Making money on ES was always part of the plan. It is as obvious as anything.
This is a company that makes millions and revenue, and has a multi-billion dollar valuation.
This is a company that has never had, and never really tried having a strong community of contributors. Technically users can submit features and bug fixes, but the profit-seeking staff of Elastic NV gets to choose what is accepted. This is in stark contrast to the community-driven projects that most people associate with Open Source.
This is a company that, as recently as December 2020, had a page on their website claiming the open source products would be under Apache 2 "Now and always"

Huh. How about that...
This is a company that makes breaking changes to their API in both major and minor version releases (I can't find a concrete example of minor release breakage, but I know I encountered it a few years ago. Here is an example of breakage in a major release, which wouldn't be as big a deal if major releases weren't being cranked out so frequently).
This is a company that intermingles the code for their proprietary features in with the Open Source product, in hopes of hooking users on these features before notifying them a month or so later that, sorry, you now have to pony up for them.

Elastic NV loves - loves to talk about how much they love the Open Source community, but it is a sack of BS. The company has always - always - been in it for the money, above and beyond everything else. And that’s fine from a certain perspective. The problem, at least for me, is that they tried to make that money by taking advantage of the goodwill and marketshare that came from adopting the Apache 2 License, only to change the terms to the non-open SSPL once the company went public and their need for goodwill switched to a need for revenue. They used Open Source to build themselves up, then threw it away once it was no longer useful. Adam Jacob (former CTO at Chef) puts it this way:

It was designed to get the benefit of open source collaboration and reach, of development in the commons. But it isn’t now, and likely never was, intended to be something that was shepherded by the community for the mutual benefit of all. Because when push comes to shove, Elastic NV is Elasticsearch. If it’s your interest against theirs, their interest will win. That truth is ultimately corrosive to sustainable communities.

That, quite frankly, is bull. And if I can quote VM Brasseur one more time, it is the sign of a company that doesn’t have a real business model:

There are many potential variables to consider and those variables will be different for each company, but “how will we make enough money from this to maintain and grow the company sustainably?” is one that is consistent across all of these decisions. If a company’s answer to that is, “we’ll just give away the software to bring in leads” but they don’t have a compelling enough commercial offering on top of that to convert those leads to sales, while their competitor converts those leads and more using the same technology, that is NOT the fault of open source software, licensing, or culture. That’s a company that doesn’t understand how to do business, and blaming Amazon isn’t going to change that.

This is either a company that is profoundly bad at business, or it knows exactly what it is doing as it jerks everyone around. I cannot fathom how anyone could defend their practices, unless you happen to be the kind of person who also hopes to make money in a similar fashion, and is secretly hoping that the golden goose doesn’t get cooked before you yourself have a chance to cash in (which would probably explain a lot of the apologists on Hacker News).

As for me, I agree with the critics. Elasticsearch is a liability, and the company behind it can no longer be trusted. Get out if you can, and be wary of any Open Source product that is driven by a single for-profit entity without a strong independent community surrounding it. Otherwise, you risk history repeating itself.

Other Thoughts

One common argument you see in these discussions is that writing good software is hard, and the people making it ought to be paid for their troubles. Obviously I agree with this stance, but it is often used as justification for the business practices of companies like Elastic and MongoDB. Basically, “if you want to benefit from this software, pay the people who make it”.

The problem with this argument is twofold. First, if that’s the approach you want to take, then make your software proprietary. No one is going to fault you for that.

Second of all, there are companies that pay people to help maintain Open Source codebases that said companies rely on. IBM does it. Red Hat does it. Hosting providers do it. In other words, there are ways for a company to monetarily support the development of an OSS project without directly paying a for-profit company that chooses to be that project’s sole arbiter and maintainer. The argument that paying into these company’s crummy business models is a way to pay hungry developers is a load of hooey.

Elasticsearch and the SSPL

My Take

Other Thoughts

Further Reading