“You never actually own a project, you merely look after it for the next generation.”
— with apologies to Patek Phillippe.
In early March 2026, Dan Blanchard published chardet 7.0.0. The package metadata was familiar — same name on PyPI, same import path, same public API. The license was not. Versions 1.1 through 6.x had shipped under the LGPL since 2012. 7.0.0 ships under the MIT license, and the release notes credit Anthropic’s Claude as a contributor. Two days later Mark Pilgrim — the original author, who removed himself from the public internet in 2011 and was widely assumed to have stayed gone — opened issue #327: “No right to relicense this project.”
He’s right. Whatever Blanchard did with Claude, he did not acquire the right to relicense the codebase by doing it.
This isn’t an edge case. It’s the central case for a class of question that PostgreSQL people are about to be asked over and over: what does picking up an apparently-abandoned project actually permit you to do?
What you inherit when you take over maintenance
The first thing to understand about chardet is that there is no single owner.
Pilgrim wrote the original Python port in 2006 by hand-translating Mozilla’s MPL-licensed character-detection code. He chose the LGPL. In 2011 he left public life and walked away from the project. Dan Blanchard showed up, and from version 1.1 in July 2012 forward he has shepherded every release. In the intervening fourteen years, dozens of other people landed patches.
There is no CLA. There is no copyright assignment. There is no “the project” as a legal entity that holds anything. What there is, is a stack of independent copyrights — Mozilla’s, Pilgrim’s, Blanchard’s, and every drive-by contributor’s — bound together by the LGPL into a single distributable work.
Maintaining a project gives you commit access. It does not give you a copyright assignment. It does not let you relicense. The only way to relicense an unassigned codebase is to obtain permission from every copyright holder, which for a project of chardet’s vintage is somewhere between impractical and impossible. (And every copyright holder includes, in this case, the one who left the internet fifteen years ago and now wants a word.)
This is how almost every old, well-loved open-source project works. The codebase outlives any one author. The license is the substrate that lets contributions accumulate. Nobody owns the substrate.
The AI clean room is not what it sounds like
Blanchard’s defense, laid out at length in his post-release writeup, is that 7.0.0 isn’t a derivative work because it was rewritten — substantially by Claude — without copying. He provides a structural-similarity report claiming under 1.3% overlap with prior releases.
There are at least two things wrong with this.
The first is procedural. Clean room reverse engineering is a doctrine with a specific shape. Two teams. Team A reads the original and produces a behavioral specification. Team B implements from the specification, with no access to the original. The wall between the teams is the part that does the legal work. You can argue about how rigorous the wall has to be, but you can’t argue it away.
When the implementer is an LLM trained on the entire indexed internet, including the LGPL’d source you’re trying to escape from, you do not have a clean room. You have a room with a one-way mirror that the implementer is staring through. No court has ruled on this yet. The argument that a model whose weights encode the original code is a “clean” implementer is not one that has ever convinced a court of anything analogous, and it is unlikely to start now.
The second is substantive. The new chardet is by design API-compatible with the old one. Same package name on PyPI. Same imports. Same function signatures. Same output for the same input. That is the entire point — drop-in replacement, no caller changes. Whether the bytes inside are different is one question. Whether the expression the code embodies is different is a much harder question, and “API-compatible reimplementation” is the precise category of work that has been litigated extensively and inconsistently in U.S. courts for the past twenty-five years. Oracle v. Google narrowed but did not erase the question. Citing 1.3% structural similarity does not answer it.
Set the legal posture aside for a moment. What Blanchard did is, on the merits, take a project that thousands of downstream projects depend on, reach into PyPI under the same name, and push out a version under a different license without the consent of the people who wrote the code. That’s the part that would matter even if there were no Pilgrim and no LGPL. Maintainers are stewards. Stewardship is not ownership.
What doing it right looks like
This brings me to pgBackRest.
On 27 April, David Steele announced that he was archiving pgBackRest, the de facto standard PostgreSQL backup tool of the last decade. Crunchy Data — Steele’s longtime sponsor — had been acquired by Snowflake, and the funding model that supported active maintenance evaporated. A few days later, after a great deal of community noise and some scrambling, it became clear that a coalition of sponsors would step in and Steele would continue. The archival is, as of this writing, almost certainly going to be reversed.
In between those two events, PGX launched pgxbackup — a continuity fork of pgBackRest, intended to keep the lights on for our support clients while the situation resolved. There are three things about how pgxbackup was set up that are worth pointing at, because they are exactly the things chardet 7.0.0 didn’t do.
Same license. pgBackRest is MIT-licensed. pgxbackup is also MIT-licensed. We kept the license because the license is the contract every contributor signed up to over thirteen years. Permissive code can be relicensed in certain directions without breaking that contract, but “can” is not “should,” and there is no good reason to do it. A continuity fork inherits the social contract along with the source.
Different name. This was at Dave’s request, and we honored it without argument. The name is a separate piece of property from the code. Trademark and copyright are different things. A permissive license gives you the right to use, modify, and redistribute the code; it does not give you the right to ship something under the original project’s name and confuse downstream users into thinking it’s the same thing. Renaming is courteous, it’s clarifying, and it makes the relationship between original and fork legible to everyone who has to make a decision about which one to install.
Forking, not impersonating. pgxbackup lives at a different URL, with different maintainers, and announces itself as continuity support for an existing project. It does not push to pgBackRest’s namespace. It does not claim to be pgBackRest. If Steele’s revival sticks — and it looks like it will — pgxbackup will continue alongside it, or fold gracefully back into the upstream effort, or coexist however the situation calls for. None of that involves anyone reaching into pgBackRest’s namespace and changing what users get when they install something called pgBackRest.
chardet 7.0.0 violates all three. Same name, on the same PyPI handle, with a license change that the contributors did not consent to.
If you find yourself maintaining someone else’s code
If you have inherited or are about to inherit an apparently-abandoned open-source project, here is the short version.
Do not relicense. Not even if the existing license is permissive and you legally could. Not even if you think you have AI cover. The license is the contract every prior contributor agreed to. It is not yours to change.
Track the contributors. If there’s an AUTHORS or CONTRIBUTORS file, keep it accurate. If there isn’t one, build it from git log. Future-you will thank present-you when somebody resurfaces with a question.
Honor the original author’s wishes about naming. If you can’t reach the original author, fork under a different name. If you can reach them and they have preferences about how their work is referenced, follow those preferences. The trademark cost of a rename is approximately zero. The trust cost of not renaming, when you should have, is much higher.
Be loud about what you’re doing. “I have taken over maintenance of X” is a legitimate thing to announce. “I have rewritten X with an LLM and the new version is mine” is a legitimate thing to do only if you are publishing it as a new project, with a new name, that competes with X on its own merits. Pretending the rewrite is just the next version of the original is the move that gets you into trouble.
The AI clean room defense is not yet a defense. No court has blessed it. The technical claim — that a model trained on the original is a clean implementer — is dubious. The legal claim — that API-compatible reimplementations are categorically non-derivative — is unsettled. If your only argument for relicensing a copyleft project under a permissive license is “Claude wrote it,” you are running an experiment with other people’s work, and you are running it without their consent.
The reason to care about all of this isn’t that someone is going to sue you. Most of the time, nobody will. The reason to care is that maintained open source is a long-running cooperative project, and the things that make it work — license stability, contributor consent, namespace hygiene — are the things that, if you erode them, you erode for everybody.
The maintainer is not the owner. You’re holding it for the next person.