The only way a company can switch the license for a given bit of software if one of two things are true: 1) The license allows bundling of licensed code with c

The only way a company can switch the license for a given bit of software if one of two things are true: 1) The license allows bundling of licensed code with code under alternate licenses. This kind of is the point of many business friendly licenses such as the widely used Apache 2.0 and MIT licenses. I don't see this as a bad thing. 2) Alternatively, the company simply owns the copyright to the entire code base and insists on copy right transfers for any outside contributions. Elastic did this. And they were using Apache 2.0 as their license as well. The best way to insure against companies re-licensing and controlling a code base is by diversifying the community of contributors. Most long lived open source projects have so many contributors across the industry that anyone taking the source code and closing it would just amount to a weird isolated fork that probably won't get much traction. Perfectly legal under some licenses. If you want a BSL licensed version of Apache httpd. You can just take the source code and start layering your BSL licensed patches on top. But there's very little point in doing that as everybody else will just keep on adding to the upstream OSS code base. Other licenses are designed to prevent this entirely. Which is where copyright transfers become relevant. Any company using AGPL v3 and insisting on copyright transfers is basically just trying to coerce people to buy their proprietary licensed version instead. It's a common strategy among some OSS companies. I don't think it works that well for many companies. Mostly you just throw away the baby with the bathwater. You alienate a lot of potential users as well as contributors. I use a few simple rules: - I avoid anything licensed under the AGPLv3. Just not worth the legal headaches. Luckily, this is easy because there isn't a whole lot of software under that license that I particularly care about. If I need a lawyer to figure out if my intended use of a given bit of software is allowed, morally justified, etc., I'm not interested. The attitude with a lot of users of this license seems to be leaning towards communism in the sense that all form of value creation is frowned upon and seen as profiteering. So, I respect that attitude by just ignoring anything under that license for personal or company use. No exceptions. - I don't contribute source code if there's a copyright transfer involved or if the software is not under a proper open source license. If you want to own your software that's fine, but that means you are responsible for fixing it as well. So, anything BSL or similarly licensed is not going to get patches from me. I might file a bug but I won't lift a finger to close it. A hard condition for me coding anything is either financial compensation or a proper OSS license. - I avoid using non open sourced software as much as I can. That future proofs what I do. I tend to gravitate to things with active communities. This put me a bit in a dilemma with Elasticsearch when they went closed their source and fractured their community (opensearch is the OSS fork). I still deal with Elasticsearch professionally. But I'm gradually shifting my attention to Opensearch. And my observation is that they fractured their customer base and that new users are defaulting to Opensearch. Hashicorp is likely to end up facing a similar situation. - For my own oss projects, I use the MIT license. Maximizes my user's flexibility to do whatever they need to do without limiting mine. Including creating valuable closed source products. That's a feature, not a bug. Go for it. I want you to create value and benefit from my software. More power to you. That's part of the OSS contract. Contributing back is appreciated but not required. Companies that value having active developer communities are mutually exclusive with overly restrictive licenses. What's nice about things like Linux is that the community is lots of companies taht build commercial and proprietary products on top of it. And they end up contributing back. It's this commercial success of Linux that drives its success and keeps its community healthy and diverse. GPLv2 was a happy accident that it contained enough loopholes for this to work.