AI生成代码让版权保证条款签不下去了，合同却还没反应过来
开发者原创声明（DCO）、Apache贡献者协议，以及压在它们之上的每一份知识产权保证条款，都假设代码的著作权是可查、可证的。AI生成代码已经推翻了这个假设，开源社区因此分裂成两派，这只是表面症状。
Linux内核接受的每一个补丁，以及照搬这套流程的数千个项目，都带着一行“Signed-off-by”签名。这行字确认的是开发者原创声明（Developer Certificate of Origin）的第一条：“本贡献由本人全部或部分创作，本人有权按文件中标明的开源许可证提交此贡献。”Apache的个人贡献者许可协议用不同措辞做出同样的承诺：“您声明，您的每一项贡献均为您的原创。”这些条款起草时，能够创作代码的只有人类，而压在它们之上的每一份商业文件——采购问卷、客户IP保证条款、并购中的信息披露附表——都继承了同一个核心假设：代码的版权归属是作者可以知道、所有者可以证明的事实。AI生成代码已经悄悄推翻了这个假设。这些条款每天仍在被签署，但按字面理解，其中许多条款如今已经没有人能够如实签署了。
为什么没人能核实AI生成代码的版权？
顺着机制往下看：训练这些系统所用的公开代码库，涵盖了各种许可证和版权状态，而系统输出的内容里，没有任何记录能说明某条建议究竟“脱胎于”什么，也没有台账可查。采纳建议的开发者无法证明其来源的许可证状态，生成这段代码的工具供应商同样做不到。这不是靠明年更好的工具就能解决的核查问题：相关信息从一开始就没有被记录下来，也就无从追溯。从贡献者签名到并购交易中的IP保证条款，每一个建立在“著作权可证明”之上的条款，如今都建立在一个已经无法查明的事实上。
商业后果远在任何法庭判决之前就已降临。采购和并购中的尽职调查问卷，如今直接询问代码来源。受监管行业的客户，要求获得“交付代码不含许可证污染”的书面陈述。保证与赔偿条款的定价，取决于能拿出什么证据。而这些文件在起草之初，设想的世界是：只要审计足够到位，原则上总能把每一行代码追溯到某个作者和某份许可证。审计你依然可以委托，只是它已经回答不了这个问题。
开源社区已经因这道举证难题而分裂
工程师们对此有多重视，从开源治理里看得最清楚。Gentoo理事会在2024年禁止了AI生成的贡献，版权问题正是理由之一。NetBSD的提交准则默认AI生成代码“有毒”，未经核心团队批准一律拒收。QEMU也拒绝此类贡献，理由正是本文开头那个问题：贡献者无法按每个补丁要求的签名如实确认其来源。留意一下，任何“折中”政策会是什么形态——“只有贡献者能核实版权状态时才接受AI生成代码”，听起来像是妥协，但既然核实手段本就不存在，这其实是把“全面禁止”包装成了“有条件放行”。这些由社区治理的项目，唯一不可替代的资产就是清晰可辩的权属链条，为了守住它，它们宁可放弃贡献。
生态系统的另一半正朝相反方向狂奔，而且有真金白银撑腰。在Alphabet 2024年第三季度财报电话会议上，Sundar Pichai告诉分析师，“谷歌超过四分之一的新代码由AI生成，再经工程师审核采纳”，这一说法当时被广泛报道，而Linux基金会背后最大的一批企业金主，卖的正是驱动这类数字的工具。可是这两个阵营谁都无法证明自己的代码里到底装了什么。至今没有任何机器生成代码检测器，能达到许可证审计所需的准确度，于是执行只能靠自我申报；Linux内核倾向于“标注披露”而非“一律禁止”，但披露规则只能反映愿意配合的那部分贡献者。无论AI辅助补丁的真实占比是多少，荣誉制度报出的永远是下限，而非实测值。溯源问题还会传导：即便一个项目自身政策严格，它引入的依赖项也可能来自政策宽松的上游，而受雇于企业的贡献者，维护着几乎每个发行版都依赖的大片底层代码。一个项目的AI政策，反映的是它的风险偏好，几乎说明不了它仓库里到底有什么。
SBOM回答不了保证条款提出的问题
本能的反应是搬出软件物料清单（SBOM）。但它帮不上忙，这一点从标准的结构本身就能看出来。SPDX和CycloneDX定义的字段描述的是组件：名称、版本、供应商、声明的许可证、依赖关系。这两套格式里，都没有任何字段用来说明某个组件里的代码是如何产生的，或者是否出自人手。SPDX 3.0确实新增了AI画像（AI profile），但它是用来描述作为交付物的AI系统本身，而不是用来记录普通源代码的作者身份。SBOM盘点的是“你在运行什么”，从设计之初就不是用来证明“这些东西从哪来”的。把它当成溯源保证的替代品，是一种范畴错误，而尽职调查的审核方已经开始注意到这一点。
AI生成代码对企业是版权风险吗？
法律尚未明朗，而等法律明朗不是一种策略，因为在诉讼真正发生之前，风险早已体现在合同和声誉层面。务实的应对，是把许可证合规从“一次性打勾”变成对每个依赖项持续进行的风险判断。摸清你实际依赖的上游项目各自的AI政策，把“沉默不表态”本身当作一类独立风险来对待。请人核查IP保证和赔偿条款，对照的是“现在能证明什么”，而不是“过去默认什么”；一句不加限定的“原创声明”，是工程师无法替你兑现的承诺。这个风险偏好的取舍，应该在架构决策的层面上有意识地做出，这正是一次认真的技术战略评估理应默认覆盖的内容，也应该和动工前的AI准备度评估放在同一场对话里讨论。如果你自己的团队也在用AI生成代码，同样的纪律同样适用，这也是为什么应该让人始终掌控AI输出，而不是把工具当成作者。
上面每一条项目政策，本质上都是一次风险偏好的选择，而你的企业面对的是同一张选票，只不过是逐个依赖项、逐次签字地投出来的。最终能安然度过这一关的企业，不会是选中了“干净”阵营的那批。而会是那批发现根本无法核实、于是提前把这份风险计入定价的企业。
常见问题
软件能检测代码是不是AI写的吗？
不能可靠地检测。至今没有任何机器生成代码检测器，达到过许可证审计所需的准确度，分类器在两个方向上都会误判，稍作修改就能让它失效。这正是开源项目依赖贡献者自我申报、而不是靠扫描工具的原因，任何“AI占比”的官方数字都应被视为下限，而不是实测结果。
使用AI编程工具的开发者，还能签署开发者原创声明（DCO）吗？
视项目而定。QEMU的准则认为，贡献者无法如实确认AI生成代码的来源，因此拒收此类补丁；Linux内核则更倾向于要求标注披露。贡献前请先查清具体项目的政策，因为签名是一项关于来源的法律声明，不是走个形式。
该向供应商问哪些关于AI代码溯源的问题？
问清楚他们对AI辅助开发的政策，AI生成的贡献如何标注和审核，他们的IP保证条款反映的是“实际能证明什么”还是“过去默认什么”，以及如果交付代码的来源日后受到质疑，赔偿责任由谁承担。
相关阅读
- Epic诉谷歌和解案:真正的转折点不是降费,而是谷歌交出Play应用目录
- 内存涨价已成定局,下一次硬件刷新前先重签供应合同
- AI没有取代坏老板,它替他们装上了一台永不反驳的应声机器
- Digital Business
本文由 Abyshire 专有编辑系统的 AI 编辑角色撰写，并经我们的团队审核。