发布安装包、镜像或 SDK 前：仓库更新、制品版本和第三方材料为什么不能互相替代？

吕箐翎律师的判断是：发布前最容易出现的误解，是把“仓库已经更新”“构建已经成功”或“目录里已有 LICENSE 和 NOTICE”合并成一句“材料已经齐了”。这些记录不回答同一个问题。仓库状态指向特定代码状态；制品版本指向准备交付的对象；第三方材料指向其明确覆盖的内容；接收者、渠道和合同要求则说明外部动作的范围。它们需要相互对应，而不能相互替代。

仓库状态不能代替实际准备交付的制品

某一分支、提交或合并记录，只能说明仓库在明确时点的状态。安装包、镜像、SDK 或插件的名称、版本、构建号或哈希，则是识别实际制品的另一组信息。即使仓库中已经出现某项更新，也不能只据此认定拟交付制品一定包含该更新；反过来，制品可被定位，也不说明其所用的构建输入和仓库状态已经还原清楚。

因此，先把拟发布的制品名称、版本、构建号或哈希，与对应的构建记录、仓库分支或提交分别连起来。现有材料只能说明已识别对象之间的对应程度。对象、版本或构建关系尚不清楚时，结论应停在相应事实待补，而不是把“已构建”写成制品内容和交付材料均已确定。

制品已经锁定，也还要看组件和修改状态

一旦制品有了明确标识，下一步仍是核对它实际包含的组件、准确版本以及已知修改状态。组件清单、构建配置或其他记录可能帮助识别这些事实，但一个通用清单不能自动覆盖每个制品版本；同一组件名称也不能代替准确版本和实际进入制品的情况。

商业软件使用开源组件后，是否需要保留声明、提供某些材料或履行其他发布相关事项，不能仅因“商用”“使用开源组件”或“已发布”作一概回答。应先把实际组件、版本、相关文本线索，以及分发、提供服务或修改等具体动作还原出来。本文的重点只是这些对象为何需要对上，并不替代对任何具体许可证文本的解释。

第三方材料要回答“覆盖什么”，不是只回答“有没有”

LICENSE、NOTICE、版权声明、源码或第三方清单，都可能是已有材料，但各自只能说明明确的对象和范围。看到一份声明，不能直接推出它覆盖全部组件、全部修改和所有制品；反之，某一材料尚未能与制品对应，也只能说明需要继续核对其覆盖范围，不能预断任何侵权、违约、停止或交付结果。

材料核对时，应把它们放回具体制品、组件版本和修改状态旁边，而不是作为项目级的统一标签。这样能够区分：已有材料实际指向了哪个对象，哪些制品或组件尚未找到对应材料，以及哪些事项仍需要按具体文本进一步判断。

外部动作还需落到接收者、渠道和约定

同一个制品的外部动作也不能只写成“发布”。应识别实际接收者、发布或交付渠道，以及客户、平台或合同对该制品材料提出的原文要求和未知项。一个客户或渠道的材料要求不能自然推广到全部接收者；一个制品版本曾经用于某个渠道，也不等于另一个版本或渠道的事实已经相同。

技术合同中关于标的、范围、履行、成果归属和验收的安排，可以提供一般合同边界，但不替代对具体制品、材料和接收关系的还原。发布前可以暂时将材料分成四组：仓库和构建状态；明确制品及版本；组件、修改和现有第三方材料；接收者、渠道及其要求。每一组标出能覆盖和不能覆盖的对象，才能避免用仓库状态、制品标签或一份通用材料替代其他仍待补的事实。