Does it matter if you anger practitioners and enthusiasts?

I put this topic on my kanban board in August of 2023. At the time, Hashicorp had just angered a lot of people by switching their popular tools to the Business Source License (BuSL). This was not long after Red Hat angered a lot of people by changing how they made source code for Red Hat Enterprise Linux (RHEL) public. While the anger was numerous and voluminous, my suspicion was that it didn’t matter.

The people who buy enterprise software are, by and large, not the enthusiasts who care about the practical or philosophical importance of open source software. You can anger the nerds (I use that term with endearment, as I am one, too) all you want, because they’re not the ones who sign the checks. This is a cynical take, but Hashicorp’s subsequent (pending) acquisition by IBM would seem to reinforce it. Much of the analysis I read at the time suggested that switching to the BuSL was part of Hashicorp trying to be more appealing to potential buyers and perhaps the reason that IBM made the acquisition offer. I’m not convinced of the latter, since IBM was willing to pay a lot more for Red Hat, who open sourced everything*.

It doesn’t seem to matter

Shortly after the Hashicorp acquisition was announced, SJVN wrote an article in which he noted that IBM’s share price had fallen 8% on the news. This, combined with the fact that Hashicorp stock fell 22% between the announcement of the BuSL switch and the acquisition news, led him to wonder if the acquisition was a “blunder” on IBM’s part. But as of Friday’s close, just over four months since the news was announced, IBM shares are up almost 10% from the pre-announcement price and have reached a one-year high. If the price isn’t quite at an all-time high, it’s within spitting distance of the 2013 peak.

But now we have actual analysis. RedMonk analyst Rachel Stephens published an article last week examining the effect of license changes on Hashicorp, MongoDB, Elastic, and Confluent. You should read the whole article, but the quick summary is that the license changes appear to have no impact on revenue. The changes in valuation and net income are a little messier, but the conclusion holds: “here does not seem to be a clear link between moving from an open source to proprietary license and increasing the company’s value.”

Importantly, though, the analysis does not show a clear link between moving to a proprietary license and decreasing the company’s value. It’s a small sample size, but the best we can tell, changing the license doesn’t matter either way. If your primary business is enterprises, not SMBs or individuals, there’s little evidence that a change that angers practitioners matters, at least in the short term.

What about Elasticsearch?

Elastic dropped a surprise on Thursday. They announced that Elasticsearch is once again open source, this time under the AGPL. Elastic announced a change from the Apache Software License in January 2021, driven in part by issues with Amazon Web Services. Does this mean they finally caved to pressure from the people who were upset about the initial change?

I don’t think so. On the same day Elastic announced the shift to the AGPL, they also released their quarterly earnings. Although the earnings and revenue beat expectations, the company cut their guidance from the coming quarter. The market was displeased, and about a quarter of Elastic’s market value went poof in a single day.

I’m not a market analyst and I don’t have any inside knowledge, so the best I can do is speculate based on what I know about the software industry. But my take is that this license change is less about responding to the pressure from open source fans and more about reducing ambiguity for potential adoptees. The Server Side Public License has some vague terms that could scare away someone trying the free offering, and a better-known license can remove that friction. Is this a win? Maybe, but not a philosophically-driven one.

Elastic’s re-re-license announcement mentions working issues out with AWS. The fact that they switched to the AGPL seems like a defensive move against future perceived shenanigans. If this is the primary motivator, then it seems like the move away from open source was successful and justifies the first license change.

So what do we do?

Anger from practitioners doesn’t seem like a meaningful consequence, so how do we prevent the sort of license changes that have caused such a stir in the last few years? If I had an easy answer, I’d get paid a lot of money as a consultant. (Spoiler: I do not get paid a lot of money as a consultant.)

But it’s clear when making the case for open source at our employers that we should not rely on philosophical arguments (because those only work when money is cheap and times are good). Nor should we rely on a “this will kill us with enthusiasts” because it turns out that might not matter.

The case for open source has to be presented in terms that matter to the business. This doesn’t have to be revenue or profit, which is good since the links are not always direct. But it does need to connect in clear, direct ways to the business’s goals, strategy, or other decision influences.

Thoughts on Elastic License v2

Yesterday Elastic announced a revision to their not-great Elastic License. The Elastic License v2 was updated based on feedback from the community and apparently had a lawyer’s input. And while they seem to be backing off trying to imply that it is open source (because it decidedly is not), it still doesn’t seem like a good license.

First of all, it doesn’t comply with the Open Source Definition, so if that’s important to you, that’s all you need to know. I’m assuming if you’re reading this, you care about the license beyond that. And while I’m not a lawyer (so this is very much not legal advice), here are my thoughts: it’s vague! Seriously, the vagueness makes it a big risk whether or not you care about OSD compliance (and there are many reasons you might not, as I’ll discuss in an upcoming post).

The first line in the Limitations section reads thus:

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.

This contains two things I have questions about. First of all, what is a “managed service” exactly? Does that include consulting services where someone provides direct management of a customer’s software? I have a good idea of what “managed service” means in industry terms, but if a licensor using this software decides they don’t like what you’re doing, there’s enough vagueness there for them to cause you problems. And of course, if you want to use it in a Software-as-a-Service model, you can’t use it under this license. You can use it under the SSPL, of course, but that is a non-starter for a lot of users.

Secondly, what is a “substantial set of the features or functionality of the software”? If someone does their own implementation of the functionality, does that count? If someone develops additional code that extends the functionality of the software and the upstream project later adds that functionality, does the additional code now violate the license?

Another problem is that it treats “you” and “your company” as distinct entities. This doesn’t make a lot of sense to me. If I use software on behalf of my employer, the employer is the licensee. The “Patents” section contains the only uses of “your company” and says “[i]f your company makes such a claim, your patent license ends immediately for work on behalf of your company”, but that’s redundant because the license was always for my company, not for me.

Frankly, I don’t see why anyone would use this license, particularly now that Amazon has forked the project.