3. 许可证识别与代码溯源
在企业研发流程中，开源合规的第一道关口不是“能不能用”，而是“我到底用了什么”。如果连项目里混入了哪些开源组件、它们各自采用什么许可证、版权归属如何都说不清楚，后续的许可证兼容性判断、义务履行和发布审批都无从谈起。本节聚焦三件事：如何识别代码中的开源成分，如何读懂许可证声明与版权头，以及如何借助工具完成成分分析与溯源。
一、开源成分的三种存在形态
项目中的开源代码通常以三种形态出现，识别方式各不相同。
- 显式依赖：通过包管理器声明，如
package.json、pom.xml、requirements.txt、go.mod。这类成分有明确的名称和版本，最容易识别，但传递依赖会层层展开，实际引入的组件数量往往远超直接声明。 - 源码内嵌：把第三方源码文件直接复制进项目，例如把某个 JS 库的
.js文件放进vendor/或third_party/目录。这类成分不会出现在依赖清单里，只能靠文件头注释和目录约定发现。 - 代码片段复用：从 Stack Overflow、博客或开源项目中复制几行到几十行代码，往往不带任何声明。这类成分最难识别，需要靠代码指纹比对。
三种形态的识别难度依次上升，而合规风险恰恰与识别难度正相关——越难发现的成分，越容易在发布时被遗漏。
二、许可证声明与版权头怎么读
识别到开源文件后，下一步是判断它的许可证。常见声明位置有三处：项目根目录的 LICENSE、COPYING、NOTICE 文件；源文件顶部的版权头注释；以及包元数据中的 license 字段。三者可能不一致，必须以最具体的声明为准。
一个典型的源文件版权头如下：
/*
* Copyright (c) 2019-2023 Example Authors
* SPDX-License-Identifier: Apache-2.0
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
* http://www.apache.org/licenses/LICENSE-2.0
*/这里有两个关键信息：版权行说明权利人，SPDX-License-Identifier 用标准短标识符声明许可证。SPDX 标识符是识别许可证最可靠的方式，因为它避免了“Apache License 2.0”“Apache 2.0”“ASL 2.0”这类写法差异带来的歧义。常见标识符包括 MIT、Apache-2.0、BSD-3-Clause、GPL-2.0-only、GPL-3.0-or-later、LGPL-2.1-only、MPL-2.0 等。
需要特别注意的是许可证的“版本”和“only/or-later”后缀。GPL-2.0-only 表示仅限 GPL 2.0，GPL-2.0-or-later 表示 GPL 2.0 或更高版本，两者在兼容性判断上结论可能完全不同。同样，LGPL-2.1-only 与 LGPL-3.0-only 对动态链接的要求也有差异。识别阶段必须精确到后缀，不能只写“GPL”或“LGPL”。
三、用工具做成分分析与溯源
人工逐个文件检查不现实，实际工作中依赖 SCA（软件成分分析）工具。工具的核心能力有三项：扫描依赖清单和锁文件、解析源码中的许可证声明、通过代码指纹比对识别片段复用。
以常见的开源工具为例，一次典型的扫描流程如下：
# 1. 生成依赖清单（以 Node.js 为例）
npm install
npm ls --all --json > deps.json
# 2. 用扫描工具分析许可证与组件
scancode -clpieu --json-pp result.json ./src
# 3. 生成 SBOM（软件物料清单）
syft dir:. -o spdx-json > sbom.spdx.json扫描结果通常包含组件名、版本、许可证标识、匹配到的文件路径和置信度。下面是一份简化的结果示例：
| 组件 | 版本 | 许可证 | 来源文件 | 置信度 |
|---|---|---|---|---|
| lodash | 4.17.21 | MIT | package-lock.json | 高 |
| commons-lang3 | 3.12.0 | Apache-2.0 | pom.xml | 高 |
| 某内嵌工具函数 | 未知 | GPL-2.0-only | src/utils/legacy.js | 中 |
第三行就是典型的“源码内嵌”风险：它不在依赖清单里，但被指纹比对识别出与某 GPL 项目高度相似。置信度为“中”意味着需要人工复核，不能直接采信，也不能直接忽略。
四、溯源与人工复核
工具给出的是线索，不是结论。对低置信度或高风险条目，需要做溯源复核，判断依据包括：
- 文件路径与目录约定：
vendor/、third_party/、external/下的文件通常来自外部。 - 版权头与作者信息：版权人是否为本公司，年份是否与项目历史一致。
- 代码风格差异：命名习惯、缩进、注释语言与主项目不一致，往往是复制痕迹。
- 提交历史：用
git log --follow查看文件引入时间和提交者，判断是否为外部引入。 - 上游比对：将可疑片段与候选开源项目做逐行比对，确认来源和版本。
复核完成后，应把结论回写到 SBOM 中，标注“已确认”“已替换”“待处理”等状态，形成可追溯的记录。这样在后续发布审批时，每一行开源成分都有据可查。
五、识别阶段的最小交付物
完成一轮识别与溯源后，建议至少交付一份可追溯的组件清单，字段包括：组件名称、版本、许可证 SPDX 标识、引入方式（直接依赖/传递依赖/内嵌/片段）、来源文件路径、置信度、复核状态、处理结论。这份清单是后续许可证兼容性分析和发布审批的输入，也是审计时最直接的证据。