从 Flathub 禁令到 QEMU 松绑：开源世界的 AI 代码裂痕

Flathub 没有尝试在 AI 的使用上划出精细的界限。它选择了一刀切的禁令，因为审核过程的分诊本身已经成为一种无法承受的代价。与其指望一个仍在追赶技术步伐的法律体系来解决问题，平台选择了直接保护审核者的注意力和心理健康。

QEMU 的转向：尝试用“披露”走出中间道路

与 Flathub 的方向正好相反。QEMU 在 2025 年中推行了开源界最严苛的 AI 禁令之一，其正式的代码来源政策规定，但凡已知或怀疑包含、衍生自 AI 生成内容的任何贡献（包括 ChatGPT、Claude、Copilot、Llama 等工具），都将直接拒绝 。理由是 AI 代码无法满足开发者来源证书（DCO），因为没有人类能够做出所需的认证声明 。

但到了 2026 年 5 月末，该项目开始倒车。Red Hat 的杰出工程师兼 KVM 维护者 Paolo Bonzini 提议，允许在风险足够有限的领域中接受 AI 辅助的补丁——尤其是那些版权违规后果易于修正且不太可能扩散的范围，而核心代码则在没有维护者事先同意的情况下仍属禁区 。

Bonzini 的理由非常务实：那些接受了 AI 辅助贡献的项目至今尚未遇到严重的法律麻烦，且 Red Hat 的法务团队评估认为，在已界定的变更类别里相关风险是可接受的 。提案也加入了一项强制的披露要求，敦促贡献者明确标记出代码中 AI 生成的部分，而非加以隐藏 。

QEMU 实际上是把赌注押在了一条基于透明度的中间道路上。尤其对于那些测试用例、文档修复或小规模补丁类的机械化贡献，他们认为这条中间道路能减少“一刀切禁令”所带来的摩擦，并避免产生不成比例的法律收效。

为什么 DCO 成了断裂带？

无论是 Flathub 的铁腕禁令，还是 QEMU 谨慎的松绑，二者都围绕着同一个悬而未决的法律难题：当 AI 生成的代码遇上开发者来源证书（DCO），会发生什么？

DCO 要求贡献者证明他们是该贡献的创建者，或有权依据项目的许可证提交该贡献。但在现行法律下，AI 生成的代码没有一个可被识别的人类“作者”。美国版权局在 2025 年 1 月裁定，只有当人类贡献了“足够的表达性要素”时，AI 的输出才可能受版权保护——而仅靠编写提示词并不足够 。在 Thaler v. Perlmutter 一案的判决中，哥伦比亚特区巡回上诉法院于 2025 年 3 月确认《版权法》要求作品必须首先由人类创作，而至 2026 年 3 月，美国最高法院已拒绝受理进一步的挑战 。

这制造了一个令人不舒服的困局。一名提交了 AI 生成代码的开发者可能无法诚实地签署 DCO。Linux 内核在 2026 年 4 月拿出了有史以来第一份针对 AI 编码助手的正式政策，要求只有人类才能添加 Signed-off-by 标签，并且该人类需对所有 AI 生成的代码行列承担全部法律责任 。但 QEMU 最初之所以实行禁令，正是因为其认为在许可存在模糊性的情况下，有人声称 AI 代码符合 DCO“并不可信” 。

至今尚无法院能明确界定：AI 生成的代码能否获得版权？如果可以，权利归属何人？下游又该承担何种许可义务？因为法律体系还没能为它们提供一个明确的答案，每个项目都在自行做出各自的风险计算。

版权之外还有巨大的人力成本

法律辩论固然重要，但最终压垮 Flathub 的，正是维护者倦怠。多个项目的维护者都报告了相同的模式：AI 生成的提交往往数量庞大却流于表面——大量的代码差异（diff）背后几乎没有真正的技术理解，产生的审核负担与其价值完全不成比例 。

GNOME Shell 扩展（EGO）也遭遇了类似的洪流。在 2025 年末，审查者报告称有时甚至每天需要审核超过 15,000 行 AI 生成的扩展代码，同时，还会收到 AI 针对审核问题自动生成的回复 。Flathub 维护者 Piotrowski 直言不讳地将崩坏点概括为：政策之所以必要，是因为某些提交者“根本不懂得如何好好沟通” 。

人力成本与法律成本是无法分割的。DCO 之所以重要，是因为维护者需要为其接纳的代码承担真实的法律责任。倦怠之所以重要，是因为维护者是时间和善意都严重受限的志愿者。而 AI 生成的提交在同一时刻让这两根弦都绷到了极限。

三大阵营，共识为零

RedMonk 在 2026 年 2 月所做的一项分析调查了 32 个开源组织，发现并无共识正在形成 。当前的项目已大致分裂为三个阵营：

• 全面封杀派：Flathub、Gentoo（2024 年经委员会一致投票决定禁止）、NetBSD（称 AI 代码为“推定被污染的”），以及 GNOME 的 EGO 审查系统，均明令禁止 AI 生成的贡献 。
• 附条件披露接纳派：QEMU 当前的提议与 Apache、Fedora、Linux 基金会和 EFF 等组织一致，它们允许使用 AI，但需作强制标记并由维护者自行决断 。
• 宽容但须人类担责派：Linux 内核和 Red Hat 允许使用 AI 工具，前提是由人类开发者承担全部责任、签署 DCO 并标记所用工具——但 Signed-off-by 标签唯独保留给人类 。

这几个阵营所争的并非仅仅是政策分歧。它们更在争论，AI 代码到底是一种尚待管理的工具，还是一个必须排除在外的威胁——以及管理它的代价究竟应由维护者来承担，还是该落在一个远未准备好的法律体系头上。

接下来会发生什么

Flathub 和 QEMU 都不是孤例。它们只是同一个光谱上的数据点，而这条光谱将随着 AI 编码工具的进步以及生成式提交量的增加而愈发拓宽。一些观察者指出，检测 AI 生成的代码在一两年内将变得在功能层面不再可能，也就是说无论本意如何，禁令届时都将失去执行力 。

EFF 也已得出结论，鉴于大语言模型的使用已如此普遍，一刀切的禁令在实操中并不可行 。然而，实操上的不可执行性，并不能解决当初迫使 Flathub 做出决定的维护者倦怠问题。

在法院判决或立法为 AI 生成代码的作者身份和法律责任确立明晰规则之前，每一个开源项目实际上都是在选择自己的赌博方式。Flathub 选择现在就保护它的审查者，代价是关上了 AI 工具的大门。QEMU 则选择将门开出一条窄缝，以透明度的要求为杠杆，并押注对于低风险贡献，法律风险是可控的。

两种举措在现有信息的制约下都是理性的，只不过它们都反映了对同一个令人不安问题的不同回答：在一个建立在人类署名和志愿劳动之上的社区，当代码携带着两样东西都没有的意味到来时，你该怎么办？