Dependency Compliance (license & SBOM mechanics)

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.

• "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).