# License Compliance Checker

> license-compliance-checker

- Skill: `themarmack/license-compliance-checker` (Agent Skill)
- Install (CLI): `npx skillmds@latest add themarmack/license-compliance-checker`
- Raw SKILL.md: https://api.skillmd.com/api/skills/themarmack/license-compliance-checker/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: themarmack (https://skillmd.com/u/themarmack)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/themarmack/license-compliance-checker

---


# license-compliance-checker

A Category 4 ops tool. License compliance is the surface where AppSec, legal, and procurement collide — and where dependency adoption stalls without a clear allow/review/deny posture. This skill makes the org's posture explicit and the scan reproducible.

## When to use

- Dependency review PR phase (a new dependency added — does its license stand?).
- Before going to production with a service that uses a new dependency.
- Portfolio audit: scan N repos' dependency trees for risky licenses.
- After a license change at the upstream level (e.g., Elastic licensing change, Hashicorp BUSL move) — re-scan for impact.

## When NOT to use

- Code-level review → CodeQL.
- IP indemnity question for AI tool output → [`copilot-faq-answerer`](../copilot-faq-answerer/SKILL.md) `ip-indemnity` entry.
- License authorship review (the org's own code) → that's a different process.

## Org's license posture (the allow / review / deny list)

### Allowed (no further review)

- **MIT** — permissive, no copyleft, attribution required
- **Apache-2.0** — permissive, patent grant included
- **BSD-2-Clause** (Simplified BSD)
- **BSD-3-Clause** (Modified BSD)
- **ISC** — equivalent to MIT
- **Unlicense** — public-domain dedication
- **0BSD** — zero-clause BSD
- **CC0-1.0** — public domain (note: NOT same as CC-BY-NC)
- **Zlib** — permissive
- **Python-2.0**, **PSF-2.0** — Python software foundation

### Review-required (case-by-case)

These need legal review before adoption:

- **LGPL-2.1 / LGPL-3.0** — weak copyleft; OK for dynamic linking, problematic for static/embedded
- **MPL-2.0** — file-level copyleft; OK if used unmodified, careful if forked
- **EPL-2.0** — weak copyleft, file-based
- **CDDL-1.0** — weak copyleft, file-based
- **CPL-1.0** — older variant of EPL
- **Artistic-2.0** — Perl Foundation; review needed for embedded contexts

### Denied (do not adopt without an exception)

- **GPL-2.0 / GPL-3.0** — strong copyleft; risk to proprietary code combined with GPL dependency
- **AGPL-3.0** — network copyleft; particularly risky for SaaS-style services
- **SSPL-1.0** (Server Side Public License) — non-OSI-approved; explicit obligations on org's service
- **BUSL-1.1** (Business Source License) — time-bombed source-available; not free; obligation post-conversion
- **CC-BY-NC** (non-commercial) — incompatible with org's commercial use
- **CC-BY-ND** (no derivatives) — incompatible with normal usage
- **Proprietary / "All rights reserved"** — requires explicit commercial agreement
- **Custom licenses** — explicit review required regardless of permissiveness

### Transitive concerns

A package with an Allowed license depending on a Review-required or Denied package: the transitive license obligation flows through. The skill traces the full tree and surfaces transitive risks separately from direct ones.

## Workflow

1. **Identify the dep tree**: parse `pom.xml` + lockfile / `package-lock.json` / `poetry.lock` / `go.sum` / etc.
2. **Resolve licenses**: each package's declared license (per its registry metadata).
3. **Categorize**: allowed / review / deny.
4. **Trace transitives**: for any Review or Deny finding, identify the path from a direct dependency to it.
5. **Produce findings**: structured list per package + license + verdict + remediation — presented in chat.
6. **Persist the scan** — after presenting findings, write the full compliance note via `vault-writer.write_research` to `vault/research/compliance/YYYY-MM-DD-license-compliance-{repo-slug}.md` (frontmatter per `research.yml`, `topic: compliance`) so repo-level license trends stay queryable.

## Output structure

```markdown
# License Compliance — {repo / target}

## Summary
- Direct dependencies: {N}
- Transitive: {M}
- Allowed: {A} | Review-required: {R} | Denied: {D}

## Denied direct dependencies (must remediate)
| Package | Version | License | Remediation |
|---------|---------|---------|-------------|

## Denied transitive dependencies
| Package | Version | License | Via direct dep | Remediation |
|---------|---------|---------|----------------|-------------|

## Review-required (legal review queue)
[same shape]

## Notable allowed (informational)
[high-profile dependencies for audit visibility]
```

Lands at `vault/research/compliance/YYYY-MM-DD-license-compliance-{repo-slug}.md` (workflow step 6).

## Composes with

- `dependabot-config-helper` — Dependabot itself doesn't have a license-deny step; this skill fills the gap.
- [`sbom-reviewer`](../sbom-reviewer/SKILL.md) — natural pair; SBOMs include license metadata.
- `vault-querier` — load prior license-compliance findings to track repo-level trends.
- `vault-writer.write_research` — persists the compliance note (workflow step 6).

## Acceptance test (for step 25 done-criteria)

The allow/review/deny lists shipped per category. SKILL.md describes the workflow + transitive-tracing approach + output shape. Live exercise against a real repo deferred until first invocation.