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
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
- 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 or equivalent package coordinates.
- Producing engineering gate recommendations, evidence gaps, distribution obligations, and replacement or upgrade recommendations.
Required Inputs
- 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 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
- 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
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
- 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 (select a compatible branch), (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
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
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
- Should every LGPL finding be blocked? Not necessarily. First determine whether it is an 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.