企业软件交付验收：开源组件清单、许可证与 NOTICE 要怎样核对

先给判断：验收开源合规，不能只看一张“可商用组件表”

企业软件准备交付客户时，开源组件的验收对象不是抽象的研发仓库，而是客户实际取得的安装包、容器镜像、SDK、源码包，或实际获得的软件服务。开源组件可以用于商业项目，并不等于交付时无需保留声明、附带许可证材料或处理其他许可证条件。

是否需要公开对应源码、保留 NOTICE 或版权声明，或者履行其他发布义务，不能只凭“这是商业软件”下结论。组件是什么、准确版本为何、许可证文本如何规定、是否修改过，以及本次究竟是分发制品、交付源码还是提供服务，都会改变判断。

判断一：BOM 必须对应最终制品，不能只交研发依赖截图

交付验收先看软件物料清单（BOM）能否回答一个具体问题：客户收到的每个制品里，究竟包含哪些开源组件。安装包、镜像、SDK 和源码包可能各自包含不同组件；构建或测试时使用过的工具，也未必进入交付物。

因此，BOM 不宜只有组件名称和“开源/商用”标签。至少应让每个交付制品对应组件名称、准确版本、获取或引入方式、是否进入最终制品，以及相应许可证文本。若供应商给出的只是通用依赖表，无法映射到本次制品，就不能替代交付验收记录。

判断二：许可证识别要连同版本和修改事实核对

同名组件的不同版本，或者未修改使用与修改后再交付的情形，不能当然沿用旧项目的处理方式。验收人员需要确认清单中的许可证标识能否追溯到该组件、该版本的许可证文本，并单列是否改动代码、改动了什么、改动后的代码进入了哪个交付物。

这里的边界是：没有组件、版本、许可证文本和使用事实，就不宜给出“无需提供源码”或“只要附一份声明即可”的结论。Open Source Initiative 的许可证目录可用于定位许可证文本；具体交付义务仍要结合实际组件和提供方式分析。

判断三：NOTICE 和版权声明要随交付物核验，而不是留在开发资料夹

对于需要保留的 NOTICE、版权声明或许可证副本，验收时要查它们是否已经进入与组件相应的交付包、随附文档或约定的交付位置，并能说明对应的是哪一个组件和版本。仅在内部合规表中标注“已处理”，但客户取得的材料中找不到相应内容，交付记录就没有闭合。

这一核对也应区分制品：镜像中的组件、SDK 中的组件与源码包中的组件，未必适用同一份随附材料。企业应保留“组件—版本—许可证—声明材料—交付位置”的对应记录，以便客户验收或后续版本更新时复核。

判断四：供应商承诺和客户合同，不能替代许可证事实

采购、外包或集成供应商交付软件时，应要求其提供与本次制品对应的组件 BOM、许可证识别、修改说明和声明材料，而不是只接受“全部可商用、无风险”的笼统承诺。供应商承诺可以约定资料交付、问题处理和责任分配，但不能代替对实际组件和许可证文本的识别。

客户合同同样应与验收结果对齐。合同可以明确交付范围、第三方组件资料、技术资料保密、验收标准和责任边界；但如果尚未弄清哪些组件进入了何种制品、是否有修改、如何提供给客户，合同中的开源表述就可能与实际交付脱节。技术合同中对标的范围、履行方式、资料保密、成果归属和验收标准的约定，也需要落到这批具体交付物上。

交付前，把一条对照链放进验收包

企业下一步可按每个安装包、镜像、SDK、源码包或服务交付形成一条对照链：交付物名称与版本；对应的组件 BOM；组件准确版本和许可证文本；是否修改及实际分发或提供方式；应随附的 NOTICE、版权声明或许可证材料及其交付位置；供应商提供的说明；以及客户合同和验收单中对应的约定。

这不是为了预先假定某一许可证必然要求公开代码，而是避免把“可商用”误写成“没有任何义务”。事实和材料对齐后，再判断本次交付应如何处理具体许可证条件，结论才有可核对的基础。

吕箐翎律师提示：开源组件交付验收的关键，不是让合同多写一句保证，而是让最终制品、组件清单、许可证材料和交付承诺指向同一组事实。