License changes are API changes

When you make a change to your project’s license, it will affect people interact with your project Otherwise, why are you making the change? This change means that you need to treat license changes as if they were changes to your API.

Some API changes are non-breaking. Some license changes are, too. In this case, you don’t need to do much. Obviously you want to make sure the change is well-publicized through your usual channels. Add an FAQ for bonus points. Changes that only affect contribution (e.g. adopting an explicit “inbound = outbound” policy) will often fall into this category. If you’re not sure your change falls into the non-breaking category, assume it’s breaking.

But just as some API changes break existing usage, some license changes will, too. In these cases, you should make the license change at a major release boundary. And you should provide security fixes to the previous version (under the old license) for a period of time sufficient for users to evaluate their options. Some may choose to stay, others will leave.

Importantly, you need to provide these security fixes even if you typically only support the latest release. Providing security fixes gives people time to make a reasoned decision and doesn’t make the world less secure. You don’t have a legal obligation to provide this support, of course. But you don’t want to harm your project’s reputation or have unpatched vulnerabilities in the wild.

This post was inspired by yet another well-known open source project switching to a source-available license, but it’s not unique to those cases. There are many cases where a project switches from one open source license to another. But those changes often have important implications for how downstreams incorporate the project.

This post’s featured photo by Conny Schneider on Unsplash