共享组件库复用到新产品时，企业怎样保留版本、制品和用途记录？

江苏鑫律联律师事务所的组织判断是：同一模块被抽取为内部共享组件库后，常会进入不同产品、不同团队维护的仓库，最终又生成不一样的构建制品。共享库可访问、某个版本已经稳定，或一个产品曾经使用过，都不意味着其他复用点的事实已经同时明确。真正需要连续保留的，是从原始模块到公共库版本，再到每一个产品、制品和实际动作的对应关系。

组件责任人首先需要维护组件自身的版本边界：原始模块是什么、来自何处、起始版本为何、经历过哪些修改，以及当前公共库中可供引用的版本是什么。这个记录帮助企业识别公共库里的对象，而不是给所有下游产品预先赋予同一结论。公共库中一个组件存在，不当然说明每个仓库都实际引用该版本；原始引入记录也不能自动说明后来新加入的依赖、修改或替换关系。

平台或研发团队应将“可被引用”与“已经被某个产品使用”分开。对于每一个复用点，可以记录产品或团队对应的仓库、实际依赖的组件版本、锁定文件或其他版本线索，以及构建参数、补丁、替代依赖或环境差异。这样，公共库版本与产品实际构建对象之间才有可核对的连接。一次主仓合并、一次构建成功或一个通用组件清单，通常只能指向它明确记载的范围，不能替代对其他产品、其他制品或后续依赖变化的确认。

复用产品团队则应把代码引用和业务或交付动作拆开说明。相同组件可能仅被内部服务调用，也可能进入下载包、客户部署包或其他对外制品；产品将进入哪个市场、面向哪些客户或以何种形态提供，也未必由组件仓库记录回答。构建与交付团队应在形成制品时保留制品与构建版本的对应信息，并标注已知的使用或交付范围。某一个产品没有对外分发，不能据此说明其他产品没有需要核对的外部动作；同样，某个制品已经完成构建，也不自动覆盖其余产品的实际使用范围。

法务的工作重点是让现有材料能够回到具体复用点。基于组件责任人提供的来源与版本、研发平台提供的依赖和构建差异、产品和交付团队提供的动作范围，法务可将许可证、NOTICE、合同、贡献者关系或授权材料分别放入对应索引。文件存在不等于覆盖范围已经清楚：一份 LICENSE 或 NOTICE 不能当然代表所有产品版本、依赖组合和实际用途；一份产品合同材料也不能替代其他产品或制品的事实。无法与对象、版本或用途对应的内容，应保持为待核事项。

这种协作索引不应是一张笼统的“开源已合规”清单。对每一个复用点，至少应能够看见：使用的是哪个组件和版本；由哪个产品或仓库引用；形成了什么制品；目前已知是内部运行、服务、下载、交付或其他动作中的哪一种；现有哪些许可证、声明、合同或授权材料；哪些环节仍没有材料覆盖。组件责任人、平台研发、产品团队、构建交付和法务各自对其事实来源负责，才能避免把原始记录放大为全部产品的结论。

开源组件可以商用，不等于企业不需要核对组件清单、许可证识别、使用方式、修改和分发、NOTICE 与版权声明、源代码提供义务、供应商交付及客户合同承诺。技术合同中有关标的、范围、履行、技术资料保密、成果归属与验收的一般安排，也提示企业应将对象和实际动作分开识别。对共享组件库而言，连续记录只能帮助定位事实与缺口；具体许可证、合同和实际使用尚未核清时，不宜将其写成任何产品当然可以复用、交付或已无风险的判断。