你的 GPL 项目被 AI "合法"抄了，你能告谁？
假设这样一个场景。
你花两年写了个开源项目，用了 GPL 协议。某公司把你的代码丢给 AI，让它"理解功能后重新实现一遍"。新代码没有一行和你的相同，但功能完全一样。
你能告他侵权吗？
大概率，不能。
这不是假设，这是一篇正在引发开发者圈讨论的文章提出的真实问题：Is legal the same as legitimate（作者 Bradley M. Kuhn，2025 年 3 月）。
Copyleft 保护的是什么？
先搞清楚 GPL 的底层逻辑。
GPL（General Public License）的核心思想是：你用了我的代码，就必须把你的代码也开源。这叫"传染性"（copyleft）。
但有个关键前提：它保护的是代码表达，不是思想本身。
这不是 GPL 的缺陷，是版权法的基本原则。你不能垄断一个想法，只能保护你表达这个想法的具体方式。
历史上这个逻辑一直行得通。1980 年代，IBM PC 出来了。一堆公司想做兼容机，但没法直接复制 IBM 的 BIOS（那是侵权）。Phoenix Technologies 的工程师怎么做的？"干净室"方法：一组人阅读 IBM BIOS 的文档写规格，另一组人完全没看过原代码，只根据规格重写。
法院判这种做法合法。因为他们保护的是"思想"不被垄断，保护创新可以发生。
同样的思路，后来 Oracle 告 Google 抄 Java API，最终最高法院也判 Google 合理使用，理由类似。
所以 Copyleft 从来都不是万无一失的——它的边界，从设计之初就在这里。
<figure><img src=“images/01-timeline.png” alt=“01-timeline”></figure>
AI 重实现，哪里不一样？
传统的"干净室重写"有个隐含约束：得有人理解原始代码的意图，然后写出规格，再重写。这个过程需要时间、需要理解，成本不低。
AI 改变了成本曲线。
现在你可以：
- 把一个 10 万行的 GPL 项目丢给 LLM
- 让它理解功能
- 要求它重写一个"语义等价、代码不同"的实现
这不需要干净室。不需要两组工程师。甚至不需要你读懂代码。
成本从"几个月的工程量"变成"一个 API 调用"。
作者 Kuhn 提出了一个更深的判断：现在，规格（spec）才是 GPL 项目真正的知识产权所在，而不是代码本身。
你写了 10 万行代码，真正有价值的是你在代码里编码的那套设计决策、接口规范、行为约定。那是你花几年做出来的东西。代码只是它的一种表达。
但 Copyleft 保护不了这个。它只保护代码表达。
<figure><img src=“images/02-compare.png” alt=“02-compare”></figure>
谁会用这个漏洞？
不是小开发者，是大公司。
小开发者没有动机去绕开 GPL——他们通常是 GPL 的受益方，或者根本不在乎授权细节。真正有动力系统性地"AI 重实现"开源项目的，是想商业化但不想遵守 GPL 传染性条款的大公司。
这跟历史上的模式一致：Oracle API 版权案、Adobe PDF 标准、Microsoft Word 格式。每一次，有能力利用这类法律边界的，都是资源雄厚的一方。
Kuhn 的担忧在这里：我们的"祖先"（开源先驱们）当年争取的，是任何人都有权对私有软件进行功能等价实现——这是开放的基础。但现在我们反过来，要不要用 AI 版权问题阻止别人对开源软件做同样的事？
如果我们说"AI 训练/重实现构成侵权"，那我们打开的是一扇让大公司更有能力垄断的门，而不是一扇保护小开发者的门。
开源真的死了吗？
没有。但需要重新想清楚它的价值在哪里。
GPL 的法律保护本来就不是开源的全部。开源真正有持续力的是：社区、信誉、协作惯例。一个公司可以 AI 重实现你的代码，但没法 AI 重实现你的贡献者网络、你的 issue tracker 里沉淀的知识、你的用户社区对你的信任。
法律可以被绕过，生态不好绕。
当然，这不是说 Copyleft 的侵蚀无所谓。而是：如果你在乎开源生态，现在需要关注的不只是授权选择，还有怎么建立那些 AI 没法轻易复制的部分。
这个问题没有简单答案。但至少，应该先把问题想清楚，再决定要不要焦虑。
来源：Is legal the same as legitimate: AI reimplementation and the erosion of copyleft — Bradley M. Kuhn，2025-03-08 | HN 讨论