License Analyzer

---
name: license-analyzer
description: |
  Trigger when the user asks to analyze licenses of dependencies, check license
  compliance, or audit for restrictive licenses. Phrases: "license check",
  "license audit", "GPL dependency", "AGPL", "license compliance".
allowed-tools:
  - Read
  - Bash(pnpm licenses *)
  - Bash(npm ls *)
  - Bash(license-checker *)
  - Grep
---

# License Analyzer

Audit the license profile of a codebase's dependencies. Flag restrictive
or incompatible licenses for legal review before they bite during a ship.

## Prerequisites

- Dependency tree locked (lockfile committed)
- `license-checker` or `pnpm licenses` available

## Steps

1. **Generate the license report:**
   ```bash
   pnpm licenses list --long --prod > licenses.txt
   # or for npm:
   npx license-checker --production --json > licenses.json
   ```

2. **Bucket by license category:**
   - **Permissive (safe):** MIT, Apache-2.0, BSD-2/3-Clause, ISC
   - **Weak copyleft (usually fine):** LGPL-2.1/3.0, MPL-2.0
   - **Strong copyleft (read carefully):** GPL-2.0, GPL-3.0
   - **Network copyleft (risky for SaaS):** AGPL-3.0
   - **Unknown / unlicensed:** no LICENSE file or UNLICENSED - flag loudly

3. **Flag the risky buckets** for your distribution model:
   - SaaS: AGPL is the one to worry about. It can require source disclosure
     to users of the network service.
   - Shipped binaries: GPL in the dep tree forces your whole binary to be
     GPL unless you dynamically link a LGPL boundary.
   - Closed-source commercial: copyleft in general is a careful review.

4. **For each flagged dep:**
   - Is it actually used? (Dead deps should be removed anyway.)
   - Is there a permissively-licensed alternative?
   - Is the license genuinely incompatible with the use case, or is it a
     false-positive on scanner heuristics?

5. **Document the approved license policy** in `LICENSES.md` or
   `THIRD_PARTY_NOTICES.md`. For every non-permissive dep you ship,
   include attribution as required by the license.

6. **Add a CI check** that fails the build if a new restrictive license
   enters the dependency tree without explicit approval.

## Policy patterns that work

- Allow-list: explicit list of approved licenses; new ones need review
- Block-list: explicit list of banned licenses (usually GPL, AGPL for SaaS)
- Review queue: unknown licenses land in a queue, block PR until resolved

## Output

- License inventory grouped by category
- Flagged-dep report with rationale for each
- Updated THIRD_PARTY_NOTICES.md
- CI check that prevents regressions