Coding Agent 能否用“洁净室”重写为开源项目改授权？chardet 争议引爆讨论
2026年3月5日
过去几个月已经越来越清楚：coding agents 在构建一种“很不传统”的代码“洁净室（clean room）实现”方面，能力非常强。
这个模式最著名的历史案例，是 Compaq 在 1982 年 对 IBM BIOS 做出的洁净室克隆：先由一组工程师逆向 BIOS 形成规格说明，再交给另一组工程师基于规格从零实现。
这种流程过去往往需要多组工程师花上数周甚至数月才能完成。而 coding agents 可以在数小时内做出一个变体——我在去年 12 月就用这个模式的一个版本，针对 JustHTML 做过实验。
这里有大量悬而未决的问题，既有伦理层面的，也有法律层面的。而这些问题如今似乎正在老牌 Python 库 chardet 身上集中爆发。
chardet 由 Mark Pilgrim 在 2006 年 创建，并以 LGPL 发布。Mark 在 2011 年退出公开互联网活动后，chardet 的维护转交他人，尤其是 Dan Blanchard——自 2012 年 7 月的 1.1 版本 起，每个版本都由他负责发布。
两天前，Dan 发布了 chardet 7.0.0，并在发布说明中写道：
chardet 的从零重写版本，使用 MIT 许可证。包名不变、公开 API 不变——可直接替换 chardet 5.x/6.x。只是速度更快、准确率更高！
昨天，Mark Pilgrim 提交了 #327: No right to relicense this project：
[...] 首先，我要感谢当前维护者和这些年来为这个项目做出贡献、推动其改进的每一个人。这确实是自由软件的成功案例。
但是，有人提醒我，在 7.0.0 版本中，维护者声称他们有权为项目“重新授权（relicense）”。他们并没有这种权利；这样做明确违反 LGPL。带许可证的代码在被修改后，必须继续以相同的 LGPL 发布。他们所谓“完全重写”的说法无关紧要，因为他们曾大量接触原先的许可证代码（即这并不是“洁净室”实现）。往流程里加一个花哨的代码生成器，并不会神奇地赋予他们额外权利。
Dan 在一则长回复中表示：
你说得对，我确实长期接触原始代码库：我维护它已经十多年了。传统洁净室方法要求“了解原始代码的人”和“编写新实现的人”严格隔离，而这里并不存在这种隔离。
但洁净室方法的目的，是确保结果代码不构成原作的衍生作品。它是手段，不是目的本身。在这个案例里，我可以通过直接测量来证明结果一致——新代码在结构上独立于旧代码——而不是只依赖流程上的保证。
Dan 接着给出了 JPlag 工具的结果（该工具自称“State-of-the-Art Source Code Plagiarism & Collusion Detection”）：新发布的 7.0.0 与上一个版本的最高相似度为 1.29%，与 1.1 版本为 0.64%。而其他历史版本之间的相似度通常在 80%~93%。
随后他披露了流程中的关键细节，其中这段尤其值得注意：
为了完全透明，下面是这次重写如何开展的。我使用 superpowers 的头脑风暴能力创建了一份设计文档，基于我为这次重写设定的一系列需求，明确了目标架构和方法 [...]
然后我在一个空仓库里开始，没有访问旧源码树，并且明确要求 Claude 不要基于任何 LGPL/GPL 许可证代码。 之后我使用 Claude 对结果的每个部分进行审查、测试和迭代。[...]
我理解这是一个新且令人不安的领域，在重写一个长期存在的开源项目时使用 AI 工具，会引发合理质疑。但这里的证据很清楚：7.0 是独立作品，不是 LGPL 代码库的衍生作品。MIT 许可证适用于它，且具有正当性。
由于这次重写使用了 Claude Code，仓库里留下了大量有意思的过程痕迹。尤其是 2026-02-25-chardet-rewrite-plan.md 非常详细，按阶段展示了重写流程——先从测试入手，再逐步补全计划中的替代代码。
这个案例之所以很难得出有把握的结论，还因为存在多个“转折点”：
- Dan 已深度维护 chardet 超过十年，显然不可避免地受到原始代码库影响。
- 有一个例子显示 Claude Code 在工作时确实引用了原代码库的内容，如该计划文档所示：它查看了 metadata/charsets.py。这个文件以 dataclass 字典形式列出字符集及其属性。
- 更复杂的是：Claude 本身极有可能在海量训练数据中见过 chardet——但我们无法确认。一个在某代码库上训练过的模型，能否产出在道德或法律上站得住脚的洁净室实现？
- 如 2014 年这个 issue 所讨论（Dan 首次公开考虑改许可证），Mark Pilgrim 的原始代码本身就是把 Mozilla 的 MPL 许可字符检测库从 C 手工移植到 Python。
- 新版 chardet 继续使用原有 PyPI 包名，这一点究竟有多关键？如果以新名称发布一个全新包，是否会更有说服力？
我也不知道这件事最终会如何发展。就我个人而言，我倾向于认为这次重写是正当的；但双方的论点都完全站得住脚。
在我看来，这是一个更大问题的缩影：当 coding agents 用于对既有、成熟代码进行“重新实现”时，我们该如何界定边界？这个问题先在开源世界爆发，但我预计很快也会出现在商业世界里的“Compaq 式”场景中。
一旦商业公司意识到其严密保护的 IP 受到威胁，我预计我们会看到资金充足的诉讼陆续出现。
