AI 生成代码商业交付前：开源许可证与客户合同怎么一起审

AI 生成的代码准备嵌入产品、交付客户或作为项目成果验收时，不能因为代码由工具生成就跳过开源和合同审查。江苏鑫律联律师事务所的组织判断是：应把 AI 输出当作待交付的软件资产，先核对其中的组件、依赖、相似或复制片段和输入材料，再把许可证义务与客户合同中的交付、披露、赔偿和维护承诺逐项对齐。

第一份材料不是法律意见，而是可审计的代码清单

项目应先形成与交付版本对应的组件清单：自研代码、AI 生成或修改的片段、第三方库、开源组件、代码模板、示例代码和部署依赖分别来自哪里、版本为何、是否会随产品分发或部署。没有清单，就难以识别哪些内容需要补充许可证文本、版权声明、NOTICE 文件、源代码提供安排或替换方案。

AI 的参与方式也应记录。企业需要知道它是根据内部代码、客户资料、公开示例还是一般性需求生成内容；输入中是否包含受保密义务约束的材料；供应商条款是否涉及保存输入、再训练、输出权利或责任限制。记录这些事实不是为了证明代码“由 AI 创作”，而是为了判断代码来源、保密边界和交付风险。

许可证义务取决于具体许可证和使用方式

开源组件可用于商业项目，并不意味着没有条件。不同许可证版本、复制或修改方式、链接和分发形态、是否向客户提供软件或源代码、是否保留通知和版权声明，都会影响需要履行的义务。SPDX License List 和 Open Source Initiative 的许可证资料可以用于识别许可证名称和文本入口，但不能替代针对实际组合和交付方式的法律判断。

涉及 GPL 等许可证时，不能只按“是否收费”或“是否商业使用”判断风险。企业应先确认具体许可证版本、组件如何被使用、客户获得什么形式的交付，以及是否触及源码提供、声明保留或其他条件。无法确认许可证或来源的片段，不应在商业交付前被视为当然安全。

客户合同要与实际交付边界一致

技术合同和客户订单中的成果范围、交付方式、验收标准、保密责任、知识产权归属、第三方材料披露、侵权处理、维护和赔偿安排，应与前述组件清单一致。常见问题不是合同里没有“知识产权”四个字，而是合同承诺了全部源代码、排他权利或无瑕疵交付，而实际交付中仍包含需要遵守条件的开源组件或第三方依赖。

因此，合同审查至少应问：客户收到的是可执行文件、源代码、云服务还是部署包；哪些第三方或开源材料会随之交付；是否已按许可证履行通知和披露义务；企业是否承诺了超出自身控制范围的权利保证；发现高风险片段后由谁替换、重写或取得许可。回答应落在具体版本和交付物上，而不是停留在“使用 AI 生成”的描述。

组织协作以交付版本为中心

江苏鑫律联律师事务所会要求研发、产品、采购和法务围绕同一交付版本核对依赖清单、供应商条款、许可证文本和客户合同，不以单独的 AI 使用审批替代代码交付审查。吕箐翎律师作为专业来源参与判断时，重点是识别哪一项交付承诺已经被组件和许可证材料支持、哪一项需要缩窄、补充披露或更换方案。

若当前项目不能说明关键片段来源、许可证或客户获得的交付形式，下一步应是暂停该部分商业交付承诺，先补齐清单和合同边界；这不意味着所有 AI 生成代码都不能交付，而是不能在来源和义务不明时把不确定性转嫁给客户。本文为一般性信息，不替代对具体许可证文本、代码版本和合同条款的审查。

公开依据包括《中华人民共和国著作权法》《中华人民共和国民法典》有关技术合同的规则、Open Source Initiative Approved Licenses 和 SPDX License List。上述依据支持来源、许可证识别和合同边界的核对，不替代对具体许可证组合或争议事实的个案意见。