License Distribution Across the npm Ecosystem 2026

TL;DR

MIT wins at ~75% of npm packages — but 15% have problematic or unclear licenses. GPL packages are rare in npm but legally viral (any project using them must also be GPL). ISC and Apache-2.0 are the safe MIT alternatives. The real risk: ~5% of packages have no license at all, making them legally ambiguous to use commercially. For production apps, run a license audit before shipping.

Key Takeaways

• MIT: ~75% — the default safe choice, permissive, widely understood
• ISC: ~10% — MIT-equivalent, Node.js core's preferred license
• Apache-2.0: ~5% — permissive but includes patent grant (good for enterprise)
• GPL/LGPL/AGPL: ~2% — viral licenses, incompatible with proprietary software
• Unlicensed: ~5% — legally "all rights reserved" by default, risky to use commercially

The License Breakdown

npm ecosystem license distribution (approximate, top 100K packages):

MIT:            ~75%  — permissive, no copyleft, free to use anywhere
ISC:            ~10%  — functionally identical to MIT (shorter text)
Apache-2.0:      ~5%  — permissive + patent termination clause
BSD-2-Clause:    ~3%  — permissive, similar to MIT
BSD-3-Clause:    ~2%  — adds non-endorsement clause
0BSD:            ~1%  — more permissive than MIT (no attribution required)
Unlicensed:      ~5%  — NO license = "all rights reserved" by default
GPL variants:    ~2%  — GPL-3.0, LGPL-2.1, AGPL-3.0 (viral)
Other:           ~2%  — WTFPL, CC0, Unlicense, custom

Key packages by license:
MIT:      React, Vue, Express, Lodash, Axios, Zod, TanStack Query, Vitest
ISC:      semver, glob, rimraf, nopt (npm team's packages)
Apache-2.0: Babel, Angular, TypeScript (Microsoft), RxJS
BSD-3-Clause: D3.js, React DevTools
GPL-2.0:  Rarely on npm (common in Linux/C world, not JS)
AGPL-3.0: Some self-hosted tools (Supabase uses it for their server)
No license: thousands of personal packages, experiments, abandoned tools

MIT's dominance at 75% of the npm ecosystem is not a historical accident — it reflects a deliberate community choice made in the early years of Node.js. The Node.js core team chose MIT for the runtime itself, and the convention propagated through the ecosystem by example. Ryan Dahl chose MIT for Node.js because it maximized adoption with minimum friction. The JavaScript community, already accustomed to permissive web standards, found MIT's terms natural: use it freely, give credit, don't hold the original author liable. The result is an ecosystem where license compatibility is rarely a concern between packages, because nearly all of them use effectively the same terms.

The 5% unlicensed figure is the largest practical concern for professional developers. These packages are not "free to use" in any legal sense — copyright attaches automatically to any creative work, and a package without a license is under "all rights reserved" by default. Courts and enterprise legal teams interpret this consistently: no license means no grant of rights, even for packages published publicly on npm. The practical risk is low for small personal tools with active maintainers who can clarify intent, but high for abandoned packages with no maintainer to contact.

The 2% GPL figure is small but concentrated in high-impact areas. While the JavaScript ecosystem itself is overwhelmingly MIT, the Linux ecosystem that runs JavaScript servers is heavily GPL. When a JavaScript tool wraps a GPL command-line utility or requires a GPL-licensed system library, the GPL implications can bleed into the JavaScript stack. This is rare in pure npm packages but real in native add-on packages that link against GPL system libraries.

MIT vs ISC: What's the Actual Difference?

MIT License:
"Permission is hereby granted, free of charge, to any person obtaining a copy..."
[150 words, explicit permission list]

ISC License:
"Permission to use, copy, modify, and/or distribute this software..."
[70 words, same permissions, shorter text]

Legal equivalence: YES — both are permissive, both require attribution.
The ISC is a simplified MIT. Node.js core uses ISC.
npm's own packages (semver, glob, rimraf) use ISC.

If you see ISC, treat it identically to MIT.
You can include ISC-licensed code in:
→ Commercial products ✅
→ Proprietary software ✅
→ SaaS products ✅
→ Modified and redistributed ✅ (keep copyright notice)

The ISC license's prevalence in the npm ecosystem reflects its origin. The Internet Systems Consortium — the organization behind BIND (DNS software) and other infrastructure — developed the license as a simplified, legally equivalent alternative to the MIT license. Node.js core adopted ISC; the npm package manager team (now part of npm Inc.) used ISC for their packages; and the pattern propagated to the packages the Node.js core team authored and maintained as side projects. semver, glob, rimraf, and nopt are all ISC because they were written by Isaac Schlueter (npm's creator) and colleagues who followed the Node.js convention.

For practical decision-making, the ISC equivalence to MIT means you can treat the two interchangeably in your license policy allow-lists. You do not need a separate approval process for ISC-licensed packages. The only material difference between ISC and MIT in practice is the brevity of the text — ISC is 70 words compared to MIT's 150 — which makes it slightly easier to include in attribution notices. Some organizations prefer ISC specifically because its shorter text reduces the NOTICE file length when listing attribution requirements for all bundled packages.

The attribution requirement in both MIT and ISC is real but lightweight: you must preserve the copyright notice when distributing software that includes MIT/ISC code. For SaaS products that don't distribute binaries, this requirement is generally interpreted as less demanding — you're not shipping a product that a customer installs, so the "distribution" trigger for attribution may not apply. For distributed software (desktop apps, CLI tools, packages you publish), including a NOTICE or LICENSE file with the attributions is the standard compliance approach.

Apache-2.0: When It Matters for Enterprise

Apache-2.0 vs MIT — one key difference:

Apache-2.0 includes an explicit patent grant:
"Each Contributor...grants to You a perpetual, worldwide...
patent license to make, have made, use, offer to sell, sell,
import, and otherwise transfer the Work."

Why enterprises care:
→ If the company that wrote the software has relevant patents,
  the Apache-2.0 license prevents them from suing you for using
  the software in the way it's designed to be used
→ MIT has no patent clause — theoretically a company could release
  MIT-licensed code and still sue you for patent infringement

In practice for npm:
→ Apache-2.0 is preferred for packages from Microsoft (TypeScript),
  Google (Angular, Firebase), Apache Software Foundation (many)
→ These organizations have large patent portfolios
→ Apache-2.0 is a safer choice when the author is a large corporation

TL;DR: Apache-2.0 ≈ MIT for most uses, but with patent protection.
Prefer it when the author is a company with patents.

The patent grant in Apache-2.0 matters more as software becomes more valuable. The MIT license's silence on patents creates a theoretical gap: a company could release MIT-licensed code and technically retain the right to sue users for patent infringement on the patented techniques the code implements. In practice, few companies do this because the legal and reputational consequences would be severe. But in high-value domains — AI model architectures, cryptography implementations, database query optimization — the theoretical risk becomes concrete enough that enterprise legal teams act on it.

Microsoft's decision to use Apache-2.0 for TypeScript reflects this reality. Microsoft holds a substantial patent portfolio that touches on programming language design and tooling. By licensing TypeScript under Apache-2.0, they explicitly grant users a patent license for using TypeScript in the way it's designed to be used. This removes a legal uncertainty that would otherwise exist for large organizations considering TypeScript adoption. The Apache-2.0 choice is a signal to enterprise buyers: "We commit not to weaponize our patents against you for using this software." Google uses Apache-2.0 for Angular for the same reason — Angular runs in many enterprise environments where Google's patent portfolio is a latent concern.

For most npm packages authored by individual developers or small teams without patent portfolios, Apache-2.0 and MIT are practically identical. The patent grant only matters when the licensor actually has relevant patents. The convention in the npm ecosystem is that individual developers use MIT (it's simpler, more familiar) and large corporate open source projects use Apache-2.0 (it provides the patent guarantee enterprise procurement teams require).

The GPL Problem

GPL licenses are "viral" (copyleft):
Using GPL code in your project makes YOUR project GPL-licensed.
You must publish your source code.

In npm, GPL is rare but real:
AGPL-3.0 (most restrictive):
→ Not only must you publish source, but ANY user of a web service
  you run gets the right to the source code
→ Supabase's self-hosted option is AGPL
→ Most npm packages explicitly avoid AGPL

LGPL-2.1/3.0 (weaker copyleft):
→ Designed for libraries — you CAN link to LGPL code without your
  code becoming LGPL
→ BUT if you modify the LGPL code itself, your modifications are LGPL
→ Safest: don't modify, treat as black box

GPL-2.0/3.0 (strong copyleft):
→ Your entire application must be GPL if you use GPL code
→ Almost no npm packages use GPL-3.0 (would kill commercial adoption)
→ WordPress PHP uses GPL — their npm packages typically use MIT/ISC

Rule: If you're building commercial/proprietary software,
scan for any GPL/AGPL packages and remove them before shipping.

GPL's rarity in the npm ecosystem is partly design and partly culture. The npm ecosystem developed alongside the web platform, which has always been built primarily on permissive licensing. Web developers deploying applications as services — rather than distributing binaries — were in an ambiguous space with GPL even before AGPL clarified the issue. The cultural expectation that npm packages would be freely usable in commercial projects became strong enough that maintainers who chose GPL for their npm packages quickly discovered adoption barriers and often changed to MIT in subsequent versions.

LGPL's design — intended to allow linking to a library without GPL infection — was primarily conceived for compiled languages where the distinction between "using" a library and "linking" it is mechanically clear. In JavaScript, where module imports are the norm and code is often bundled together before execution, the distinction between "using" and "modifying" an LGPL library is murkier. Enterprise legal teams typically treat LGPL in JavaScript with extra caution precisely because the standard LGPL rationale (dynamic linking doesn't trigger copyleft) is harder to apply. Using an LGPL JavaScript library in a bundled production build is a genuinely ambiguous question that different legal teams answer differently.

The practical advice for teams dealing with GPL variants in their dependency tree: find a MIT-licensed alternative first. The JavaScript ecosystem is large enough that for almost any utility an LGPL or GPL package provides, a permissively-licensed alternative exists. The investment in finding and migrating to an alternative is almost always lower than the legal review cost of auditing whether your specific usage pattern satisfies the LGPL exception.

The Unlicensed Package Problem

# Packages with no license field are legally "all rights reserved"
# Even if they're on npm, you technically don't have permission to use them

# How to check a package's license:
npm view package-name license
# Returns: "MIT", "ISC", "Apache-2.0", or "(none)" or undefined

# Scan your entire dependency tree for license issues:
npx license-checker --summary
# Shows: MIT: 423, ISC: 87, Apache-2.0: 23, UNKNOWN: 12

# Detailed report with all packages:
npx license-checker --csv > licenses.csv
# Opens in spreadsheet — filter for UNKNOWN and GPL

# Find unlicensed packages specifically:
npx license-checker --failOn "UNLICENSED;GPL-3.0;AGPL-3.0"
# Exits with error if any of these license types found
# Great for CI gating

# Why unlicensed packages are common:
# 1. Developer published personal tools without thinking about license
# 2. Abandoned packages created before license culture was established
# 3. Experiment packages
# 4. Copy-paste packages (author didn't realize they needed a license)

# Practical guidance:
# Well-known package, active maintainer, no license field:
# → Usually safe (courts look at intent, npm=public sharing), but risky
# → Contact maintainer, ask them to add MIT
#
# Unknown package, no license:
# → Don't use it for commercial projects
# → Find an alternative

The unlicensed package problem is most acute in transitive dependencies. A direct dependency without a license is easy to notice and address. A transitive dependency three levels deep without a license is invisible until a license audit surfaces it. The larger and older the codebase, the higher the probability that at least one transitive dependency somewhere in the tree is unlicensed.

The legal interpretation of unlicensed publicly published packages is unsettled but generally conservative. Some legal scholars argue that publishing code publicly on npm implies an intent to allow use, and that a court would consider the context. Others argue that copyright attaches automatically and without a license the author retains all rights regardless of where they published. Enterprise legal teams, operating under procurement requirements that must withstand audits, almost universally take the conservative interpretation: no license means all rights reserved.

In practice, the most common unlicensed packages fall into two categories. The first is personal tools that authors published for their own use and never thought to license — often small utilities with no documentation. The second is very old packages created before license culture developed in the JavaScript community, around 2010-2013. For the first category, the author is usually reachable and will add MIT if asked. For the second, the original author may be unreachable and the package abandoned. If the package is widely used despite being unlicensed — which does happen — the practical risk of a legal challenge is low, but the theoretical risk remains, and a formal exception process in your legal documentation is the appropriate response.

Running a License Audit

# For production apps: run before every major release

# 1. Generate full license report
npx license-checker --production --summary
# --production: skips devDependencies (tools you don't ship)
# Output:
# ├── MIT: 847
# ├── ISC: 143
# ├── Apache-2.0: 56
# ├── BSD-2-Clause: 23
# ├── UNKNOWN: 8
# └── AGPL-3.0: 1   ← FIX THIS

# 2. Find the problematic packages
npx license-checker --production --excludeLicenses "MIT;ISC;Apache-2.0;BSD-2-Clause;BSD-3-Clause;0BSD"
# Shows only packages with non-standard licenses

# 3. Check if a specific package's license is acceptable
npm view @some/package license
# Or check the package.json on npm:
npm view @some/package --json | jq '.license'

# 4. Verify the license is actually in the package (not just claimed)
npm pack @some/package --dry-run | grep -i license
# Should show a LICENSE file in the package

# 5. CI gate — fail on problematic licenses
# package.json scripts:
{
  "scripts": {
    "license:check": "license-checker --production --failOn 'GPL-3.0;AGPL-3.0;UNLICENSED'"
  }
}

The audit output from license-checker surfaces license information at the declared level — what the package's package.json claims. This is reliable for the vast majority of packages but can be incomplete in two situations. The first is packages that contain vendored code under a different license than the package itself declares. A package that declares MIT but bundles a JavaScript file copied from a GPL project has a license conflict that license-checker will not detect — it reads the declared license, not the license of every file inside the package. This is rare but real, and is why some organizations run deeper static analysis (FOSSA, Black Duck) for compliance-critical deployments.

The second situation is packages that update their license between versions. npm view package@2.x license vs npm view package@3.x license might return different results if the maintainer changed terms with a major version. Your current installation's license is what matters, and license-checker correctly reads the installed version's declared license — but your CI policy should pin or audit specific versions rather than relying on floating ranges to ensure the license you approved is the one you're running.

For teams that need to report on license compliance to enterprise customers or as part of SOC 2 evidence, the JSON output of license-checker — --json --out licenses.json — feeds cleanly into third-party SBOM generation tools and into custom reporting scripts that produce the formatted compliance documentation customers require.

Dual Licensing (Commercial + Open Source)

Some popular tools use dual licensing:

MongoDB → SSPL (Server Side Public License)
→ SSPL is more restrictive than AGPL
→ If you offer MongoDB as a service, you must open source your service
→ AWS cannot offer managed MongoDB without buying a commercial license
→ This is why AWS offers DocumentDB (compatible but not MongoDB)

Elastic (Elasticsearch) → Elastic License 2.0
→ Not OSI-approved open source
→ Cannot use to provide a competing hosted service
→ Amazon forked to OpenSearch when Elastic changed license

React → MIT (Facebook explicitly chose permissive)
→ Earlier patents rider controversy (2017) — they removed it
→ Pure MIT since 2017

What this means for npm packages:
→ Most npm packages are MIT/ISC — no dual licensing concern
→ Watch for: SSPL, Elastic License, Commons Clause
→ These look open source but restrict cloud service usage
→ npx license-checker will flag these as non-standard

Safe licenses for commercial use:
✅ MIT, ISC, Apache-2.0, BSD-2/3, 0BSD, Unlicense, CC0
❌ GPL-3.0, AGPL-3.0, SSPL, Elastic License, Commons Clause
⚠️  LGPL (OK if you don't modify it), GPL-2.0+classpath exception

The trend toward restrictive source-available licenses among commercial open source companies is the most significant licensing development in the npm-adjacent ecosystem over the past four years. MongoDB's SSPL, Elastic's Elastic License 2.0, and HashiCorp's BSL 1.1 all represent variations of the same business model: make the software free to self-host but prohibit cloud providers from offering it as a managed service without a commercial agreement. This is a direct response to hyperscalers — primarily AWS — hosting popular open source databases and tools as managed services without contributing back to the projects.

For npm packages specifically, these licenses appear primarily in packages that are clients or SDKs for the server-side software, not in the server software itself. The Elasticsearch JavaScript client, for example, uses Apache-2.0 — you can use the client freely. The server it connects to uses the Elastic License. The licensing distinction between the client library and the server product is deliberate and important: restricting the client would kill adoption of the server, which is the opposite of what the license change aims to achieve.

The practical implication for JavaScript developers: if you are building a client application or SaaS product that uses a MongoDB, Elasticsearch, or similar database as a backend dependency (not packaging and reselling the database itself), the npm packages you install are almost certainly MIT or Apache-2.0. The restrictive license applies to the binary you might self-host, not to the JavaScript library you use to communicate with it.

Recommended License Policy

# For projects:
# 1. Use MIT for your own open source packages (maximum adoption)
# 2. Use Apache-2.0 if you're a company with patents
# 3. Never use GPL for npm packages meant for wide use

# For consuming packages:
# 1. Only approve: MIT, ISC, Apache-2.0, BSD-2/3, 0BSD, Unlicense
# 2. Block: GPL-3.0, AGPL-3.0, SSPL, Elastic License, UNLICENSED
# 3. Review manually: LGPL, CC-BY (depends on use case)

# Set up automated enforcement:
# .github/workflows/license-check.yml
name: License Check
on: [push, pull_request]
jobs:
  licenses:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npx license-checker --production --failOn "GPL-3.0;AGPL-3.0;UNLICENSED;SSPL"

# For large teams: generate NOTICE file for attribution
npx license-checker --production --out NOTICE.txt
# Lists all packages + their licenses for legal compliance

The AGPL Trap for SaaS Companies

AGPL (Affero GPL) is the license most likely to catch SaaS developers off guard, and the consequences of missing it in a dependency tree are severe enough that many large organizations treat it as a hard block.

The core difference from GPL: AGPL extends the copyleft requirement to network services. Regular GPL triggers when you distribute software — if you only run software internally or as a web service, GPL doesn't force you to open source your application. AGPL closes this "network use loophole." If you run AGPL-licensed software as a service and users interact with it over a network, you must make your entire application's source code available to those users on request. This is why Google's internal open source policy explicitly prohibits AGPL dependencies — a single AGPL package in a monorepo could theoretically expose the whole codebase to the disclosure requirement.

In the npm ecosystem, AGPL appears most often in self-hosted tooling and certain infrastructure packages. Supabase's server-side components use AGPL (which is why they also offer a commercial license for companies that can't comply with AGPL). Some analytics, logging, and observability packages have adopted AGPL to prevent cloud providers from offering competing hosted services without contributing back.

The risk in practice: a transitive dependency three levels deep using AGPL is easy to miss in a manual review. You only discover it when your legal team runs a compliance audit before a funding round or acquisition.

The prevention workflow is straightforward. Add AGPL-3.0 to your license-checker deny list in CI alongside GPL-3.0 and SSPL:

npx license-checker --production --failOn "GPL-3.0;AGPL-3.0;SSPL"

The license-checker npm package reports the declared license for every package in your dependency tree, including transitive dependencies. The legally npm package offers pre-configured allow/deny lists for common use cases (commercial SaaS, internal tooling, open source projects) and runs as a drop-in CI step. Either tool, run on every pull request, prevents AGPL from accumulating unnoticed.

Running a Complete License Audit (2026 Workflow)

For codebases that haven't been audited before, the process is more involved than a single CI gate. Here's the workflow that covers both ongoing prevention and one-time remediation.

For new codebases (ongoing prevention): Add a CI step using the --onlyAllow flag, which fails the build if any dependency uses a license not on your approved list:

npx license-checker --onlyAllow 'MIT;ISC;Apache-2.0;BSD-2-Clause;BSD-3-Clause;CC0-1.0;0BSD;Unlicense' --excludePrivatePackages

The --excludePrivatePackages flag skips packages with "private": true in their package.json (your own internal packages). This command failing in CI means a new dependency introduced a non-approved license — stops the issue before it merges.

For existing codebases (one-time audit): Generate a full report for legal review:

npx license-checker --production --csv --out licenses.csv

This creates a spreadsheet with every production dependency, its version, license, and the path to the license file. Filter the CSV for UNKNOWN, GPL, AGPL, and SSPL entries — those are the packages that need either replacement or a documented exception.

The --excludePackages flag allows known exceptions with documentation: --excludePackages "some-package@1.0.0". Document each exception in your repository's LEGAL.md with the rationale.

Enterprise compliance — SBOM requirements: US federal contracts and many enterprise procurement processes now require a Software Bill of Materials (SBOM) per Executive Order 14028. The SBOM must enumerate all software components and their licenses. license-checker output in JSON format (--json --out sbom.json) can feed directly into SBOM generation tools like CycloneDX. FOSSA and Snyk both offer automated license compliance as managed services that handle SBOM generation, policy enforcement, and legal review workflows at scale — worth evaluating if your team ships to regulated industries or federal customers.

View package license data and health scores at PkgPulse.

See also: AVA vs Jest and Open Source License Compliance for npm 2026, The npm Ecosystem Is Too Fragmented (And That's OK).