---

name: license-compliance-triage license: Apache-2.0 description: Review dependency-license reports, reduce false positives, and produce evidence-backed compliance triage when commercial use, source-disclosure obligations, multi-license expressions, or exact-coordinate exceptions must be assessed. Use for engineering compliance review; do not present the result as legal advice.

License Compliance Triage

把扫描器的原始命中转化为可审计的工程结论。核心目标是减少误报，同时不把证据不足伪装成合规通过。

快速开始

适用于开发者、发布负责人、合规工程师和审查人员。用户可以这样开始：

• “按可商用且不要求公开本项目源码的标准，审查这份 THIRD-PARTY.txt。”
• “分析为什么 LGPL 命中很多，区分真实风险和多许可证误报。”
• “为这些 Maven 坐标生成逐项许可证证据与处置建议。”

优先接受：依赖清单或 SBOM、完整坐标、许可证表达式、发布方式、是否修改/静态合并依赖、组织策略。缺少材料时，先基于明确假设给出临时分诊，并逐项列出“缺少什么、如何补充”；不要空等，也不要默认为通过。

能力边界

擅长处理

• Maven、Gradle、npm、Cargo 等依赖清单的许可证归一化与分诊。
• 多许可证表达式的可选分支识别，以及粗粒度关键字扫描的误报定位。
• 精确到 group:name:version 或等价包坐标的证据核验、例外记录与版本漂移检查。
• 输出工程门禁建议、证据缺口、分发义务和替换/升级建议。

需要素材

• 只有许可证名称时，需要包坐标和版本才能形成可审计结论。
• 弱 copyleft 或 Classpath Exception 场景，需要说明链接方式、是否修改以及交付形态。
• 自定义、商业或 Unknown 许可证，需要官方许可证正文或供应商条款。
• 要验证真实发布物时，需要 SBOM、许可证报告和最终分发包，而不只是构建文件。

超出范围

• 不替代律师或组织法务作法律意见；输出应标注“工程合规分诊”。
• 不凭许可证名称批准商标、专利、出口管制、隐私或制裁合规；将其路由到对应专项审查。
• 不在未经授权时修改依赖、CI、策略文件或发布物；只生成审查结论与建议。
• 不把漏洞、供应链来源或维护状态混入许可证结论；可单独建议安全或供应链审查。

先确定策略语义

不要从固定白名单开始。先把用户目标写成可观察的政策问题，例如：

• 是否允许商业使用？
• 是否允许闭源分发？
• “不公开源码”指不公开本项目源码，还是连第三方修改源码也不能公开？
• 依赖是原样独立 JAR/动态链接、静态链接、复制源码，还是已修改/fork？
• 是否接受 NOTICE、许可证文本、版权、上游源码地址、替换或重新链接义务？

若用户采用“可商用且无需公开本项目源码”，不要把任何出现 copyleft 词样的整行直接判为高风险。弱 copyleft、例外条款和多许可证必须结合选定分支与分发方式判断。

分诊工作流

1. 确认输入真实性：识别实际报告格式、生成工具、目标发布物、完整坐标和版本。区分源码依赖、运行时依赖、测试依赖、构建工具与未进入发布物的组件。
2. 保留原始声明：保存报告中的原许可证表达式；归一化为 SPDX 时保留映射理由，未知名称不得强猜。
3. 解析表达式语义：区分 OR（可选择兼容分支）、AND（通常同时履行）以及扫描器把多个声明粗暴拼接的情况。不得因为表达式中出现一个受限分支就整体标红。
4. 按坐标核验：结论必须绑定完整包坐标和版本。证据优先级为固定版本官方 POM、官方 LICENSE/NOTICE、上游固定 tag/commit、权威许可证目录；搜索摘要和漂移的默认分支只能作为线索。
5. 结合使用方式判定：评估是否修改、复制源码、静态合并或原样独立分发，并记录触发的许可证文本、NOTICE、版权、源码提供、替换/重新链接等义务。
6. 给出分类和理由：使用“通过 / 有条件通过 / 需补证据 / 阻断 / 不在发布物”五类，不用含糊的“高危”。每项都写出原始表达式、选定分支、证据、使用方式、义务和决定逻辑。
7. 反向验证误报：统计扫描原始命中数与真实阻断数，单列由别名、解析错误、多许可证、作用域或陈旧例外造成的误报。
8. 验证门禁：用最小测试覆盖允许、选择、阻断、未知、缺版本、证据漂移和陈旧条目；再对真实 SBOM/许可证报告运行门禁。编译成功或 HTTP 200 不是许可证通过证据。

详细判定与证据字段见 references/decision-model.md。遇到常见误用先读 references/anti-patterns.md；边缘问题见 references/faq-deep.md。

输出格式

先给政策口径和结论摘要，再给逐项表格：

字段	要求
coordinate	完整包坐标与版本
scope	runtime / build / test / optional / excluded
declared_expression	原始许可证表达式
selected_license	选定 SPDX 分支；无法选择则为空
usage_mode	原样/修改/复制源码/静态合并等
decision	通过/有条件通过/需补证据/阻断/不在发布物
evidence	固定、官方、可复核的 URL 或文件位置
obligations	NOTICE、许可证、源码或替换义务
rationale	结合政策与事实的决定逻辑
action	保留、补证、升级、替换或移除

结尾必须包括：原始命中数、确认误报数、真实阻断数、未决数、门禁验证证据、剩余风险。事实、推断和建议要分开；无法确认时写“需补证据”，禁止编造 SPDX、许可证条款或官方来源。

隐私与安全

依赖报告可能包含私有包名、仓库 URL、客户名称或访问令牌。展示前应脱敏凭据和内部域名；证据链接不得携带 token。不要上传私有 SBOM 或许可证正文到外部服务，除非用户明确授权。发现密钥时停止传播并提醒轮换。

常见问题

1. 看到 LGPL 就阻断吗？ 不一定；先看是否为 OR 分支、链接与修改方式以及组织政策。
2. 开源许可证都能商用吗？ 不能据“开源”二字判断，仍需核验许可证和义务。
3. 为什么必须精确版本？ 许可证声明会随版本变化，宽泛例外会漂移。
4. GitHub 默认分支能作证据吗？ 只能作线索；优先固定 tag 或 commit。
5. 扫描器通过是否等于合规？ 不等于；它只证明当前规则和输入没有报错。
6. 可以全局白名单未知名称吗？ 不可以；应按精确坐标补官方证据或替换依赖。