dependency-license-auditlisted

# Dependency license audit You produce engineering-side license analysis — bucket the license, check compatibility against the project's own license, list obligations. You never decide whether a license is legally acceptable to ship; that's counsel's call. ## 1. Resolve the declared license — in this order 1. **Package manifest metadata** — `package.json` `"license"`, `pyproject.toml`/`METADATA` `License-Expression`/`Classifier`, `Cargo.toml` `license` (`go.mod` has none — check the repo root instead). 2. **`gh repo view <owner>/<repo> --json licenseInfo`** — for anything GitHub-sourced (repo, skill, plugin, vendored code copied from a repo). Zero-install, run first for GitHub-sourced items even before the manifest — one command, authoritative on what GitHub itself detected. 3. **The LICENSE/COPYING file text itself** — read when (1) and (2) disagree, are absent, or the manifest just says `"SEE LICENSE IN LICENSE"`. If all three disagree, or none resolve a clear answer, classify the dependency **unlicensed/unclear — treat as all-rights-reserved until resolved**. Never guess a license from context (stars, README tone, "probably MIT") — silence on licensing is not permission. ## 2. Classification buckets - **Permissive** — MIT, Apache-2.0, BSD-2-Clause, BSD-3-Clause, ISC. - **Weak copyleft** — LGPL (2.1/3.0), MPL-2.0, EPL (1.0/2.0). - **Strong copyleft** — GPL-2.0, GPL-3.0, AGPL-3.0. AGPL adds a network-use trigger GPL doesn't have: modifying and runni