Dependency License Flags Checker

Introduction

Dependency license review checks whether the components in a project can move through a release under the policy the team actually uses. A dependency can look harmless because it has no vulnerability finding, yet still need review when its license is denied, missing, custom, or outside the approved list.

The core idea is evidence matching. A dependency row brings a name, version, scope, directness, and license expression. A policy brings allowed, review, and denied license lists. The useful result is not a broad legal answer. It is a release gate signal showing which rows pass, which rows need approval evidence, and which rows should stop a shipment until the dependency or exception path is resolved.

Modern software bill of materials data often uses SPDX license identifiers and license expressions. Those expressions can be simple, such as MIT, or compound, such as MIT OR GPL-3.0-only. The difference matters because an OR expression can offer an acceptable license path, while an AND expression can mean multiple terms apply together.

A license flag is a triage signal, not legal advice. It helps an engineering, security, or release team prepare the rows that need counsel, owner review, replacement, or attribution evidence before a release record is closed.

Technical Details:

License policy review depends on consistent identifiers. SPDX provides short identifiers and expression syntax so a scanner, software bill of materials, and release gate can refer to the same license in a machine-readable way. Case, aliases, and scanner wording still vary, so a practical checker has to normalize common labels before comparing them with policy lists.

The current rule model treats each dependency row as evidence to classify. A row can be allowed, denied, assigned to review, marked unknown, marked unlisted, or marked as an allowed choice. The distinction between unknown and unlisted matters. Unknown means the evidence is missing or reported as NOASSERTION-style data. Unlisted means a specific license identifier is present but does not appear in any policy list.

Compound expressions are reduced into common AND and OR shapes. AND terms are checked together because each term can add obligations. OR branches are checked as alternatives; if any branch is allowed, the row becomes an allowed choice and the selected branch should be documented. License exceptions after WITH are not independently validated, so exception text still deserves manual review when obligations matter.

Policy status is separate from queue priority. Denied direct runtime rows receive the highest priority, denied rows outside that shape still block, and runtime review or unknown rows receive a release-review priority. Allowed choices remain visible because a dual-license dependency needs an approval note even when one branch is acceptable.

Input shape controls how much evidence can be used. Headered CSV can provide dependency, version, license, scope, directness, owner, and path columns. JSON inputs can come from arrays, dependency objects, package-lock style data, CycloneDX components, or SPDX packages. Headerless CSV is accepted, but it depends on the expected column order, so warnings should be checked before using the finding queue.

The license risk score is the average policy pressure across parsed dependencies, capped on a 0 to 100 scale. It is useful for comparing snapshots from the same policy, but it is not a legal-risk score and it does not inspect source code, fetch registry data, or verify the full license text.

Everyday Use & Decision Guide:

Start with a project label that matches the repository, service, release branch, or SBOM you plan to attach to a ticket. That label appears in the policy snapshot and exports, so a versioned name is better than a generic team name.

Keep Allowed licenses narrow. Put licenses there only when your team can approve them without more review under the current distribution model. Use Review licenses for licenses that may be acceptable after context is checked, and use Denied licenses for terms that should stop the release unless an exception already exists.

For the first pass, leave unknown and unlisted flagging enabled. Missing license evidence and unfamiliar IDs are common release-review problems because they make it hard to prove what terms apply. If you turn that setting off, use the ledger to confirm that no unclassified license quietly moved into the allowed path.

• Use Browse report when the source file is already exported as CSV, JSON, SPDX, or CycloneDX text.
• Use Format JSON only after pasting valid JSON. CSV text should be left as rows.
• Open Policy Gate Snapshot first to see pass, review, or block status.
• Open Dependency License Ledger when you need every parsed dependency row, not only findings.
• Open License Finding Queue for rows that need owner action, replacement, evidence, or review.

Parsing and scoring run in the browser page. That is useful for sensitive dependency lists, but copied CSV, downloaded JSON, exported DOCX tables, and chart images can still contain project names, dependency names, owners, and paths. Treat those files as release records.

Use the result to prepare the next review step, not to skip it. A clean gate means the pasted evidence matched the policy lists you entered. It does not prove the SBOM is complete, that every transitive dependency was present, or that legal obligations have been satisfied.

Step-by-Step Guide:

Use one policy and one source snapshot per run so the gate, ledger, chart, and JSON describe the same review.

1. Enter a recognizable value in Project label, such as a release branch, service name, container image, or SBOM title.
2. Review Allowed licenses, Review licenses, and Denied licenses. Keep identifiers comma-separated or line-separated.
3. Leave Unknown license policy enabled unless your process deliberately allows unlisted license IDs to pass without review.
4. Paste dependency license rows into Dependency license source, drop a supported text file on the field, or load a report with Browse report.
5. If the source alert appears, fix the pasted text before using the result. Empty input, unrecognized rows, or malformed JSON can leave the gate with no real dependency evidence.
6. Review the summary badges, then move through Policy Gate Snapshot, Dependency License Ledger, License Finding Queue, License Mix, and JSON as needed for the release record.

Finish by checking the first finding rows and any warning in the source status line. Those two places usually reveal column-order mistakes, missing evidence, and policy-list gaps fastest.

Interpreting Results:

The summary heading is the fastest read. Dependency License Gate Blocking means at least one denied row was found. Dependency License Review Queue means no denied row was found, but review, unknown, or unlisted rows need attention. Dependency Licenses Cleared means the parsed rows matched allowed policy or allowed-choice handling under the current settings.

Policy Gate gives the release-level status. Block should stop the release path until denied terms are replaced or an exception is documented. Review means the next step is policy or owner review. Pass means no finding row was created by the pasted source and current policy lists.

• Flagged dependencies counts denied, review, unknown, and unlisted rows. Allowed-choice rows are counted separately.
• Allowed OR choices identifies dual-license rows where at least one branch is allowed. Keep an approval note for the branch you intend to use.
• License risk score averages policy pressure. Compare it only against runs that use similar source quality and policy lists.
• License Mix shows how many dependencies landed in each outcome so a reviewer can spot a source dominated by unknown or unlisted rows.

A pass result can still be wrong if the source export omitted dependencies, used nonstandard license names, or placed CSV fields in an unexpected order. When the result looks surprisingly clean, inspect the ledger and JSON warnings before copying rows into a ticket.

Worked Examples:

Default sample with mixed policy outcomes

The sample CSV includes permissive rows such as vue and axios, an unknown internal dependency, a denied GPL-3.0-only dependency, a review-path MPL-2.0 dependency, a denied CC-BY-NC-4.0 row, and a dual-license MIT OR GPL-3.0-only row. With the default policy lists, the gate blocks because denied rows are present. The finding queue separates denied, review, and unknown work, while the dual-license row appears as an allowed choice rather than a blocker.

Unlisted license after a scanner change

A scanner starts reporting LicenseRef-Proprietary-Notice for one transitive dependency. If that ID is not in allowed, review, or denied lists and unknown flagging stays enabled, the row becomes unlisted. The right follow-up is to classify the ID under policy, not to assume it is acceptable because it did not match the denied list.

Headerless CSV copied from a report

A copied line such as legacy-parser,0.9.4,GPL-3.0-only,runtime,false,platform,node_modules/legacy-parser can parse without headers. The assumed order is dependency, version, license, scope, directness, owner, and path. If your export uses another order, add a header row before trusting the gate.

Dual-license row that still needs a note

A dependency reported as MIT OR GPL-3.0-only can pass as an allowed choice when MIT is allowed. That does not mean the denied branch disappeared. It means the release record should document that the project relies on the allowed branch and should preserve attribution evidence for that choice.

FAQ:

Glossary:

SPDX ID

A short license identifier used in software supply-chain records, such as MIT or Apache-2.0.

License expression

A license statement that may combine IDs with operators such as AND, OR, or WITH.

Allowed choice

A dual-license or multi-branch expression where at least one branch is allowed by the current policy.

Unknown license

A row whose license evidence is missing, blank, none, null, or reported without assertion.

Unlisted license

A specific license ID that is present in the source but absent from the allowed, review, and denied lists.

Policy gate

The release-level pass, review, or block signal derived from the parsed dependency rows and policy lists.

References:

• SPDX overview, SPDX project.
• SPDX License Expressions, SPDX specification v2.2.2.
• CycloneDX Authoritative Guide to SBOM, license evidence section.
• OpenChain ISO/IEC 5230 license compliance, OpenChain Project.