license-compliance-triage

# 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/decision-model.md)。遇到常见误用先读 [references/anti-patterns.md](references/anti-patterns.md)；边缘问题见 [references/faq-deep.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. **可以全局白名单未知名称吗？** 不可以；应按精确坐标补官方证据或替换依赖。