Having to patch and maintain a complex piece of open source code yourself for most smaller non tech companies for all practical purposes means that it might as well be abandoned closed source code.
Folks are wise to question if they should use OSS that has a CLA assigning copyright because that means they should have zero expectations about the license not changing.
HashiCorp's CLA doesn't assign copyright. It just licenses it. Hence CLA---contributor license agreement. Contributors keep their rights to use and license their work otherwise.
Seeing legal FUD via throwaway account here doesn't make me happy for HN.
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.
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.
But if you don’t have the time or energy, you don’t have the capability.
I might as well say I have the capability of flying my own private plane if I had the money to buy the plane and the time to learn how to fly it.
I'll give a clearer example taken from my actual job:
At my job, we needed to use a NodeJS library to accomplish something. We found one, but it eventually fell out of maintenance. We discovered a bug that was blocking us from continuing to use it, so we had the choice: fork it or find an alternative. We chose to find an alternative because even though we had the technical capability and understanding to fork the library and fix the bug, we realized that would be one more piece of infrastructure that would take time and energy from our team which are a finite supply.
It's more equivalent of an airline pilot saying "I wish I had more time and energy to fly a plane for fun, and not just for work." The ability is there, just not the bandwidth.