维护者利用AI扼杀了他的开源许可证,只用了五天.

一年内下载量达8.54亿次。Claude Code仅用五天。

仅仅如此，就剥夺了 chardet 长达二十年的 copyleft 保护。chardet 是一个 Python 字符编码库，几乎内置于地球上每一个 Python 环境中。

在深入探讨之前，我们先来澄清本文将围绕的两种重要许可证类型：

LGPL 规定：“你可以使用此代码，但如果对其进行修改，你必须在相同条款下分享你的修改。”MIT 则表示：“你可以随心所欲。”前者旨在保护社区，而后者则允许企业在不回馈的情况下获取。

pip install

2026年3月2日，Dan Blanchard 发布了 chardet 7.0.0。他称之为“一次从头开始、采用 MIT 许可证的重写”。自2006年以来一直保护该库的 LGPL 许可证已不复存在，取而代之的是 MIT 许可证。执行此次重写的工具是 Anthropic 的 Claude Code，运行 Opus 4.6 版本。

两天后，Mark Pilgrim 回归了。Pilgrim 于2006年创建了 chardet。2011年，他删除了自己在互联网上的所有痕迹，这一行为被互联网称为“信息自杀 (infosuicide)”。在十五年的沉默之后，他十多年来的首次公开帖子是 GitHub Issue #327，标题为：“无权重新授权此项目。”

1,468人对此表示认同。目前，该议题已被锁定。

如果你是一名 Python 开发者，你几乎肯定依赖于 chardet。而围绕其许可证的法律斗争，可能会决定在 AI 时代，copyleft 是否仍具有实际意义。

The Creator Erased Himself

Mark Pilgrim 于2006年创建了 chardet，作为 Mozilla C++ 字符集检测代码的 Python 移植版。他将其以 LGPL 许可证发布，LGPL 是一种 copyleft 许可证，要求衍生作品必须保持相同的许可条款。该库主要用于检测字符编码，这是一种实现文本在不同语言和系统间正确显示的“隐形管道”。

2011年，Pilgrim 进行了他后来被称为“信息自杀 (infosuicide)”的行动。他删除了自己的博客和在 GitHub 上的所有资料，彻底从互联网上消失。

Dan Blanchard 于2012年7月接任维护者一职，并使 chardet 持续运行了十多年。这十多年间，他进行了无数的错误修复、兼容性更新，以及默默无闻地维护这个每月下载量高达1.35亿次却鲜有人关注的库。

Daring Fireball 的 John Gruber 指出，Issue #327 是“我很久以来看到的 Pilgrim 的第一篇公开帖子。”十五年的沉寂，因一场许可争议而被打破。

五天、264 次提交，以及一个新许可证

Blanchard 的立场很明确。他希望 chardet 更快、更准确，同时摆脱他认为具有限制性的 LGPL 许可约束。

“过去阻碍我实现这些目标的主要因素是时间，” Blanchard 写道。 “Claude 让我在大约五天内就能完成我想要的一切。”

Blanchard 从一个空的仓库（repository）开始，就像雇佣承包商在同一地块上建造新房。他指示 Claude 不要引用 LGPL 许可的代码。PR #322 显示有 264 次提交。JPlag 抄袭分析工具发现 chardet 7.0.0 与前一版本之间仅有 1.29% 的相似度。作为对比，5.x 到 6.x 版本之间则显示出 80% 到 93% 的相似度。

新版本宣称实现了显著改进：

• 通过 mypyc 编译，速度提升 41 倍

• 准确率达到 96.8%（提高 2.3 个百分点）

• 支持 99 种编码（相比旧版本的约三四十种大幅增加）

• 实现了零外部依赖

但问题在于，在开发过程中，Claude 引用了原始代码库中的文件。在一个旨在保持纯净的流程中，发生了唯一一次“污染”事件。

metadata/charsets.py

图片来源：作者，chardet AI 重写流程图

“无权重新授权许可。”

Pilgrim 的反对意见直指版权法和 Copyleft 许可的核心要义。

“被许可的代码，在修改后，必须以相同的 LGPL 许可发布，” Pilgrim 写道。 “在其中加入一个花哨的代码生成器，并不能因此赋予他们任何额外的权利。他们声称这是一次‘彻底重写’，但这与事实无关，因为他们曾充分接触原始许可的代码（即，这并非‘洁净室’（clean room）实现）。”

“洁净室”（clean-room）实现要求严格的分离，就像仅根据设计规范来制造汽车发动机，而从未见过原始发动机一样。一个团队负责记录行为，而另一个完全独立的团队则负责编写代码。Blanchard 曾维护 chardet 超过十三年，但他本人就身处这两个团队之中。而几乎可以肯定是在 chardet 源代码上进行过训练的 Claude，则是实际的构建者。

自由软件基金会 (FSF) 介入此事。FSF 执行董事 Zoë Kooyman 告诉 The Register： “一个大型语言模型 (Large Language Model, LLM) 摄入了其被要求重新实现的代码，这样的模型毫无‘纯洁’可言。” 她补充道：“削弱 copyleft 是一种严重的行径。”

来自 NVIDIA 的 Madison Taylor 在评论 Issue #331 时直言不讳地指出了实际情况： “在没有获得所有贡献者批准的情况下，这种风险可能根本无法消除，而 Mark 目前看来并不愿意批准。”

244 条评论。问题被锁定。没有解决方案。

每条法律途径都是死胡同

就在 Blanchard 发布 chardet 7.0.0 的同一天，美国最高法院拒绝审理 Thaler 诉 Perlmutter 一案。在该案中，Stephen Thaler 辩称他的人工智能应被列为其生成艺术作品的作者。法院驳回了这一请求：只有人类才能拥有版权 (copyright)。

这一驳回形成了一个三难困境，好比一个所有信号灯都显示红色的十字路口。

Credit: Author, The Three-Way Legal Paradox

1. 路径 1 ： AI 生成的代码没有版权，因为它并非由人类创作。在这种情况下，Blanchard 应用的 MIT 许可证毫无意义。该代码属于公有领域 (public domain)。任何人都可以使用它，但无人拥有其所有权。
2. 路径 2 ： AI 输出是派生作品 (derivative work)，因为该模型是在 LGPL 许可的代码上训练的。Blanchard 的重写必须遵守 LGPL，这使得以 MIT 许可证重新授权成为违规行为。
3. 路径 3 ： AI 输出是独立新作 (independent new work)。1.29% 的相似度表明是真正的原创作品，并且 MIT 许可证是有效的。

每条路径都会给某些人带来问题。路径 1 摧毁了 AI 编码工具的商业模式。路径 2 意味着每一行 AI 生成的代码都可能带有其训练数据的许可证。路径 3 意味着地球上任何 copyleft 项目都可以通过 LLM “洗白”为宽容性许可证。

《开源定义》的作者 Bruce Perens 直言不讳地表示： “我要打破玻璃拉响警报！整个软件开发的经济体系已经死亡、消逝、结束，彻底完蛋了！”

贵公司是否评估过您的 AI 编码工具是否遵守其训练所用代码的许可证？如果还没有，那么这个案例就与你息息相关。

五天之内终结二十年的保护

Flask 的创建者 Armin Ronacher 用一个词来形容 chardet 所发生的事情：“slopfork”。

他借用忒修斯之船的悖论阐明了更深层的问题：“如果你完全抛弃现有代码并从零开始，即使最终行为表现一致，它也构成了一艘‘新船’。”

然而，Ronacher 也指出了结构性弱点：copyleft 的效力依赖于“摩擦力”。他写道：“因为代码编写的成本日益降低，这其中也包括重新实现。”人工智能 (AI) 的出现，使得复现软件行为的成本变得微乎其微，而copyleft 对此束手无策。

这一洞察解释了为何此事的影响远超 chardet 本身。

图源：作者，《人工智能前后的 Copyleft 保护》

Copyleft 真正的保护从来不是许可证本身，而是重写的成本。当重写所需的时间从五年骤降至五天时，许可证就只剩下一纸空文。

如果 chardet 的做法被接受，其“食谱”将异常简单：选取任何 GPL、LGPL 或 AGPL 项目，将其行为（而非代码）输入大型语言模型 (LLM)。然后，生成一个新的实现，声称其相似度极低，并应用 MIT 许可证。届时，唯一能剩下的保护措施将是商标权。你不能将你的分支命名为“chardet”，但除此之外，一切都将任人予取予求。

OSnews 的 Thom Holwerda 将其回应文章命名为“大规模许可证洗牌已然开始”，并警告称：“‘AI’是历史上对开源领域最严重的协同攻击。”

开源社区的反应与后续

开源社区已然开始做出反应：

• NetBSD 和 Gentoo 已全面禁止接受人工智能生成的代码贡献

• Debian 仍在就此进行辩论

• Daniel Stenberg 在收到大量由 AI 生成的报告后，关闭了 curl 的 Bug 赏金计划

• 作为 chardet 的一个免 LGPL 替代方案，charset-normalizer 已经面世，为那些希望在没有法律风险的情况下进行字符编码检测的用户提供了选择

你的

正在资助这场斗争

在任何机器上运行

pip install requests

。自 2.26.0 版本以来，requests 默认依赖 charset-normalizer，但 chardet 仍作为依赖链中受支持的替代品存在。如果你在生产环境中部署 Python，你很可能也是这场事件的参与者之一。

如果此事件引起你的关注，请点赞并分享，让更多的 Python 开发者看到它。这不仅仅是 chardet 的困境。

chardet 案例绝不会在 GitHub 评论区中尘埃落定。它需要通过法庭裁决，或至少，就人工智能生成的代码是否继承其训练数据许可证的问题，给出明确的法律意见。在此之前，所有使用 chardet 7.0.0 的项目都将面临法律上的不确定性。

Blanchard 维护 chardet 长达十三年之久，这份工作值得认可。然而，他所选择的机制——利用人工智能将遵循 copyleft 协议的代码以宽松许可证重写——威胁到了所有有意选择 copyleft 协议的开源贡献者所赖以生存的根本基石。

Mark Pilgrim 之所以选择 LGPL 协议，自有其缘由。二十年前，他便做出了此项选择，而为捍卫这项选择，他打破了长达十五年的沉默。问题的关键在于，法律体系能否及时跟进那些使得其选择变得如此容易规避的新技术发展。

请检查您的依赖关系树。如果您的依赖关系中包含 chardet 7.0.0 版本，请将其锁定至 6.x 版本，直至法律局面明朗。同时，审查贵组织关于人工智能生成代码及许可证合规性的相关政策。如果您正在维护一个 copyleft 项目，那么当从零开始重写代码的成本从五年缩短至五天时，请开始思考何种保护措施依然有效。

谁是谁非？ Blanchard 从零开始重写了代码，并拥有长达十三年的维护者贡献。Pilgrim 是原始代码的作者，他选择 LGPL 协议也自有其理由。请选择您的立场，并在评论区告诉我们您的理由。