In early March 2026, a dispute broke out over a Python library that most developers use every day. Chardet, a character encoding detection tool that powers a large portion of the Python ecosystem, became the unlikely center of a licensing debate. At its core, the controversy asks: can an AI rewrite of copyleft-licensed software be legally released under a more permissive license?
A Library, a License, and Lags
Chardet was created by Mark Pilgrim in 2006 and released under the GNU Lesser General Public License (LGPL). The project was a port of a Mozilla’s universal charset detection library. Then, in 2011, Pilgrim’s various online projects began returning 410 errors. A 410 status code (Gone), unlike a 404 (Not Found), a signals that a resource has been permanently removed. Then he deleted his social media accounts, apparently unplugging from the online world entirely. After this, various maintainers stepped in, most notably Dan Blanchard, who has been maintaining Chardet for over a decade.
Chardet is a very popular, basic library for Python, but due to licensing issues, it is not an official Python standard library. Being in the standard library means the library ships with every Python installation, and is implicitly endorsed by the Python core team as the canonical solution to a problem. According to Python policy, inclusion in the Python standard library requires permissive licensing, in order to maximize integration possibilities.
If your code is going to end up in Python or the standard library, the PSF will require you to: License your code under an acceptable open source license. These currently include only the Academic Free License 2.1 … and the Apache License 2.0…. https://wiki.python.org/moin/PythonSoftwareFoundationLicenseFaq
Of the two choices, the Apache license is much more common, and the likely choice.
This made Chardet’s LGPL terms an obstacle to the goal of getting Chardet accepted into Python’s standard libraries. In 2015, Chardet was considered for inclusion in the Python standard library, but the effort died because the LGPL license turned out to be a gating item.
Blanchard wanted to fix that, and also address some performance problems with the library. But his efforts to do so encountered some serious backlash.
The Rewrite and the Relicensing
On March 2, 2026, Blanchard released Chardet 7.0.0–a “ground-up, MIT-licensed rewrite” with the same package name and the same public API as prior versions of Chardet. The rewrite was apparently a success, with huge increase in speed. Blanchard’s detailed notes on how he accomplished the rewrite are here. These notes are both thoughtful and transparent. To show that he had not copied the code, Blanchard provided the results of a plagiarism-detection analysis showing that version 7.0.0 shared less than 1.3% structural similarity with any prior release, suggesting that nothing protectable from the old codebase had been retained.
Just two days after the release, however, Pilgrim suddenly resurfaced. He opened GitHub issue #327, entitled “No right to relicense this project,” identifying himself as the original author and calling for licensing under LGPL.
“Their claim that it is a ‘complete rewrite’ is irrelevant, since they had ample exposure to the originally licensed code (i.e. this is not a ‘clean room’ implementation). Adding a fancy code generator into the mix does not somehow grant them any additional rights.” GitHub
Legal and Community Questions
The issue on GitHub quickly escalated into a controversy. In typical open source fashion, what followed was a war of words among many commentators, who–shall we say–did not engage in the tenor of analysis favored by those who actually know the law.
The best practices for a clean-room development to manage copyright issues requires a separation between two teams of developers: one that creates the specifications and another that writes the reimplementation. The reimplementation developers are blocked from access to the original source code, creating a “clean” environment.
Blanchard, however, had spent over a decade maintaining Chardet’s codebase. His knowledge of the library could not be cleansed. This is an issue endemic to all open source reimplementation projects: there is no way to completely insulate any developer of exposure to public code. In this case, the issue applied in spades.
Nevertheless, using AI to perform clean room development can help manage this issue by interposing a neutral actor–the AI–between the reimplementation developer and the specification developer.
Richard Fontana, an expert on open source licensing, commented that he saw no current basis for concluding that Chardet 7.0.0 was required to be released under the LGPL, noting that no one had identified copyrightable material from earlier versions in the new code. This is probably the right legal analysis with respect to copyright. Still, the controversy raged on, probably because it was only partly about copyright and also about open source community expectations.
Blanchard later switched the license from MIT to 0BSD (a permissive license with no notice requirement) in an attempt to deflect the question of whether AI-generated code is copyrightable in the first place. As a side note, neither MIT nor 0BSD seem to be expressly approved by PSF for standard libraries in the FAQ quoted above, though it would make sense if such permissive licenses posed no hurdle to adoption. But all of this is a red herring for the infringement issue surfaced by Pilgrim.
Takeaways
The Malus Question. What makes this controversy significant is the larger question of AI-assisted clean room rewrites. The same technique could theoretically be applied to any open source project: feed a copyleft-licensed codebase to an LLM, ask it to rewrite the functionality, and publish under a permissive license. Open source advocates point out that if such a technique is legal, the entire copyleft model has begun to disintegrate. That’s an interesting question, and if you want to read more about it, you should read my post about MALUS, the not-quite-April-Fool’s-joke posted recently about using clean room implementations to avoid copyleft. Spoiler: I agree that copyleft is moribund, but I think it’s demise has been a slow, lingering malaise rather than a sudden death.
Clean Room is Rarely a Real Solution. Moreover, in my view, a clean room development undertaken solely to avoid copyleft will usually create a lot of technical debt. Engineering around copyleft effectively creates a fork to the project. Whether that fork is free of the copyright burden of the original is one question. The bigger question is whether anyone will trust a fork enough to use it. And everyone knows that maintaining a fork is almost always more expensive and difficult than complying with open source licenses. However, compared to the average clean room effort, the reasons for the Chardet rewrite were more complex: avoiding a stringent licensing policy and improving performance.
Naming Issues. There is one aspect of the Chardet controversy that most people miss.
That’s the mistake – not the rewrite, not the AI. Not even the license change in isolation. The mistake is claiming your code is “an independent work, not a derivative” while simultaneously shipping it as the next version of the thing you say it’s independent from. –https://shiftmag.dev/license-laundering-and-the-death-of-clean-room-8528/
A key issue here was that the clean room reimplementation used the same project name and API, which could cause confusion with the prior version. Although this may have been a strategic misstep, perhaps we should cut Blanchard some slack for the many years he put into maintaining the project. Naming conventions in open source are usually considered trademark issues. Trademark is, in turn, about the source, nature and quality of products. What constituted Chardet in 2026 may be as much Blanchard’s doing as anyone else’s, so perhaps he effectively controls the name. Other than that, this clean room effort is one of the more conscientious ones I have seen.
The Great Open Source Wealth Transfer. This controversy also raises the familiar (but largely unaddressed) issue of what happens when the original authors of open source code–or their heirs–start to exert what the law calls “dead hand control” over their intellectual property. There is a tension between the right to enforce licenses based on old copyright interests, on one hand, and the need to keep projects useful, secure, and up-to-date, on the other. The truth is that copyright duration–which is largely dictated by the lobbying of the media industry–is just too long for the world of software. As the first generation of open source developers goes to software heaven, goes “410” or just hands the baton to other maintainers, their interests diverge from the community of active users. And worst of all, as they die, their copyright interests will pass to their heirs–who might well have apathy, or even antipathy, for the open source community. Today, we stand at the brink of a “great wealth transfer” of copyright interests from this Boomer generation, and we have not done enough to address it. This dispute, between an ostensibly retired developer and a current maintainer, is a portent of things to come.


















