License changes are an ongoing controversy in the COSS world. They go by many names, depending on your viewpoint: rug-pulls, bait and switch, or new-and-improved licenses. To understand this phenomenon, you need to dig below the headlines.

The most notorious license changes have applied to popular open source projects, like Redis, Confluent, Elastic, Cockroach, and Hashicorp. These happened in sequence a few years ago, as companies started to move to source available licensing. Some preserved an open core, and some did not.

But the phenomenon is still happening. Recently, Sabir Ibrahim of Chinstrap Community commented on the bait-and-switch of Liquibase, a popular database schema migration tool. But this example is not the first, nor will it be the last.

License changes cause great upheaval in COSS communities. The most hue and cry follows companies who start as true COSS–with core software under open source licenses like Apache 2.0 or MIT–and change to source available licenses, AGPL, or SaaS. Companies that come out the door with a mixed or limited licensing model don’t usually face so much blowback. It’s a natural impulse: people hate having things taken from them. Every software release under any free license is a gift, on a certain level. But on a practical level, when a license change occurs, companies who have already integrated a COSS project into their technology stack have to re-assess whether they can comply with a new license. It’s that disruption that causes most of the consternation, even though a lot of the social media ignites around the morality of using licenses that are not open source.

License changes, of course, are not changes per se. Once a company releases code under, say, Apache 2.0, the code will be available under that license forever. If the company changes to a license like, say, BUSL, it is only for forward-going versions. The upshot is that, when a company changes its license, future releases of its software are under a new license, but there is no change to the license for the prior releases.

So, after a license change, companies who have adopted the software have a choice to follow the new license (if they can), seek an alternative commercial license (if it is on offer), stay on an old version with the original license, or fork the open source project. All of these happen, sometimes all at once.

Companies that change licenses from open source to limited licenses always risk forking. The most famous examples track the most famous license changes: Elastic spawned OpenSearch, Redis spawned Valkey, and Hashicorp spawned OpenTofu. These forks often end up at neutral stewards like the Linux Foundation.

Whether a fork happens is a measure of the popularity of the project. If there is enough community support, a fork will be likely. It’s important to take the long view, though. A project can fork precisely because the original open source license grants the rights to fork. In that sense, the open source license has done its job, and the fork–which necessarily retains the original open source license–is simply a re-allocation of maintenance costs from the COSS company to the community.

License changes often happen when a COSS company is purchased by private equity–or other owners who are uninterested in the COSS model. But it also happens when COSS founders lose their faith in their own COSS businesses. The best way to prevent this, from the community point of view, is to support the true COSS companies so they can continue to offer sustainable COSS products.