Linux社区吵了3个月，Torvalds一句话拍板

2024年1月，Intel工程师Dave Hansen和Oracle的Lorenzo Stoakes在邮件列表里吵了整整17天。议题只有一个：Linux内核该不该彻底封杀AI生成的代码。

这场辩论的激烈程度，堪比当年systemd之争。Hansen主张强硬路线，认为大语言模型(LLM)的训练数据版权不明，任何AI辅助代码都可能"污染"内核的法律根基。Stoakes则认为这纯属因噎废食，工具无罪，关键看怎么用。

吵到最后，Linus Torvalds亲自下场。他的回复只有三段，核心意思翻译成中文大概是："你们吵这个纯属姿势摆得太高。坏人根本不会看规则，好人你禁了也没用。"

三个月后，这份 pragmatism（实用主义）变成了白纸黑字的官方政策。Linux内核项目本周正式发布全项目范围的AI代码贡献规范，成为全球最大开源项目对生成式AI的首次制度化回应。

新规则的核心：工具归工具，责任归人

政策文本不长，但每一条都指向同一个逻辑——AI可以帮忙写代码，但法律责任100%锚定在提交者身上。

最关键的一条：AI代理禁止使用"Signed-off-by"标签。这是开源世界的法律签名，意味着提交者以Developer Certificate of Origin（开发者原创证书，简称DCO）的名义宣誓自己对代码拥有完整权利。从今往后，这个标签只能人类使用。

取而代之的是新设立的"Assisted-by"标签，专门用于标注AI工具的参与。Torvalds在邮件列表里解释过这个设计的用意："我们要的是透明，不是猎巫。用了Copilot就老实写上，用了ChatGPT也别藏着，但别指望机器替你背法律责任。"

Red Hat去年底的法律分析为此提供了注脚。DCO要求人类"legally certify they have the right to submit their code"（法律上证明其有权提交代码），而LLM的训练数据混杂着GPL、BSD、MIT等各种许可证的代码，版权归属确实模糊。Linux的新政策没有回避这个问题，而是把举证责任完全推给了提交者——你用AI可以，但得自己确保不侵权。

这种"用者自负"的立场，和NetBSD、Gentoo等发行版的路线形成鲜明对比。过去两年，Gentoo和NetBSD先后出台全面禁令，将AI生成代码拒之门外。NetBSD维护者甚至用了一个很重的词："tainted"（被污染的），来形容LLM输出的法律风险。

Torvalds的底层逻辑：别跟工具较劲，跟人较劲

理解这份政策，得先理解Torvalds对"工具"的定义。

他在1月的邮件里举了个例子：内核社区从来不问开发者用的是Vim还是Emacs，是GCC还是Clang，是本地跑模型还是云端调API。工具链的演进史就是不断把机械劳动自动化，从汇编到C，从手写Makefile到各种构建系统。AI在他看来只是这个链条的最新一环。

"The bad actors aren't going to read the documentation anyway"（坏人根本不会看文档）——这句话被多次引用，因为它戳破了一个幻想：以为靠规则就能筛选出诚意。Torvalds的逻辑是，内核社区的真正防线是代码审查，是maintainer（维护者）的眼睛，是长期建立的信任关系。把精力花在甄别"这段代码是不是AI写的"上，属于防御方向错误。

这个立场有其历史背景。Linux内核的代码审查强度在开源世界首屈一指，平均每个补丁要经过多轮review，核心子系统的maintainer往往有十年以上的深耕。Torvalds赌的是：这套机制足以过滤掉AI生成的"slop"（垃圾代码），无论这些slop是人写的还是机器写的。

"AI slop"这个词在政策讨论中反复出现，指的是那种看起来语法正确、实则漏洞百出的生成代码。内核社区对slop的警惕并非杞人忧天——2023年多起安全事件都指向同一个模式：开发者直接粘贴LLM输出，未加验证就提交。

但Torvalds认为，问题在人不在工具。"Garbage in, garbage out"（垃圾进，垃圾出）是计算机科学的老话，现在只是把"in"的环节从键盘输入扩展到了提示词工程。一个不负责任的开发者，用不用AI都能产出垃圾；一个严谨的开发者，用Copilot也能写出可靠代码。

政策细节：比"允许"更重要的是"怎么允许"

完整政策文件发布在内核官方文档中，几个技术细节值得拆解。

首先是"Assisted-by"标签的格式规范。它必须紧跟在"Signed-off-by"之后，明确标注使用的AI工具名称和版本。例如："Assisted-by: GitHub Copilot (v1.200)"或"Assisted-by: Claude 3.5 Sonnet"。这个设计有两个用意：一是建立审计线索，二是给maintainer提供决策信息——某些工具在特定场景下的表现，社区会逐渐积累口碑。

其次是禁止范围。政策明确排除AI代理自主提交代码的可能性。也就是说，你可以用AI辅助编写，但不能设置一个bot让它自己跑完从生成到提交的完整流程。这条红线划得很清楚：人类必须在循环中（human-in-the-loop），且是最终决策点。

第三是责任追溯条款。政策文本里有一句话被法律界人士特别关注："The human submitter retains full legal liability for any defects, security vulnerabilities, or copyright infringements in AI-assisted contributions."（人类提交者对AI辅助贡献中的任何缺陷、安全漏洞或版权侵权承担全部法律责任。）换句话说，如果AI生成的代码后来被发现抄袭了GPL代码，或者引入了缓冲区溢出，签字的人类开发者要负全责。

这个条款的严厉程度，在开源世界尚无先例。大多数项目的做法是把AI代码当作普通贡献处理，责任边界模糊。Linux选择明确切割，某种程度上是在保护项目本身——万一未来出现针对AI训练数据的集体诉讼，内核可以主张自己已尽到披露义务，责任在个体开发者。

行业反响：有人叫好，有人观望

政策发布后，内核邮件列表的反馈呈现分化。

长期贡献者Greg Kroah-Hartman表示支持，认为这"给maintainer提供了清晰的决策框架"。他在Linux基金会负责稳定版内核的维护，日常要处理大量来自企业雇员的补丁。对他来说，"Assisted-by"标签最大的价值是减少猜测——以前看到一段代码风格突变，得花精力判断是新人手生还是AI代笔，现在直接看标签就行。

但也有声音质疑执行难度。内核子系统众多，maintainer的精力分配本就紧张，现在要多一道核查标签的工序。更实际的担忧是：怎么验证"Assisted-by"标签的真实性？一个开发者完全可以用了AI却不标注，或者标注了却隐瞒具体工具。Torvalds对此的回应是："我们靠信任，不靠警察。发现撒谎的，ban掉就是。"

企业侧的反响更值得玩味。Intel和Oracle作为此前辩论的对立方，各自有内部AI工具部署。新政策实际上给它们开了绿灯——只要遵守披露规则，员工可以继续使用Copilot等工具为内核贡献代码。这与某些发行版的全面禁令相比，显然更利于大公司的工程实践。

Red Hat的法律团队在政策发布后更新了此前的分析，认为Linux的做法"在创新与风险之间取得了合理平衡"，但也提醒这"不等于解决了AI训练数据的根本版权问题"，只是"把风险转移给了个体贡献者"。

开源法律专家Pamela Chestek在个人博客中指出，DCO的设计初衷是建立清晰的权利链条，AI的介入让这个链条出现了"灰色节点"。Linux的新政策没有消除灰色，而是明确"谁为灰色负责"——这在诉讼频发的当下，是一种务实的风险管控。

对比其他项目：Linux为什么敢"开闸"

把Linux的政策放在开源生态的全景中，更能看出其特殊性。

NetBSD的禁令最为彻底，其2023年的决议禁止"any code generated or substantially modified by AI tools"（任何由AI工具生成或实质性修改的代码）。理由是训练数据的版权状态"无法审计"，项目承担不起潜在的法律风险。Gentoo Linux采取了类似立场，但留了一个口子：文档和注释可以使用AI辅助，核心代码不行。

Debian和Fedora目前处于中间状态，没有全项目政策，由各软件包维护者自行决定。这种"分布式治理"在大型发行版中很常见，但也导致标准不一——同一个开发者给不同包贡献代码，可能遇到完全不同的AI政策。

GitHub上的大量项目则完全沉默，既没有允许也没有禁止，全靠默认的社区规范调节。这种模糊性在AI代码占比尚低时问题不大，但随着Copilot等工具的普及，争议案例正在增加。2024年初，一个流行的Python库因为合并了疑似AI生成的文档字符串而引发风波，最终maintainer不得不回滚提交并出台临时政策。

Linux选择在这个时候明确规则，某种程度上是抢占定义权。作为全球最大的单体开源项目，其政策很可能成为事实标准。已经有内核子系统的maintainer在邮件列表表示，希望其他项目"参考我们的模板"，以减少开发者的认知负担。

Torvalds本人对此似乎并不热衷当"标准制定者"。他在后续的邮件里写道："我们解决我们自己的问题。别人爱抄抄，不爱抄拉倒。"但这种低调的姿态，反而让政策更具说服力——它不是公关产物，是真实治理需求的回应。

技术层面的连锁反应

政策落地后，一些技术细节正在快速演化。

首先是工具链的适配。GitHub Copilot团队已经表示将研究如何自动插入"Assisted-by"标签，减少开发者的手动操作。这涉及IDE插件、Git钩子（hook）和提交信息模板的联动修改。类似的，JetBrains的AI助手也在评估合规方案。

内核代码审查流程本身也可能变化。部分maintainer开始要求AI辅助的补丁附带额外的测试证据——不是信任人类开发者，而是不信任他们用的工具。这种"对AI的歧视性对待"是否公平，正在成为新的争论点。

更深远的影响可能在安全审计领域。内核的安全响应团队（SRT）需要追踪漏洞的来源，"Assisted-by"标签提供了新的维度。未来某个漏洞如果被确认与特定AI工具有关，可能会触发该工具的"信誉降级"，影响maintainer的接受意愿。

这种机制设计，暗合了Torvalds"靠市场而非禁令"的哲学。不禁止任何工具，但让信息透明流动，让社区用脚投票。表现好的AI助手会积累口碑，频繁产出slop的则会被自然淘汰。

一个尚未回答的问题

政策发布一周后，内核邮件列表里出现了一封有趣的帖子。一位匿名开发者问：如果我用AI辅助写了代码，然后自己逐行审查、修改、测试，最终版本和AI原始输出已经大不相同，还需要标注"Assisted-by"吗？

这个问题触及了政策的核心模糊地带。目前的文本对此没有明确界定，maintainer们的理解也不一致。有人主张"只要用过AI就要标"，有人认为"实质性修改后可以豁免"。Torvalds尚未表态，但他在类似问题上的一贯立场是：交给具体的人具体判断，不要追求绝对精确的规则。

这种"有意的不完整"，或许是Linux治理智慧的体现。技术演进太快，任何写死的规则都会迅速过时。留下解释空间，让社区在实践中磨合出共识，反而比一纸完美但僵化的禁令更有生命力。

当其他开源项目还在争论"该不该让AI进门"时，Linux已经开始了下一阶段的实验：在门内建立新的游戏规则。这套规则能跑多久、会演化出什么形态，可能比政策本身更值得观察。