3. 违规使用风险识别方法

识别开源违规使用风险，核心不是“查一遍有没有开源代码”，而是回答三个问题：用了什么、以什么方式用、这种用法是否触发许可证义务。代码扫描解决“用了什么”，依赖分析解决“传递依赖里还有什么”，许可证冲突检测解决“义务是否被触发”，人工审计解决“工具判断不了的部分”。四类方法各有盲区，只有组合使用才能形成可复核的证据链。

一、代码扫描：从文件指纹到片段匹配

代码扫描的基本原理是把待检代码与开源代码库做相似度比对。常见做法有两类：一是文件级哈希匹配，对文件做归一化（去空白、去注释、统一换行）后计算哈希，命中即高置信；二是片段级指纹匹配，把代码切成固定长度的 token 序列（如 20～30 个 token）生成指纹，再与指纹库比对，能发现被改写、插入、重排的片段。

实际执行时，建议先做预处理再扫描：排除第三方目录、构建产物、压缩文件、二进制和测试数据，避免噪声淹没真实命中。例如某项目扫描结果中 80% 命中来自 node_modules/ 和 dist/，排除后有效命中从 1200 条降到 90 条。扫描输出应至少包含：命中文件路径、匹配的开源项目与版本、匹配片段行号、相似度、许可证标识。相似度低于阈值的命中不能直接定性，需进入人工复核。

二、依赖分析：把传递依赖摊开

现代项目直接声明的依赖往往只有几十个，但传递依赖可能上千。依赖分析要生成完整的依赖树或依赖图，并标注每个节点的许可证、版本、来源仓库和引入路径。以 Maven 为例，可用 mvn dependency:tree -DoutputType=text 输出依赖树；npm 可用 npm ls --all --json；Python 可用 pipdeptree --json-tree。

依赖分析的关键不是“列出清单”，而是识别三类高风险节点：传染性许可证节点（如 GPL、AGPL）、版本冲突节点（同一库多版本共存）、无许可证或自定义许可证节点。例如某服务依赖树中出现 libX 1.2 (GPL-2.0) 被 libY 3.0 (Apache-2.0) 间接引入，而项目本身以闭源方式分发，这就构成需要处置的冲突点。依赖分析还应记录“引入路径”，即从根依赖到该节点的完整链路，便于判断能否通过替换上层依赖来消除风险。

三、许可证冲突检测：把义务映射到使用方式

许可证冲突检测的本质是义务匹配：把每个组件的许可证义务，与项目的分发方式、链接方式、修改情况做比对。常见判断维度包括：是否分发、是否动态链接、是否修改源码、是否作为服务对外提供。例如 GPL-2.0 要求分发时提供对应源码并以同许可证授权；AGPL-3.0 在网络服务场景下也触发源码提供义务；Apache-2.0 与 GPL-2.0 存在专利条款兼容性争议，通常不建议直接混用。

检测时建议建立“组件—许可证—义务—使用方式—结论”的映射表。下表为示例结构，参数为合理假设，用于说明判断逻辑：

冲突检测工具（如 FOSSA、ScanCode、ORT）能自动完成部分映射，但“使用方式”往往需要人工确认。工具给出的是候选冲突，不是最终结论。

四、人工审计：处理工具判断不了的部分

人工审计重点覆盖四类场景：许可证文本缺失或模糊（如仅有 “see LICENSE” 但文件不存在）、多许可证选择（如 “MIT OR GPL-2.0”，需确认实际选择）、代码片段来源不明（扫描命中但无明确许可证）、修改后的衍生作品判断（是否构成衍生、是否触发传染）。审计时应保留证据：文件路径、行号、许可证原文、判断依据、结论和处置建议。人工审计不是全量重做，而是对工具输出的高风险项做定向复核。

五、工具链组合策略：分层过滤，逐级收敛

单一工具无法覆盖全部风险，建议按“依赖分析 → 代码扫描 → 许可证冲突检测 → 人工审计”的顺序分层执行。依赖分析先建立组件清单，代码扫描补充依赖清单之外的复制代码，冲突检测把清单映射为义务判断，人工审计处理剩余不确定项。每一层的输出作为下一层的输入，最终形成可追溯的风险台账。

组合策略的落地要点有三：第一，固定扫描与依赖分析的执行频率，建议在每次版本发布前和依赖升级后各执行一次；第二，为每条风险记录指定责任人和处置时限，避免台账只增不减；第三，把工具输出与人工结论分开存储，工具结果是候选，人工结论才是最终判断依据。只有形成“工具初筛—人工复核—台账闭环”的链路，风险识别才具备可重复性和可审计性。