Skip to main content

License Distribution Across the npm Ecosystem

·PkgPulse Team
npmlicensingopen-sourcelegaljavascript2026

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 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)

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 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.

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

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'"
  }
}

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

# 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

View package license data and health scores at PkgPulse.

See the live comparison

View npm vs. pnpm on PkgPulse →

Comments

Stay Updated

Get the latest package insights, npm trends, and tooling tips delivered to your inbox.