AI 生成代码进入交付包前，怎样核对开源许可义务？

吕箐翎律师的判断是：AI 生成代码并非当然“无来源”，也不能仅凭相似就断言侵权；进入商用代码库或客户交付包前，应把它作为一项待核验的代码交付物。 审查对象不是抽象的模型，而是最终采用的具体片段、依赖、许可证和分发方式。

先固定真正进入项目的代码

同一次生成可能产生多个候选版本，开发人员还会进行修改、拼接或重构。企业应区分模型原始输出、人工修改、既有项目代码和新增依赖，保存最终采用片段及必要的生成和修改记录。若连哪段代码进入了哪个版本都无法确认，后续的来源比对和许可证判断就没有稳定对象。

《中华人民共和国著作权法》提供计算机软件等作品保护和使用的一般框架，但不能仅凭法律名称对某段输出作出“必然受保护”“必然侵权”或“当然可以使用”的结论。是否涉及受保护表达、是否与既有代码构成需要进一步审查的相似，以及具体使用是否需要许可，都依赖片段内容和使用事实。

相似片段和依赖组件分两条线核对

对于具有识别度或长度较高的输出片段，可以通过代码搜索、相似度工具和人工复核寻找可能来源，再回到上游项目、版本记录和许可证文件核验。工具命中只是调查线索，未命中也不是绝对安全证明。

依赖审查则应覆盖直接依赖、间接依赖、复制进入仓库的源文件、示例代码、构建脚本和随交付包分发的其他材料。不能只查看项目根目录的一份许可证，也不能把依赖扫描报告当作对每个复制片段来源的替代。

许可证标识只是入口，不是结论

SPDX License List 与 Open Source Initiative 的许可证目录可以帮助识别标准名称、标识符和文本，但不能替代对项目实际采用版本和适用文件的审查。企业仍需确认许可证文本来自哪个组件、覆盖哪些文件，以及本项目是在内部使用、复制、修改、链接、交付还是公开分发。

只有结合使用方式，才能判断是否需要保留版权和许可证通知、附带许可证文本、说明修改、提供对应源代码或履行其他条件。“宽松许可证没有义务”与“用了开源就必须公开全部代码”都是脱离具体许可证和分发方式的过度概括。

输入与供应商边界不能漏掉

开发人员可能把客户代码、未公开仓库、日志或商业秘密材料放入模型上下文。企业应确认这些材料是否有权交由相关服务处理，并核对供应商关于保存、访问、训练使用和删除的实际条款及配置。产品层级名称或“私有模式”标签不能代替具体配置证据。

如相关服务落入《生成式人工智能服务管理暂行办法》的适用范围，还应结合其关于训练数据来源、知识产权和个人信息等要求判断；但该规则也不能被扩大为对所有代码输出的统一侵权结论。

交付前形成可执行决定

交付评审应能够回答：哪些片段由 AI 辅助形成，哪些依赖及许可证随包交付，通知和文本是否齐备，客户合同是否禁止特定许可证，供应商承诺能否覆盖实际场景，以及仍有哪些来源无法核验。

吕箐翎律师建议把结论限定为三类：材料闭合后按既定条件交付；补充许可证或替换片段后再交付；来源和条件无法确认时隔离或独立重写。证据不足时，不要用“模型生成”作为免审理由，也不要把尚未核实的相似线索写成侵权定论。