This source did not publish a separate summary. Review SKILL.md before using the skill.
SKILL.md
Checking License Compliance
Overview
License compliance is a security concern only in the indirect sense
that an unintended license obligation can force you to release
proprietary source code, retroactively invalidate a customer
contract, or render an M&A transaction infeasible. The cost is
legal and contractual rather than exploitative — but the
consequence ladder is real.
The most-stepped-on landmine is copyleft contamination:
unintentionally including a GPL or AGPL-licensed package in a
codebase the rest of which is permissively licensed (MIT, Apache-2.0,
BSD). The terms of the GPL family say that any project distributing
GPL code MUST itself release source under a GPL-compatible license.
If your package.json says MIT and one of your transitive deps is
GPL-2.0, you may be obligated to either re-license your code or
remove the dep.
This skill audits the resolved dependency tree against an explicit
policy file and emits findings for:
Direct deps with deny-listed licenses
Transitive deps with deny-listed licenses
Packages with UNKNOWN license metadata (no SPDX identifier)
License conflicts between metadata and source headers
Combinations of licenses that are mutually incompatible (e.g.
GPL-2.0 + Apache-2.0 without a patent grant)
When the skill produces findings
Finding
Severity
Threshold
Affected control
Strong-copyleft in permissive project
CRITICAL
GPL-2.0/3.0, AGPL-3.0, or similar in a project declaring MIT/Apache-2.0/BSD
(legal)
Weak-copyleft requiring source disclosure
HIGH
LGPL family in a project where the obligation isn't being met (no source-availability commitment)
(legal)
Custom / non-SPDX license
HIGH
License field doesn't match SPDX expression syntax; requires legal review
(legal)
Unknown license
MEDIUM
Package has no license field, no LICENSE file detected
(legal)
Deny-listed license (per policy)
HIGH
Package license is in the explicit deny-list in the policy file
(legal)
Review-required license (per policy)
MEDIUM
Package license is in the review-list (e.g. MPL-2.0)
(legal)
Incompatible license combination
HIGH
Detected pair of licenses known to conflict (e.g. GPL-2.0-only + Apache-2.0)
(legal)
License declared differently in metadata vs source headers
MEDIUM
LICENSE file says one license; per-file SPDX-License-Identifier headers say another
(legal)
Permissive license requiring attribution
INFO
MIT/BSD/Apache-2.0 — emit reminder that NOTICE / attribution file should list the package
(informational)
Prerequisites
Python 3.9+
Target project with EITHER a package.json + node_modules/
OR a Python project (pyproject.toml/requirements.txt/
installed venv)
Policy file at ./.license-policy.json (auto-detected) or
passed via --policy. If absent, the skill uses a built-in
default policy that flags strong copyleft for permissive parent
projects.
Instructions
Step 1 — Identify the project's own declared license
The skill reads the project's top-level license from:
npm: package.json's license field
Python: pyproject.toml's [project].license table OR
setup.cfg's license field
If the project's own license isn't declared, the skill emits a
FATAL operational finding — license compliance can't be checked
without a baseline. Add a license field before running.
allow: licenses that pass without comment.
deny: licenses that produce a finding regardless of project license.
review: licenses that produce a MEDIUM-severity finding for legal review.
project_license: enforced — if the project declares this but a dep is in deny, finding is CRITICAL.
Usage: check_licenses.py PATH [OPTIONS]
Options:
--output FILE Write findings to FILE (default: stdout)
--format FMT json | jsonl | markdown (default: markdown)
--min-severity SEV (default: info)
--policy FILE Override default policy
--emit-attribution Also emit an attribution file (NOTICE.md) listing
every permissive-licensed dep that requires attribution
Step 4 — Interpret findings
CRITICAL findings block release pending legal review. Either remove
the offending dep, replace it with a permissively-licensed
alternative, or escalate to legal for a written exception.
HIGH findings require legal sign-off but don't necessarily block
release if the legal posture (e.g. service-only deployment under
AGPL) makes the obligation moot.
MEDIUM findings should be reviewed quarterly and either resolved
or moved into an explicit exception list.
INFO findings are reminders that an attribution / NOTICE file
should reference these packages.
