2026 年 9 月 16 日，美国联邦第九巡回上诉法院就 Doe v. GitHub, Inc.（案件号 24-7700）作出裁决：生成式 AI 编程工具输出的代码属于"新生成的作品"，而不是训练数据的"复制件"，因此不构成《数字千年版权法》（DMCA）第 1202(b) 条所禁止的删除或改动版权管理信息（CMI）。据彭博法律报道，这是美国联邦上诉法院层面第一份直接裁定 AI 与 CMI 争议的判决。
法院到底裁了什么
原告是几名匿名程序员，起诉对象是 GitHub Copilot——这款代码补全工具基于 OpenAI Codex 的改进版本训练，训练语料包含数十亿行公开代码，其中不少仓库带有作者署名、版权声明和开源许可条款，这些信息正是 DMCA 保护的"版权管理信息"。原告提出了两套理论：一是"输出理论"，即 Copilot 输出的代码是对原作品的复现且删去了 CMI；二是"输入理论"，即训练时把代码灌进管线、剥离 CMI 的过程本身违法。
地方法院先驳回了输出理论，理由是原告举的例子与原文不够"完全相同"。第九巡回维持了驳回，但换了理由：DMCA 第 1202(b) 条针对的是对"已存在作品"实施的"删除"行为；生成一个"从一开始就没有携带 CMI 的新作品"，不等于"删除"CMI。两者是不同的行为。
但法院没有给 AI 公司发"免死金牌"。它同时拒绝了"必须逐字相同"的硬标准：轻微改头换面不能免责，如果输出近乎逐字复现原作品、只是删去了署名和许可信息，仍可作为"确实发生过删除"的旁证。另外，法院明确没有裁定两个问题：AI 输出复现受版权保护的材料是否构成直接侵权；训练阶段剥离 CMI 是否违法（因程序原因回避）。法院还顺带区分了生成式系统和检索式系统，暗示直接调取、传播已有作品的检索式系统可能面临不同处理。
影响谁
第一类是 AI 代码工具和通用生成式 AI 的开发者。GitHub、微软和 OpenAI 拿到的是"窄胜利"：只封堵了 CMI 输出这一条诉因，训练合规和直接侵权的战场还在。
第二类是开源作者和权利人。CMI 这条索赔路径基本被堵死，今后的诉讼只能转向直接侵权，举证难度和成本都更高。
第三类是企业用户。在公司里用 AI 生成代码的团队要注意：这份判决没有说"AI 输出不侵权"，代码的许可与侵权风险并没有消失。
该怎么做
对开发者：别把"输出是新作品"当成免责金牌。保留署名和许可信息输出机制仍然是最佳实践；训练管线如何处理 CMI 仍是法院没裁的灰色地带，宜保守；如果产品里有检索、缓存、逐字引用已有作品的功能，要单独做合规评估，因为法院暗示这类系统可能被区别对待。
对权利人：调整诉讼策略，把重心从 CMI 删除转向直接侵权，同时注意收集"近乎逐字复现"的证据，这类证据在 CMI 争议里仍有分量。
对企业用户：审查 AI 编程工具供应商服务条款中的知识产权赔偿条款；对 AI 生成的关键代码保留来源记录；对疑似逐字复现的片段做一次许可核查，成本远低于事后纠纷。
风险在哪里
- 判决只解决第 1202(b) 条的输出理论，直接侵权问题法院明确保留，相关诉讼不会停。
- 训练端 CMI 问题因程序原因未被裁决，仍是开放风险。
- 这份判决只在美国第九巡回辖区有约束力，对其他巡回法院只有说服力。不能把它当成全美乃至全球通用规则，欧盟、日本、中国适用各自的版权法。
- 检索式 AI 系统可能被区别对待，判例的保护伞没那么大。
- 近乎逐字复现且缺失 CMI 的输出，仍可能被认定为删除，"改几个变量名就安全"是误解。
合规问答
Q：用了 AI 编程工具生成的代码，企业就不会有版权麻烦了吗？
A：不会。这次判决只排除了"删除版权管理信息"这一项指控，法院明确没有裁定 AI 输出是否构成侵权。代码的许可归属和侵权风险依然存在，企业仍要做来源记录和许可核查。
Q：开源作者以后是不是没法维权了？
A：不是。被堵死的是 CMI 删除这条路径，直接侵权诉讼仍然开放。法院还留了一个口子：近乎逐字复现且删去署名信息的输出，仍可作为删除 CMI 的旁证。
Q：这份判决在中国或者欧盟有效吗？
A：没有直接效力。它是美国联邦上诉法院的判决，只在第九巡回辖区有约束力。欧盟、日本、中国适用各自的版权法律，不能把美国规则当成全球通用。
