No conflicting license combinations in production dependencies

License incompatibilities create legal obligations that may be impossible to satisfy simultaneously. GPL-2.0 and Apache-2.0 are considered mutually incompatible for combined works because the Apache patent termination clause is inconsistent with GPL-2.0's terms — the FSF and OSI both document this. If your production application statically links both, the resulting combined work cannot be legally distributed under either license. Creative Commons licenses applied to code — rather than content — create a different set of incompatibilities with standard software licenses. The consequence is that your software may not legally be shipped or distributed in its current form, regardless of your intent or how the components are actually used at runtime.

Enumerate all unique license types across production dependencies and check for known conflicts:

npx license-checker --production --summary
# Or fail the build on specific combinations:
npx license-checker --production --failOn 'GPL-2.0;GPL-3.0;AGPL-3.0'

For detected conflicts, replace one of the conflicting packages with a permissively-licensed alternative. If the conflict involves a niche package with no alternative, consult a software licensing attorney — the SaaS vs. distribution distinction matters significantly under GPL-2.0 and Apache-2.0.

• ID: dependency-supply-chain.license.no-license-conflicts

• Severity: medium

• What to look for: Examine the combination of licenses across production dependencies. Look for combinations known to be legally incompatible: GPL-2.0 combined with Apache-2.0 (the Apache patent clause is considered incompatible with GPL-2.0), or multiple copyleft licenses with different terms. Also check for Creative Commons licenses on code packages (CC licenses are designed for content, not code). For most npm projects with standard MIT/Apache/ISC dependency sets, this check will pass. Count all instances found and enumerate each.

• Pass criteria: Verify that no dependency combination creates a license conflict. For example, a MIT-licensed project cannot statically link AGPL code without adopting AGPL for the entire distribution. Enumerate all unique license types in the dependency tree and check for incompatible combinations based on the project's own license. At least 1 implementation must be confirmed.

• Fail criteria: A known license incompatibility is detected (e.g., Apache-2.0 and GPL-2.0 together in a combined work).

• Skip (N/A) when: No package.json detected, fewer than 2 production dependencies, or no non-permissive licenses are detected (if all dependencies are MIT/ISC, there are no conflicts).

• Detail on fail: "Apache-2.0 and GPL-2.0 packages are combined in production dependencies — these licenses are considered mutually incompatible for redistribution"

• Remediation: License incompatibilities are complex legal territory. If flagged:

  1. Identify the conflicting packages.
  2. Determine if the incompatibility applies to your use case (linking, distribution, SaaS use).
  3. Seek a permissively-licensed alternative for one of the conflicting packages.
  4. Consult a software licensing attorney for a definitive determination.

  Note: SaaS applications (running on a server, not distributed) have different obligations than desktop/distributed software under many licenses.

  # Run license compatibility check
  npx license-checker --production --summary
  # Or add to package.json scripts: "license-check": "license-checker --production --failOn 'GPL-2.0;GPL-3.0;AGPL-3.0'"