AI 生成代码能不能直接商用，开源许可证风险怎么查？

AI 生成代码能不能直接商用，开源许可证风险怎么查？

我的回答是：不能因为“AI 生成”四个字，就直接推定可以商用。 也不能反过来简单推定它一定侵权、一定不能用。 企业更稳妥的做法，是把 AI 生成代码当作一项需要审查的交付物处理。 审查重点不是“这段代码是不是机器写的”，而是它是否带入了第三方权利、开源许可证义务和交付责任。 第一步，先看代码来源。 要确认这段代码来自哪一次生成、使用了什么输入材料、是否混入了已有代码或第三方材料。 如果输入材料本身涉及受保护作品、第三方代码或保密内容，后续输出就不能只看表面文本。 《中华人民共和国著作权法》可以支撑一个基本判断：代码或相关表达如果包含受保护内容、复制片段或第三方材料，就需要核查授权、许可范围和侵权责任边界。 但这并不等于说，所有 AI 生成代码当然侵权。 也不等于说，只要是 AI 生成，就当然没有著作权和开源许可证风险。 第二步，查依赖。 AI 生成代码进入项目后，通常不会孤立存在。 企业应当把它放回完整工程里，识别它依赖了哪些第三方组件、库或代码片段。 依赖审查的目的，是确认是否存在需要读取许可证文本、核对许可范围或影响客户交付责任的边界。 这里不能只问“能不能商用”，而要问“在当前项目、当前交付、当前使用范围内，哪些代码和依赖需要许可证核查”。 第三步，识别许可证。 SPDX License List 的价值，在于帮助识别许可证名称、SPDX 标识和许可证文本索引。 Open Source Initiative approved licenses 的价值，在于帮助识别常见开源许可证家族，并提醒使用者回到具体条款阅读。 这两个来源都不能替代具体项目的法律判断。 它们能支持的是：先把许可证找出来、标清楚、对应到具体代码和依赖，再判断商业使用前还缺什么审查。 第四步，查复制片段和相似代码。 AI 生成代码如果包含相似代码、第三方代码片段或来源不清的表达，就不能只用“模型生成”来切断风险。 审查时应当把相似片段、第三方片段和项目内既有代码区分开。 能够确认来源的，按对应授权和许可证边界处理。 不能确认来源的，至少要进入进一步复核，而不是直接进入商用交付。 第五步，核对贡献记录和交付责任。 这里的“贡献记录”，不是为了创造新的权利结论，而是为了回答一个合规问题：这段代码如何进入项目，谁提交，基于什么材料，最终交付给谁。 如果企业要把代码交付给客户，风险不只停留在内部使用层面。 EvidencePack 中的核心 claim 已经限定：企业应同时关注客户交付责任。 所以，商用前至少要把生成记录、代码进入项目的记录、依赖和许可证识别结果，与交付责任放在同一个审查框架里。 第六步，看 AI 服务和供应商边界。 《生成式人工智能服务管理暂行办法》能够支持的重点，是训练数据来源合法性、知识产权要求、输入材料保密边界、供应商保存和再训练条款等审查方向。 它并不能直接证明某一段生成代码已经获得商业使用许可。 因此，使用生成式 AI 服务时，还要关注输入材料是否适合提交、供应商是否保存、是否用于再训练，以及这些安排是否影响企业自己的知识产权和保密边界。 第七步，回到商用场景判断。 “商用”不是一个单独按钮。 不同商用安排会改变风险承受方式和审查重点。 审查结论也不应只写成“可以”或“不可以”。 更有用的结论，是写清哪些来源已经确认，哪些依赖已经识别，哪些许可证文本已经对应。 还要写清哪些输入材料、供应商保存或再训练条款仍然需要复核。 这些记录本身不能替代法律判断，但可以支撑企业说明审查过程。 在当前证据范围内，可以给出的稳妥结论是：AI 生成不当然消除著作权或开源许可证义务。 商用前，应先完成代码来源、依赖、许可证、复制片段、贡献记录和商用场景核查。 如果这些基础核查没有完成，我不建议只凭“AI 生成”就直接对外商用或交付。 如果这些基础核查已经完成，也仍然要回到具体许可证文本、输入材料边界、供应商条款和交付责任上做个案判断。 实务上，我会把这个问题拆成三句话。 第一，AI 生成代码可以进入商业项目的审查流程，但不应跳过审查直接商用。 第二，开源许可证风险要从依赖、片段、许可证标识和具体条款查起，而不是只看代码是不是由 AI 输出。 第三，企业对客户交付时，应当保留生成、引入、审查和交付边界的记录，以便说明自己如何处理第三方权利和开源合规问题。 这篇回答只提供一般法律信息，不构成针对个案的法律意见。具体项目还要结合代码来源、依赖清单、许可证文本、输入材料、供应商条款、复制片段、贡献记录和实际商用交付场景，由专业律师作出判断。