一份悄悄换掉的许可证，炸出了一条 Python 供应链
2026 年 3 月 4 日，GitHub 上一个编号很靠前的 issue 突然炸了。
有人发现，Python 生态里年下载量约 8.5 亿次的字符编码检测库 chardet，在最新发布的 7.0.0 版本里，许可证从 LGPL 悄悄换成了 MIT。这本来不稀奇--开源项目换许可证的事时有发生。但这次不一样。
维护者 Dan Blanchard 用 Anthropic 的 Claude Code，在 5 天内把整个库从头到尾重写了一遍。JPlag 相似度分析显示，新版和旧版的代码相似度只有 1.29%，而旧版本之间的相似度高达 80-93%。从技术上看，这是一个"全新"的代码库。
但问题在于--Dan 在重写过程中深度接触过原 LGPL 代码。这算不算"clean room"？
就在社区吵得不可开交的时候，issue 里出现了一条评论，把所有人看愣了。
评论者的 ID 叫 Mark Pilgrim--chardet 的原作者，一个已经从开源社区消失了整整 15 年的人。他说：维护者深度接触过原许可代码，这不是真正的 clean room。
242 条评论涌进来。The Register、Ars Technica 等科技媒体跟进报道。开源定义（OSD）的原作者 Bruce Perens 发出警告："软件开发的经济整体已死。" FSF 的 Zoe Kooyman 称 AI 介入是"高度反社会"行为。
社区给这种现象起了个名字--许可证漂白（License Laundering）。
但另一边也有人替 Dan 说话：代码相似度只有 1.29%，这难道不算创新？GPLv3 的共同作者 Richard Fontana 就泼了盆冷水："看不出必须以 LGPL 发布的理由。"
一边是「漂白」，一边是"创新"。要搞清楚这场争论的内核，得先回答一个更基础的问题--
许可证这东西，到底是个什么魔法？
开源许可证到底是什么
你可能会觉得，开源不就是把代码放到 GitHub 上让大家免费用吗？没那么简单。
开源软件仍然受版权法保护。版权持有人没有放弃版权，而是通过一份"许可证"告诉大家：你可以用我的代码，但得遵守这些条件。
这就像房东出租房子--房子还是房东的，但租客可以在里面住、做饭、请朋友来玩，前提是按合同来。违反合同？房东可以收回钥匙。
2008 年，美国联邦巡回上诉法院审理了一个叫 Jacobsen v. Katzer 的案子。被告未经许可使用了开源代码，还删掉了原作者的署名信息。被告辩称"我根本没签过什么协议，顶多算合同违约"。但法院明确裁定：开源许可证的条件是版权法下的条件，违反就是版权侵权，不是简单的合同纠纷。
这个判例一锤定音--开源许可证有牙齿，会咬人。
2026 年 5 月，另一桩案子也进入了庭审。软件自由保护协会（SFC）起诉电视厂商 Vizio，指控其智能电视的 Linux 系统没有按 GPLv2/LGPLv2.1 要求公开完整源码。这个案子的结果可能外溢到 LG webOS、三星 Tizen、Roku OS 等所有基于 Linux 的智能电视系统。
开源许可证不是写着玩的。那 chardet 事件里的 LGPL 又是什么？为什么换成 MIT 会引发这么大的争议？
许可证三大家族
理解开源许可证，最简单的方式是按"对你自由的约束程度"分成三大家族。FSF（自由软件基金会）就是这么分类的。
家族一：宽松型--"拿去用，记得署名"
这类许可证最随和，基本上就一句话：你随便用、随便改、随便卖，但别忘了在软件里留个我的名字。
代表成员：MIT、Apache 2.0、BSD
| 许可证 | 一句话概括 | 专利条款 |
|---|---|---|
| MIT | 最短最宽松，几乎零限制 | 无 |
| Apache 2.0 | 企业级宽松，含专利保护 | 有，含报复条款 |
| BSD 2-Clause | MIT 的老前辈，极简 | 无 |
| BSD 3-Clause | 多了一条：别用我的名字打广告 | 无 |
用这类许可证的项目，你可以放心拿来做商业产品、闭源分发，只需要在代码里保留版权声明和许可证文本。Apache 2.0 比 MIT 多了一个重要的东西--专利授权。如果你用了 Apache 2.0 的代码，贡献者不仅给了你版权许可，还给了你相关专利的使用权。但有个"报复条款"：你要是拿这代码去告别人专利侵权，你的专利许可就没了。
这就是为什么大公司更偏爱 Apache 2.0--它提供了专利维度的保护。### 家族二：弱 Copyleft--"改了就得开源，但调用我的不用"
这一家族开始讲条件了：你可以用我的代码，但如果修改了我给你的东西，修改后的版本也得用同样的许可证开源。不过，你自己的代码不用开源。
代表成员：LGPL（库级）、MPL 2.0（文件级）、EPL 2.0（文件级）
这里的"级别"很关键：
- 文件级（MPL/EPL）：你改了我的某个文件，那个文件得开源。但你新建的文件不受影响。
- 库级（LGPL）：你修改了我的库，库得开源。但你的应用程序通过接口调用这个库，应用程序可以闭源。
LGPL 就是为"库"场景量身定制的。你写了个商业 App，动态链接了一个 LGPL 的库，没问题--你的 App 可以闭源。但如果你改了这个库本身，改后的库得用 LGPL 开源。
回到 chardet 事件--原作者用 LGPL 是有道理的。他想保证库本身始终开源，但不阻止商业项目使用。而维护者把它改成 MIT，意味着任何人都可以把 chardet 的代码拿去闭源，这恰恰是 LGPL 想防止的。
家族三：强 Copyleft--"碰了就得全开源"
这是最严格的一族。用了我的代码，你整个程序都得用我的许可证开源。没有讨价还价的余地。
代表成员：GPL v2、GPL v3、AGPL v3
GPL 就像一个"传染源"--一旦你的代码和 GPL 代码产生了"衍生关系"，整个程序就会被"传染"，必须以 GPL 许可证开源。这就是为什么它被称为"病毒式许可证"。
AGPL 是 GPL 的加强版，专门对付 SaaS 场景--后面会详细讲。
理解了三大家族，就能看懂 chardet 事件的本质了：从 LGPL 到 MIT，是从"弱约束"跳到了"零约束"。 争论的焦点不是代码本身好不好，而是这种跳跃合不合法、合不合伦理。
"传染性"到底怎么运作的
这是很多人最困惑的问题：到底什么情况下会"被传染"？
关键在于一个词：分发（distribution）。
GPL 的开源义务只在"分发"时触发。也就是说，只有当你把包含 GPL 代码的程序交给第三方时，才需要开源。如果你只是在自己公司内部用、自己改自己用，不对外分发，那就不需要公开任何东西。
这就引出了一个著名的漏洞--SaaS 漏洞。
假设你拿了一个 GPL 数据库，加了自己的查询优化算法，部署在服务器上，以 API 服务的形式提供给用户。用户通过网络调用你的接口，但他们从来没有"拿到"你的软件副本。分发从未发生，所以你不需要公开任何修改。
在 GPL 的框架下，这完全合法。
FSF 看到这个漏洞后坐不住了，于是搞出了 AGPL。
AGPL：堵住 SaaS 漏洞
AGPL v3 在 GPL 基础上加了一条--第 13 条"远程网络交互"：
如果你运行修改后的 AGPL 软件，让用户通过网络与之交互，你必须向这些用户提供对应源码。
触发点不再是"分发"，而是网络访问。这意味着，即使你不分发任何副本，只要用户通过网络使用了你修改过的 AGPL 软件，你就得公开修改的源码。
这条款对 SaaS 和云服务公司来说简直是噩梦。所以很多公司的法务部门有一条铁律：生产代码禁用 AGPL。
那如果链接方式不同，传染情况又如何呢？这里有一个从"确定传染"到"通常安全"的梯度：
| 组合方式 | 是否触发传染 | 说明 |
|---|---|---|
| 静态链接 GPL 代码 | 确定 | 编译成同一个可执行文件，是共识 |
| 动态链接 GPL 库 | 多数情况是 | 共享地址空间 + 复杂数据交换，倾向衍生作品 |
| Socket / 管道 / 命令行通信 | 通常不是 | 视为独立程序间通信，但交换复杂数据结构仍有风险 |
| 调用独立服务（网络 API） | 不是 | 调用方和被调程序完全独立 |
一个常见的"规避"手段是所谓的 wrapper 技术：在 GPL 代码和你的专有代码之间放一层薄薄的中间层，通过 socket 跨网络通信，试图"切断"传染链。但 FSF 的立场是--如果双方交换的数据结构足够复杂（比如直接实例化 GPL 代码中定义的类对象），这个手段未必能过关。
现在你可能已经看出来了：copyleft 的整个体系，建立在"代码是衍生作品"这个法律概念上。 而 AI 重写，恰恰打的就是这个概念的根基。
"创新"的一面
先别急着下定论。我们来看看支持 Dan 的人怎么说。
从技术上看，这是一次真实的重写。 JPlag 相似度分析显示，新版和旧版的代码相似度只有 1.29%。如果把代码提交给任何抄袭检测工具，结论都是"全新代码"。旧版本之间的相似度高达 80-93%，而新版本完全不在那个范围。如果代码不相似，凭什么说它是"衍生作品"？
Dan 的动机也说得通。 他想把 LGPL 改成 MIT，是为了让 chardet 有机会进入只接受宽松许可的 Python 标准库。这不是为了个人牟利，是为了库的生态前景。
而且，版权法里有"idea-expression 二分法"。 思想（idea）不受版权保护，只有表达（expression）受保护。AI 重写恰恰是保留了思想、改变了表达。如果表达确实不同--1.29% 的相似度似乎证明了这一点--那在版权法框架下，这可能根本不构成侵权。
GPLv3 的共同作者 Richard Fontana 也泼了盆冷水： "看不出必须以 LGPL 发布的理由。" 他的意思是，LGPL 的约束力本来就不像 GPL 那么强，换成 MIT 并不是什么大逆不道的事。
这些论点听起来都有道理。那为什么社区还是炸了？
「漂白」的一面
因为硬币的另一面，远比相似度数字复杂得多。
传统的 clean room 有严格的隔离要求。 标准做法是：A 团队读原始代码，写一份规格文档；B 团队只看文档写代码，双方零接触。这是法律上被认可的"净室开发"。而 Dan 一个人用 AI 重写了所有代码，过程中还被发现参考了旧版的 metadata 文件。一个人既读了原代码又写了新代码，隔离从何谈起？
原作者 Mark Pilgrim 的回归，让"知情同意"的问题浮出水面。 他消失了 15 年，却在这个节骨眼上冒出来说了一句--维护者深度接触过原许可代码，这不是真正的 clean room。原作者的态度本身就是法律判断的重要参考：他不同意这种做法。
更深层的问题在于 Bruce Perens 的担忧。 如果 AI 统计性重写可以绕过 copyleft，那版权法基于"idea-expression 二分法"的整个根基就被动摇了。许可证不再有约束力，因为任何人都可以让 AI 漂白一遍代码再换个许可证。Perens 的原话是："软件开发的经济整体已死。" 这话听起来夸张，但逻辑是成立的--copyleft 的全部价值在于"衍生作品必须开源"，如果 AI 重写能切断"衍生"关系，copyleft 就成了一纸空文。
FSF 的 Zoe Kooyman 把话说得更重。 她称 AI 介入是"高度反社会"行为。FSF 的立场一贯明确：自由软件的约束不仅是对代码的约束，也是对社区伦理的约束。用 AI 绕过这种约束，是对整个自由软件运动的不尊重。
社区把这种现象命名为许可证漂白（License Laundering），逻辑和资金漂白一模一样：来历不明的钱（copyleft 代码），经过一系列操作（AI 重写），变成了看起来干净的钱（MIT 代码）。但来源的痕迹真的抹掉了吗？
更麻烦的是，chardet 是 requests、urllib3、pip 的底层依赖。NVIDIA 的工程师直接说 7.0.0 版本"绝对有毒"--不是因为代码有问题，而是因为许可证的争议状态本身就让企业法务不敢用。
截至 2026 年 7 月，这个争议还没有法律结论。
大背景：为什么是现在
chardet 事件不是孤立的。理解了许可证体系，再来看 2025-2026 年发生的一连串事件，脉络就清晰了--这是一个"云厂商免费搭便车"与"开源项目反击"的拉锯战，而 AI 重写是最新出现的一条裂缝。
Redis 回归开源（2025 年 5 月）
2024 年 3 月，Redis 从 BSD 改成 SSPLv1 + RSALv2 双重许可。AWS、Google、Oracle 当周宣布 Valkey 分叉，保持 BSD 3-Clause。社区一片哗然。
一年后，2025 年 5 月 1 日，Redis CEO Rowan Trollope 在官方博客宣布：自 Redis 8 GA 起，在原有许可证之外新增 AGPL v3 作为第三个选项。AGPL v3 是 OSI 认证的开源许可证，这意味着 Redis 重新获得了"开源"身份。
为什么选 AGPL？Redis 官方的说法是"重建与开源社区的信任"。但更实际的原因是--Valkey 分叉在 AWS ElastiCache 上线后大获成功，Redis 公司看到了失去生态的风险。AGPL 既能保持开源身份，又能让云厂商想用就得公开自己的代码。
Elastic 的三年学费（2021-2024）
Elastic 走了同样的路。Elasticsearch 原本是 Apache 2.0，AWS 直接搞了个 Amazon Elasticsearch Service。Elastic 一怒之下在 2021 年改成了 SSPL + ELv2 双重许可。AWS 当周就分叉出了 OpenSearch。
但三年后，2024 年 8 月，Elastic 创始人 Shay Banon 宣布"再次开源"--在原有许可证基础上增加 AGPL v3 作为第三个选项。他在博客里说："对于像我们这样的基础架构软件来说，AGPL 已经足够了。"
这是 Elastic 用三年学费换来的答案。
Unleash 跟进（2026 年 6 月）
2026 年 6 月 2 日，特性开关平台 Unleash 的联合创始人 Ivar Østhus 官宣：核心仓库源码从 Apache 2.0 转为 AGPLv3，自 v8.0.0 起生效。理由同样是防止云厂商"商业分叉免费搭便车"。
Unleash 做了一个巧妙的设计--官方 Docker 镜像仍保留 Apache 2.0、SDK 不变、企业版仍为商业许可。源码 AGPL，但生态接口保持宽松，让用户有平滑过渡的空间。
这一系列事件的根本动因可以浓缩成一句话：云厂商拿你的代码搞托管服务赚得比你多，你不干了。而 AI 的出现，又给了"绕过 copyleft"一条看似可行的新路径--chardet 事件正是这条路径上第一个被曝光的案例。
"源码可用"不等于"开源"
前面说的都是 OSI 认可的开源许可证。但近几年出现了一批"看起来像开源、实际不是"的许可证。
OSI（开放源代码促进会）有一套开源定义（OSD），共 10 条标准。一个许可证要想被认证为"开源"，必须全部满足。其中最关键的三条：
- 第 5 条：不歧视任何人或群体
- 第 6 条：不歧视任何应用领域（不能禁止商业使用）
- 第 9 条：不得限制同介质分发的其他软件
MongoDB 在 2018 年发明了 SSPL（Server Side Public License），要求作为服务提供时不仅程序本身要开源，连你的管理工具、备份软件、监控界面等整个服务栈都得开源。这违反了第 5、6、9 条，OSI 直接拒绝认证。
MariaDB 在 2013 年搞了 BSL（Business Source License），在转换期内禁止"生产使用"和"竞争性使用"，违反了第 6 条。
这些许可证有一个统称：源码可用（Source-Available）。你可以看代码、甚至可以改代码，但商业使用受限。OSI 明确表示，这类许可证不是开源。
2025 年，OSI 执行董事 Stefano Maffulli 打了个比方："把 BSL 称为开源，就像把素汉堡称为牛肉。"
但 HashiCorp、MongoDB 这些公司也有自己的道理--他们认为 OSI 的定义写于 1998 年，没有预见到云时代的商业模式：AWS 拿着你的代码搞托管服务，赚得比你还多，你却一点办法没有。
这就是为什么 Redis 和 Elastic 最终都选了 AGPL--它既是 OSI 认可的开源许可证，又能约束云厂商。而 chardet 事件里的 MIT，恰恰是另一个极端：连最基本的"改了得开源"都不要求。
二次开发的雷区地图
对于想用开源基座做二次开发的人来说，到底哪些操作是安全的，哪些是雷区？
| 二开方式 | 触发 Copyleft？ | 风险等级 |
|---|---|---|
| 直接修改 GPL 源码然后分发 | 是，必须以 GPL 开源 | 高 |
| 静态链接 GPL 代码到你的程序 | 是，整个程序被传染 | 高 |
| 动态链接 GPL 库 | 多数情况是，存在争议 | 中高 |
| 用 wrapper + socket 跨网络调用 GPL | 通常不是，但有灰色地带 | 中 |
| 调用独立服务（HTTP API） | 不是，完全独立 | 低 |
| 修改 LGPL 库本身并分发 | 库须开源，你的 App 不用 | 中 |
| 动态链接 LGPL 库，不修改库 | 不触发，App 可闭源 | 低 |
| 使用 MIT/Apache 2.0 代码 | 不触发，保留声明即可 | 极低 |
| 用 AI "重写" copyleft 代码 | 法律未定，极高风险 | 未知 |
最后那行是 chardet 事件留给所有人的警示--用 AI 重写 copyleft 代码再换个许可证，目前没有判例支持其合法性。在企业生产环境中，这种行为的风险比直接违反 GPL 还要高，因为你不只是面临版权侵权，还面临整个许可证链条的不确定性。
最安全的方式是调用独立服务--把开源项目部署为独立进程，通过标准 HTTP API 调用。这种模式下，调用方和被调程序是完全独立的程序，不构成衍生作品。Elastic 官方 FAQ 也确认了：用 Elasticsearch 作为后端构建 SaaS 应用不受许可证变更影响。
如果你不得不深度修改 GPL 代码并需要闭源分发，还有最后一条路--购买商业许可。很多 GPL 项目（如 MySQL、Qt）采用双重许可模式：免费版是 GPL，付费版是商业许可。你选了商业许可，就不用受 Copyleft 约束了。
给开发者的避坑清单
选基座时先看 LICENSE 文件。 是 OSI 认可的开源许可证，还是 BSL/SSPL 这类"源码可用"许可证？后者不是开源，商业使用有限制。如果看到 BSL，先查有没有 OSI 认可的分叉版本--OpenTofu、Valkey、OpenSearch、OpenBao 都是现成的替代。
理解传染性边界。 GPL 的传染性由"分发"触发，内部使用和 SaaS 服务（GPL 而非 AGPL 的情况下）不触发。AGPL 把触发点扩展到网络交互。链接方式决定传染范围--静态链接确定传染，API 调用通常安全。
注意兼容性陷阱。 GPL v2 和 Apache 2.0 不兼容，这是实务中最常见的坑。原因是 Apache 2.0 的专利条款不在 GPL v2 的覆盖范围内，Stallman 后来在 GPL v3 中修复了这个问题。另外，选 GPL v2 的项目时，优先选"GPL v2 or later"而非"GPL v2 only"，前者保留了向前兼容的灵活性。
警惕许可证变更风险。 许可证不是一成不变的--Elasticsearch 2021 年从 Apache 2.0 改成了 SSPL，Redis 2024 年从 BSD 改成了 SSPL，chardet 2026 年差点从 LGPL 改成 MIT。在使用开源基座时，锁定一个版本并持续监控许可证变更，是必要的防御措施。
别碰 AI 重写的 copyleft 代码。 chardet 事件给所有人敲了警钟--用 AI 重写 copyleft 代码再换许可证，法律风险未知，供应链影响却是实打实的。如果你的依赖链里有这样的项目，企业法务大概率会直接拉黑。
建好 SBOM。 SBOM（软件物料清单）已经不是可选项了--美国 EO 14028 行政令、欧盟 CRA 网络韧性法案都要求企业提供 SBOM。用 FOSSA、Black Duck 或 Snyk 这类 SCA 工具扫描依赖树，搞清楚你的项目里到底引入了哪些许可证。
尾声：漂白还是创新
chardet 事件的后续怎样了？
截至 2026 年 7 月，争议仍在发酵。社区分成了两派：一派认为 AI 重写是技术进步的必然，版权法需要与时俱进；另一派认为这是对 copyleft 理念的釜底抽薪，如果这条路走通了，所有 copyleft 许可证都将形同虚设。
而那个消失 15 年又突然回归的原作者 Mark Pilgrim，在留下一串评论后，又一次沉默了。
「漂白」还是"创新"--这个问题的答案，可能不在于代码相似度是 1.29% 还是 80%，而在于我们如何定义"衍生"。当 AI 能够把任何代码的表达形式完全替换、同时保留其功能与思想时，版权法赖以运转的 idea-expression 二分法，第一次面临了真正的挑战。
开源世界里，代码是免费的，但不懂规则的成本可能很贵。尤其是当 AI 开始改写规则的时候。
