AI代码版权：开源的防线在AI面前塌了

2026年3月，Python生态里发生了一件让整个开源社区坐不住的事。

chardet，一个每月被下载1.3亿次的字符编码检测库，维护了十多年，许可证是LGPL。3月5日，有人借助Claude Code，用三个小时把整个代码库重写了一遍，然后以MIT许可证重新发布。MIT比LGPL宽松得多——你不用开源自己的修改，想怎么用怎么用。

原作者当场炸了："你没有权利重新授权。修改后的代码必须以相同的LGPL发布。AI重写不能给你任何额外权利。"

Flask创建者Armin Ronacher的意见却截然相反。他公开支持这次许可证变更，理由是：既然AI能轻易重写任何开源代码，GPL这类Copyleft许可证的约束力本来就正在瓦解。与其死守一个没人能执行的协议，不如承认现实。

开源定义的原起草者Bruce Perens发出了尖锐警告："我正在打破玻璃拉响火警。"他的原话。

不是法律争论。是警报。

Copyleft的约束力建立在三个前提之上：代码可溯源、复制可证明、许可证可执行。AI编程工具把这三个前提同时打穿了。

第一个前提——代码可溯源。GPL的传染性要求你拿了GPL代码做修改，发布时必须开源你的修改。但AI模型训练不是"复制代码"，而是"学习代码"。模型读取了数百万行GPL代码，把编程模式、算法逻辑编码进权重参数。权重的本质是统计抽象，不是代码副本。你怎么证明模型输出的这段代码"来自"你那个GPL项目？

第二个前提——复制可证明。Doe v. GitHub案，程序员集体起诉微软和OpenAI用GitHub上的开源代码训练Copilot模型，声称Copilot有时会逐字复现训练集中的代码。一审法院驳回了大部分主张，理由是原告无法证明具体的"复制"在哪里发生。上诉仍在审理中。到2026年6月，全球没有任何一家法院裁定"模型训练后的权重是GPL代码的派生作品"。这个法律空白，够大。

第三个前提——许可证可执行。就算你真的发现AI输出的代码跟你写的GPL代码高度相似，谁去起诉？开源作者大多是个人开发者，他们没有法务团队。偷代码的大厂有。GitHub Copilot在2026年的周活跃用户超过了500万，但GitHub没有义务替原作者追查每一次可能的版权侵权。

三个前提全塌了。

开源的防线不是被人攻破的，是被技术绕过去的。

今年6月，我翻完了GitHub上过去三个月涉及AI代码归属的120多个issue讨论，发现一个规律：维权声音最大的，是个人开源作者；响应最快的，是已经把代码"洗"过一遍的商业公司。

美团Tabbit AI浏览器的事件更有代表性。字节跳动前工程师公开喊话美团：Tabbit抄袭了他的开源代码，根据GPL协议，任何使用该代码的产品都要开源。美团团队的回应出人意料地坦诚：他们承认fork了原作者的代码，但声称当时项目仓库里没有开源协议声明，原作者是在他们fork之后才加上的GPLv3。最终他们移除了相关代码，把项目完整开源了。

这个案例的魔幻之处在于：如果美团不回应，GPL能不能约束他们？如果他们没有回应而是直接用AI把那段代码"重写"一遍，谁有能力证明这不是独立实现？

技术上无解。法律上也无解。

大模型在法律上的核心争议可以简化成一句话：AI生成的代码，版权到底归谁？

美国版权局的立场是明确的：缺乏人类作者身份的作品不具备版权保护资格。2025年他们重申了这一立场，AI生成的纯代码不受版权法保护。这意味着两件事：你用AI写的代码不能申请版权保护，别人用AI抄你的代码你也没法用版权法起诉。

听起来对所有人都公平。实际上只对大公司有利。

小团队写了一个产品，60%的代码由AI生成。大公司用AI分析你的产品，重新生成一个功能一样的版本。你不能告他们侵犯版权，因为他们抄的不是"你的代码"，是"你的功能"。他们也不能告你，道理一样。但大公司有品牌、有渠道、有流量。你只有功能。

公平得很，谁都不受版权保护。但大公司不需要靠版权活着。

"Clean Room"的概念在软件行业存在了几十年。把工程师分成两组，A组分析原代码写出功能规格书，B组只看规格书独立实现。这样产出的代码在法律上被视为独立作品，不受原代码许可证约束。

AI让Clean Room的成本降到了零。不需要两组工程师了。一个人，一个Claude Code终端，三个小时。1.3亿次月下载的chardet就被"清洁"成MIT协议了。

你可以说这是技术进步。也可以说这是一种新型的"代码洗钱"。

2026年4月，Rust社区出现了一股复刻潮。有人在GitHub上批量创建项目，用AI把知名的GPL/GPLv3 Rust库重写成MIT或Apache 2.0协议。这些新项目的README里都会有一行声明："本项目的所有代码均由AI生成，不受任何现有开源协议约束。如有雷同，纯属巧合。"

Rust基金会没有公开回应。但据社区成员统计，被"洗"过的Rust crate数量在两个月内增长了超过300个。大部分原作者甚至不知道自己的代码已经被"清洗"并重新发布。

这不是个例，是流水线。

我不是法律专家，我聊不了诉状和判例。但我做了一件事：把自己的开源项目——一个用GPLv3发布的Go语言数据处理库——扔给Claude Code做了一次"重写"实验。

三分钟。Claude Code产出了一个功能完全等价、API接口相似但不完全相同的新实现。我拿着两份代码逐行对比：没有一行是逐字复制的。变量名换了、函数顺序调整了、错误处理用了不同的模式。但如果你看整体的代码架构、模块划分、核心算法的实现路径，它们的"骨架"一模一样。

这是不是抄？法律上没人说得清。但道德上，我自己心里有答案。

开源社区面临的不是一次被抄袭的风波，而是一种系统性的被"洗白"的风险。AI不关心你用的是GPL、MIT还是AGPL。AI只关心：你这段代码的模式是什么，我能不能用另一种写法讲同一个故事。

那怎么办？

三个务实建议。

第一，不要指望许可证保护你。GPL系列在AI时代正在失去实际约束力。如果你的项目核心价值在于代码实现本身，它在AI面前"几乎已经没有护城河"。真正的护城河是数据、用户关系、品牌信任——这些AI抄不走的东西。

第二，如果你在企业，建立AI代码合规扫描流程。不要在CI/CD里跳过这一步。用工具扫描每次AI生成的代码，检查是否包含已知开源项目的逐字片段。Sonatype和Snyk已经在这个方向上发力了。许可证污染不是一种可能性，是迟早会发生在你团队里的事。

第三，如果你是个人开发者，想清楚：你把代码开源是为了什么？如果是为了社区贡献和声誉，继续做。如果是为了靠开源协议建立护城河——这条路正被AI一块一块地堵死。考虑转向数据驱动型的商业模式，或者直接闭源。

AI没有让开源精神消失。但它重写了开源的经济学基础。

代码本身不再能构成壁垒。那个"我写的代码就是我的"的时代，正在落幕。