When your infra tool changes its license

Somebody on the team asked in Slack on the 11th whether we had to stop using Terraform. It was a reasonable question to ask the morning after HashiCorp announced it was moving its products from the Mozilla Public License to the Business Source License, and I didn’t have a good answer for about two days, which is the reason for this post.

For us, the short-term answer turned out to be no. The longer answer is that I’d never written down which of our open source tools could do this to us, and that’s the actual problem.

What changed

On August 10 HashiCorp said that future releases of Terraform, Vault, Consul, Nomad and the rest would be under BSL 1.1 instead of MPL 2.0. The BSL is a source-available license. You can read the code, modify it and use it, including in production, but the license has an “additional use grant” that says what you can’t do, and HashiCorp’s version rules out offering a product that competes with HashiCorp’s own commercial ones. Each release converts to MPL four years after it ships.

Their licensing FAQ is explicit that end users who run these tools for their own infrastructure aren’t affected, and that it’s about vendors embedding or hosting HashiCorp’s software in a competing product. Existing MPL releases stay MPL forever, since you can’t take back a license you’ve already granted, and they’ve said they’ll backport critical security fixes to the MPL versions until December 31, 2023. Terraform 1.5.5, released around the same time as the announcement, is the newest MPL release. The providers, including the AWS provider we actually spend our lives in, are staying MPL.

Who it does hit is the companies that sell Terraform automation and hosting: Spacelift, env0, Scalr, Gruntwork and others. A week ago a group of them published the OpenTF manifesto, asking HashiCorp to go back to an open source license and saying that if it doesn’t, they’ll fork the last MPL version and put it in a foundation. Nearly a hundred companies and hundreds of individuals have signed it so far. As of this morning there’s no fork yet, just the threat of one, and HashiCorp hasn’t said anything in response that I’ve seen.

Why this keeps happening

This keeps happening, which is the depressing part. MongoDB moved to the SSPL in 2018. Elastic moved Elasticsearch and Kibana off Apache 2.0 in early 2021, and Amazon forked the last Apache version into OpenSearch a few months later. Redis Labs did something similar with its Redis modules back in 2018 and 2019. The pattern is always the same: a company builds a popular open source project, a cloud provider or a competitor makes money hosting it, and the company decides it wants that money.

What makes it possible is the CLA. HashiCorp, like Elastic and MongoDB, required contributors to sign a contributor license agreement, which gives the company the right to relicense their contributions. Linux couldn’t do this if Linus woke up one morning and wanted to, because the copyright is held by thousands of people under the GPL. A project where one company holds or controls all the copyright can change its license with a blog post. When I’m deciding whether to build on something, “who owns the copyright, and is there a CLA?” now belongs on the list right next to “is it actively maintained?”.

I’m not going to pretend I’m outraged on behalf of the vendors. HashiCorp built the thing and has a business to run, and I’d rather it stays in business and keeps maintaining the AWS provider. But I do think something real is lost. A lot of people contributed to Terraform because it was open source, and some of those contributions now ship under terms they didn’t agree to.

What we actually did

Our setup is open source Terraform, run from CI, with state in S3 and a DynamoDB lock table. We don’t use Terraform Cloud, and we don’t sell anything that looks like infrastructure automation, so the BSL doesn’t touch us. We were on 1.5.4. I pinned required_version to ~> 1.5.0 across our modules, which keeps us on MPL releases for now, and put a note on the calendar for November to look at where things stand. If OpenTF ships a fork and it’s healthy by then, moving to it should be close to a binary swap, since it’ll start from the same code. If it isn’t, staying on 1.5 until the end of the year costs us very little, since we haven’t been waiting on anything in 1.6.

The bigger job, and the one I spent most of last week on, was the spreadsheet. We’ve had a vendor spreadsheet since Log4Shell, and it’s grown a column after every scare since, but it lists companies we have a relationship with. Terraform isn’t on it, because we’ve never paid HashiCorp anything. After left-pad we got serious about which packages we depend on and where they’re downloaded from, but the only license question we ever asked was “is it MIT or Apache?”, and nobody asked who could change the answer. So the spreadsheet has a new tab. I went through everything we run in production or depend on to deploy, and wrote down for each one: who maintains it, what license it’s under, whether one company controls the copyright, and what we’d do if the license changed tomorrow. It’s 41 rows. Most are fine, either foundation-run (Kubernetes bits, Postgres, Linux) or permissively licensed with lots of independent contributors.

Nine rows are a single company’s open source project with a CLA, which means each of them can do what HashiCorp just did. Some I knew about, Terraform and Vault among them. A couple surprised me, including a log shipper on every one of our hosts that I’d always thought of as a community project and that turns out to be one company’s repository with a CLA and a commercial cloud product next to it. That doesn’t mean we should rip it out. It means that row now has an owner and a one-line plan, which is more than it had last week.

The thing I can’t decide is how much weight to give this when we pick new tools. “Prefer foundation-governed projects” sounds sensible until you notice that some of the best tools we use are single-company projects, and that a foundation doesn’t guarantee anyone maintains anything. For now it’s one of the questions in our design doc template, and somebody has to write an answer to it, even if the answer is “we accept the risk”.