OpenBSD收到1份AI写的驱动：开源社区版权系统当场死机

3月17日，Thomas de Grivel往openbsd-tech邮件列表扔了颗炸弹——一份完整的ext4文件系统实现，读写全支持，能通过e2fsck检测。他没说的是，这代码一行人工都没写。

「没有读过任何Linux源文件。纯AI（ChatGPT和Claude-code），加上我的代码审查、错误检查、编译内核和重启测试。」de Grivel在博客坦白。OpenBSD社区的反应，像有人把自动炒菜机的产出端上了米其林评审桌。

许可证雷区：GPL的幽灵

Christian Schulte的质疑很直接：他搜ext4文档，找到的维基页面带GPL许可证，大部分资料直接或间接指向GPL代码。「即使从零开始写驱动，你几乎总得融入携带非自由许可证的知识。」

这个担忧不是空穴来风。训练大模型的语料里，Linux的ext4实现和文档占比极高。LLM输出算不算GPL衍生作品？法律上没人敢拍板。但对OpenBSD来说，这题更刁钻——他们连「作者是谁」都答不上来。

Theo de Raadt出来降温：重新实现结构和算法，版权法允许，互操作性就这么来的。但他没说要合并这份代码。换句话说，技术上合法，和项目上能要，是两件事。

版权系统遇到AI：文件格式错误

De Raadt把核心矛盾挑明了：软件社区和法律界，目前都不接受「指挥AI的人拥有版权」；AI公司也没被版权条约承认为权利主体。版权系统至今没有处理「非人类产出」的接口。

Damien Miller补了一刀：「谁是版权持有者？能签许可证吗？」OpenBSD需要明确的授权链来分发代码，AI生成的产物卡在第一步——连「能不能有版权」都是问号，遑论转让。

de Grivel的代码现在躺在邮件列表里，像一份格式正确的文件，被旧系统拒绝解析。社区在等的不只是法律答案，是一个能兼容新生产工具的规则补丁。问题是，版权法和开源许可证的迭代速度，大概比内核编译还慢几个数量级。

这份驱动最终能不能进OpenBSD base？如果进了，下一个AI提交的驱动该走什么流程？de Raadt没给时间表，只留下了系统报错信息。