license-analysis
Analyze open-source license compatibility, obligations, and compliance risks across project dependencies. Use when the user requests license analysis or provides relevant inputs for this workflow.
git clone --depth 1 https://github.com/seb1n/awesome-ai-agent-skills /tmp/license-analysis && cp -r /tmp/license-analysis/legal-and-compliance/license-analysis ~/.claude/skills/license-analysisSKILL.md
# License Analysis
Analyze open-source license compatibility and obligations across a project's dependency tree. This skill identifies all licenses in use, checks for compatibility conflicts, flags copyleft infection risks, and generates a compliance report with actionable recommendations. It covers permissive licenses (MIT, BSD, Apache-2.0), weak copyleft (LGPL, MPL), strong copyleft (GPL, AGPL), and proprietary/mixed licensing scenarios.
## Workflow
1. **Scan Dependencies** — Parse the project's dependency manifest (package.json, requirements.txt, go.mod, Cargo.toml, pom.xml, etc.) and resolve the full transitive dependency tree. Identify every direct and indirect dependency, including optional, dev, and peer dependencies. Note any dependencies without declared licenses or with SPDX expressions indicating dual licensing.
2. **Identify Licenses** — For each dependency, extract the license from the SPDX identifier in the package metadata, the LICENSE file in the package, or the license field in the manifest. Normalize license names to SPDX identifiers. Flag packages with no license (all rights reserved by default), custom/proprietary licenses, or ambiguous multi-license declarations that require choice.
3. **Check Compatibility Matrix** — Evaluate pairwise license compatibility based on the project's intended distribution model (SaaS, distributed binary, open-source library, internal tool). Permissive licenses (MIT, BSD, ISC) are broadly compatible. Apache-2.0 has a patent grant that conflicts with GPLv2 (but not GPLv3). Copyleft licenses (GPL, AGPL) impose distribution obligations that may conflict with proprietary licensing of the combined work. AGPL triggers obligations even for network use.
4. **Flag Copyleft Risks** — Identify any dependency licensed under GPL, AGPL, LGPL, or MPL and evaluate whether the usage pattern (static linking, dynamic linking, separate process, network interaction) triggers copyleft obligations. A GPL library statically linked into a proprietary application requires the entire application to be GPL-licensed. LGPL allows dynamic linking without copyleft infection. AGPL extends copyleft to network interactions.
5. **Generate Compliance Report** — Produce a structured report containing: license inventory table, compatibility analysis, risk flags with severity, required attributions and notices, and specific recommendations for resolving any conflicts. Include a bill of materials suitable for inclusion in project documentation or legal review.
## Usage
Provide your project's dependency manifest or list of dependencies along with your project's license and distribution model. Specify whether the project is distributed as source, binary, SaaS, or internal-only.
**Example prompt:**
```
Analyze the licenses in my Node.js project. Here's my package.json dependencies. The project is MIT-licensed and distributed as an npm package. Flag any compatibility issues.
```
## Examples
### Example 1: Node.js Dependency Tree Analysis
**Input:** A Node.js REST API distributed as an open-source MIT-licensed npm package. Key dependencies from package.json:
```json
{
"dependencies": {
"express": "^4.18.2",
"lodash": "^4.17.21",
"pg": "^8.11.3",
"sharp": "^0.33.2",
"leaflet": "^1.9.4",
"jsdom": "^24.0.0"
}
}
```
**Output:**
**License Inventory**
| Package | Version | License | Category | Risk |
|---------|---------|---------|----------|------|
| express | 4.18.2 | MIT | Permissive | None |
| lodash | 4.17.21 | MIT | Permissive | None |
| pg | 8.11.3 | MIT | Permissive | None |
| sharp | 0.33.2 | Apache-2.0 | Permissive | None |
| leaflet | 1.9.4 | BSD-2-Clause | Permissive | None |
| jsdom | 24.0.0 | MIT | Permissive | None |
| *libvips* (sharp native) | 8.15.1 | LGPL-2.1 | Weak Copyleft | Medium |
| *canvas* (jsdom optional) | 2.11.2 | MIT | Permissive | None |
**Transitive Dependency Summary:** 347 total packages scanned. 331 MIT, 8 Apache-2.0, 4 BSD-2-Clause, 2 ISC, 1 LGPL-2.1, 1 unlicensed.
**Risk Flags:**
- **LGPL-2.1 — libvips (via sharp), Severity: Medium** — libvips is dynamically linked by the sharp package via native bindings. Dynamic linking under LGPL-2.1 is permitted without copyleft infection, but you must: (1) include the LGPL-2.1 license text in your distribution, (2) provide attribution, and (3) allow users to replace the LGPL component with a modified version. Since sharp uses prebuilt binaries, document this in your NOTICES file.
- **Unlicensed package: colors@1.0.3 (transitive via debug), Severity: High** — No license file or SPDX identifier found. Without a license, no permission to use is granted. Action: verify if this is an outdated version (colors@1.4.0 is MIT-licensed) and pin to the licensed version, or find an alternative.
**Required Attributions:** Include LICENSE files or notices for all 347 packages. Use `license-checker` or `legally` npm packages to auto-generate a THIRD-PARTY-NOTICES file.
### Example 2: Mixed License Compatibility Analysis
**Input:** A proprietary commercial desktop application (closed-source) that wants to incorporate three libraries: an MIT-licensed utility library, an Apache-2.0 data parser, and a GPL-3.0 charting library.
**Output:**
**Compatibility Matrix**
| | MIT | Apache-2.0 | GPL-3.0 | Proprietary (your project) |
|---|---|---|---|---|
| **MIT** | Compatible | Compatible | Compatible (one-way) | Compatible |
| **Apache-2.0** | Compatible | Compatible | Compatible with GPL-3.0 only | Compatible |
| **GPL-3.0** | Can use MIT code in GPL | Can use Apache in GPL-3.0 | Compatible | **INCOMPATIBLE** |
| **Proprietary** | Can use MIT | Can use Apache-2.0 | **INCOMPATIBLE** | — |
**Analysis:**
- **MIT utility library → Proprietary project: COMPATIBLE.** MIT permits use in proprietary software. Obligation: include the MIT license text and copyright notice in your distribution.
- **Apache-2.0 data parser → Proprietary project: COMPATIBLE.** Apache-2.0 permits proprietary use.Design reproducible evaluations for AI agents with representative task sets, explicit rubrics, appropriate graders, baselines, regression gates, and failure analysis. Use when defining agent quality, comparing prompts or models, validating a release, measuring tool-use reliability, investigating regressions, or deciding whether an agent is ready for production.
Design privacy-aware observability for AI agents using traces, spans, structured events, metrics, cost attribution, dashboards, alerts, and investigation workflows. Use when instrumenting an agent, debugging intermittent tool or model failures, defining service-level objectives, analyzing latency or spend, auditing agent decisions, or preparing production monitoring.
Design and verify auditable human oversight, approval gates, escalation paths, and safe state transitions for AI agent workflows. Use when deciding which agent actions require review, adding approve/reject or dual-control flows, preventing unauthorized autonomous effects, creating decision records, reducing rubber-stamping, or recovering safely from rejected, expired, or failed actions.
Design, implement, harden, and verify Model Context Protocol (MCP) servers with precise tool contracts, least-privilege authorization, safe transports, structured errors, and interoperability tests. Use when creating a new MCP server, exposing an API or data source through MCP, reviewing an MCP server design, adding or revising MCP tools, or preparing an MCP server for production.
Design and operate bounded multi-agent workflows with task decomposition, dependency graphs, ownership, handoff contracts, shared-state controls, approvals, recovery, and synthesis. Use when a task contains genuinely independent workstreams, specialized roles, parallel research or implementation, reviewer-worker loops, or coordination problems that one agent should not execute sequentially.
Design and validate model-facing tool definitions with clear names, action-oriented descriptions, bounded JSON Schema parameters, explicit side effects, safe defaults, idempotency, errors, and realistic tests. Use when creating function-calling tools, MCP tools, agent actions, structured tool inputs, or when a model selects the wrong tool, invents arguments, or causes unsafe side effects.
Plan, execute, document, and retest authorized security assessments of AI agents and multi-agent workflows using safe adversarial cases, synthetic identities, canaries, and evidence-based findings. Use when defining red-team rules of engagement, assessing prompt injection or excessive agency, testing tool and identity boundaries, evaluating memory or cross-agent attacks, scoring a campaign, or verifying remediation in an approved environment.
Threat-model and harden AI agents, RAG systems, assistants, and tool-using workflows against direct, indirect, stored, cross-agent, and multimodal prompt injection. Use when reviewing an agent architecture, isolating untrusted content, constraining tools and egress, protecting secrets, adding injection-focused tests, investigating a suspected injection incident, or documenting residual prompt-injection risk.