license-compliance-triage

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

License Compliance Triage

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

Turn raw scanner findings into auditable engineering conclusions. The core objective is to reduce false positives without disguising insufficient evidence as compliance approval.

快速开始

Quick Start

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

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

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

This skill is suitable for developers, release owners, compliance engineers, and reviewers. Users can begin with requests such as:

“Review this THIRD-PARTY.txt under a policy that allows commercial use and does not require disclosure of this project's source code.”
“Analyze why there are so many LGPL findings, distinguishing genuine risks from multi-license false positives.”
“Generate item-by-item license evidence and remediation recommendations for these Maven coordinates.”

Preferred inputs include a dependency manifest or SBOM, full coordinates, license expressions, distribution method, whether dependencies are modified or statically linked, and organizational policies. When materials are missing, first provide preliminary triage based on explicit assumptions and list, for each item, “what is missing and how to provide it”; do not wait idly and do not default to approval.

能力边界

Capability Boundaries

擅长处理

Strong Suited For

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

License normalization and triage for dependency manifests such as Maven, Gradle, npm, and Cargo.
Identification of selectable branches in multi-license expressions and pinpointing false positives caused by coarse-grained keyword scanning.
Evidence verification, exception recording, and version-drift checks down to
```
group:name:version
```
or equivalent package coordinates.
Producing engineering gate recommendations, evidence gaps, distribution obligations, and replacement or upgrade recommendations.

需要素材

Required Inputs

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

When only license names are available, package coordinates and versions are required to reach an auditable conclusion.
Weak copyleft or Classpath Exception scenarios require the linking method, whether modifications were made, and the delivery format.
Custom, commercial, or
```
Unknown
```
licenses require the official license text or vendor terms.
Validating the actual release artifact requires an SBOM, license report, and final distribution package, not merely build files.

超出范围

Out of Scope

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

It does not replace a lawyer or an organization's legal counsel in providing legal advice; outputs should be labeled “engineering compliance triage.”
It does not approve trademark, patent, export-control, privacy, or sanctions compliance based on license names; route these matters to the appropriate specialist review.
It does not modify dependencies, CI, policy files, or release artifacts without authorization; it only produces review conclusions and recommendations.
It does not mix vulnerabilities, supply-chain provenance, or maintenance status into license conclusions; a separate security or supply-chain review may be recommended.

先确定策略语义

Establish Policy Semantics First

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

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

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

Do not begin with a fixed allowlist. First express the user's objective as observable policy questions, such as:

Is commercial use permitted?
Is closed-source distribution permitted?
Does “no source disclosure” mean that this project's source code is not disclosed, or that even modified third-party source code cannot be disclosed?
Is the dependency provided as an unmodified standalone JAR, dynamically linked, statically linked, copied as source, or modified/forked?
Are NOTICE files, license texts, copyright notices, upstream source locations, or replacement and relinking obligations accepted?

If the user's policy allows commercial use without requiring disclosure of this project's source code, do not automatically classify every line containing a copyleft term as high risk. Weak copyleft, exception clauses, and multi-license expressions must be evaluated against the selected branch and distribution method.

分诊工作流

Triage Workflow

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

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

Confirm input provenance: Identify the actual report format, generating tool, target release artifact, full coordinates, and versions. Distinguish source dependencies, runtime dependencies, test dependencies, build tools, and components that are not included in the release artifact.
Preserve original declarations: Retain the original license expressions from the report. When normalizing to SPDX, preserve the rationale for each mapping and never guess unknown names.
Parse expression semantics: Distinguish
```
OR
```
(select a compatible branch),
```
AND
```
(usually requiring simultaneous compliance), and cases where a scanner has crudely concatenated multiple declarations. Do not mark an entire expression as high risk merely because it contains one restrictive branch.
Verify by coordinate: Conclusions must be bound to full package coordinates and versions. The evidence priority is a version-pinned official POM, official LICENSE/NOTICE files, an upstream pinned tag/commit, and an authoritative license directory. Search snippets and drifting default branches may only be treated as leads.
Evaluate usage mode: Assess whether the dependency was modified, copied as source, statically linked, merged, or distributed independently and unmodified. Record any triggered requirements for license text, NOTICE, copyright notices, source-code provision, replacement, or relinking.
Assign a category and rationale: Use the five categories “Pass / Conditional Pass / Needs Evidence / Blocked / Not in Release Artifact,” rather than an ambiguous “high risk.” For every item, state the original expression, selected branch, evidence, usage mode, obligations, and decision logic.
Reverse-validate false positives: Count raw scanner hits and genuine blockers, and separately list false positives caused by aliases, parsing errors, multi-license expressions, scope differences, or stale exceptions.
Validate the gate: Use minimal tests to cover allowed, selectable, blocked, unknown, missing-version, evidence-drift, and stale-entry cases; then run the gate against the actual SBOM or license report. A successful build or HTTP 200 response is not evidence of license compliance.

Detailed decision criteria and evidence fields are available in references/decision-model.md. Read references/anti-patterns.md for common misuse cases and references/faq-deep.md for edge cases.

输出格式

Output Format

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

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

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

First present the policy basis and conclusion summary, followed by an item-by-item table:

Field	Requirement
coordinate	Full package coordinate and version
scope	runtime / build / test / optional / excluded
declared_expression	Original license expression
selected_license	Selected SPDX branch; empty if no branch can be selected
usage_mode	Unmodified / modified / source copied / statically linked, etc.
decision	Pass / Conditional Pass / Needs Evidence / Blocked / Not in Release Artifact
evidence	Pinned, official, reproducible URL or file location
obligations	NOTICE, license, source-code, or replacement obligations
rationale	Decision logic based on the policy and facts
action	Retain, obtain evidence, upgrade, replace, or remove

The conclusion must include the raw hit count, confirmed false-positive count, genuine blocker count, unresolved count, gate-validation evidence, and residual risks. Separate facts, inferences, and recommendations. When something cannot be confirmed, write “Needs Evidence”; never fabricate SPDX identifiers, license terms, or official sources.

隐私与安全

Privacy and Security

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

Dependency reports may contain private package names, repository URLs, customer names, or access tokens. Redact credentials and internal domain names before displaying them; evidence links must not contain tokens. Do not upload private SBOMs or license texts to external services unless the user has explicitly authorized it. If a secret is discovered, stop propagating it and recommend rotation.

常见问题

Frequently Asked Questions

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

Should every LGPL finding be blocked? Not necessarily. First determine whether it is an
```
OR
```
branch and review the linking method, modifications, and organizational policy.
Can all open-source licenses be used commercially? Commercial use cannot be inferred merely from the term “open source.” The license and its obligations must still be verified.
Why is an exact version required? License declarations may change between versions, and broad exceptions can drift.
Can a GitHub default branch serve as evidence? It can only serve as a lead; prefer a pinned tag or commit.
Does a passing scanner result mean the project is compliant? No. It only shows that the current rules and inputs did not produce an error.
Can unknown license names be globally allowlisted? No. Obtain official evidence for the exact coordinate or replace the dependency.