license-compliance-triage

License Compliance Triage

Turn raw scanner hits into auditable engineering conclusions. The core objective is to reduce false positives while not disguising insufficient evidence as compliance pass.

Quick Start

Suitable for developers, release owners, compliance engineers, and reviewers. Users can start like this:

• "Review this THIRD-PARTY.txt against the standard of being commercially usable and not requiring disclosure of this project's source code."
• "Analyze why there are so many LGPL hits, and distinguish genuine risk from multi-license false positives."
• "Generate item-by-item license evidence and disposition recommendations for these Maven coordinates."

Preferentially accept: dependency manifests or SBOMs, complete coordinates, license expressions, distribution method, whether dependencies are modified/statically combined, and organizational policy. When materials are missing, first provide provisional triage based on explicit assumptions, and list item by item "what is missing, how to supplement it"; do not wait idly, and do not default to pass.

Capability Boundaries

Good At Handling

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

Materials Needed

• When only the license name is available, package coordinates and version are needed to form an auditable conclusion.
• For weak copyleft or Classpath Exception scenarios, the linking method, whether modifications were made, and the delivery form need to be explained.
• For custom, commercial, or Unknown licenses, the official license text or vendor terms are needed.
• To verify the actual released artifacts, an SBOM, license report, and final distribution package are needed, not just build files.

Out of Scope

• Does not replace legal advice from a lawyer or organizational legal department; output should be labeled "engineering compliance triage."
• Does not approve trademark, patent, export control, privacy, or sanctions compliance based on license names; route these to the corresponding specialized review.
• Does not modify dependencies, CI, policy files, or release artifacts without authorization; only generates review conclusions and recommendations.
• Does not mix vulnerabilities, supply chain provenance, or maintenance status into license conclusions; security or supply chain review may be recommended separately.

First Determine Policy Semantics

Do not start from a fixed allowlist. First write the user's objectives as observable policy questions, for example:

• Is commercial use allowed?
• Is closed-source distribution allowed?
• Does "not disclosing source code" mean not disclosing this project's source code, or does it also mean even third-party modified source code cannot be disclosed?
• Are dependencies used as-is in separate JARs/dynamic linking, statically linked, copied source, or modified/forked?
• Are NOTICE, license text, copyright, upstream source address, replacement, or relinking obligations acceptable?

If the user adopts "commercially usable and no need to disclose this project's source code," do not directly judge any entire line containing copyleft-like wording as high risk. Weak copyleft, exception clauses, and multi-licensing must be judged in combination with the selected branch and distribution method.

Triage Workflow

1. Confirm Input Authenticity: Identify the actual report format, generation tool, target deliverable, complete coordinates and versions. Distinguish source dependencies, runtime dependencies, test dependencies, build tools, and components that do not enter the deliverable.
2. Preserve the original declaration: Save the original license expression in the report; when normalizing to SPDX, preserve the mapping rationale, and do not guess unknown names.
3. Parse expression semantics: Distinguish OR(may choose a compatible branch),AND(usually fulfilled simultaneously), and cases where scanners crudely concatenate multiple declarations. Do not mark the whole thing red just because one restricted branch appears in the expression.
4. Verify by coordinates: Conclusions must be bound to complete package coordinates and versions. Evidence priority is pinned-version official POM, official LICENSE/NOTICE, upstream fixed tag/commit, authoritative license directories; search summaries and drifting default branches can only serve as leads.
5. Determine in light of usage mode: Assess whether it is modified, source code copied, statically merged, or independently distributed as-is, and record the triggered obligations such as license text, NOTICE, copyright, source provision, replacement/relinking, etc.
6. Give classification and rationale: Use the five categories “pass / conditional pass / more evidence needed / block / not in deliverable”, not vague “high risk”. For each item, write the original expression, selected branch, evidence, usage mode, obligations, and decision logic.
7. Reverse-verify false positives: Count the scanner’s raw hit count and the true blocking count, and separately list false positives caused by aliases, parsing errors, multiple licenses, scopes, or stale exceptions.
8. Verify the gate: Use minimal tests to cover allow, choice, block, unknown, missing version, evidence drift, and stale entries; then run the gate against real SBOM/license reports. A successful compile or HTTP 200 is not evidence of license passing.

For detailed determination and evidence fields, see references/decision-model.md. For common misuse, read references/anti-patterns.mdfirst; for edge cases, see references/faq-deep.md。

Output format

First give the policy stance and conclusion summary, then give an item-by-item table:

Field	Requirement
coordinate	Complete package coordinates and version
scope	runtime / build / test / optional / excluded
declared_expression	Original license expression
selected_license	Selected SPDX branch; empty if it cannot be selected
usage_mode	As-is/modified/source code copied/statically merged, etc.
decision	Pass/conditional pass/more evidence needed/block/not in deliverable
evidence	Pinned, official, verifiable URL or file location
obligations	NOTICE, license, source, or replacement obligations
rationale	Decision logic combining policy and facts
action	Retain, supplement evidence, upgrade, replace, or remove

The ending must include: raw hit count, confirmed false positive count, true blocking count, unresolved count, gate verification evidence, and residual risk. Facts, inferences, and recommendations must be separated; when unable to confirm, write “more evidence needed”, and do not fabricate SPDX, license terms, or official sources.

Privacy and security

Dependency reports may contain private package names, repository URLs, customer names, or access tokens. Before display, redact credentials and internal domains; evidence links must not carry tokens. Do not upload private SBOMs or license texts to external services unless the user explicitly authorizes it. If a secret is found, stop propagation and remind to rotate it.

Common questions

1. Should LGPL always be blocked? Not necessarily; first see whether it is OR Branches, linkage and modification methods, and organizational policy.
2. Can all open source licenses be used commercially? It cannot be judged based on the word "open source" alone; the license and obligations still need to be verified.
3. Why must the exact version be used? License declarations change with versions, and broad exceptions can drift.
4. Can the GitHub default branch serve as evidence? It can only serve as a clue; prefer to pin a tag or commit.
5. Does passing a scanner equal compliance? No; it only proves that the current rules and inputs reported no errors.
6. Can unknown names be globally allowlisted? No; official evidence should be added by exact coordinates, or the dependency should be replaced.