Open Source License Compliance for npm 2026

Q: What "Copyleft" Actually Means for Your npm Project?

The theoretical explanation of copyleft is straightforward. The practical implications require more context.

TL;DR

MIT and ISC licenses make up roughly 60% of npm packages and impose no meaningful restrictions on use. The risk zone is GPL and AGPL: GPL requires that applications using GPL code be distributed as GPL, and AGPL extends that to SaaS applications where users access your code over a network. One AGPL package in your dependency tree can create compliance obligations for your entire product. The solution: automated license scanning in CI with license-checker plus FOSSA or Black Duck for enterprise-grade policy enforcement.

Key Takeaways

MIT and ISC are permissive — no distribution requirements, no copyleft obligations
Apache 2.0 is permissive but requires preservation of notices and attribution
GPL v2/v3 is copyleft — distribution of GPL-linked software must be licensed as GPL
AGPL v3 extends copyleft to network distribution — providing a service using AGPL code triggers the same obligations as distributing it
license-checker gives instant visibility into all dependency licenses; run it in CI
FOSSA and Black Duck provide enterprise-grade scanning with policy enforcement, legal review workflows, and compliance reporting
When in doubt about a specific package, read the license text — the summary may not capture nuances

The License Landscape of npm

npm hosts over 2.5 million packages. Understanding the distribution of licenses matters because it tells you where your compliance risk concentrates.

Permissive licenses (most of npm):

MIT (~30% of packages): Do what you want, keep the copyright notice. No copyleft, no distribution requirements, compatible with everything.
ISC (~15%): Functionally identical to MIT, slightly simpler text. Same permissions and requirements.
BSD 2-Clause, BSD 3-Clause (~5%): Similar to MIT; 3-Clause adds a non-endorsement requirement.
Apache 2.0 (~8%): Permissive with additional requirements: preserve copyright notices, state modifications, include the Apache license text when distributing, and provide patent grants to downstream users.

Copyleft licenses (the risk zone):

GPL v2 (~3%): Strong copyleft. Software that links to or incorporates GPL v2 code must be distributed under GPL v2 when distributed.
GPL v3 (~4%): Same obligations as v2 with additional anti-tivoization clauses.
LGPL (~2%): "Lesser" GPL — copyleft obligations are limited. Using an LGPL library through its standard API doesn't create copyleft obligations on your code; modifying the library does.
AGPL v3 (<1% of packages, but high-profile): Extends GPL obligations to network distribution — running AGPL software as a service triggers the same obligations as distributing it.

Dual licenses and custom licenses (~5%): Some packages offer GPL for open-source use and commercial licenses for proprietary use (the open-core model). Reading the license text carefully is essential here.

What "Copyleft" Actually Means for Your npm Project

The theoretical explanation of copyleft is straightforward. The practical implications require more context.

GPL in Your Dependency Tree

If you build a Node.js application that require()s or import()s a GPL-licensed package, you have created a "derivative work" under most GPL interpretations. If you distribute that application — ship binaries, publish it for download, package it for enterprise deployment — the GPL requires the entire application be licensed under GPL.

The critical qualifier: distribution. GPL obligations trigger on distribution, not use. If you build an internal tool that never leaves your organization, GPL packages don't create public licensing obligations. If you ship software to customers, publish it, or deploy it as a product users install, distribution triggers copyleft.

What doesn't trigger GPL distribution obligations (generally):

Building a SaaS product where users access your software over the network (though see AGPL below)
Internal tools used only within your organization
Development tools (bundlers, linters, test runners) that don't ship with your product

What does trigger GPL distribution obligations:

Desktop applications distributed to users
CLI tools published to npm or distributed as binaries
Libraries published to npm (you should prefer permissive licenses for libraries)
SDK code that ships inside products

AGPL: The SaaS Trigger

AGPL was designed specifically to close the "SaaS loophole" in GPL. The AGPL network distribution clause states: if users access your software over a network (web app, API), you're "distributing" it under AGPL terms. You must make the source code of the entire application available to those users under AGPL.

This matters for npm because several popular packages are AGPL-licensed:

Some versions of certain database adapters
Several AI/ML toolkit components
Some popular data visualization libraries

One AGPL dependency in a SaaS application's production bundle potentially creates an obligation to open-source the entire application. This is why enterprise legal teams often maintain explicit AGPL blocklists.

AGPL defense options:

Find a permissively-licensed alternative
Purchase a commercial license from the package maintainer (many AGPL packages offer this)
Remove the package and implement the functionality differently

Quick Scanning: license-checker

license-checker is an npm package that audits your dependency tree and lists the license for every package:

# Scan and list all licenses
npx license-checker

# List only packages with a specific license
npx license-checker --csv > licenses.csv

# Fail if any GPL licenses are found
npx license-checker --failOn "GPL-2.0;GPL-3.0;AGPL-3.0"

# Exclude development dependencies
npx license-checker --production

The output lists every package with its license type and the path to the license file:

├─ package@1.0.0
│  ├─ licenses: MIT
│  ├─ repository: https://github.com/...
│  └─ licenseFile: node_modules/package/LICENSE
├─ another-package@2.3.1
│  ├─ licenses: AGPL-3.0
│  └─ licenseFile: node_modules/another-package/LICENSE

A CI step that fails on problematic licenses:

# .github/workflows/license-check.yml
- name: Check licenses
  run: |
    npx license-checker --production \
      --failOn "GPL-2.0;GPL-3.0;AGPL-3.0;LGPL-2.0;LGPL-2.1;LGPL-3.0" \
      --excludePackages "my-package"

The --production flag is important — it only scans packages in dependencies, not devDependencies. Build tools, test runners, and linters that are AGPL or GPL don't create obligations because they're not shipped with your product.

Enterprise Tools: FOSSA and Black Duck

For organizations with formal compliance requirements, license-checker provides visibility but lacks policy enforcement, legal review workflows, and the audit trail compliance teams need.

FOSSA

FOSSA is a software composition analysis (SCA) platform built around license compliance. It integrates with GitHub and CI systems to scan every pull request, maintain a license inventory, and enforce organizational policies.

Core capabilities:

Policy enforcement: Define allowed and prohibited licenses at the organization level. FOSSA automatically blocks PRs that introduce prohibited licenses, with customizable exception workflows for human review.

Notice generation: Automatically generate the NOTICES file required by Apache 2.0 and similar licenses, keeping it up to date as your dependency tree changes.

Legal review workflow: When a new package with a license that requires review is added, FOSSA routes it to a legal review queue rather than blocking it outright — useful for dual-licensed packages or unusual license texts.

Vulnerability correlation: FOSSA correlates license compliance data with security vulnerabilities, giving a combined SCA view.

# Install FOSSA CLI
curl -H 'Cache-Control: no-cache' https://raw.githubusercontent.com/fossas/fossa-cli/master/install-latest.sh | bash

# Run analysis
fossa analyze

# Check compliance against your policy
fossa test

FOSSA is typically priced per contributor and is aimed at enterprise teams with formal compliance requirements.

Black Duck (Synopsys)

Black Duck is one of the oldest and most comprehensive SCA tools in the market. It maintains its own knowledge base (KB) with over 5 million open-source components, covering edge cases like packages with multiple licenses or custom license text that automated parsers miss.

Where Black Duck differs from FOSSA:

Snippet scanning: Black Duck can analyze your proprietary code and identify copied snippets from open-source projects — catching cases where a developer copied GPL code directly rather than importing it as a package.

Binary analysis: Analyzes compiled binaries and container images for embedded open-source components, not just package manifests.

License conflict detection: Identifies when multiple licenses in the same project create conflicts — two packages whose licenses are incompatible with each other.

Black Duck is the tool of choice for large enterprises with complex supply chains, strict compliance audits (FedRAMP, HIPAA), and M&A due diligence requirements.

Building an Enterprise License Policy

A practical license policy for a software company in 2026:

Approved without review (green list):

MIT
ISC
BSD 2-Clause, BSD 3-Clause
Apache 2.0 (requires notice preservation)
CC0 (effectively public domain)
Unlicense

Requires legal review (yellow list):

LGPL v2, v2.1, v3 (permissible if used via standard API, not modified)
MPL 2.0 (file-level copyleft, usually manageable)
CDDL (similar to MPL)
Dual-licensed packages (need to determine which license applies)
CC BY, CC BY-SA (usually for content, not software — verify context)

Blocked without exception approval (red list):

GPL v2 (for distributed or published software)
GPL v3 (for distributed or published software)
AGPL v3 (for any SaaS or network-accessible application)
SSPL (Server Side Public License — effectively AGPL-like for infrastructure)
EUPL (can be complex, varies by version)

The yellow list requires a workflow: developer submits use case, legal reviews within a defined SLA, approved with or without conditions. Documenting these decisions creates an audit trail.

License Compatibility Between Packages

Library authors face a different compliance problem: choosing a license that's compatible with your dependencies and doesn't restrict how consumers use your package.

Key compatibility rules:

MIT and Apache 2.0 are compatible with each other and can be combined in a single project
Apache 2.0 cannot be used in GPL v2 projects (due to a specific patent clause conflict); it can be used with GPL v3
LGPL code can generally be used in Apache 2.0 and MIT projects
GPL dependencies force GPL licensing on your entire distributed package if you link against them

For npm library authors: use MIT or Apache 2.0. These licenses impose no obligations on your consumers, which maximizes adoption. Using GPL for a library means consumers who distribute their software must also GPL it — most commercial teams won't use it.

A practical licensing decision for new open-source packages:

General utility libraries: MIT
Libraries with significant corporate backing where you want patent grants: Apache 2.0
Libraries where you want to require open-source contributions in return: LGPL (use via standard API stays permissive, modifications must be shared)
Complete applications you want to keep open: AGPL (but understand it limits commercial adoption)

License Scanning in the Development Workflow

Compliance works best when it's integrated into the daily workflow, not treated as a periodic audit.

Developer IDE integration: FOSSA and some Black Duck configurations provide IDE plugins that flag license issues as packages are added to package.json, before they're committed.

Pull request gates: Both FOSSA and license-checker can be configured as required status checks on PRs. A dependency added with a prohibited license blocks merge automatically.

Dependency update PRs: When Renovate or Dependabot opens a PR to bump a package version, there's a (rare but real) risk that the new version has a different license than the old one. License scanning on update PRs catches license changes before they're silently merged.

# Add license scanning to your security workflow
- name: Check dependency licenses
  run: npx license-checker --production --failOn "GPL-2.0;GPL-3.0;AGPL-3.0"

- name: Run Snyk (vulnerability scan)
  run: npx snyk test --severity-threshold=high

For how vulnerability scanning (Snyk and Socket) integrates with the same CI pipeline, see npm Vulnerability Management: Snyk vs Socket 2026.

Notice Files and Attribution Requirements

Apache 2.0, some Creative Commons licenses, and BSD 3-Clause require preserving copyright notices and attributing contributions. For distributed software, this means including a NOTICES or ATTRIBUTIONS file.

# Generate NOTICES file automatically
npx license-checker --production --out NOTICES.txt --customFormat \
  '{"name":"","version":"","licenses":"","repository":"","copyright":""}'

Keep this file updated. FOSSA automates this — it regenerates the NOTICES file on every dependency change, keeping it accurate without manual effort.

For SaaS applications that never distribute binaries to users, attribution requirements are less clear-cut under Apache 2.0. The conservative position is to include attribution in your application's documentation or "about" page. Your legal team should have a documented stance on this.

Key Resources for License Research

When license-checker shows an unfamiliar license, or you need to understand a dual-license package's terms:

SPDX License List (spdx.org/licenses): The canonical reference for open source license identifiers and full texts
tl;drLegal (tldrlegal.com): Plain-language summaries of common licenses — "can, cannot, must" format
choosealicense.com: GitHub's license comparison tool, good for understanding license intent
OSI Approved Licenses (opensource.org/licenses): The Open Source Initiative's list of licenses that meet the Open Source Definition

For understanding which packages are gaining adoption across the npm ecosystem — useful context when evaluating whether to use a less-popular package with problematic licensing versus a well-adopted permissive alternative — see 20 Fastest-Growing npm Packages in 2026.

Methodology

This article draws on:

SPDX License List documentation and SPDX identifier standards
FOSSA documentation and platform capabilities
Synopsys Black Duck product documentation
OSI (Open Source Initiative) license definitions
npm public license distribution statistics
GitHub's choosealicense.com license explanation framework
Linux Foundation research on open-source license compliance practices
Electronic Frontier Foundation guidance on AGPL and network distribution

The 2026 JavaScript Stack Cheatsheet