The Terraform Registry Terms of Service have been updated

Some of them, however, may want to be acquired by companies that compete with HashiCorp.

From my point of view, controlling the canonical namespace is a form of soft power in the ecosystem. Since as the post says, the actual files are hosted on GitHub, the cost of the extra load on their infrastructure is real but probably not material to a company of their size -- as I understand it, it's more like running a DNS service than a file host.

So it _seems_ (the word I used above as well) from my perspective that they’re giving up a bunch of soft power for little gain, but it's very possible that I'm either wrong about the value of the soft power, or wrong about the cost of running the infra.

Again, that is not important for my argument. It only matters that some are concerned.

You can’t change the license of the original code. But you can say “all changes from now on are licensed under the BSL”, with no need to physically separate the BSL and non-BSL parts. The result is a codebase where users have to comply with both the original license and the BSL. For most permissive licenses, that’s basically the same thing as a pure BSL codebase, except that typically the original license notice needs to be preserved in addition to the BSL one.

This isn’t the case if the original license is the GPL, because the GPL requires derivative works to also be licensed under the GPL.

I suspect you're conflating two meanings of "relicense" here. That's understandable: we've badly overloaded the term.

For the kind of "relicensing" relevant to HasiCorp and similar, the question is "What will be the license terms for new work going forward?"

Unless authors are claiming to revoke the license under which they previously released code---neither Hashi, nor Elastic, nor Mongo, nor the Commons Clause companies I saw ever claimed to do this---those old license grants do not go away. Hashi Terraform releases from the before the announcement are still available under MPLv2, and likely always will be. There is no backwards-looking, retroactive change.

When I fork, say, an Apache-2-licensed project, add my own work, and release under Hashi's BSL, the original, Apache-2-licensed code doesn't cease to be Apache-2-licensed. However, Apache 2 license terms don't apply to my new work unless I say they do. If I choose BSL instead, users of my new releases---old Apache-2 work plus my new Hashi-BSL-licensed work---have to comply with both Apache 2 and the BSL. They can toss my new work and just comply with Apache 2, but they can't have the whole package with my new work without my terms.

The situation's akin to using an Apache-licensed library or copying in Apache-licensed code snippets. All of this is possible because Apache 2, a "permissive" license, doesn't restrict how I can license new work.

The "relicensing" that requires getting every copyright owner's agreement is giving license grants under new or different terms for old releases. Say we're trying to "relicense" a project "from GPLv2 to GPLv3". If we get all copyright holders to sign off, the old releases essentially become "dual licensed"---another overloaded term that here means effectively "available under the user's choice of two or more licenses", specifically GPLv2 or GPLv3. Once copyright holders in existing work have agreed to make that work available under GPLv3, as well, future developers can license further work under GPLv3, too, effectively choosing to comply with the new GPLv3 grant for the old code, rather than the old GPLv2 grant.

We tend to see CLAs less often in permissive-licensed projects. There are various reasons for that, one of which is that permissive terms are by nature less complicated, more stable over time, and contend with fewer "license compatibility" issues. But we still see CLAs in some permissively licensed projects that never anticipate making grants under new terms for old releases, because the project stewards want to make sure people have the legal rights to license copyright in the contributions they offer, and they want documentation to back that up if there's a dispute. Typical CLA forms also address that problem.

So "uses CLA" is only a poor proxy for "stewarded by a company that may not choose to make its new work available under the old license forever". Developers can certainly choose to develop patches to these projects and refuse to give the steward a contributor license agreement. But the steward isn't obligated to accept or maintain those patches. They may very well refuse to do so without the flexibility the CLA provides.

When the public license for the project is copyleft, commercial-company project stewards are highly unlikely to give up licensing flexibility, agree to comply with the new contributor's copyleft license, and "lock the project open" just for some new patch, even if it's quality work. Depending on the copyleft license, that work may have to be licensed under the same copyleft terms, rendering it "compatible". But it simply won't be merged.

This happens, but in my experience, pretty rarely, and with little lasting effect. Outside developers usually aren't interested in spending all the time developing patches to other people's projects in the first place if their work won't be merged to mainline and kept up by the maintainers driving development.