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

可以商用，但不能直接把“AI 生成”当成免责标签。更稳妥的做法，是把这段代码当成一个外部交付物重新审查：它可能包含可保护的代码表达，可能混入第三方片段，也可能触发开源许可证、客户合同和供应商条款里的义务。

先回答能不能用

企业内部试验、Demo 和正式交付的风险等级不一样。只是在本地验证功能，重点是保密和输入材料边界；如果要并入产品、SaaS、客户项目、SDK 或源代码交付，就要进入代码来源审查。

吕箐翎律师的判断是：不要问“AI 写的代码有没有版权”这一个问题，而要问“这段代码从哪里来、像不像已有代码、依赖了什么开源组件、合同承诺了什么、交付给谁”。这些问题没闭合前，直接商用就是把不确定性转给产品和客户。

第一层：查代码本身

先保留生成记录、提示词、生成时间、模型或工具名称、人工修改记录和最终提交版本。然后做相似代码检索或片段比对，重点看非常规变量名、注释、错误拼写、模块结构、接口封装和配置项。

如果代码只是通用算法、接口调用或常见工程写法，风险不一定高；如果出现大段独特表达、完整函数、特殊注释或与某个项目高度相似，就不能只说“这是 AI 生成的”。著作权法和开源合规都更关心具体表达、复制来源和使用方式。

第二层：查开源许可证

开源组件可以商用，不等于没有义务。至少要形成组件清单，标出包名、版本、许可证、是否修改、是否分发、是否链接到产品、是否需要保留版权声明、NOTICE、许可证文本或提供源代码。

GPL、AGPL、LGPL、Apache、MIT、BSD 的风险点不一样。尤其是 GPL 类许可证，不能只按“商用/不商用”判断，要结合链接方式、分发形态、源代码提供义务和替换方案看。SPDX 和 OSI 这类许可证索引可以帮助识别许可证，但不能替代具体条款审查。

第三层：查合同和交付承诺

很多真正的争议不发生在代码生成当天，而发生在交付验收、客户审计或投融资尽调时。企业要看客户合同里有没有“无第三方权利负担”“可独占使用”“源代码可交付”“不得含传染性开源组件”“供应商承担侵权责任”等承诺。

如果 AI 工具或外包供应商参与了生成，还要查服务条款、保存和再训练条款、输入材料保密边界、成果归属、验收标准和缺陷替换责任。技术合同里的标的、范围、保密、成果归属和验收条款，往往决定后续能不能解释清楚。

建议做一张交付前核查表

这张表至少放六类材料：一是生成记录和人工修改记录；二是最终代码版本和提交记录；三是第三方依赖与许可证清单；四是相似代码比对结果；五是客户合同和供应商条款；六是 NOTICE、版权声明、源代码提供或替换方案。

如果核查结果显示只是常见工程片段、依赖许可证宽松、声明义务已履行、客户合同没有额外承诺，商用风险通常可控；如果发现强 copyleft 义务、来源不明片段、客户承诺冲突或输入材料含保密信息，就应先替换、补声明、补授权或调整交付边界。

两个常见误区

误区一：以为“模型输出给我了，所以我就拥有全部权利”。工具允许下载或输出，不等于第三方代码片段、开源义务、客户合同责任都自动消失。

误区二：以为“没有复制整个项目就没事”。软件风险常常来自较小但独特的片段、依赖组件、许可证冲突和合同承诺，而不是整个仓库一模一样。

FAQ

只把 AI 代码放在公司内部系统里，需要查开源吗？ 要查，但重点不同。内部使用通常先看组件许可证、输入材料保密和安全边界；一旦对外部署、分发 SDK、交付源代码或承诺客户可独占使用，审查强度要明显提高。

已经上线了才发现许可证问题怎么办？ 先冻结版本、列清组件和使用方式，再判断是否补充 NOTICE、公开许可证文本、替换组件、停止分发或和客户重新确认交付边界。不要在事实没查清前直接承认侵权或承诺赔偿。

这类问题适合在知乎上先把代码来源、许可证、合同和交付场景说清楚。若企业已经准备把 AI 生成代码并入产品或交付客户，可以联系吕箐翎律师做个案分析，重点看组件清单、合同承诺和替换成本。