Skip to content
Back to skills

Dependency License Compliance

ASecurity

Reviews open-source license risk — a legal-compliance concern distinct from dependency-supply-chain's vulnerability/version-pinning focus. Flags no license scanning in the dependency pipeline, a copyleft (GPL/AGPL) dependency pulled into proprietary code with no legal review, no documented license allow-list/deny-list policy, and license metadata missing from the SBOM already generated for release artifacts. Outputs findings with pilot-core license-compliance standard IDs.

  • 2 stars
  • 0 votes
  • 0 copies
  • 1 view
  • Added September 6, 2026
developmentgogitsecurity

Security analysis

A100/100

Scanned September 6, 2026

npx -y skills add AgenticPawan/FullStack-Pilot --skill dependency-license-compliance --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Dependency License Compliance?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Dependency License Compliance
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/agenticpawan-dependency-license-compliance/badge)](https://www.skillsdirectory.com/skills/agenticpawan-dependency-license-compliance)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: dependency-license-compliance
description: Reviews open-source license risk — a legal-compliance concern distinct from dependency-supply-chain's vulnerability/version-pinning focus. Flags no license scanning in the dependency pipeline, a copyleft (GPL/AGPL) dependency pulled into proprietary code with no legal review, no documented license allow-list/deny-list policy, and license metadata missing from the SBOM already generated for release artifacts. Outputs findings with pilot-core license-compliance standard IDs.
when_to_use: open source license, GPL, AGPL, copyleft, license scanning, license allow-list, SPDX, dependency license audit, license compliance, proprietary code contamination
---

## Standard IDs

| ID | Severity | What it checks |
|----|----------|-----------------|
| LIC-001 | P1 | No license scanning in the dependency pipeline |
| LIC-002 | P0 | Copyleft (GPL/AGPL) dependency in proprietary code with no legal review |
| LIC-003 | P1 | No documented license allow-list/deny-list policy |
| LIC-004 | P2 | License metadata missing from the SBOM |

This is the legal-compliance sibling to `dependency-supply-chain`'s security-vulnerability
scanning — a dependency can be perfectly secure and still create real legal exposure if
its license terms conflict with how the code is distributed.

---

## Check A — No license scanning in the pipeline (LIC-001)

### Detection

Check whether CI runs a license scanner (`dotnet-project-licenses`, `license-checker` for
npm, or a commercial SCA tool's license module) against the dependency tree. Without one,
nobody actually knows what licenses are in the transitive dependency graph until someone
manually audits it — which in practice means never, until a legal question forces it.

### BAD — no license scanning anywhere in CI

```yaml
# .github/workflows/ci.yml
- run: dotnet restore
- run: dotnet build
- run: dotnet test
# No license scan step — the transitive dependency tree's license mix is unknown.
```

### GOOD — license scan as a CI step, findings routed the same way as vulnerability findings

```yaml
- run: dotnet tool install --global dotnet-project-licenses
- run: dotnet-project-licenses -i ./MyApp.sln --json -o licenses-report.json
- run: npx license-checker --json --out licenses-report-npm.json
# Both reports feed into the same audit-orchestration findings.json pipeline.
```

---

## Check B — Copyleft dependency with no legal review (LIC-002)

### Detection

Check the license scan output for GPL/AGPL/LGPL (or other copyleft) licenses on a
dependency linked into proprietary, closed-source code with no documented legal review
of that specific usage. GPL's copyleft terms can require derivative works to also be
open-sourced under the same license — pulling a GPL library into a proprietary product
without legal sign-off is a real, not hypothetical, exposure.

### BAD — a GPL-licensed library used with no review

```xml
<PackageReference Include="Some.Gpl.Licensed.Library" Version="2.1.0" />
<!-- No note anywhere that legal reviewed and approved this specific usage. -->
```

### GOOD — either avoided, or explicitly reviewed and documented

```markdown
<!-- docs/LICENSE-EXCEPTIONS.md -->
`Some.Gpl.Licensed.Library` (GPLv3): reviewed by legal 2026-03-01. Used only in an
internal tooling script never distributed to customers — GPL's copyleft terms trigger
on distribution, not internal use, per counsel's guidance. Re-review required if this
tool is ever packaged for external distribution.
```

---

## Check C — No documented license allow-list/deny-list (LIC-003)

### Detection

Check for a documented policy stating which license families are pre-approved (MIT,
Apache 2.0, BSD — the common permissive licenses) versus which require review (any
copyleft license) versus which are outright disallowed. Without one, every new
dependency's license is a one-off judgment call by whichever engineer happens to add it.

### BAD — no policy, license acceptability decided ad-hoc per dependency

```
<!-- No documented stance — whether a new dependency's license is "fine" is whatever
     the engineer adding it assumes, with no consistent bar applied. -->
```

### GOOD — an explicit policy the license scanner (Check A) is configured against

```markdown
<!-- docs/LICENSE-POLICY.md -->
**Pre-approved (no review needed):** MIT, Apache-2.0, BSD-2-Clause, BSD-3-Clause, ISC, CC0-1.0
**Requires legal review before use:** LGPL-*, MPL-2.0
**Disallowed without an explicit, documented exception (see LICENSE-EXCEPTIONS.md):** GPL-*, AGPL-*
```

```yaml
# CI enforces the policy directly — license scanner fails the build on a disallowed license
- run: dotnet-project-licenses -i ./MyApp.sln --allowed-license-types allowed-licenses.json --fail-on-missing
```

---

## Check D — License metadata missing from the SBOM (LIC-004)

### Detection

Check whether the SBOM `dependency-supply-chain` DSC-004 already requires includes
license information per component, not just name/version. A CVE disclosure needs the
version inventory; a license audit (triggered by an acquisition, a customer's legal
team, or a new distribution channel) needs the license inventory — the same SBOM
generation step can capture both if configured to.

### BAD — SBOM has versions but no license field populated

```xml
<!-- bom.xml component entries have name/version but licenses left empty —
     answering "what licenses do we ship" still requires a separate manual audit. -->
```

### GOOD — SBOM generation configured to include license metadata

```yaml
- run: dotnet CycloneDX ./MyApp.sln -o ./sbom --json
# CycloneDX's component schema includes a licenses field when license metadata is
# available from the package registry — verify it's populated, not left as null.
```

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…