License Analysis

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:

{
  "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

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: [email protected] (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 ([email protected] 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

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. Obligations: include the Apache-2.0 license, NOTICE file if present, and state any modifications to Apache-licensed files. The patent grant protects you from patent claims by the Apache-2.0 contributors.

• GPL-3.0 charting library → Proprietary project: INCOMPATIBLE. GPL-3.0 requires that the combined work be distributed under GPL-3.0 with complete source code. This directly conflicts with proprietary/closed-source distribution. Including this library makes your entire application subject to GPL-3.0.

Recommendations:

1. Replace the GPL-3.0 charting library with an MIT or Apache-2.0 alternative. Options: Chart.js (MIT), Apache ECharts (Apache-2.0), Plotly.js (MIT).
2. If the GPL library is essential, evaluate whether it can be isolated into a separate process communicating via IPC or network API. The FSF's position is that this may avoid copyleft infection if the components are genuinely separate programs, though this interpretation is debated and legally untested.
3. Consider purchasing a commercial license — some GPL projects offer dual licensing with a proprietary option for a fee.

Best Practices

• Scan the full transitive dependency tree, not just direct dependencies — copyleft risks often hide several levels deep in the dependency graph.
• Treat "no license" as "all rights reserved" — the absence of a license does not mean permissive; it means you have no legal permission to use, copy, or distribute.
• Distinguish between distribution models: SaaS (AGPL triggers, but GPL usually doesn't), npm package (GPL triggers for downstream users), internal tool (most copyleft obligations don't apply to internal use).
• Automate license scanning in CI/CD using tools like FOSSA, Snyk, WhiteSource, or license-checker to catch new issues as dependencies are added.
• Keep a pre-approved license allowlist (e.g., MIT, BSD, Apache-2.0, ISC) and require manual review for anything outside the list.
• Document all license obligations in a THIRD-PARTY-NOTICES file shipped with your distribution.

Edge Cases

• Dual-licensed packages (e.g., MIT OR Apache-2.0) — When a package offers a choice via SPDX OR expressions, you may select the most compatible license. Document which license you chose and apply only that license's obligations.
• SSPL and Commons Clause — MongoDB's SSPL and the Commons Clause are not OSI-approved licenses. They restrict SaaS use and commercial use respectively. Treat them as proprietary restrictions even though the source code is available.
• License changes between versions — A dependency may change licenses across versions (e.g., Elasticsearch moved from Apache-2.0 to SSPL in v7.11). Pin to a known-good licensed version and monitor for license changes in updates.
• Fonts, images, and non-code assets — Creative Commons licenses on assets have different compatibility rules than software licenses. CC-BY-SA is share-alike (similar to copyleft) and CC-BY-NC prohibits commercial use. Don't assume code license scanning covers bundled assets.
• Snippets from Stack Overflow or AI-generated code — Stack Overflow content is CC-BY-SA 4.0 licensed. Substantial code snippets copied verbatim carry share-alike obligations. AI-generated code may have unclear provenance. Document the source of non-original code segments.