AI 编程引发开源社区版权责任争议：GCC、Linux、Zig 应对策略大不同
当下，AI 编程正处于一个微妙阶段。Claude Code、Cursor、GitHub Copilot 等工具让程序员借助 AI 编写函数、修复 Bug 甚至生成完整模块，改变了开发流程。然而，开源社区却面临新难题，若代码主要由大模型生成，提交者仅复制粘贴，贡献归属和责任承担成了疑问。
近日，GNU 编译器集合（GCC）社区就因 AI 生成代码问题展开讨论，并决定采取谨慎态度，今年不再接受任何由 AI/大语言模型 Agent 生成的“具有法律重要性”的代码贡献，即不接受那些可能影响版权归属、许可证合规或法律责任的核心代码修改。
GCC 是全球重要的开源编译器项目，支撑着大量 Linux 发行版、嵌入式系统及基础软件生态。其新的 AI 政策规定，拒绝包含 LLM 生成内容或基于此衍生的、具法律重大意义的贡献；维护者可自由接受法律意义不重大的贡献，但要明确标注使用了 LLM；可接受全部或部分由 LLM 生成的、具法律重大意义的测试用例贡献。
传统开源开发中，提交代码的人既是作者也是责任承担者。但在 AI 时代，开发者用自然语言让 LLM 生成代码，简单检查后就提交。若维护者对代码设计、优化影响、Bug 修复边界情况等提问，提交者无法回答，开源协作体系就会断裂。所以，AI 生成代码的问题关键不在于质量，而在于代码背后工程判断的缺失。
并非只有 GCC 遇到此类问题。过去一年，大量开源社区面临生成式 AI 带来的新贡献模式——大量低成本 Pull Request。对于大型项目，维护者审核代码成本高。
Linux 内核社区中，Linux 之父 Linus Torvalds 不反对 AI，认为其可帮助发现 Bug、提高效率，但反感有人利用 AI 提交无价值报告或未经验证代码增加负担。Linux 为此制定规则，AI 可辅助开发，提交者须理解代码并承担责任，AI 不能替代 DCO 签署者，还可通过 Assisted - by 标签注明 AI 工具和模型信息。
而 Zig 编程语言社区则选择严格路线，明确禁止 AI 生成代码贡献。其维护者认为大量 AI 生成 Patch 会浪费核心维护者时间，小型开源项目维护者数量有限，若每天面对大量此类提交，可能无法维护重要功能。
AI 的爆发式发展加速了软件开发方式重构，但过去几十年开源世界的运转依赖代码背后有真实的人，这个人要理解代码、能解释设计选择、回应社区 Review 并承担责任。LLM 的出现挑战了这一基础假设。
基础软件领域不会简单拥抱“AI 编程革命”，对于编译器、操作系统、数据库等核心基础设施，代码背后的理解、责任和可信任性才是关键。AI 可成为开发者工具，但在开源世界，最终被接受的必须是有人愿意负责的代码。
编辑观点：AI 编程虽带来效率提升，但开源社区对代码责任归属的重视不可忽视。各社区不同应对策略反映出在保障代码质量和可信任性上的探索。