OpenBSD拒收“AI写的ext4”：这不只是代码之争，更是开源世界的一次法律体检
一段 ext4 代码，点燃了 OpenBSD 最不想碰的火药桶
最近，OpenBSD 社区上演了一场相当有时代感的争论：一位开发者 Thomas de Grivel 向邮件列表提交了一份 ext4 文件系统实现，声称已经支持完整读写，还能通过 e2fsck 检查，只是暂时不支持日志功能。单看功能描述，这本来像是个会让很多用户拍手叫好的补丁——毕竟 ext4 仍是 Linux 世界最主流的文件系统之一，跨系统读写的现实需求从来没有消失。
真正让事情变味的，不是 ext4 本身，而是这份代码的“出身”。de Grivel 后来在博客里承认，这套驱动并没有参考 Linux 源码，“纯 AI”生成，主要使用了 ChatGPT 和 Claude，再加上他自己的审查、编译、重启和测试。这个说法一出来，OpenBSD 社区几乎立刻进入警戒状态。
如果你了解 OpenBSD，就不会觉得这反应夸张。这个项目向来以“保守、严谨、洁癖式工程文化”闻名，它对代码来源、许可证、长期维护都异常敏感。换句话说，你把一大坨来路含糊、法律状态不明、作者自己都未必能完全解释清楚的代码丢进 OpenBSD，基本等于拿着打火机走进火药库，还问一句：大家觉得这火苗漂亮吗？
OpenBSD怕的，不只是 GPL，而是“谁拥有这段代码”
这场争论最容易被误读成“BSD 阵营抗拒 GPL 污染”。这当然是一个重要背景，但事情比“开源许可证之争”更复杂。
ext4 是 Linux 的核心文件系统之一，而 Linux 内核采用 GPL 许可证。OpenBSD 长期对 GPL 风格的强传染性授权保持距离，所以社区里有人担心：既然大模型极有可能在训练时接触过 Linux ext4 的代码和文档，那么它生成的 ext4 实现，会不会构成某种衍生作品？这个问题现在没有清晰答案。更麻烦的是，连“问题该怎么问”都还没形成共识。
Theo de Raadt 的表态其实很有代表性。他并没有说“重新实现 ext4 一定违法”，恰恰相反，他指出，结构和算法的再实现本来就是互操作性的基础，版权法并不禁止你独立实现兼容系统。问题在于，LLM 让“独立实现”这四个字突然变得非常暧昧。你没有直接读 Linux 源码，不代表模型没有“读过”；你没有复制粘贴，不代表生成结果就和训练语料彻底切断关系。过去工程师做 clean-room reverse engineering，可以靠人员隔离、文档隔离、自证流程来建立信任；现在你只说一句“这是 AI 写的”，反而像把所有中间环节都打成了黑箱。
更致命的一点，是 OpenBSD 关心的不是抽象伦理，而是现实分发责任。Theo de Raadt 和 Damien Miller 都提到了一个核心难题：如果 AI 生成代码的版权归属根本不明确，那项目拿什么获得再分发、合并、修改所必需的授权？AI 不能持有版权，人类提示词作者是否自动拥有版权也没有定论，模型公司有没有权利主张更说不清。对于一个要长期发布源代码、打包系统、承担潜在法律风险的项目来说，这不是哲学问题，而是最朴素的风控问题。
OpenBSD 最终的态度几乎没有悬念。de Raadt 说得非常直白：这种版权状态“可疑”的新代码，被接收的可能性是零。这个“零”字，比很多长篇论证都更有力量。
比法律更现实的，是维护地狱正在逼近
有意思的是，LWN 文章下面的讨论区里，很多开发者并不认为版权才是最大问题。有人直接说，如果大家讨论 AI 代码时只盯着版权，那多少有点抓错重点。真正可怕的，也许是另一件事：这些代码到底谁来维护？
这话非常扎心。AI 生成代码最大的诱惑，是它能在很短时间里吐出成千上万行“看起来像那么回事”的实现。第一眼看去，能编译、能跑测试、功能甚至还挺完整，像极了一个勤奋又便宜的初级程序员。但真正的软件工程从来不是“把第一版写出来”就结束了，后面还有重构、修补边界情况、性能调优、接口统一、与旧系统兼容、应对下一轮安全问题。这些活儿既枯燥又昂贵，却决定了代码能不能活过三年。
而 OpenBSD 这种项目，偏偏最在意“十年后谁来收拾残局”。如果提交者只是借助 LLM 快速生成一批代码，自己对设计没有完整掌控，那之后任何一次 bug 修复都可能像拆盲盒。你今天是合入了 ext4，明天可能合入的是一个没人敢改、没人想碰、每次改都担心牵一发动全身的定时炸弹。
评论区里还有一个细节很有启发：既然 ext4 在很多方面可以视作 ext2/ext3 的演进，为何不在 OpenBSD 现有 ext2fs 的基础上做增量修改，而要“另起炉灶”生成一整套新代码？这正是 AI 时代一个很典型的工程偏差：当生成大量代码变得极其容易，人们就更倾向于用“多写一套”来解决问题，而不是去耐心梳理现有系统、做局部重构、减少重复。代码产量上去了，系统复杂度也跟着水涨船高。
这让我想到今天很多企业内部开发已经出现的苗头：本来一个脚本就能搞定的事，最后变成几千行“AI 帮忙搭的工具”；本来可以复用成熟组件，最后却长出一套半成品的自制轮子。表面上开发速度飞快，实际上维护账单被悄悄推迟到了未来。
这不是 OpenBSD 一家的难题，而是整个开源世界的压力测试
这起风波之所以重要，不在于 ext4 最终有没有进 OpenBSD，而在于它把开源社区接下来几年一定会反复面对的矛盾，提前摊在了桌面上。
过去一年多，围绕 AI 生成代码的争议已经越来越多。有人试图用 LLM“重写”已有项目，以摆脱 copyleft 约束；也有人把模型当成高速代码搬运工，希望绕开传统授权边界。Python 社区此前就因为类似问题出现过争议。现在 OpenBSD 给出的答案非常清楚：在版权状态未明、贡献者责任不清、代码维护能力无法证明之前，宁可不要。
从工程治理角度看，我反而觉得这是一个相当成熟的选择。开源项目不是代码回收站，更不是 AI 生成物的试验田。尤其是操作系统、编译器、加密库、文件系统这种基础设施，一旦收进主干，后面就是持续多年的维护承诺。你当然可以说，法律还没跟上技术，不该太保守；但对于一个以稳定和可信赖著称的项目来说，等法律明朗一些再说，可能恰恰是最负责任的做法。
当然，这并不意味着 AI 代码就注定没有未来。我更愿意把这场争论理解为一次“治理规则补课”。未来真正可行的方向，可能不是简单地禁止或放任，而是建立一整套更严格的来源披露机制：哪些部分由模型生成、生成时参考了什么文档、贡献者是否逐行审阅、是否能解释关键设计、是否愿意承担后续维护责任。换句话说，AI 也许可以成为工具，但不能成为责任的替身。
还有一个更值得深想的问题：当“写代码”越来越便宜，软件世界最稀缺的东西会不会从开发能力，转向审查能力、维护能力和法律判断能力？如果答案是会，那 OpenBSD 这次看似顽固的拒绝，可能恰恰是在提醒整个行业：别只顾着庆祝生成速度，忽略了系统可信度。
在“能不能写”之外，开源还要回答“能不能相信”
这次事件里，de Grivel 后来表示会移除所有 LLM 生成代码，只保留自己亲手写的部分。但坦白说，一旦第一版已经打上“纯 AI 生成”的标签，后续再想让社区完全恢复信任，就会变得异常困难。开源世界表面上靠 patch 和 commit 运转，骨子里靠的是可验证的信任链。
这也是为什么我觉得，这件事的戏剧性远不只是一次邮件列表吵架。它像一面镜子，照出了 AI 编程热潮里最容易被忽视的地方：你可以很快生成一份补丁，却不能自动生成信誉；你可以让模型写出函数，却不能让它替你承担作者义务；你甚至可以让它模仿 ext4 的代码气质，却未必能模仿一个资深维护者对系统边界的敬畏。
技术圈这些年很爱讲“vibe coding”——凭感觉写、靠模型补、先跑起来再说。做原型、做个人项目、做实验工具，这一套确实痛快，甚至让人上瘾。但当场景切换到操作系统底层、文件系统、网络栈、安全组件时，光有 vibe 就不够了。基础设施不是短视频，不能靠情绪价值更新。
OpenBSD 这次把门关得很重，也许会被一些人嫌老派、嫌不够开放。但站在 2026 年这个时间点看，我反而觉得这种“扫兴”很宝贵。因为总得有人提醒大家：代码不是生成出来就算完成，真正困难的部分，才刚刚开始。