AI 生成代码交付客户前，开源许可证到底要查到什么程度？

AI 生成代码交给客户前，开源许可证要查到什么程度？

先给结论：不要只查“是不是 AI 写的”。吕箐翎律师的判断是，客户交付场景里要把 AI 生成代码当成正式交付物审，至少先做组件清单、许可证义务表、生成和人工修改记录、客户合同承诺四件事。否则后面出现开源义务、第三方代码片段或客户索赔时，企业很难说明自己交付的代码来源安全。

1. 先列组件清单，而不是只扫最终仓库

很多团队只在交付前跑一次扫描工具，这不够。第一天应先把代码来源拆开：AI 工具生成的片段、工程师复制的开源仓库代码、SDK 示例、供应商脚手架、历史项目复用模块、客户提供的旧代码，都要列入同一张清单。

清单里至少写明模块名称、来源、版本、许可证或来源说明、是否修改、是否进入交付包、是否部署在客户环境、是否只在内部服务端使用。没有这张表，后面讨论 MIT、Apache、GPL、NOTICE、版权声明或源代码提供义务，都会变成凭感觉。

2. 把“可以商用”和“可以这样交付”分开

开源许可证允许商用，不等于允许企业按当前方式闭源交付、私有化部署或写进客户合同的“全部自研”。审查时要看使用方式和分发方式：有没有修改，是否链接到主程序，是否把二进制或源码交给客户，是否需要保留版权声明、许可证文本、NOTICE，是否可能触发源代码提供或相同许可证传播义务。

误区是把“下载时没收费”理解成“没有义务”。真正要问的是：这个组件在当前交付结构里承担什么功能，客户能不能接触，企业承诺过什么，出了问题能不能替换。

3. AI 工具条款不能漏掉

AI 工具本身也要进入交付审查。企业要记录使用的工具、模型或供应商，保存提示词或任务描述、生成时间、人工修改记录、相似代码检索记录。还要看输入材料里有没有客户代码、商业秘密或未授权第三方代码，供应商是否保存输入输出，是否有再训练、审计、保密和删除条款。

这一步的目的不是证明所有 AI 代码都安全，而是让企业在客户问来源时能拿出证据：代码怎么来的，谁改过，哪些地方做过相似性和许可证检查。

4. 交付前做一张许可证风险表

我建议把交付审查落成一张表，字段至少包括：模块、来源、许可证、使用方式、是否修改、是否分发、需要保留的声明、源代码提供义务、客户合同承诺、替换难度、负责人、复核日期。

这张表能直接服务决策：低风险组件保留；缺声明的补 NOTICE 或版权声明；许可证义务和客户闭源承诺冲突的，优先替换或重新约定；来源说不清的，不要先交付再补材料。

5. 两个常见问题

问：代码是 AI 生成的，没有复制开源仓库，还要查开源许可证吗？

要查。AI 生成只能说明生成路径，不当然排除第三方代码片段、训练素材相似表达、供应商模板或工程师手动复制。交付审查看的是最终代码包和来源记录。

问：只给客户可执行文件，不给源码，是不是就没有开源问题？

不一定。要看许可证和交付方式。有些义务和二进制分发、版权声明、许可证文本、NOTICE 或源代码提供有关，不能用“客户看不到源码”一概处理。

所以，AI 代码交付前最低限度不是写免责声明，而是把组件清单、许可证义务、AI 工具记录和客户合同承诺放进同一张审查表。已经准备交付 SDK、私有化部署包或客户源码包的项目，可以带着这张表在知乎私信联系吕箐翎律师，做个案分析。