开源许可证合规扫描知识库
文档说明
本知识库面向开源社区三维基础几何引擎的开源许可证合规扫描场景，整理了许可证分类模型、SPDX 标识符、许可证兼容性（compatibility）方向性规则、组合场景（链接/衍生/聚合/网络服务）、合规义务，以及对应的违规知识条目。本平台的许可证合规扫描统一采用 清源 SCA（CleanSource SCA） 工具执行。
适用动机：几何引擎通常依赖大量第三方库（如几何/数学/网格库），其中 CAD 内核类组件常见弱 copyleft（如 LGPL）许可。若本项目期望以宽松或弱 copyleft 形式开放，必须通过扫描防止 GPL/AGPL 传染、缺失署名、不兼容组合等问题。
检测器边界：清源 SCA 能识别组件与许可证、构建依赖图、输出 SBOM、对许可证风险与冲突给出建议，并据合规策略在 CI 做门禁，降低人工成本并留存可审计证据（SBOM）。
规则结构概览
| 模块 | 规则范围 | 主检测器 | 条目数 | 说明 |
|---|---|---|---|---|
| 声明完整性 | LIC-1.x | 清源 SCA | 3 | 文件级许可证/版权声明、LICENSE 文件、未知许可证 |
| 兼容性 | LIC-2.x | 清源 SCA | 4 | copyleft 传染、单向兼容、版本冲突、网络 copyleft |
| 义务履行 | LIC-3.x | 清源 SCA | 3 | 署名/通知保留、NOTICE、源码披露 |
| 治理与供应链 | LIC-4.x | 清源 SCA | 2 | SBOM 缺失、依赖未登记/拒绝清单 |
| 合计 | LIC-* | 清源 SCA | 12 | 合规检测规则与知识条目统一来源 |
目录
- 1 许可证分类模型
- 2 SPDX 标识符与表达式
- 3 兼容性方向性规则（核心）
- 4 组合场景与"衍生作品"判断
- 5 合规义务速查
- 6 清源 SCA 扫描与 SBOM
- 7 标准知识条目列表
1 许可证分类模型
| 类别 | 强度 | 代表许可证（SPDX id） | 核心特征 |
|---|---|---|---|
| 公共领域/极宽松 | 无 | 0BSD、Unlicense、CC0-1.0 | 几乎无义务 |
| 宽松（permissive） | 弱 | MIT、BSD-2-Clause、BSD-3-Clause、Apache-2.0、MulanPSL-2.0、ISC、Zlib、BSL-1.0 | 仅需保留署名/许可证文本；可闭源再分发 |
| 弱 copyleft（file/library 级） | 中 | LGPL-2.1-only、LGPL-3.0-only、MPL-2.0、EPL-2.0、CDDL-1.0 | 仅"被修改文件/库本身"需开源，可与闭源链接 |
| 强 copyleft（项目级） | 强 | GPL-2.0-only、GPL-2.0-or-later、GPL-3.0-only、GPL-3.0-or-later | 整个"衍生/组合作品"须以同等许可证开源 |
| 网络 copyleft | 最强 | AGPL-3.0-only、AGPL-3.0-or-later | 经网络提供服务也触发源码披露义务 |
| 专有/不兼容 | — | 商业 EULA、CC-BY-NC-*（非商用）、无声明 | 通常禁止再分发或与开源混用 |
关键直觉：许可证越靠下（copyleft 越强），对"组合后整体"的约束越强；宽松许可证可以"流入"copyleft 项目，反之不行——这就是"单向兼容"。
2 SPDX 标识符与表达式
- 标准词汇：用 SPDX License List 的标准 id（如
Apache-2.0、GPL-3.0-or-later）统一表述，避免"BSD""GPL"等歧义说法。清源 SCA 的识别结果即以 SPDX id 输出。 - 版本后缀：
-only（仅此版本）与-or-later（及后续版本）语义差异巨大，直接影响兼容性（见 LIC-2.3）。 - 许可证表达式：
AND：须同时满足（如(MIT AND BSD-3-Clause)）；OR：可任选其一（双重许可，如(GPL-2.0-or-later OR MIT)）；WITH：附加例外（如GPL-2.0-only WITH Classpath-exception-2.0、LGPL-2.1-only WITH <library-exception>）。
- 文件级声明：源文件头写
SPDX-License-Identifier:与版权信息（SPDX-FileCopyrightText:），使清源 SCA 可在文件粒度确定许可证。
3 兼容性方向性规则（核心）
兼容性是有向的：「A → B」表示 A 许可证的代码可被并入 B 许可证的作品，组合结果取 B（可能附带 A 的义务）。下图箭头方向即"可流入"方向（上游 → 下游）——宽松许可证可流入 copyleft，反之不行。
代表性兼容性结论（务必结合 -only/-or-later）：
| 上游 A | 下游 B | 兼容？ | 说明 |
|---|---|---|---|
MIT/BSD-3-Clause | GPL-2.0-only 或 GPL-3.0 | ✅ | 宽松可并入任意 GPL |
Apache-2.0 | GPL-3.0-* | ✅ | FSF 认定与 GPLv3 兼容 |
Apache-2.0 | GPL-2.0-only | ❌ | 专利终止/赔偿条款被 GPLv2 视为附加限制 |
GPL-2.0-only | GPL-3.0-* | ❌ | 版本互斥 |
GPL-2.0-or-later | GPL-3.0-* | ✅ | "or later" 允许升级到 v3 |
LGPL-2.1/LGPL-3.0 | 同/更高版本 GPL | ✅ | LGPL 可升级为 GPL |
MPL-2.0 | GPL-2.0+/LGPL-2.1+/AGPL-3.0+ | ✅（间接） | MPL-2.0 §3.3 提供与 GPL 系列的间接兼容（除非标注"Incompatible With Secondary Licenses"） |
GPL-3.0-* | Apache-2.0 项目 | ❌ | copyleft 不能并入宽松项目并保持宽松 |
CC-BY-NC-*（非商用） | 任意开源 | ❌ | 非商用限制与 OSI 开源定义冲突 |
兼容性矩阵
行＝组件（上游）许可证 A，列＝最终作品（目标）许可证 B；单元格表示"能否将 A 许可证的代码并入以 B 为许可证的作品"。✅ 可并入；⚠️ 有条件 / 需评审；❌ 不可（须改组合方式或替换依赖）。
| A（上游）＼ B（目标） | MIT | Apache-2.0 | MPL-2.0 | LGPL-3.0 | GPL-3.0 | AGPL-3.0 |
|---|---|---|---|---|---|---|
MIT / BSD-3-Clause | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
Apache-2.0 | ❌ | ✅ | ✅ | ✅ | ✅ | ✅ |
MPL-2.0 | ❌ | ❌ | ✅ | ✅ | ✅ | ✅ |
LGPL-3.0 | ❌ | ❌ | ❌ | ✅ | ✅ | ✅ |
GPL-2.0-only | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ |
GPL-3.0 | ❌ | ❌ | ❌ | ❌ | ✅ | ✅ |
AGPL-3.0 | ❌ | ❌ | ❌ | ❌ | ❌ | ✅ |
说明：
MulanPSL-2.0为宽松许可证，作为目标可比照MIT/Apache-2.0处理；其与 GPL 系列的兼容性官方未明确，建议个案评审。矩阵为通用单向兼容判断；静态/动态链接、是否标注 Secondary Licenses 等边界以 §4 组合场景与扫描策略为准。
本项目策略落点：本项目目标许可证暂定为
Apache-2.0/MIT/MulanPSL-2.0（三者均为宽松许可证；MulanPSL-2.0即木兰宽松软件许可证第 2 版，信创场景常用）。据此，清源 SCA 的合规策略应配置为：
- 允许：宽松许可证（
MIT、BSD-2-Clause、BSD-3-Clause、Apache-2.0、MulanPSL-2.0、ISC、Zlib等）；- 拒绝：强 copyleft 与网络 copyleft（
GPL-*、AGPL-*）——会强制整体开源，与宽松目标冲突；- 弱化/个案评审：弱 copyleft（
LGPL-*、MPL-2.0）——动态链接通常可用，静态链接/源码改写需谨慎并经评审。注意：即便目标取
Apache-2.0，仍需避免与GPL-2.0-only组件组合（专利条款不兼容，见 LIC-2.2）。该策略应写入清源 SCA 做自动门禁。
4 组合场景与"衍生作品"判断
copyleft 的触发取决于"组合方式"是否构成衍生/组合作品：
| 组合方式 | 典型判断（GPL 视角） | 影响 |
|---|---|---|
| 静态链接 | 通常构成组合作品 | 触发 copyleft（GPL 整体传染） |
| 动态链接 | 多数解释下仍构成组合作品（FSF 立场）；LGPL 为此专设链接例外 | GPL 谨慎、LGPL 允许闭源链接 |
| 源码合并/改写 | 衍生作品 | 触发 copyleft |
| 进程隔离/独立可执行 + 标准接口（管道/socket/CLI） | 一般视为"聚合"（mere aggregation） | 各自保留许可证，不传染 |
| 仅同盘分发（aggregation） | 聚合 | 不传染 |
| 经网络提供服务（SaaS） | GPL 不触发分发；AGPL 触发披露义务 | AGPL 需向使用者提供对应源码 |
几何引擎常见情形：以动态库形式集成 LGPL 内核可保持自身闭源/宽松，但须满足 LGPL 的可替换性义务（允许用户替换该库）。
5 合规义务速查
| 义务 | 适用许可证（示例） | 检测点 |
|---|---|---|
| 保留版权与许可证文 本 | 几乎所有 | 分发物中是否含原始 LICENSE/版权头 |
| 保留 NOTICE / 声明变更 | Apache-2.0 | 是否随附 NOTICE、是否标注修改 |
| 不可附加额外限制 | GPL-* | 是否叠加了更严限制 |
| 提供对应源码 | GPL-*/LGPL-*/AGPL-* | 分发/服务时是否提供 source offer |
| 允许库替换（链接例外） | LGPL-* | 动态链接 + 提供重链接能力 |
| 专利授权与终止 | Apache-2.0/GPL-3.0 | 是否理解专利条款影响 |
| 商标/背书限制 | BSD-3-Clause/Apache-2.0 | 是否用原作者名做背书 |
6 清源 SCA 扫描与 SBOM
本平台采用 清源 SCA（CleanSource SCA） 作为唯一的许可证合规与软件成分分析工具。
核心能力：
- 多粒度识别：代码片段识别、文件识别、组件识别、依赖识别、容器镜像扫描，定位项目中所有开源成分；
- SBOM 输出：生成完整、准确的软件物料清单（SBOM），纳入发布物与审计；
- 风险与冲突建议：对安全漏洞、许可证风险与许可证冲突给出提示与修复建议；
- 部署方式：在线版（SaaS）或本地版（On-Prem，部署于内网服务器），满足内网/涉密场景。
与本知识库的集成方式：
| 环节 | 做法 |
|---|---|
| 扫描触发 | 在 CI 流水线中调用清源 SCA，对源码 + 依赖进行成分与许可证扫描 |
| 策略门禁 | 在清源 SCA 中配置许可证策略（允许/弱化/拒绝清单 + §3 兼容性规则），命中拒绝项即阻断流水线 |
| 结果留存 | 以 SBOM 形式留存可审计证据，纳入发布物 |
| 条目映射 | 扫描报告中的 组件 / 检测许可证(SPDX) / 声明许可证 / 依赖层级 / 风险或冲突项 映射到本文 LIC-x.y 条目编号，实现"扫描结论 → 知识条目"跳转 |
- 唯一事实来源：项目根维护清源 SCA 的许可证策略配置（允许/弱化/拒绝清单 + 兼容性规则）；扫描结论以 SBOM 形式留存。
- 日志特征统一格式：清源 SCA 报告通常含
组件名、detected_license(SPDX)、declared_license、scope(依赖层级)、policy/conflict(规则项)，可直接映射本文条目编号。
7 标准知识条目列表
7.1 条目字段说明
每条规则采用统一字段：规则编号、规则名称、类别、检测器、漏洞描述、产生原因、影响范围、典型输入、日志特征、修复 建议、相关案例、关联规则。规则编号采用本库自定义的 LIC-x.y 合规检查号，并在条目内标注关联的 SPDX 标识符，便于清源 SCA 扫描报告的风险/冲突项直接映射。
7.2 条目明细
声明完整性类
LIC-1.1 - 文件缺少许可证/版权声明
- 规则编号：LIC-1.1
- 规则名称：文件缺少许可证/版权声明
- 类别：声明完整性
- 检测器：清源 SCA（文件级许可证/版权识别）
- 漏洞描述：源文件缺少
SPDX-License-Identifier与版权声明，导致下游无法确定该文件许可证，复用时引入法律不确定性。 - 影响范围：仓库内所有源文件、脚本、资源。
- 日志特征：清源 SCA 报告该文件"缺少许可证/版权信息"，列出文件清单。
- 产生原因
- 新增文件未套用许可证头模板
- 从外部复制代码片段未保留声明
- 典型输入
// mesh_builder.cc —— 文件头无任何许可证/版权信息
#include "geom/mesh.h" - 修复建议
- 在文件头加入：
// SPDX-FileCopyrightText: 2026 Open3DGMBE Community
// SPDX-License-Identifier: Apache-2.0 - 仓库提供许可证头模板并在 CI 接入清源 SCA 扫描
- 在文件头加入：
- 相关案例
- 案例编号：LIC-1.1-01
- 违规场景：贡献者新增工具类未加许可证头，发布前审计阻断。
- 修复结果：补齐 SPDX 头，清源 SCA 扫描通过。
- 关联规则：LIC-1.2、LIC-3.1
LIC-1.2 - 仓库缺少 LICENSE 文件或与声明不一致
- 规则编号：LIC-1.2
- 规则名称：缺少/不一致的项目级 LICENSE
- 类别：声明完整性
- 检测器：清源 SCA / 人工审查
- 漏洞描述：仓库根缺少
LICENSE/LICENSES/目录，或项目声明的许可证与文件头 SPDX 不一致，造成"项目许可证"不可确定。 - 影响范围：整个仓库与发布物。
- 日志特征：扫描报告
declared_license为空或与detected_license冲突。 - 产生原因
- 仅在 README 口头声明、未放许可证全文
- 迁移后未同步许可证
- 典型输入
仓库根无 LICENSE；README 写 "Apache"，文件头却是 GPL-3.0 - 修复建议
- 在
LICENSES/Apache-2.0.txt放全文；统一 README、文件头、SBOM 三处一致
- 在
- 相关案例
- 案例编号：LIC-1.2-01
- 违规场景：项目声称 Apache，但混入 GPL 头文件，外部集成方质疑。
- 修复结果：清理 GPL 代码或改项目许可证，三处对齐。
- 关联规则：LIC-1.1、LIC-2.1
LIC-1.3 - 未知/自定义/不可识别许可证
- 规则编号：LIC-1.3
- 规则名称：未知或自定义许可证
- 类别：声明完整性
- 检测器：清源 SCA（未知/低置信度许可证识别）
- 漏洞描述：依赖使用非 SPDX 标准、定制或扫描器无法匹配的许可证文本，无法自动判断义务与兼容性，属高风险项。
- 影响范围：第三方依赖。
- 日志特征：扫描报告
detected_license: unknown或低匹配置信度。 - 产生原因
- 上游用了魔改许可证或私有条款
- 典型输入
third_party/foo: LICENSE 为自定义条款，含 "non-commercial" 字样 - 修复建议
- 人工研判条款；若含非商用/不可分发限制则替换该依赖
- 相关案例
- 案例编号：LIC-1.3-01
- 违规场景：网格库使用自定义"学术使用"条款，禁止商用集成。
- 修复结果：替换为
MIT等价库。
- 关联规则：LIC-2.1、LIC-4.2
兼容性类
LIC-2.1 - 强 copyleft 传染（GPL/AGPL 进入宽松项目）
- 规则编号：LIC-2.1
- 规则名称：强 copyleft 许可证传染
- 类别：兼容性
- 检测器：清源 SCA（许可证策略·拒绝清单）
- 漏洞描述：在以宽松/弱 copyleft（如
Apache-2.0/LGPL-2.1）发布的项目中，以静态链接/源码合并方式引入GPL-*/AGPL-*依赖，会强制整个组合作品以 GPL/AGPL 开源，与项目许可策略冲突。 - 影响范围：链接/合并了 copyleft 组件的整个分发物。
- 日志特征：清源 SCA 报告
策略违规：组件 X 为 GPL-3.0-only（命中拒绝清单），并标注依赖路径。 - 产生原因
- 引入依赖时未核查许可证
- 传递依赖（依赖的依赖）携带 GPL
- 典型输入
本项目 Apache-2.0
└─ 依赖 libsolver (GPL-3.0-only) ← 触发传染 - 修复建议
- 替换为宽松/弱 copyleft 等价库；或进程隔离调用（聚合，见 §4）；或经法务评估整体改用 GPL
- 相关案例
- 案例编号：LIC-2.1-01
- 违规场景：约束求解器引入 GPL 库静态链接，发布受阻。
- 修复结果：改用 MPL-2.0 等价实现。
- 关联规则：LIC-2.4、LIC-3.3、LIC-4.2
LIC-2.2 - 单向不兼容组合（Apache-2.0 与 GPL-2.0-only）
- 规则编号：LIC-2.2
- 规则名称：单向/互斥不兼容组合
- 类别：兼容性
- 检测器：清源 SCA（兼容性策略）
- 漏洞描述：组合中同时存在
Apache-2.0与GPL-2.0-only组件——前者的专利条款被 GPLv2 视为附加限制，二者不可合并；类似地GPL-2.0-only与GPL-3.0互斥。 - 影响范围：含互斥许可证组件的组合作品。
- 日志特征：清源 SCA 报告
依赖树中存在不兼容许可证：Apache-2.0 vs GPL-2.0-only。 - 产生原因
- 未区分
-only/-or-later - 同时引入两类不可调和的依赖
- 未区分
- 典型输入
A: Apache-2.0
B: GPL-2.0-only ← 与 A 不兼容 - 修复建议
- 寻找
GPL-2.0-or-later版本（可升级到 v3，与 Apache 兼容）；或替换其一
- 寻找
- 相关案例
- 案例编号：LIC-2.2-01
- 违规场景：同时依赖 Apache 库与仅 GPLv2 库，法务判定不可分发。
- 修复结果：将 GPLv2-only 依赖换为 or-later 版本。
- 关联规则：LIC-2.3、LIC-2.1
LIC-2.3 - 许可证版本后缀冲突（-only vs -or-later）
- 规则编号：LIC-2.3
- 规则名称：版本后缀导致的兼容性误判
- 类别：兼容性
- 检测器：清源 SCA（版本识别）
- 漏洞描述：将
GPL-2.0-only误当作可升级，或把-or-later误标为-only，导致兼容性结论错误（如错误放行/错误阻断）。 - 影响范围：所有 GPL/LGPL/AGPL 系列依赖。
- 日志特征：声明许可证与检测许可证的版本后缀不一致告警。
- 产生原因
- 上游声明含糊（仅写 "GPLv2"）
- SBOM 录入时丢失后缀
- 典型输入
声明: "GPL v2" → 应澄清为 GPL-2.0-only 还是 GPL-2.0-or-later - 修复建议
- 向上游确认；在 SBOM 中固定带后缀的 SPDX id
- 相关案例
- 案例编号：LIC-2.3-01
- 违规场景：误判 only 为 or-later 而放行与 Apache 组合。
- 修复结果：澄清为 only 后判定不兼容并替换。
- 关联规则：LIC-2.2、LIC-4.1
LIC-2.4 - 网络 copyleft（AGPL）触发源码披露
- 规则编号：LIC-2.4
- 规则名称：AGPL 网络服务披露义务
- 类别：兼容性
- 检测器：清源 SCA（许可证策略）
- 漏洞描述：引入
AGPL-3.0-*组件后，即便不分发二进制、仅以网络服务（如云端几何计算 API）提供，也须向使用者提供对应源码，否则违规。 - 影响范围：以 SaaS/在线服务形式部署的组合作品。
- 日志特征：清源 SCA 报告
策略违规：AGPL-3.0-only（网络 copyleft）。 - 产生原因
- 误以为"不分发就无义务"
- 典型输入
在线网格修复服务后端依赖 AGPL-3.0 库 - 修复建议
- 替换 AGPL 依赖；或公开服务端对应源码；经法务评估
- 相关案例
- 案例编号：LIC-2.4-01
- 违规场景：云服务后端引入 AGPL 库但未披露源码。
- 修复结果：替换为 Apache-2.0 等价库。
- 关联规则：LIC-2.1、LIC-3.3
义务履行类
LIC-3.1 - 分发物缺失署名/许可证文本保留
- 规则编号：LIC-3.1
- 规则名称：缺失署名与许可证文本
- 类别：义务履行
- 检测器：清源 SCA（署名/attribution 报告）
- 漏洞描述：分发物（二进制包/源码包）未保留所依赖宽松组件（MIT/BSD/Apache 等）要求的版权声明与许可证全文，违反最基本的署名义务。
- 影响范围：所有对外发布物。
- 日志特征：署名报告中某组件"许可证文本/版权声明缺失"。
- 产生原因
- 打包时剥离了第三方 LICENSE
- 典型输入
release.tar.gz 中无 third_party/*/LICENSE - 修复建议
- 由清源 SCA 自动汇总生成
THIRD_PARTY_NOTICES/署名文件，随包附带
- 由清源 SCA 自动汇总生成
- 相关案例
- 案例编号：LIC-3.1-01
- 违规场景：发布包遗漏 BSD 组件版权声明。
- 修复结果：构建流程自动汇总署名清单。
- 关联规则：LIC-3.2、LIC-1.1
LIC-3.2 - Apache-2.0 NOTICE 缺失或未标注修改
- 规则编号：LIC-3.2
- 规则名称：NOTICE 缺失/未声明变更
- 类别：义务履行
- 检测器：清源 SCA / 人工审查
- 漏洞描述：使用
Apache-2.0组件时未随附其NOTICE文件，或修改了源码却未按要求标注"已修改"，违反 Apache-2.0 第 4 条义务。 - 影响范围：含 Apache-2.0 依赖的发布物。
- 日志特征：扫描报告"Apache NOTICE 未随发布物传递"。
- 产生原因
- 不了解 NOTICE 传递义务
- 典型输入
依赖 Apache-2.0 库，发布物缺其 NOTICE；改了源码未加 "Modified by ..." - 修复建议
- 传递 NOTICE 内容；在改动文件标注修改与日期
- 相关案例
- 案例编号：LIC-3.2-01
- 违规场景：fork 了 Apache 组件并修改，未标注。
- 修复结果：补 NOTICE 与修改声明。
- 关联规则：LIC-3.1
LIC-3.3 - copyleft 源码披露义务未履行
- 规则编号：LIC-3.3
- 规则名称：copyleft 源码披露缺失
- 类别：义务履行
- 检测器：清源 SCA（许可证义务） / 发布前人工检查
- 漏洞描述：分发了包含
GPL-*/LGPL-*组件（或其衍生）的作品，却未向接收方提供对应完整源码或有效的书面 source offer。 - 影响范围：含 copyleft 组件的发布物。
- 日志特征：合规清单中该组件标注"源码披露：未提供"。
- 产生原因
- 仅分发二进制，未配套源码
- 典型输入
发布含 LGPL 内核的二进制，未提供该库可替换/可重链接的途径与源码 - 修复建议
- 提供对应源码或 written offer；LGPL 动态链接还需保证可替换性
- 相关案例
- 案例编号：LIC-3.3-01
- 违规场景：嵌入式发布含 LGPL 库但静态链接且未提供重链接能力。
- 修复结果：改动态链接并提供源码与目标文件。
- 关联规则：LIC-2.1、LIC-2.4
治理与供应链类
LIC-4.1 - 缺失/过期 SBOM
- 规则编号：LIC-4.1
- 规则名称：缺失或过期的 SBOM
- 类别：治理与供应链
- 检测器：清源 SCA（SBOM 生成）+ CI 校验
- 漏 洞描述：发布物未附软件物料清单（SBOM），或 SBOM 与实际依赖不一致，导致许可证与漏洞无法审计、无法回溯。
- 影响范围：发布治理、供应链安全。
- 日志特征：CI 报
SBOM 缺失或SBOM 与实际依赖不一致（drift）。 - 产生原因
- 未将 SBOM 生成纳入构建
- 依赖更新后未刷新 SBOM
- 典型输入
release v2.1.0 无清源 SCA 生成的 SBOM 文件 - 修复建议
- 构建阶段由清源 SCA 自动生成 SBOM 并随包发布；CI 校验其与依赖一致
- 相关案例
- 案例编号：LIC-4.1-01
- 违规场景：依赖升级后 SBOM 未更新，审计失败。
- 修复结果：SBOM 生成纳入流水线。
- 关联规 则：LIC-2.3、LIC-4.2
LIC-4.2 - 依赖未登记/命中拒绝清单
- 规则编号：LIC-4.2
- 规则名称：未登记依赖或命中拒绝清单
- 类别：治理与供应链
- 检测器：清源 SCA（依赖解析 + 策略门禁）
- 漏洞描述：引入未经审批登记的第三方依赖，或依赖（含传递依赖）命中项目"拒绝许可证清单"，绕过了合规门禁。
- 影响范围：整个依赖树。
- 日志特征：清源 SCA 报告
组件不在允许清单或许可证命中拒绝清单，并给出依赖路径。 - 产生原因
- 直接加依赖未走审批
- 传递依赖未审查
- 典型输入
新增 dep 'X'，其传递依赖 'Y' 为 AGPL-3.0（拒绝清单） - 修复建议
- 建立允许/弱化/拒绝三级清单并由清源 SCA 在 CI 强制；新依赖须审批 + 更新 SBOM
- 相关案例
- 案例编号：LIC-4.2-01
- 违规场景：传递依赖引入拒绝清单许可证，PR 被门禁拦截。
- 修复结果：替换传递依赖或加例外审批记录。
- 关联规则：LIC-2.1、LIC-1.3、LIC-4.1
版本与时效说明：许可证分类、SPDX 标识符与兼容性结论依据 SPDX License List、GNU 许可证兼容性说明、Apache 基金会 GPL 兼容性声明等整理。许可证生态与 SPDX 列表会更新，兼容性判定务必结合
-only/-or-later后缀与具体组合方式。