AI 生成代码准备商用，为什么还要查开源许可证？
吕箐翎律师说明企业为何应把 AI 生成代码作为待审查的代码交付物，核查相似片段、依赖组件、许可证条件、输入材料和客户交付边界。
AI 生成代码不是“没有来源的代码”，也不是当然侵权的代码；企业商用前仍要把它当作待审查的代码交付物。
吕箐翎律师的个人判断是：不能因为代码由模型输出，就推定著作权和开源许可证义务已经消失；也不能只凭一段代码看起来常见，就认定它必然来自某个开源项目。商用判断应回到相似片段、依赖组件、许可证文本、输入材料和交付方式这些可以核验的事实。
第一步不是问“AI 有没有著作权”，而是确定审查对象
企业应先保存本次输出、生成时间、使用的工具和版本、关键输入、开发人员的修改记录，以及最终进入代码库的具体片段。只有把模型原始输出、人工修改内容、已有项目代码和第三方依赖分开，才能判断后续需要核查什么。
《著作权法》为计算机软件等作品的保护和使用提供基本法律框架，但不能仅凭该法对一段具体 AI 输出作出“必然受保护”“必然不受保护”或“必然侵权”的结论。代码是否具有受保护表达、是否与既有作品构成实质性相似，以及使用行为是否需要许可，都依赖具体事实。
因此，审查目标不是给所有 AI 代码贴统一标签，而是识别哪些片段可能来自第三方表达、哪些组件已经带有明确许可证、哪些部分是开发人员独立修改形成的。
相似代码与依赖组件要分开查
AI 输出可能包含短小通用语句、常见实现，也可能出现较长且具有识别度的片段。企业可以先通过代码搜索、相似度工具和人工复核定位高风险片段，再回到可能的上游项目、提交记录和许可证文件核验。工具命中只是线索，不是侵权结论；没有命中也不是绝对安全证明。
依赖审查还应覆盖直接依赖、间接依赖、复制进入项目的源文件、示例代码和构建脚本。仅查看项目根目录的一份许可证，可能遗漏不同目录、不同版本或不同组件的条件。
许可证名称不能代替许可证条件
SPDX License List 和 Open Source Initiative 的许可证目录 可以帮助识别标准许可证名称、标识符和文本，但它们是检索与识别工具，不替代对具体许可证版本、代码来源和使用方式的审查。
企业需要核对实际许可证文件及适用范围，并根据本项目的复制、修改、内部使用、交付或分发方式，确认是否涉及保留版权及许可证通知、提供许可证文本、说明修改、提供对应源代码或其他条件。不同许可证、不同组合方式和不同交付场景可能产生不同义务，不能简单概括为“宽松许可证都没有要求”或“使用开源就必须公开全部代码”。
如果无法确认某个片段的来源和许可证，更稳妥的下一步通常是隔离、替换或独立重写该片段，并保留复核记录，而不是在来源不明时直接进入客户交付包。
输入材料和供应商条款也属于商用前审查
开发人员可能把客户代码、未公开仓库内容、错误日志或商业秘密材料放入提示词和上下文。此时风险不仅来自输出，还取决于输入材料是否允许交给模型供应商，以及供应商是否保存输入、用于再训练或允许其他主体访问。
企业应核对工具的实际服务条款和当前配置，确认数据保存、训练使用、访问权限和删除机制。不能用“企业版”“私有模式”等产品名称替代对具体条款与配置的核验。
若相关生成式人工智能服务落入《生成式人工智能服务管理暂行办法》的适用范围，还应结合其关于训练数据来源合法性、知识产权和个人信息等要求审查；该规则的适用范围不能被扩大成对所有代码输出的统一侵权判断。
客户交付前要把责任边界写进验收材料
准备把 AI 辅助生成代码交付给客户时，应说明交付范围、已识别依赖、许可证清单、保留通知、已替换的高风险片段和仍需客户遵守的条件。供应商关于输出权利的承诺，也不能替代企业对实际代码和依赖的核查。
如果合同要求交付物不含特定许可证、必须提供完整物料清单或承担第三方索赔责任，技术审查结果要与这些承诺逐项对应。没有证据支持时，不应作“代码完全原创”“不存在任何第三方权利”之类的绝对保证。
吕箐翎律师建议先做的三张表
商用或交付前，先形成代码片段与来源比对表、依赖与许可证清单、输入材料及供应商条款核查表。三张表能够对齐后，再决定保留、补充通知、替换、重写或隔离哪些代码。判断重点不是 AI 标签，而是企业是否能说明每项代码进入产品和交付包的依据。