Dependency License Flags Checker

Introduction

License flags usually appear late in a release because dependency evidence is scattered across manifests, scanner exports, software bills of materials, and old inventory spreadsheets. A useful review does more than find a license name. It asks whether the dependency evidence is complete enough, whether each license matches the organization policy, and whether the planned use changes the amount of scrutiny needed before shipping.

A dependency can be technically safe and still stop a release. Missing license evidence, a nonstandard license label, a strong-copyleft identifier, a commercial restriction, or a dual-license expression can all require a reviewer to slow down. The same dependency can also mean different things in different contexts. An internal service, a redistributed product, and an early inventory cleanup often use different approval pressure even when the raw license string is identical.

Most automated license reviews work from short identifiers rather than full legal text. SPDX identifiers such as MIT, Apache-2.0, and GPL-3.0-only give scanners and software bills of materials a common vocabulary. SPDX expressions then combine identifiers with operators such as AND, OR, and WITH. Those operators matter: MIT OR GPL-3.0-only offers a choice, while MIT AND GPL-3.0-only means both terms apply.

License policy lists are triage tools, not substitutes for legal review. A typical policy separates identifiers that are allowed without extra action, identifiers that require review, and identifiers that should be denied unless an exception exists. Unknown and unlisted values deserve their own treatment because they are evidence gaps rather than known approvals.

The practical goal is a defensible queue: rows that can pass, rows that need a reviewer, rows that should block, and rows whose evidence is too weak to trust. That queue helps engineering fix dependency choices and helps compliance preserve the reasoning behind a release decision.

How to Use This Tool:

Run one dependency evidence snapshot against one policy posture at a time. That keeps the summary, finding queue, chart, and JSON report aligned with the same release decision.

1. Enter a Project label that would make sense in a release ticket, audit note, container image record, or SBOM handoff.
2. Choose the Organization policy profile. Standard release gate fits ordinary release checks. Redistributed product raises pressure around distribution duties. Internal service focuses the review on production service use. Inventory discovery records blockers as follow-up instead of stopping a release.
3. Select the Input/source format. Leave it on Auto-detect CSV or JSON for pasted mixed evidence, or pin CSV, npm license-checker JSON, CycloneDX JSON, or SPDX JSON when a CI artifact should have one known shape.
4. Set SPDX normalization. Tolerant aliases cleans common scanner labels. SPDX strict expressions avoids alias expansion and sends unlisted WITH exceptions to review. Evidence-first conservative treats custom or non-SPDX-looking text as missing evidence.
5. Choose Dependency reach and Unknown/unlisted handling. For formal release review, start with all parsed dependencies and review or block unknown values. Narrow to release-surface or direct runtime rows only when the source includes extra inventory you deliberately want outside the gate.
6. Update Allowed licenses, Review licenses, and Denied licenses. Use comma-separated or line-separated SPDX identifiers and keep the allowed list limited to licenses your process truly approves without extra context.
7. Paste, drop, or browse the Dependency license source. If the status line shows zero rows, malformed JSON, or a headerless CSV warning you did not expect, fix the evidence before treating Policy Gate Snapshot as release-ready.

Read Policy Gate Snapshot first. Move to License Finding Queue for the work list, Dependency License Ledger for row-by-row evidence, Policy Scope Ledger when dependency reach excluded rows, and Review Recommendations for policy follow-up notes.

Interpreting Results:

The most important result is the active gate value. Block means at least one included row blocks under the selected profile and unknown policy. Review means no blocking row was found, but at least one included dependency still needs owner, license, distribution, or evidence review. Pass means the included rows matched the current policy lists without creating a block or review action.

A pass is not a legal clearance. It means the parsed dependency rows, active reach setting, normalization mode, and license lists did not raise a finding. Missing dependencies, incomplete SBOMs, overly generous allowed lists, scanner aliases, and stale release artifacts can still leave obligations outside the result.

• License risk score compares policy pressure across runs made with the same settings. It is a triage score, not a legal-risk measurement.
• Allowed choice means an OR expression has at least one allowed branch. Record the branch you rely on before approval.
• Unknown and Unlisted rows point to evidence or classification gaps. Check the source artifact, registry metadata, repository license file, or SBOM evidence before sign-off.
• Policy Scope Ledger should be checked whenever dependency reach is narrowed. Excluded dev, optional, transitive, or non-runtime rows may return to scope if the shipped artifact changes.
• Included License Mix is useful for spotting concentration, such as a release dominated by review or unknown rows, but the finding queue remains the action list.

Technical Details:

Dependency license triage has two separate jobs. The first is evidence parsing: dependency rows must be reduced to a consistent set of names, versions, scopes, directness values, paths, owners, and license expressions. The second is policy classification: each expression is compared against allowed, review, denied, unknown, and unlisted outcomes.

SPDX expressions provide the main grammar for license meaning, but scanner exports are often imperfect. Common aliases may need normalization, NOASSERTION needs to be treated as missing evidence, and custom identifiers may not be reliable enough for automatic approval. The checker handles common identifier, AND, OR, WITH, comma, semicolon, and slash-separated patterns for triage. It does not replace a full legal analysis of license text, notice duties, source-offer requirements, or complex expression precedence.

Rule Core:

Each included row receives a policy outcome from the normalized license evidence. Denied and review matches take priority over allowed matches inside the same required group, while an allowed branch in an OR expression becomes an allowed choice that still needs documentation.

Score Construction:

The risk score is a pressure average across included dependencies. It starts from the row outcome, then adjusts for blocking unknowns, direct runtime importance, dev-like transitive rows, allowed choices in distribution contexts, and the selected policy profile.

Here n is the number of dependencies included by the active reach setting, and w_i is the adjusted pressure weight for one included row. Excluded rows appear in the scope ledger but do not contribute to the average.

Parsing and Scope Rules:

CSV rows, simple lists, npm license-checker style JSON, CycloneDX component lists, SPDX package lists, dependency arrays, dependency objects, and package-lock-like objects are reduced to the same review shape. Headered CSV can provide dependency, version, license, scope, directness, owner, and path columns. Headerless CSV is accepted in that order, but the warning should be read before relying on the output.

The finding queue sorts action rows by priority, gate effect, risk weight, and dependency name. Direct runtime blockers rise to the top, ordinary blockers follow, runtime review and unknown rows come next, and allowed-choice documentation is lower priority unless the redistribution profile raises it.

Privacy and Accuracy Notes:

Dependency names, versions, paths, owners, policy lists, and pasted license evidence are parsed in the browser page. The checker does not perform registry lookups, remote license validation, or server-side legal analysis for the dependency source. Normal page and script loading still involves browser network requests, and downloaded CSV, DOCX, chart, or JSON artifacts can contain sensitive release evidence.

• A clean result depends on the completeness of the pasted report or SBOM.
• Policy lists should be reviewed by the organization that owns the release decision.
• Complex or unusual license text should be checked against the actual license and project context before approval.
• The output is a triage aid and release-record helper, not legal advice.

Advanced Tips:

• Pin Input/source format in continuous integration when the artifact is supposed to be CycloneDX JSON, SPDX JSON, or license-checker JSON; a format error is better than silently reading the wrong evidence shape.
• Use SPDX strict expressions when WITH exceptions must be explicitly approved, and use Evidence-first conservative when custom license text should enter the unknown evidence queue.
• Keep Unknown/unlisted handling on review or block for release gates. Review missing evidence only is better reserved for cleanup passes where unlisted identifiers are intentionally outside the active gate.
• Check Policy Scope Ledger whenever Dependency reach excludes dev, optional, transitive, build, or unknown-directness rows; excluded rows can matter again if the shipped artifact changes.
• Use Included License Mix to spot concentration, then use License Finding Queue as the action list because it preserves priority, gate effect, dependency name, reason, and next action.

Worked Examples:

A standard release snapshot includes vue under MIT, legacy-parser under GPL-3.0-only, and internal-grid with NOASSERTION. The Policy Gate Snapshot reports a blocking gate because the denied GPL row is included. License Finding Queue puts the block ahead of the unknown evidence row so the release owner can replace the dependency or approve an exception before resolving lower-pressure items.

A redistributed product contains dual-logger with MIT OR GPL-3.0-only. If MIT is allowed and GPL-3.0-only is denied, the row becomes Allowed choice rather than an immediate denial. The release record should still state that the product relies on the MIT branch and should preserve the required notices for the distributed artifact.

A team narrows Dependency reach to Direct runtime rows only for a production service check. A transitive build package with MPL-2.0 moves out of the active gate, but Policy Scope Ledger still lists why it was excluded. If the build output later embeds that package or the row becomes direct runtime evidence, rerun the check with a broader reach setting.

A pasted file selected as SPDX JSON returns a validation error because no package list is recognized. Switch Input/source format back to Auto or choose the matching format, then confirm that the source status line reports parsed dependency rows before using the gate value.

FAQ:

Glossary:

SPDX identifier

A standardized short license ID such as MIT, Apache-2.0, or GPL-3.0-only.

SPDX expression

A machine-readable license statement that combines identifiers with operators such as AND, OR, and WITH.

Software bill of materials

A structured inventory of components and related metadata used for supply-chain, security, and license review.

Unknown

A row where license evidence is missing, blank, or not asserted.

Unlisted

A row where a specific identifier is present but has not been classified in the current policy lists.

Allowed choice

An OR expression with at least one allowed branch that still needs a selected-license note.

References:

• SPDX License List, SPDX.
• Annex D: SPDX License Expressions, SPDX Specification 2.2.2.
• CycloneDX Specification Overview, OWASP Foundation.
• package.json, npm Docs.