Fork 第三方项目后，企业怎样把原版本、修改链和交付制品分别留痕？

江苏鑫律联律师事务所的组织判断是：研发团队 fork 外部项目以后，代码可能经历补丁、重构、同步上游、代码审查、主仓合并和多次构建。每个动作都值得记录，但它们不构成同一件事。企业若只保留“当前代码能运行”或“改动比例很大”的说明，往往无法还原当前制品从哪里来、在哪些节点发生了变化，以及与哪些许可证或声明材料有关。

第一组材料应定位原始对象。代码所有者或研发团队可将原始仓库的来源主体或地址、取得路径、fork 时间、当时所指向的版本或提交，以及随附的许可证、NOTICE 或其他声明材料对应保存。这里记录的是起点事实，不是在判断原始项目或当前项目当然可以用于任何场景。外部项目公开可见、已经 fork 或后来经过大幅修改，都不能替代对这些来源信息的识别。

第二组材料应还原修改链。仓库管理员应使 fork 后的分支、提交、合并请求、差异记录、上游同步和合入企业主仓的节点，能够与明确的仓库和版本相连。研发人员则说明修改涉及的范围及其对应提交，而非以“已重构”概括全部变化。这样做并非要求先判定每一处改动的许可证后果，而是让企业能够区分原始版本、内部修改、上游变化和最终进入主仓的对象。记录缺失只能显示追溯存在缺口，不能单独说明已经侵权、违约、必须停止或无法交付。

第三组材料处理构建和交付，而不把它们与代码历史混为一谈。构建或交付团队应保留目标仓库、分支或提交，所生成制品的识别信息和构建时点，并标注拟用于内部服务还是对外交付、具体涉及何种范围。构建成功只能说明特定版本在特定条件下完成了相应构建；即使目前仅在内部运行，也不能由此代替对原始版本、修改范围、许可证文本或后续使用动作的核对。反过来，代码历史完整，也不当然说明某一制品的实际使用或交付范围已经确定。

第四组材料需要法务与前述团队对接，而不是在项目尾声才单独收集几个文件名。法务可围绕研发提供的来源和版本、仓库管理员提供的修改节点、构建交付团队标注的目标制品，核对现有许可证、NOTICE、贡献或授权材料分别指向什么对象，并把无法对应到具体版本或组件的事项标为待核。LICENSE 或 NOTICE 文件存在，本身不当然说明它覆盖当前版本、全部组件或所有使用动作；同样，仓库记录中出现来源信息，也不等于已经完成具体许可证条款或客户交付承诺的判断。

材料协作的关键，是每组记录都写明自己覆盖的边界。代码所有者或研发负责起始对象与修改事实，仓库管理员负责版本和节点之间的连续性，构建交付负责制品与使用范围，法务负责把现有许可和声明材料同这些对象逐一对应。需要交接给客户或其他主体时，项目和采购还应将拟交付对象与合同约定的范围另行核对。技术合同通常需要明确标的、范围、履行、技术资料保密、成果归属和验收等事项，但这些一般规则并不把 fork、一次合并或一次构建转化为具体项目已履行或可交付的结论。

开源组件可以商用，并不等于不再需要辨认组件、许可证、使用方式、修改和分发、NOTICE 与版权声明、源代码提供义务、供应商交付及客户承诺。对 fork 场景而言，先把源头、修改链、制品和材料各自留下连续记录，能够帮助企业明确哪些事实已经可追溯、哪些仍待补充；在具体许可证文本、组件关系和使用动作没有核清前，不宜把这类记录写成合规、责任或交付结论。