Dependency License Flags Checker

A dependency inventory answers what software is present. A license review asks a different question: what evidence describes each dependency's license, which obligations may apply in this use, and whether the organization has already approved that evidence. The answer can change between an internal service, a redistributed product, and an exploratory inventory.

License identifiers are not verdicts by themselves. The MIT identifier may already be approved under one policy, while MPL-2.0 may require notice review and GPL-3.0-only may be denied for a particular release. Missing evidence is another condition entirely. NOASSERTION means a conclusion was not supplied; it does not mean the dependency has no license obligations.

Software Package Data Exchange (SPDX) expressions preserve relationships that a flat license list loses. MIT OR GPL-3.0-only offers a choice of branches, while MIT AND GPL-3.0-only says both apply. A WITH expression attaches an exception or addition to a base license. Policy review must keep those operators intact because splitting the identifiers into unrelated words can reverse the conclusion.

Scope matters as much as the expression. A direct runtime dependency can ship with the product or execute in the service; a transitive development dependency may never reach the release surface. Excluding a row from a particular gate does not erase it from the inventory, and a clean gate does not prove the underlying bill of materials is complete.

Automated triage is most useful as a queue, not legal advice. It can apply a documented allow, review, and deny policy consistently, surface missing evidence, and show why a row was included. A qualified reviewer still needs to confirm license text, exceptions, linking or distribution facts, notices, source-offer duties, and any approved exception.

How to Use This Tool:

Use a current dependency inventory and a policy that matches the software's real use or distribution context.

1. Paste or load the Dependency license source, then select its format or use Auto detect. Supported inputs include CSV or a simple list, npm license-checker JSON, CycloneDX JSON, and SPDX JSON.
2. Enter a traceable project label and choose the Policy profile. Redistributed Product is stricter in the pressure score; Inventory Discovery turns denied rows into review rather than a blocking gate.
3. Choose SPDX normalization. Tolerant aliases help with familiar noncanonical names; SPDX Strict Expressions keeps exceptions from inheriting approval unless the full expression is classified; Evidence-first Conservative turns unsupported custom or malformed terms into unknown evidence.
4. Set Dependency reach. All Parsed Dependencies keeps every row in the gate; Release Surface includes runtime, peer, build, or direct rows; Direct Runtime requires both runtime scope and explicit directness.
5. Choose how unknown and unlisted identifiers should behave, then review the allowed, review, and denied lists. A denied match outranks other terms inside a required AND branch.
6. Read the gate status and parser label. Use Dependency evidence to verify what was parsed and excluded, then resolve the highest-priority rows in License finding queue before approving the release.

Interpreting Results:

Block means at least one included dependency produced a blocking policy result. Review means no blocker remains but one or more included rows need a decision. Pass means every included row passed the supplied policy. No rows in scope means the reach filter excluded the entire parsed inventory, not that the inventory is compliant.

The evidence table is the trust surface. Check dependency name and version, scope, directness, original license expression, normalized outcome, gate, and reason. A parser warning, unknown version, missing license, or unexpected exclusion can matter more than the summary badge.

Policy pressure ranks review workload from 0 to 100 by averaging built-in row scores. It is not legal risk, a compliance percentage, or a probability. A single direct runtime blocker should still stop a release even when many allowed rows lower the average.

Technical Details:

The analysis has three distinct stages: parse dependency evidence, classify each license expression against policy, and apply reach and gate rules. Keeping those stages separate makes it possible to tell a malformed inventory from a deliberate policy decision.

Transformation Core

Common aliases such as “Apache 2.0,” “MIT License,” and older GPL shorthand are mapped to canonical identifiers. Expressions are separated into OR choices and required AND terms; WITH keeps an exception attached to its base license. This is a policy-oriented parser, not a full SPDX conformance validator.

Rule Core

Each required AND branch receives its worst term outcome in this order: Denied, Review, Unknown, Unlisted, Allowed. Across OR branches, one allowed branch produces Allowed choice when alternatives exist. If no branch is allowed, the least restrictive available alternative is retained; the result is Denied only when every alternative is denied.

Priority follows gate and runtime reach: a direct runtime blocker is P0, another blocker P1, a runtime review P2, and remaining review work P3.

Formula Core

Each included row starts with an outcome weight: Denied 100, Review 65, Unknown 55, Unlisted 45, Allowed choice 12, and Allowed 0. Blocking unknown or unlisted evidence adds 30 points. A direct runtime row adds the profile boost; indirect development rows are multiplied by 0.65. Redistributed-product choices add 8 before the profile multiplier is applied. Each row is rounded and clamped from 0 to 100.

Policy pressure is the rounded arithmetic mean of all included row pressures. Excluded rows do not enter the denominator.

An inventory can contain up to 5,000 dependency rows and 262,144 characters. Each allowed, review, or denied policy list is limited to 12,000 characters; project and evidence labels are limited to 120 characters.

Privacy and Accuracy Notes:

Dependency inventories and policy lists are parsed in the browser and are not sent to a checker service. They may still reveal internal package names, paths, owners, versions, and policy decisions, so handle screenshots and exported evidence according to the project's security rules.

• This is policy triage, not legal advice and not a license-text scanner.
• Auto detection and field mapping cannot prove that the inventory is complete, current, or correctly generated.
• Declared, concluded, and detected license evidence can disagree. Resolve the underlying package evidence before approval.
• Parentheses and complex SPDX syntax are not fully validated. Use a dedicated SPDX validator when conformance or operator precedence is consequential.
• Approval lists express organizational policy, not universal judgments about a license.

Worked Examples:

References:

• SPDX license expressions, SPDX Specification 3.0.1.
• SPDX License List, Linux Foundation.
• SPDX Licensing Profile, SPDX Specification 3.0.1.
• CycloneDX Specification Overview, OWASP CycloneDX.