Relicensing a Mature Project: Consent, Forks, and Downstream Effects

A license change is not a governance decision that produces a legal effect. It is a set of copyright transactions, one per rightsholder per portion of the code, and the project’s announcement is only the summary of them. Any clause that says a project is now distributed under different terms is a statement about the permissions its holders have granted, so the work of relicensing is establishing which holders exist and which of them have already granted permission wide enough to make the change without being asked again.

Three routes exist. A contributor may have granted the project the right to distribute under any terms, which is what a broad contributor license agreement supplies; a contributor may have granted the copyright itself, which is what assignment supplies; or the contributor may have granted permission for later versions of the same license, which is what the “or any later version” phrase in a file header supplies. The first two are the subject of contribution agreements. The third is the cheapest and the narrowest, and its limits explain much of the ecosystem’s history.

The built-in upgrade channel, and the project that lacks it

A grant of the form “version 2, or at your option any later version” is an offer of a choice to each recipient: the terms of version 2, or the terms of any later version published by the license’s steward. A project distributed under that phrase can move to a later version of the same license without contacting contributors, because the option already exists in the grant. This is how a substantial part of the GPL ecosystem moved between versions of the license. The choice belongs to the recipient rather than to the copyright holder, so a project’s maintainers cannot oblige anyone to adopt the later version; they can distribute the project under it themselves, at which point new recipients receive it on the later terms.

The channel cannot change families. The option is for later versions of the same license as published by the same steward, so it never turns copyleft code into permissively licensed code, and it does not reach a license other than the one named.

The counterexample is the project that declined the phrase. The Linux kernel is licensed under version 2 of the GPL without a grant of later versions, and its own licensing documentation records that position, including the deliberate absence of the upgrade phrase in its files. Because each contributor’s grant is pinned to one version, there is no upgrade channel at all, and a move to version 3 would require asking every contributor who ever touched the tree. The distinction between two spellings of the same license header is therefore the difference between a project that can adopt a new license text with a commit and a project that structurally cannot.

Establishing who must be asked

An audit answers three questions in order. The first is what the tree actually contains: the source files, plus vendored directories copied in from elsewhere, generated files with no header, binaries checked in alongside source, and documentation under a separate license from the code. Any of those may be covered by terms the project’s root license file does not mention.

The second is who holds copyright in each part. Authorship is recorded by commits, but the holder is not always the author: contributions made within the scope of employment belong to the employer, contributions made by contractors may belong to the commissioning party, and contributions copied in from another project belong to that project’s holders. The outcome of a careful audit is a list of holders together with the files they cover, and it is usually longer than the list of commit authors because employers and outside holders are on it.

The third is whether the target license is compatible with everything already in the tree. Moving to a license means distributing the whole under terms that must satisfy every existing grant, so components under an incompatible license block the move until they are removed, isolated or replaced, for the reasons set out in license compatibility.

Consent then means outreach, recorded per holder rather than per contributor, with the request stating what is being granted and to whom. The cost of the exercise is entirely in the tail, and the tail is unavoidable: contributors whose addresses have expired, who contributed under a pseudonym with no reachable identity attached, whose employer at the time no longer exists, or who have died, leaving rights with heirs. There is no threshold short of the complete set. A project that has collected permission from most contributors has collected permission from most contributors, which is not a position anyone can distribute a relicensed work from.

The workarounds are the ones the situation allows. Contributions from unreachable holders can be rewritten from scratch, which removes the code and the encumbrance together; they can be excised if nothing depends on them; they can be isolated into a module that keeps the old license while the rest of the tree moves, which leaves a split-licensed codebase whose per-file terms have to be represented accurately rather than flattened into one package string, as discussed in license expressions; or the move can be abandoned.

What a change cannot reach

Grants already made cannot be recalled. Every recipient who received a copy under the old license holds those permissions for that copy, so a change governs future releases and nothing else. The last release under the old terms remains available, and it remains forkable: the license permits modification and redistribution, and trademark law prevents the fork from using the project’s name, which is the constraint described in maintainer authority and forks.

This is the shape of the license changes that became well known in the last decade. A product company holding the copyright in its own code can change the terms for future releases unilaterally, and several have done so, moving to source-available licenses that restrict the offering of competing managed services. In each case the last release under the previous terms was forked and continued by another party: the search and analytics fork that became OpenSearch followed a 2021 change by Elastic, the in-memory data store fork that became Valkey was announced under foundation stewardship in 2024 after Redis moved its future releases to a source-available license, and the infrastructure-as-code fork that became OpenTofu continued the last MPL release of Terraform after HashiCorp adopted a business-source license for future versions in 2023. The mechanism is identical in each case, and it is the mechanism rather than the dispute that matters: a relicensing decision is a decision to hand the previous version, with all its accumulated users, to whoever wants to continue it.

The same rule protects the project’s own history. An old release under a permissive license stays permissively licensed forever, and an old release under a copyleft license keeps its copyleft condition, which is why the archival record of a project’s releases is a series of different license expressions rather than one.

Relicensing as a test of governance

The cases that go well share a property: consent was gathered before the change was announced, and the announcement described what had already been agreed. The cases that go badly announce the intent first, discover that a fraction of the tree cannot be cleared, and are left either distributing a split-licensed codebase or reverting the announcement, with trust spent either way.

Two design lessons follow for projects that expect to live a long time. The first is that flexibility is bought early. A project that collects grants wide enough to relicense while it has a hundred contributors is making a cheap decision; the same project making it at ten thousand contributors is making an expensive one, and the same consent problem appears for any change of terms, including a change to the project’s own contribution paperwork. The second is that visibility is part of the obligation. Because a license change does not reach older releases, downstream consumers need the terms to be attached to versions rather than to a project, so that a vendored copy, a distribution package and a container image each carry the expression that applies to them.