花 5 天时间借助 Claude Code 重写运营十余年的老旧代码库后，项目维护者直接将开源许可证从 LGPL 改为更宽松的 MIT。

近日，Python 经典编码检测工具 chardet 因此陷入舆论中心。

更具戏剧性的是，这个库的新版发布后，自 2011 年便淡出公众视野的原作者突然现身，要求项目维护者立刻将许可改回原版。

然维护者坚称，新版本是用 AI 从零开始写的，与旧版本无关。

至此，一场关于 AI 重写代码的所有权与许可规则之争，就此拉开。

原作者隐退，维护者上岗

它看似小众，却是很多程序的基础组件。如果你安装过 Python 的 requests 库，它很可能已经在你的电脑上默默运行。此前有数据统计，chardet 单年度内下载量达到 8.54 亿次。

该库最早由开发者 Mark Pilgrim 于 2006 年创建， 并使用 LGPL 许可证发布。

熟悉开源协议的开发者想必也并不陌生，LGPL 允许修改与分发，但对二次分发与商业使用有严格约束，衍生作品通常需继续沿用相同许可。

原作者在维护数年后，于 2011 年彻底退出公众视野，chardet 的维护工作由其他人接手。

其中 Dan Blanchard 便是最重要的维护者之一，他负责了自 2012 年 7 月 chardet 1.1 版本以来的每一个版本，贡献了近 700 次提交。而排名第二的维护者只有 48 次。

Claude 的帮助下，维护者用 5 天完成对 chardet 库的全面重写

时间来到上周，Dan Blanchard 发布了 chardet 7.0 版本，并在 GitHub 项目页面上声称这是一次「 完全重写的版本，采用了 MIT 许可。」

同时，其表示， 这个库的包名和公共 API 保持不变—— 可直接替代 chardet 5.x/6.x，速度更快，准确性更高。支持 Python 3.10 及以上版本，无任何运行时依赖，可在 PyPy 上运行。

问题来了，MIT 许可证比 LGPL 宽松很多，你可以自由使用、修改、复制和分发软件，包括把它用在商业软件里，只要保留原作者版权声明即可。

至于为什么要变更协议，Dan Blanchard 在接受外媒采访时表示，长期以来，他希望 chardet 能进入 Python 标准库，但受限于旧许可、性能与准确率，此外，也因为时间有限，始终无法推进。

“如今，Claude 可以让我能够在大约 5 天内完成我想做的事情”，Dan Blanchard 说道。

所以，他借助 Claude Code 重写了 chardet 7.0 版本，并将其发布出来。

原作者“闪现”抗议：拒绝对原始代码的非法重新授权

就在新版本发布的两天后，一个昵称为 Mark Pilgrim 的用户在 GitHub 上发帖称，自己就是chardet 的原作者，感谢长期维护者与贡献者，但 Dan Blanchard 将 7.0 版本以 MIT 许可发布， 属于对 LGPL 代码的非法重新授权，直接违反开源协议。

他明确反对此次许可变更。

以下是他在 GitHub issue 提交的完整内容：

你好，我是 Mark Pilgrim。你也许还记得我写过的一些经典作品，比如《Dive Into Python》以及“Universal Character Encoding Detector”。我也是 chardet 的最初作者。

首先，我想感谢目前的维护者，以及这些年来所有为这个项目做出贡献并不断改进它的人。这确实是一个自由软件成功发展的典型案例。

不过，最近有人提醒我，在 7.0.0 版本的发布中，维护者声称他们有权对这个项目进行“重新授权（relicense）”。实际上，他们并没有这样的权利；这么做是对 GNU Lesser General Public License（LGPL）许可的明确违反。

根据 LGPL 的规定，对已授权代码进行修改后发布时，仍然必须继续使用同样的 LGPL 许可证。维护者声称这是一次“完全重写（complete rewrite）”，这一点并不成立，因为他们曾经大量接触过原本的授权代码（也就是说，这并不是所谓的“clean room 实现”，即完全隔离、未接触原代码的独立实现）。即使在开发过程中加入了某种复杂的代码生成器，也不会因此自动获得额外的授权权利。

因此，我在此郑重要求他们将项目的许可证恢复为最初的版本。

到底是谁的代码？谁说了算？

首先简单解释一下 Mark Pilgrim 在声明中提到的“clean room”。

计算机工程师和程序员长期以来依赖逆向工程来实现程序功能，而不直接复制受版权保护的原始代码。简单来说，就是在不侵犯版权的前提下“模仿”软件的行为和功能。过去，这种做法通常遵循所谓的“洁净房间（clean room）”原则：由完全不接触原始代码的人重新实现功能，以确保生成的新代码不会构成原作的衍生作品。

Blanchard 在回应中承认，自己维护了 chardet 超过十年了，确实长期接触过原始代码库。

传统的 clean-room 方法通常要求严格区分两组人：一组了解原始实现，另一组负责编写新的实现，而两者之间必须完全隔离。

客观的说，在这个项目里，Blanchard 并不满足「clean-room 」这样的隔离要求。

但是他认为，clean-room 方法本身只是一种手段，它的目的在于确保最终产生的代码不是原始代码的“衍生作品”。换句话说，clean-room 是达到目标的一种方式，但并不是目标本身。

在这次情况下，他可以通过直接的技术测量来证明最终结果达到了同样的目标——新的代码在结构上是独立于旧代码的，而不仅仅依赖开发流程上的保证。

基于此，他用代码相似度检测工具 JPlag 给出数据证明：chardet 7.0 版本的文件与 6.0 版本的对应文件，最大相似度仅 1.29%； 而 5.2 版本到 6.0 版本则有些文件相似度高达 80%。

Blanchard 强调，他从零开始创建了新的代码库，没有直接搬运任何旧文件。

如果仅仅因为曾经接触过原始代码就足以否定一次重写，那么对于任何 LGPL 项目的维护者来说，未来想在不同许可证下重新实现相同功能几乎都会变得不可能——无论最终写出的代码与原代码有多么不同。

我不认为 LGPL 的要求是这样的，但我也愿意听取不同的解读。在我看来，核心问题在于：新的代码是否来源于旧代码（是否属于衍生作品）。而从前面提到的证据来看，它并不是。

AI 如何参与

为了保持完全透明，Blanchard 进一步分享了这次重写的具体过程：

我使用了 Claude 的 “superpowers brainstorming” 能力来生成一份设计文档，里面详细说明了我希望采用的架构和实现思路。

这份设计基于我为这次重写设定的一系列要求（这些要求最初是我在手机的 Notes 里写下的，没有提交到仓库中，但我在这里列出来作为背景说明）：

1. 对外 API 保持兼容

2. 项目仍然叫 chardet，因为计划是用新实现替换原有 chardet

3. 不基于任何 GPL 或 LGPL 代码

4. 在测试数据上保持与 chardet 相当的编码检测准确率

5. 语言检测不是硬性要求，但如果实现起来很容易，或者是其他设计的副产品，可以顺带实现

6. 高性能、内存效率高：能够有效利用多核 CPU

7. 没有运行时依赖

8. 必须同时支持 PyPy 和 CPython

9. 设计要干净、现代化

10. 如果使用训练得到的统计模型，数据来源应使用 Hugging Face 的 load_dataset API

11. 任何训练代码都应在本地缓存数据，以便在开发过程中频繁重新训练

12. 经常进行性能基准测试

13. 避免使用大量巨大的字典字面量，因为在 CPython 3.12 中导入这类结构会非常慢

之后，Blanchard 表示，他在一个完全空的仓库中开始开发，并且没有访问旧代码库。同时，他还明确指示 Claude：不要基于任何 LGPL 或 GPL 许可的代码进行实现。

接下来，其本人使用 Claude 对生成的每一部分代码进行审查、测试和反复迭代。

不过，Blanchard 也坦言， 自己并没有逐行手写这些代码，但在整个过程中，他深度参与了架构设计、代码评审以及每一步的迭代改进。

我理解这确实是一个新的、让人不太适应的领域：在一个长期存在的开源项目重写过程中使用 AI 工具，确实会引发合理的疑问。不过，从现有证据来看情况是清楚的：7.0 是一个独立作品，而不是基于 LGPL 代码库的衍生作品，因此使用 MIT License 是正当的。

争议点：AI 生成代码的边界难界定

尽管 Blanchard 力求独立生成代码，但仍存在一些复杂因素。

首先，有网友发现 ，Claude 在重写 chardet 7.0 版本时，明确使用了 chardet 早期版本的一些元数据文件，这引发了业界开发者对这个新版本是否真的是“衍生版本”的质疑。

另一方面，Claude 模型在训练时吸收了大量公开网络数据，其中可能包括早期 chardet 的开源代码。是否意味着 AI 生成的代码属于原作衍生，仍存在争议。

此外，还有人为因素。虽然新版本的代码是由 Claude 生成的，但正如上文提到的，Blanchard 表示他“使用 Claude 对结果的每个部分进行了审查、测试和迭代…… 我没有亲手编写代码，但我深度参与了代码的设计、审查和迭代的每一个环节。” 让一位对早期 chardet 代码非常熟悉的人如此深入地参与新代码的审查，也可能影响到这个版本是否可以被视为一个全新的项目。

不止如此，Blanchard 的所有操作都是在 chardet 这个库的同一个软件包名称、同一个存储库、同一个PyPI 列表中完成的，更重要的是新版本的名字还是叫做 chardet。

网友看法

这起事件在开源社区引发广泛讨论，直指 AI 时代的底层规则空白。

有人为维护者 Blanchard 所受到的指责辩护：

Blanchard 独自维护这个库，无资金、无协作者、无支援。chardet 团队另外两人最晚 2017 年就停更，其中一人 2012 年后再无提交。原作者 2011 年彻底清空互联网痕迹。这是 Python 生态最依赖的包之一，全靠一个人用业余时间撑着。现在这个人做了大家不喜欢的事，突然所有人都对治理、托管、自由软件精神高谈阔论。

也有用户 Armin Ronacher 写了一篇《AI 与忒修斯之船》。他把 AI 重写看作终于摆脱 GPL 的出路 —— 他认为 GPL 限制了分享：

如果你扔掉所有代码从零开始，即便最终行为一致，那也是一艘新船。

不过，有不少网友认为：

把 Copyleft 代码喂给训练过它的模型，让模型生成功能等价产物，指着输出说 “看，没有相似性”。查重工具找不到匹配 token，不代表作品独立，只代表洗白有效。如果这套手法合法，现存所有 Copyleft 项目，只要跑一次 Claude 就能变成 MIT，甚至闭源。正反都行得通。

GitHub 讨论区里，更有人犀利地点评道：把泄露的 Windows 源码丢给大模型重写，再以开源发布，能接受吗？如果不能，解释 chardet 为何不同。机制完全一样，唯一变量是你是否同情版权方。

自由软件基金会（FSF）执行董事 Zoë Kooyman 直言：“AI 模型吸收了要重新实现的代码，因此根本不存在真正‘洁净’。”

一方是经典开源协议的底线，一方是 AI 辅助开发的新现实，在原作者消失、单人维护十年后，项目归谁？新版 chardet 的许可到底谁说了算，你怎么看？

参考：

https://github.com/chardet/chardet

https://shiftmag.dev/license-laundering-and-the-death-of-clean-room-8528/

https://www.theregister.com/2026/03/06/ai_kills_software_licensing/

https://arstechnica.com/ai/2026/03/ai-can-rewrite-open-source-code-but-can-it-rewrite-the-license-too/