一组具有代表性的 B2B 线索发现情境，展示 AI 如何从典型业务交流中识别值得人工核实的销售机会。
收购尽调已经开始，产品里用了哪些开源组件却没人说得清：法务先查什么？
并购尽职调查中，法务运营负责人如何在没有统一软件清单的情况下，快速锁定高影响开源组件及其许可证义务。
以下是一个典型场景演示，用于说明产品的判断逻辑，不代表真实客户案例、客户证言、合同、收入结果或转化数据。
01场景描述
02Signal 判断
03可信度与优先级
04人工下一步
判断时关注的线索
- 许可证义务不清晰
- 分发方式与清单不符
- 证据链断裂
“能用的只有这份清单。“工程副总裁把一张 A4 纸推到会议桌中间，“但容器镜像里的组件不在上面。”
尽职调查进入第三周，法务运营负责人手上有两份互相矛盾的软件物料清单。工程团队交了一份——只覆盖生产环境直接依赖。安全团队另有一份——容器扫描的输出，包名和版本号格式对不上。还有一份没人提交的清单：市场部在客户现场部署的解决方案里嵌入了修改过的开源组件，而这件事没有任何人通知法务。
这个场景把许多科技公司在并购中反复遇到的开源许可证问题压缩在一起，用来讨论一个方法层面的解法。问题本身不新鲜，但它在并购窗口下的紧迫感，会让每一个法务运营负责人都感到熟悉。
收购窗口一开，法务运营在等什么
并购协议中的陈述与保证条款通常要求卖方披露所有第三方软件使用情况。但实际操作中，法务运营拿到的往往不是一份统一清单，而是来自不同团队、格式各异的多个版本。
工程团队维护的依赖文件——package.json、requirements.txt、go.mod 等——只记录直接引用，不包含传递依赖。安全团队提供的容器镜像扫描报告覆盖操作系统层和语言运行时，但无法区分哪些组件是主动引入、哪些只是基础镜像的一部分。DevOps 记录的构建脚本和部署配置中，可能包含额外下载的二进制包，但这些信息没有被纳入任何一份正式清单中。
这三份材料单独看都有缺口，合在一起又因为编号和版本不一致而无法交叉验证。而收购方的律师正在 data room 里等着要一份统一的开源披露声明。
“许可证是 Apache 2.0，但我们是改了之后嵌入发货的”
一个容易被忽视的关键问题：即使每个组件都有明确的许可证声明，实际的义务判断还取决于分发方式。
同一个 Apache 2.0 许可的组件，在三种不同场景下的义务完全不同：
- 通过 REST API 供外部调用，不涉及分发——没有修改后再次声明的要求。
- 以源代码或二进制形式嵌入产品并直接交付给客户——需要保留版权声明和免责条款。
- 在 Apache 2.0 基础上做了修改并以源码形式再分发——需要清楚标注修改范围和日期。
但在并购尽调中，法务运营面对的实际情况是：没有人能准确说清一个组件当前被用在哪个产品版本里、以什么方式分发。更棘手的是，同一个组件在不同产品线中可能采用完全不同的分发方式，而对应的许可证义务也因此不同。
三个断层让传统做法失效
尽调团队通常会向各个部门发放问卷收集信息。但传统问卷在开源许可证审查上存在三个系统性断层。
断层一：清单与分发的分离。 开发者记录的依赖是“写了什么代码”，但法务需要知道“什么被发出去了”。容器镜像、SaaS 部署、嵌入式设备——不同的分发管道对应不同的许可证义务触发条件。
断层二：许可证文本与使用方式的分离。 一个组件声明的许可证类型只是起点。Copyleft 类许可证的具体义务取决于它是被“聚合”、“修改并分发”还是“作为服务运行”。同一份许可证文本在不同使用方式下的法律效果不同。
断层三：证据链的断裂。 尽调结束时，收购方需要的不只是当前的合规状态，还要能证明卖方在特定时间点上的义务履行情况。如果没有版本化记录和变更历史，事后补证的成本极高，甚至可能影响交割条件。
开源义务核对表：先查这四类组件
不是所有开源组件在并购尽调中都值得同等投入。以下四类必须逐项确认许可证义务和实际分发方式的对应关系。
第一类：核心功能组件。 产品如果没有这个组件就无法运行。这类组件的许可证变更或义务违规会直接阻断交易。
第二类：修改后分发的组件。 卖方在原代码基础上做了修改，并以源码或二进制形式交付给客户。需要确认修改范围的标注是否完整，以及修改后的许可证声明是否符合原许可证的要求。
第三类：含 Copyleft 传染性的组件。 使用 GPL、AGPL、SSPL 等许可证的组件，其义务可能超出组件本身，影响到与之链接或聚合的代码。这类组件需要格外关注“传染”范围的界定。
第四类：容器镜像中的操作系统层组件。 基础镜像中的包管理器安装的库，往往被团队忽略，却可能引入 GPL 类许可证。Alpine、Ubuntu 等基础镜像各自携带的包及其许可证清单，需要单独提取和审查。
判断表：高影响组件 vs 低影响组件
区分高低影响组件，决定哪条证据链需要优先加固：
| 判断维度 | 高影响（优先处理） | 低影响（可后续跟进） |
|---|---|---|
| 许可证类型 | GPL / AGPL / SSPL / Elastic 2.0 | MIT / Apache 2.0 / BSD / ISC |
| 分发方式 | 嵌入二进制产品并分发 / SaaS 对外提供服务 | 内部工具 / 仅内部 API 调用 |
| 修改程度 | 对组件源码做了修改 | 未修改，按原样使用 |
| 在产品中的角色 | 核心逻辑依赖 / 不可替换 | 辅助功能 / 可替代 |
| 许可证声明显性 | 无授权声明 / 声明与使用方式矛盾 | 声明完整且与使用方式一致 |
处理优先级：同时满足两条以上高影响条件的组件，应在两周内完成证据固化。
锁定证据负责人和修复优先级
完成高影响组件识别之后，下一步是为每个组件指定证据负责人并评估修复优先级。
证据负责人不一定是法务团队成员，而是实际掌握该组件使用情况的人：可能是负责该模块的架构师、管理对应容器镜像的 DevOps 工程师、或者签署了第三方代码引入申请的采购负责人。
为每个高影响组件建立一份最小证据包：
- 组件的来源版本和当前使用版本
- 许可证文件原文及获取时间戳
- 组件的分发方式及对应产品版本
- 如有修改，修改记录和修改范围说明
- 容器镜像或部署单元的构建时间戳和基线信息
修复优先级按影响范围和修复难度综合判断：
- P0（交易阻断）：核心组件的 Copyleft 违规，无替代方案
- P1（交易风险）：分发的修改版组件未补充授权声明
- P2（限期整改）：容器镜像中嵌套的 Copyleft 组件声明不完整
- P3（后续优化）：内部工具中的许可证声明缺失
有了这个优先级分层，法务运营可以向交易团队清晰说明哪些问题必须在本轮尽调中解决，哪些可以纳入交割后的整改计划。
将核对表固化为可复用的流程
单次并购尽调中的开源许可证审查可以靠人工突击完成。但如果公司有持续的软件交付节奏，更高效的方式是把核对表中的判断逻辑嵌入日常流程——让每次发布都自动完成许可证义务与分发方式的比对，而不是在下一次尽调时重新从头盘查。
一些团队会搭建轻量级的治理框架来维持核对表的持续运转。关于如何将法务运营信号与业务协同流程结合，信号框架 和 源码治理 这两篇文章讨论了具体的方法。对于跨部门证据链的协同管理，信号情报 提供了进一步的操作视角。
常见问题
并购尽调中开源许可证审查和普通合规审计有什么区别
并购尽调有明确的时间窗口，法务运营必须在交割前提炼出哪些组件影响交易条款，而不是像日常合规审计那样可以分阶段推进。时间压力决定了审查范围必须聚焦，没法等各个团队慢慢补全数据。
容器镜像里嵌套的开源组件怎么查
容器镜像是多层结构，基础镜像层、应用层和运行时层各自可能引入不同许可证的组件。需要从 Dockerfile 或构建脚本入手追踪每一层的来源镜像和包管理器安装记录，再与实际运行时的 SBOM 比对，才能发现多层叠加的许可证风险。
如果发现违反许可证义务的组件，修复周期一般多长
修复方案取决于组件角色和违反类型。替换核心功能组件可能需要数周甚至涉及架构调整；补充授权声明或调整分发方式可能在几天内完成。关键在于尽调阶段区分哪些必须改、哪些可以限期整改，并让收购方认可修复计划的时间表。
要点总结与资料来源
要点总结
- 并购尽调中的开源许可证审查，核心矛盾不是“用了什么”，而是“以什么方式用的”。
- 传统问卷方法在清单与分发对应、许可证文本与使用方式对应、证据链完整性三个方面存在系统性断层。
- 开源义务核对表帮助法务运营在有限时间内聚焦高影响组件，并为每个组件指定证据负责人和修复优先级。
- 判断表（许可证类型 × 分发方式 × 修改程度 × 产品角色）是区分 P0–P3 优先级的关键工具。
常见问题
并购尽调中开源许可证审查和普通合规审计有什么区别？
并购尽调有明确的时间窗口，通常 4-6 周内要完成从清单梳理到风险报告的全流程。普通合规审计可以分阶段推进，但并购场景下法务运营必须在交割前提炼出哪些组件影响交易条款——来不及等各个团队慢慢补数据。
容器镜像里嵌套的开源组件怎么查？
容器镜像是多层结构，基础镜像层、应用层和运行时层各自可能引入不同许可证的组件。需要从 Dockerfile 或构建脚本入手追踪每一层使用的来源镜像和包管理器安装记录，再与实际运行时的 SBOM 比对，才能发现多层的许可证叠加情况。
如果发现违反许可证义务的组件，修复周期一般多长？
修复方案取决于组件角色和违反类型。替换一个核心功能组件可能需要数周甚至涉及架构调整，而补充授权声明或调整分发方式可能在几天内完成。关键是在尽调阶段区分哪些必须改、哪些可以限期整改，并让收购方认可修复计划的时间表。