--- name: dependency-compliance-kabaka title: Dependency Compliance (license & SBOM mechanics) description: Use when checking a dependency's license, license compatibility, copyleft obligations, generating or reading an SBOM, SPDX identifiers, or whether a package's provenance/existence is trustworthy before adding it. Covers permissive vs weak/strong copyleft tiers, Apache NOTICE/patent terms, AGPL's network reach, SPDX IDs, SBOM (SPDX/CycloneDX) over direct AND transitive deps, lockfile pinning and advisory/provenance hygiene, and the AI-specific risks of license laundering and hallucinated/typosquatted ("slopsquatted") packages. This skill owns LICENSING / SPDX / SBOM / copyleft COMPLIANCE mechanics. Do NOT use for vulnerability or threat assessment, CVEs, malicious packages, or supply-chain ATTACK — that is `security-review`. Mechanics only; not legal advice. author: kabaka author_url: https://github.com/kabaka/ai-dlc/tree/main/product/.claude/skills/dependency-compliance license: MIT version: 0.1.0 execution_mode: open jurisdiction: general practice: ip language: en --- # Dependency Compliance (license & SBOM mechanics) This skill is the **licensing / SBOM / copyleft compliance** lens for the dependencies in your project. It describes the **mechanics** of evaluating a package's license, compatibility direction, copyleft obligations, and provenance so the human arbiter can make an informed call. > **This is not legal advice.** License compatibility and AI-generated-code > provenance are unsettled and contested areas of law; consult counsel for binding > determinations. This skill describes **mechanics only**; the human arbiter > decides what to ship. Never assert "license X is safe to combine with Y" as a > conclusion — surface the obligations and let the arbiter (and counsel) decide. ## Boundary — what this skill is NOT This skill owns **LICENSING / SPDX / SBOM / copyleft COMPLIANCE**. It is the *obligations and provenance* lens. - **Do NOT use for vulnerability or threat assessment — that is `security-review`.** CVEs, known-malicious packages, install-time exploit scripts, and supply-chain *attack* are exploitability questions owned by `security-review` and the `security` agent. - The two lenses meet at "adding a dependency": ask **both** "may I legally use and combine this?" (here) and "could this be exploited or is it malicious?" (`security-review`). Run them as two separate passes; do not conflate them. ## License tiers (obligations rise left to right) Compatibility is **directional and pairwise** — "A may include B" does not imply "B may include A," and a verdict for one pair says nothing about a third package. Always reason about a specific direction and the *combined* distribution. | Tier | Examples | Core obligation (mechanics, not advice) | | --- | --- | --- | | **Permissive** | MIT, BSD-2/3-Clause, Apache-2.0 | Minimal: preserve copyright + license text. **Apache-2.0** adds an explicit **patent grant** and requires propagating any **`NOTICE`** file. | | **Weak copyleft** | LGPL, MPL-2.0 | Obligations are **scoped to the licensed component/files**: changes to *that* component are shared back, but merely using/linking it generally does not subject your own code to copyleft. | | **Strong copyleft** | GPL-2.0/3.0, **AGPL-3.0** | **Derivative-work source obligations**: distributing a work built on it can require offering the combined source under the same terms. **AGPL extends the trigger to network/SaaS use** — providing access over a network counts as conveying, so server-side use can carry the obligation. | - "Compatible" means a specific combination's obligations can be simultaneously satisfied in a specific direction — it is a per-pair, per-direction question. - Dual-licensed or `OR`-expression packages let the consumer pick a tier; record which option you are relying on. ## SPDX identifiers and the SBOM - **SPDX license identifiers** are the machine-readable IDs for licenses (e.g. `MIT`, `Apache-2.0`, `AGPL-3.0-or-later`) plus expression operators (`OR`, `AND`, `WITH`). Prefer the SPDX ID over a free-text license name; it is what tooling and policy allowlists match on. - An **SBOM** (Software Bill of Materials) is the inventory of every component and its license, in a standard format — **SPDX** or **CycloneDX**. A useful SBOM covers **direct AND transitive** dependencies; a transitive strong-copyleft or unknown-license package is the common surprise, so the full tree is the unit of analysis, not the top-level manifest. - **Provenance / supply-chain hygiene** underpins trust in the SBOM (high level): **pin** dependencies via a committed lockfile; scan against advisory databases; and where available capture **provenance / SLSA** attestations tying an artifact to the source and build that produced it. ## AI-specific risks (why this matters in an AI workflow) An AI-driven workflow introduces two failure modes a human-only one largely avoids: - **License laundering.** An assistant can emit **near-verbatim snippets** of training-data code with the original attribution and license obligations **stripped**, so copyleft or attribution requirements silently ride into your codebase without an SPDX trail. Treat generated code that resembles a known project as a provenance question, not just a quality one. - **Hallucinated / typosquatted ("slopsquatted") dependencies.** An assistant may confidently suggest a package that **does not exist** — or whose plausible name is **squatted** by a malicious lookalike. This is why an **automated license + existence check at dependency-add** matters specifically here: the human never typed the name, so "does this package actually exist, from the expected source?" must be verified before it lands. ## Recommended checks (two points, NON-BLOCKING) > These are **recommended, non-blocking** checks. They inform the arbiter's > decision at an **existing** gate; they do **not** add a gate of their own. > **AI-DLC ships exactly four blocking arbiter gates** (Inception → Construction; > the design fork; Construction → merge; → Operations deploy/release) and **these > additions do not change that** — they are inputs inside the relevant checklist, > surfaced for the human, never a blocker the tooling enforces. 1. **At dependency-add** — license + provenance + **existence** check against the project's policy **allowlist / denylist**: resolve the package's SPDX license, confirm it actually exists from the expected source/registry (counters slopsquatting), and surface any tier mismatch with policy. Nests inside the `security-review` supply-chain lens as a recommended item. 2. **Pre-release** — **SBOM generation** (SPDX or CycloneDX) + a **full-tree license scan** across direct and transitive deps, surfaced on the `delivery-operations` pre-deploy checklist. The arbiter may still *choose* to treat a finding as decisive at an existing gate — that is the human deciding, not a new automated gate. ## How to report State, per dependency or per scan: the **SPDX license** (or expression), its **tier**, the **specific obligations** triggered by *your* intended use and distribution direction, **provenance/existence** status, and whether it matches the project policy. **Surface obligations; do not pronounce legal verdicts.** End by reminding the arbiter this is mechanics, and that combinability and AI-provenance questions may warrant counsel. ## Cross-references - **`security-review`** — the exploitability / threat lens (CVEs, malicious packages, supply-chain attack). The complementary pass at dependency-add; this skill does **not** cover it. - `delivery-operations` — hosts the pre-release SBOM/license checklist item. - `aidlc-workflow` — the four arbiter gates these checks feed (without adding one).