GCC 编译器社区发布生成式 AI 使用政策

GCC 指导委员会宣布，已采纳 GCC AI 政策工作组建议的 AI 贡献政策。

该政策部分规定，项目将拒绝任何“包含 LLM 生成内容，或衍生自 LLM 生成内容的、在法律上具有实质意义的贡献”。它采用 GNU 项目维护者指南中对“在法律上具有实质意义”的定义：从版权角度看，“大约 15 行代码和/或文本”即可达到具有实质意义的门槛。不过，GCC 维护者可以选择接受由 LLM 生成、且在法律上具有实质意义的测试用例。

该政策并不禁止使用 LLM 进行研究、分析、发现和报告 bug、审查补丁等，只要其输出没有被包含在贡献中即可。委员会表示，预计这项政策将继续演进，并会定期重新审视。

编译器会在 LLM 代码上崩溃吗？

taladar（订阅者，#68407）发表于 2026 年 7 月 30 日 7:12 UTC（星期四）（1 条回复）

编译器会在 LLM 代码上崩溃吗？

hvd（访客，#128680）发表于 2026 年 7 月 30 日 8:39 UTC（星期四）

该政策并不禁止使用 LLM 进行研究、分析、发现和报告 bug、审查补丁等，只要其输出没有被包含在贡献中即可。

这就是使用 LLM 发现 bug 的一个例子。

lmb（订阅者，#39048）发表于 2026 年 7 月 30 日 14:55 UTC（星期四）（3 条回复）

LLM 的输出可以获得版权保护吗？它们是修改作品时首选使用的形式吗？嗯……现阶段，我也不会公开接受在法律上具有实质意义的 LLM 贡献。

这看起来是一项相当明智的政策。

考虑到整个供应链中存在的那些——呃——道德问题，或者说根本没有道德可言，以及它对自由软件乃至仅仅是开源软件造成的影响，我原本以为政策会严厉得多。FSF 很少像这次这样通情达理。

bluca（订阅者，#118303）发表于 2026 年 7 月 30 日 15:19 UTC（星期四）（2 条回复）

是的，在向现有项目贡献代码的语境下，没有任何迹象表明情况并非如此。

它们是修改作品时首选使用的形式吗？

是的，真正重要的是代码。

neilbrown（订阅者，#359）发表于 2026 年 7 月 30 日 20:49 UTC（星期四）（1 条回复）

C code？Assembler code？Object code？Yacc code？Prompt code？设计说明？

界线该画在哪里？我的界线又该画在哪里？

mb（订阅者，#50428）发表于 2026 年 7 月 30 日 21:09 UTC（星期四）

不过，这和 AI 生成的代码完全不同。这里没有发生任何混淆，也没有发生类似编译器那样的向下转换。恰恰相反，生成的代码通常比生成它的 prompt 包含更多信息。

源代码——其中甚至可能包括 md 文件里的 prompt 和 AI 指令——才是修改作品时主要且首选使用的形式，无论你是手工修改，还是借助工具（AI）修改。

GNUtoo（访客，#61279）发表于 2026 年 7 月 30 日 16:51 UTC（星期四）

补充一点背景信息：“在法律上具有实质意义”这一节写于 LLM 出现之前，其目的是落实 copyleft，因为它要判断何时值得将版权转让给 FSF，何时又不值得。这种解释记录在 gnu-prog-discuss 邮件列表中，但遗憾的是，该列表仅对 GNU 维护者开放。

对于 LLM，生成的代码或数据可能来自采用不兼容许可证的自由软件项目，因此，即便结果少于 15 行，我们也完全无法保证其合法性。据我从 Conservancy 了解到的信息，泄露代码被纳入其中同样有可能，只是概率较低，因为这类代码通常会被删除，所以不太可能进入训练数据。

Guix 也在制定一项有关 LLM 的政策。在第一版提案讨论期间，这促使 Guix 不再把“在法律上具有实质意义”作为判断是否接受 LLM 生成贡献的依据。

它转而采用了另一项测试，下面是我逐字复制的原文：

2. 贡献的接受。 由 genAI 生成或衍生自 genAI 输出，且可被视为具有“创造性”、因而可能受到版权保护的修改，必须被拒绝，以避免任何版权侵权风险。反之，如果审查者认为某项由 genAI 生成的修改“不具创造性”，因而不属于版权保护范围，则可以接受该修改。不具创造性的修改示例包括：以机械方式转换其他软件仓库中的软件包元数据，类似于 guix import 所执行的操作；类似于 guix refresh 或 guix style 所执行的机械式修改；以及仅仅遵循 guix lint 所提建议的修改。

这份提案未获通过，其文本可以在 guix/guix-consensus-documents 仓库的 commit a0aca85d5079d740f953794f63722d76611aece9 中找到。

此后，这份提案促使 GNU 考虑在其正在制定的 LLM 政策中加入类似内容，而这样的政策也将与 Guix 最初提出的政策兼容。我还得到消息称，这种做法从法律角度看似乎站得住脚（我不是律师，所以询问了能够咨询律师的人）。

还要注意，在 GNU 政策正式落地之前，GNU 已暂停纳入由 LLM 生成的代码或数据，但 GNU 项目往往并不遵守这项暂停措施。不过，无论是在这里还是在 binutils 的案例中，这也可能导致低估法律风险——法律风险始终存在，真正的问题是我们愿意承担多大的风险。

Ichthyostega（订阅者，#177297）发表于 2026 年 7 月 31 日 1:04 UTC（星期五）

有些人一谈到使用 AI 就变得如此激动，着实令人惊讶。在我看来，人们对“AI”本身的认知，触碰到了某些隐藏在潜意识中的宗教母题。

话虽如此，只要运用理性推理，这里讨论的问题其实非常清楚：

你可以按照某个 License 的条款向开源项目贡献内容。这样的 License 必须以某种法律机制为基础，才能运作并产生效力。

GPL 的目的——这里无意评价其目的本身——是确保下游的每个人都拥有某些基本权利。而这一目的，是通过一连串贡献实现的，其中每一项贡献都以版权为基础。

如果你使用 AI 工具来学习、推理、质疑自己的论点，甚至审查自己的代码，这都没有问题，前提是代码由你创作。也就是说，是你这个人运用了自己的洞察、知识，以及归根结底属于你自己的判断。这样的作品，你可以主张版权。

但是，如果有人只是 vibecoding 出一大堆自己根本不理解的东西，再把它们作为贡献塞进一个采用 GPL 的项目，那么最初让他们得以贡献的那套基础机制，就会随之失效。

请注意，这不是一个回答“是”或“否”的问题，而是一个“我们无法确定”的问题：我们无法知道是否真的存在由人完成的创作行为，而且我们也无法知道作者究竟是谁。因此，它根本达不到 License 所允许接受的贡献门槛。

法律意义上的法则不同于源代码。它建立在一种态度之上，也建立在一个人有意识、负责任的行动之上。除非有人提出质疑，否则这些事实就被视为成立。如果有人质疑所贡献的代码，并证明它在结构上等同于某些受第三方版权保护的代码，那么最终结果取决于谁能提出更有力的论证，并说服法院。

AI 生成的贡献与版权

rswail（订阅者，#130113）发表于 2026 年 7 月 31 日 2:37 UTC（星期五）（2 条回复）

鉴于 GPL 的可执行性完全依赖版权，AI 贡献无法获得版权保护这一事实，很快就会让某个大人物吃到苦头。

美国版权局已发布一份公开报告，说明版权要求作品必须有人类作者。

报告比较了几种相当于“prompt engineering”的不同情况：客户向建筑师说明自己想要什么，但实际图纸和建筑结构的版权仍归建筑师所有，即使建筑师使用了 CAD 工具也是如此。

完全由 AI 根据 prompt 生成的代码，将无法通过版权知识产权获得保护。

因此，GCC 实际上是在确保流程中有人类参与，从而保证 GPL 继续具备可执行性。

AI 生成的贡献与版权

dskoll（订阅者，#1630）发表于 2026 年 7 月 31 日 2:48 UTC（星期五）

美国的实际情况其实相当混乱。

该文档第 27 页写道：

但考虑到情况如此混乱，各地规则不一，而且规则还可能随时间变化，我认为 GCC 指导委员会的做法很审慎。

AI 生成的贡献与版权

Cyberax（✭ 支持者 ✭，#52523）发表于 2026 年 7 月 31 日 4:36 UTC（星期五）

即便代码中的某些部分无法获得版权保护，也不影响 GCC 整体仍然可以获得版权保护。此外，只要包含哪怕一点艺术性的投入，汇编作品（即这个词最初的含义）同样可以获得版权保护。对于 GCC 而言，由人类审查者决定接受哪些补丁的行为，很可能已经足以触发版权保护。

所以，即使是“忒修斯之 GCC”，应该也不会有问题。