That's true, but for a lot of companies having an entity behind a piece of software will definitely be a major factor in their decision making process so these kind of tricks ultimately benefit closed source offerings. And that's quite annoying. The idea behind open source is very solid, but the assumption that any user of a large package is ultimately able to continue to maintain it is faulty and that means that for a lot of parties the benefits of open source only materialize if someone else is willing to take up the mantle, they are simply not able/staffed/wealthy enough to do this.

So every time someone does a rug-pull all FOSS projects suffer.

> Would you rather use a service that worst-case, you have to patch and maintain yourselves?

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.

Exactly. The end result is the same.

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.

I could fork any MIT, BSD, or Apache-2-licensed project without a CLA and start publishing new versions under HashiCorp's BSL tomorrow.

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.

Projects without a CLA can't be relicensed unless every contributor to the project agrees to do so. So if a project without a CLA has many contributors to it, you do have some reasonable assurance that its license cannot change (legally), because it would be impractical to do so.

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.

Even for tech companies, the problem becomes that's yet one more thing to maintain. I'm perfectly capable of maintaining a fork if I need to, but that doesn't mean I have the time and energy to do so.

Are you capable of maintaining a fork no matter the language or level of complexity? Are you going to maintain your own fork of Chromium? WebKit? MySQL?

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.

Obviously yes, the more complex the more difficult. And if it's a technology you don't have experience with it's going to be extremely difficult to impossible. But that's not what I'm talking about.

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.

Not really. If you need it fixed or extended and you can't do it yourself, you can always hire someone to do it for you. With open source, you have options.