What happens if the open-source software you rely on changes its licence?

It's one of the first questions I get when I suggest an open-source tool instead of a paid one. "What if they change their mind?" Fair question. It does happen.

The short answer: the copy you already have stays yours, under the licence you got it with. What can change is the next version. And with the right kind of project, even that usually turns out fine.

It has happened, more than once

Two well-known examples, both from the server world.

In August 2023, HashiCorp moved its products from the Mozilla Public License to the Business Source License, a licence that limits how some businesses can use the software. Their announcement said the change applied "on all future releases of HashiCorp products". The best known of those is Terraform, which a lot of companies use to set up their cloud servers.

In March 2024, Redis, a popular database that sits behind a lot of websites to make them faster, announced that from version 7.4 it "will no longer be distributed under the three-clause Berkeley Software Distribution" licence, a very permissive open-source licence. In May 2025, Redis 8 added the AGPL as an extra option, which is an open-source licence again.

It's their code, so that's their call to make. What matters to you is what happens to your systems afterwards.

What it means for the copy you already run

Nothing, straight away. A licence change applies to new releases. Redis said so plainly in its FAQ: "The license change is not retroactive." The version you installed last year is still under the licence it came with, and you can carry on running it.

The real issue is the future. Sooner or later that old version stops getting security fixes, and then you have to choose: accept the new terms, or find another way forward.

Why open source usually has another way forward

This is the part people don't expect. Because the old code was released under an open-source licence, anyone can take a copy of it and carry on developing it. That's called a fork.

Both of the examples above were forked within weeks. In September 2023 the Linux Foundation launched OpenTofu as an "open source successor to the MPLv2-licensed Terraform". In March 2024 it announced Valkey, which "will continue development on Redis 7.2.4" under the original BSD licence.

So people running those tools ended up with two choices instead of none. Stay with the original under its new terms, or move to the fork, which carried on from the same code.

Compare that with a paid product. If a software company doubles its price, changes its terms or closes down, there's no fork. The code was never yours to copy. That's the bigger risk, and the team at Dev Partners wrote a good piece on what to do if your software supplier goes bust.

Four checks before you rely on one

Not every open-source project is equally safe to lean on. Before I put one in for a business, I look at four things.

Who owns it. A project run by a foundation, or by lots of companies together, is harder to relicense than one where a single company owns all the code. If one company owns it, assume the licence could change one day, and decide whether you'd be fine with that.

What the licence actually is. The well-known ones (MIT, BSD, Apache, GPL, AGPL, MPL) are approved by the Open Source Initiative. If the licence is something you've never heard of, or says "source available", read it properly before you depend on it. Some of those limit commercial use.

How many people work on it. Have a look at the project's code page. If dozens of people from different places contribute, a fork has people to carry it. If it's one person in their spare time, it might simply stop.

Can you get your data out. This one matters more than the licence. If your files, notes or records can be exported in a standard format, you can move to something else whatever happens. If they can't, you're tied in, open source or not.

What to do this week

Make a list of the open-source tools your business actually depends on. For most small firms it's only a handful: a file share, a password manager, maybe a CRM or a helpdesk.

For each one, write down the version you're running and who looks after updates. Then do the four checks above. It takes about ten minutes a tool.

If one fails badly, that isn't a reason to panic. It's a reason to have a plan. Know what you'd move to, and make sure you can get your data out before you need to.

If you're thinking of swapping a paid tool for an open-source one, I've written up the options for the common ones, starting with Dropbox and Google Drive. And if what you rely on is bespoke software, the same idea applies: make sure you own the code. Dev Partners put that in writing on their custom software work, which is how it should be.