# Permissive License

> A permissive license lets anyone use, modify, and redistribute code, even in closed-source products, usually requiring only that its notice be kept.

Also known as: non-copyleft license, BSD-style license, permissive open source license, permissive software license

Source: https://socket.dev/glossary/permissive-license

Last updated: 2026-10-25

A permissive license (also called a non-copyleft or BSD-style license) is an open source license that lets anyone use, modify, and redistribute code, even in closed-source products, without sharing their own source. Its usual condition is keeping the copyright and license notice. As of October 2026, permissive licenses cover 96.7% of high-impact npm packages.

MIT, Apache 2.0, ISC, and the BSD licenses are the common permissive licenses. Permissive is a property of one release, not of a package. In our October 2026 scan of 17,125 high-impact npm packages, 74 have shipped a release that moved from a permissive license to copyleft, source-available, or `UNLICENSED` terms. Twenty-six made that move inside a single major version, where an ordinary caret range picks it up with no change on your side. We think a license change is a breaking change, and dependency tooling should treat it as one.

## What is a permissive open source license?

A permissive open source license is a copyright grant whose conditions cover notices and liability, never what you do with your own code.

Start from the default. Code is copyrighted the moment it is written, and copyright law reserves copying, modification, and distribution to the author. Code with no license is not free to use; it is all rights reserved. A license is the author's written permission to do those reserved things, usually with conditions attached.

The [MIT License](https://socket.dev/glossary/mit-license) shows the whole mechanism in two sentences. The grant:

```text
Permission is hereby granted, free of charge, to any person obtaining a copy of this
software [...] to deal in the Software without restriction, including without limitation
the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software [...] subject to the following conditions:
```

And the only condition:

```text
The above copyright notice and this permission notice shall be included in all copies
or substantial portions of the Software.
```

The rest of the file is a warranty disclaimer. Nothing in the MIT License says what license your product must use, whether you must publish your changes, or whether you may charge for the result. That absence is what makes a license permissive.

A [copyleft license](https://socket.dev/glossary/copyleft-license) adds one more condition. If you distribute a modified version or a combined work, you must offer it under the same license, with source. The GNU General Public License (GPL) is the best-known example. Permissive licenses impose no such condition, so permissively licensed code can end up inside proprietary software. That outcome is intended, not a loophole.

The word itself is contested. The Open Source Initiative (OSI) FAQ says ["All Open Source licenses are permissive!"](https://opensource.org/faq) and warns that using "permissive" as the opposite of copyleft "misrepresents copyleft conditions as restrictions." "Non-copyleft" is the more precise term. We use "permissive" because engineers, legal teams, and license tools such as the [Blue Oak Council list](https://blueoakcouncil.org/list) use it for this category.

Two near misses cause real confusion. A package with no license file is not permissive, even when its code sits in a public repository. On npm, `"license": "UNLICENSED"` means the opposite of `"license": "Unlicense"`. npm's documentation reserves `UNLICENSED` for packages whose authors do not grant anyone the right to use them under any terms. The Unlicense is a public-domain dedication. One letter separates the most restrictive declaration from one of the most permissive.

## What does a permissive license require?

A permissive license requires you to keep its notices when you redistribute the code, and little else.

The conditions trigger on distribution. Running MIT code on your own servers distributes nothing, so the notice condition never applies. Shipping it in a mobile app, a desktop binary, a container image you hand to customers, or a JavaScript bundle served to browsers does distribute it. Each copy you ship must carry the notice.

The licenses differ in the details:

| License | What redistribution requires | Explicit patent grant |
| --- | --- | --- |
| MIT, ISC | Keep the copyright notice and permission notice | No |
| BSD-2-Clause | Keep the notice in source; reproduce it in binary documentation | No |
| BSD-3-Clause | BSD-2-Clause, plus no use of the authors' names to endorse your product | No |
| Apache-2.0 | Keep notices and the NOTICE file, mark files you changed | Yes; it ends if you file a patent suit over the work |
| BlueOak-1.0.0 | Give recipients the license text or a link to it | Yes |
| 0BSD, MIT-0 | Nothing | No |

Patents are the largest gap in the short licenses. MIT, ISC, and BSD grant copyright permissions and say nothing about patents. Whether they carry an implied patent license is a question for courts, not for the license text. The [Apache License 2.0](https://socket.dev/glossary/apache-license-2-0) and the Blue Oak Model License grant patent rights in writing. Apache adds a defensive clause: if you sue anyone claiming the work infringes a patent, every patent license you received under Apache for that work ends.

Revocation follows the same split. Apache's copyright grant is "perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable." The Blue Oak Model License says ["No contributor can revoke this license."](https://blueoakcouncil.org/license/1.0.0) MIT, ISC, and BSD contain neither word. In practice, a copy you received under MIT stays usable under MIT after the author relicenses later versions, but the MIT text does not say so.

Permissive code flows one way into copyleft projects. MIT, ISC, and BSD-2-Clause or BSD-3-Clause code can be included in a GPL program, because their conditions fit inside the GPL's. Two exceptions catch people. Apache-2.0 is compatible with GPLv3 but not GPLv2. The original four-clause BSD license requires advertising materials that mention the software to display an acknowledgment, an added restriction the GPL does not allow.

The notice condition is also the one that breaks most often in practice. Bundlers and minifiers strip comments, and many packages publish without a LICENSE file. Our Apache License 2.0 entry measured how notices disappear between a repository, an npm tarball, and a production bundle. The same loss applies to every permissive license that requires a notice.

## What is the most permissive open source license?

The most permissive OSI-approved licenses are 0BSD and MIT-0, which grant broad copyright permissions and impose no conditions, not even keeping a notice.

The Zero-Clause BSD license (0BSD) is the ISC license with its one condition deleted. MIT-0 is the MIT License with its condition sentence deleted. Both keep the warranty disclaimer, and both are OSI-approved, which makes them easy to clear with legal teams.

The public-domain dedications look even more permissive and carry more risk. The Unlicense dedicates the work to the public domain and falls back to a license where dedication is not possible. CC0-1.0 does the same, but its Section 4(a) states: "No trademark or patent rights held by Affirmer are waived, abandoned, surrendered, licensed or otherwise affected by this document." The OSI's License Review Committee could not reach consensus on CC0, and Creative Commons withdrew its application. The OSI FAQ recommends against releasing software under CC0. In July 2022, Fedora stopped allowing CC0 for code. Fedora legal's Richard Fontana wrote that ["licenses that preclude any form of patent licensing or patent forbearance cannot be considered FOSS."](https://lwn.net/Articles/902410)

WTFPL grants everything in one profane sentence. It is not OSI-approved, and the Blue Oak Council rates it Lead, its lowest tier.

The Blue Oak Council ranks permissive licenses by quality, and its ranking inverts the "fewest conditions" ranking. Blue Oak rates its own license Model and BSD-2-Clause-Patent Gold, because Gold licenses "address patents explicitly, use robust language, and require only simple notice of license terms and copyright notices." MIT, ISC, Apache-2.0, and BSD-2-Clause are Silver. 0BSD, MIT-0, the Unlicense, CC0-1.0, and BSD-3-Clause are Bronze. Fewer conditions do not make a better license when the text is silent on patents.

| License | Conditions | Patent grant | OSI-approved | Blue Oak tier (list v16) | High-impact npm packages |
| --- | --- | --- | --- | --- | --- |
| 0BSD | None | No | Yes | Bronze | 5 |
| MIT-0 | None | No | Yes | Bronze | 75 |
| Unlicense | None (public-domain dedication) | No | Yes | Bronze | 32 |
| CC0-1.0 | None (public-domain dedication) | Expressly withheld | No | Bronze | 30 |
| WTFPL | None | No | No | Lead | 10 |
| MIT | Keep notice | No | Yes | Silver | 13,318 |
| ISC | Keep notice | No | Yes | Silver | 564 |
| BSD-3-Clause | Keep notice, no endorsement | No | Yes | Bronze | 344 |
| Apache-2.0 | Keep notices and NOTICE, mark changes | Yes | Yes | Silver | 1,882 |
| BlueOak-1.0.0 | License text or link | Yes | Yes | Model | 24 |

Counts are packages whose latest version declares only that license, from our October 2026 npm scan.

Our verdict: use 0BSD or MIT-0 for code nobody should have to attribute, such as runtime helpers that end up inside other people's builds. TypeScript's `tslib` has been 0BSD since version 1.11.2 in May 2020; code compiled with TypeScript's `importHelpers` option calls into it at runtime. Use Apache-2.0 or BlueOak-1.0.0 for a library that will be embedded widely and might touch patents. `glob`, `minimatch`, `lru-cache`, and `tar` moved from ISC to BlueOak-1.0.0 in October and November 2025. MIT and ISC remain fine for small libraries. Do not use CC0 or WTFPL for code.

## How common are permissive licenses?

Permissive licenses are the default for open source packages: 96.7% of high-impact npm packages, 99.0% of the top 1,000 crates, and 91.9% of the top 1,000 PyPI projects declare one.

We measured this on October 25, 2026. For npm, we fetched full registry metadata for every package in [npm-high-impact](https://github.com/wooorm/npm-high-impact) 1.13.0, which lists packages npm itself classifies as high-impact: 1 million weekly downloads or 500 dependents. Of its 17,338 names, 17,125 had a resolvable latest version. For crates.io we took the top 1,000 crates by all-time downloads. For PyPI we took the top 1,000 projects in Hugo van Kemenade's top-pypi-packages snapshot of October 1, 2026. We parsed each declared license as an [SPDX](https://socket.dev/glossary/spdx) expression and classified it with the Blue Oak Council's permissive and copyleft lists. An `OR` expression counts as permissive when at least one choice is entirely permissive.

| Registry | Sample | Permissive | Copyleft | Source-available or proprietary | Other, unclear, or missing |
| --- | --- | --- | --- | --- | --- |
| npm | 17,125 high-impact packages | 16,564 (96.7%) | 142 (0.8%) | 37 (0.2%) | 382 (2.2%) |
| crates.io | Top 1,000 by downloads | 990 (99.0%) | 7 (0.7%) | 0 | 3 (0.3%) |
| PyPI | Top 1,000 by downloads | 919 (91.9%) | 35 (3.5%) | 19 (1.9%) | 27 (2.7%) |

MIT dominates npm. It is the sole declared license of 13,318 high-impact packages, 77.8% of the sample. Apache-2.0 follows with 1,882, then ISC with 564, BSD-3-Clause with 344, and BSD-2-Clause with 145. Another 115 declare a compound expression such as `MIT OR Apache-2.0`. On npm, the last column holds 176 `SEE LICENSE IN` pointers, 158 packages with no license field, 47 free-text strings, and one `UNLICENSED`. On crates.io, two of the three are CDLA-Permissive-2.0, a data license the Blue Oak list does not rate.

Rust has standardized on dual licensing. Of the top 1,000 crates, 587 declare `MIT OR Apache-2.0` or `Apache-2.0 OR MIT`, which lets each user pick the license that fits. All seven copyleft crates use the Mozilla Public License 2.0 (MPL-2.0).

PyPI's numbers carry the most uncertainty, because Python license metadata is the messiest. Only 400 of the top 1,000 projects declare a `License-Expression` as defined in [PEP 639](https://peps.python.org/pep-0639/). Another 427 rely on a short free-text `License` field, 146 on Trove classifiers, and 27 declare nothing we could parse. Sixty rely on the classifier `License :: OSI Approved :: BSD License`, which does not say which BSD license applies. PEP 639 deprecates license classifiers in favor of the "more precise" `License-Expression` field. The 19 proprietary entries are NVIDIA CUDA wheels declared as `LicenseRef-NVIDIA-Proprietary`, which PyTorch lists as dependencies on Linux.

The non-permissive packages at the top of npm show why a license category is not a verdict. `caniuse-lite`, which nearly every frontend build pulls in through Browserslist, declares CC-BY-4.0, a Creative Commons attribution license written for data and media. `react-leaflet` declares Hippocratic-2.1, an ethical-use license that restricts what users may do with the software. Neither is permissive by the Blue Oak definition, and both deserve a human decision rather than an automatic block.

## A permissive license covers one release, not the package

A license attaches to each published version, so a permissive dependency can become non-permissive in its next release.

The registry stores a `license` value per version, and a version range ignores it. `^2.57.0` means any 2.x release at or above 2.57.0. When a maintainer publishes 2.58.3 under new terms, every fresh install that resolves that range gets the new terms. [Semantic versioning](https://socket.dev/glossary/semantic-versioning-semver) has no rule that a license change requires a new major version.

We checked every stable release of the 17,125 high-impact npm packages for that pattern. Seventy-four packages have at least one release where the declared license moved from permissive to copyleft (47 transitions), source-available (24), or `UNLICENSED` (6). Twenty-six of those moves happened inside a major version above 0, where caret ranges follow them; nine of the 26 are `@sentry/cli` and its platform-specific binary packages. Thirty-six of the 74 packages are still non-permissive in their latest release. Twenty-four of the 77 moves happened in 2025, more than in any earlier year.

A new major version is the honest way to relicense. [The ua-parser-js relicense](https://socket.dev/blog/ua-parser-js-drops-mit-license) kept 1.x under MIT and shipped AGPL-3.0 only in 2.0.0, so `^1` ranges never crossed it. The two cases below did not work that way.

> Two relicenses that ordinary caret ranges followed. Shaded releases declare copyleft or source-available terms. The split segment shows iframe-resizer 4.4.x releases whose package.json and LICENSE file disagree.

For `@sentry/cli`, releases 2.57.0 through 2.58.2 declare BSD-3-Clause. Releases 2.58.3 (December 10, 2025) through 2.58.6, and every 3.x release, declare FSL-1.1-MIT. The range `^2.57.0`, declared by `@sentry/bundler-plugin-core` 4.6.1 on November 20, 2025, covers 2.57.0 through 2.58.6 and resolves to 2.58.6 on a fresh install. For `iframe-resizer`, 4.3.11 (April 22, 2024) declares MIT. Releases 4.4.0 through 4.4.4 (May 17 to July 4, 2024) declare GPL-3.0 in `package.json` while shipping an MIT LICENSE file. Release 4.4.5 (July 10, 2024) declares MIT and ships no LICENSE file. Releases 5.2.3 and later declare GPL-3.0. The range `^4.3.0` resolved to a release with GPL-3.0 metadata for 54 days, then back to MIT.

### @sentry/cli: a patch release to the Functional Source License

`@sentry/cli` 2.58.2, published November 12, 2025, is BSD-3-Clause in both `package.json` and its LICENSE file. Version 2.58.3, published December 10, 2025, is `FSL-1.1-MIT` in both. The [2.58.3 changelog](https://github.com/getsentry/sentry-cli/blob/master/CHANGELOG.md) lists two improvements and a sourcemap fix, and does not mention the license. The npm API reports [17,854,548 downloads](https://api.npmjs.org/downloads/point/last-week/@sentry/cli) of `@sentry/cli` in the week of October 16 to 22, 2026.

The Functional Source License (FSL) is source-available, not open source. It permits any purpose other than a "Competing Use," defined as offering the software in a commercial product or service that substitutes for it, substitutes for another Sentry product, or offers substantially similar functionality. Each release converts to the MIT License two years after its publication date. Internal use is explicitly permitted, so most Sentry customers are unaffected in practice. A permissive-only policy is affected: FSL-1.1-MIT is not OSI-approved, and the two-year clock restarts with every release you upgrade to.

An `npm update` crosses the change without comment. With npm 12.2.1, starting from a lockfile at 2.58.2 and a `^2.58.2` range:

```bash
$ jq -r '.packages["node_modules/@sentry/cli"] | .version + " " + .license' package-lock.json
2.58.2 BSD-3-Clause
$ npm update --ignore-scripts
changed 2 packages in 823ms
$ jq -r '.packages["node_modules/@sentry/cli"] | .version + " " + .license' package-lock.json
2.58.6 FSL-1.1-MIT
```

The change also reaches projects that never chose it. `@sentry/bundler-plugin-core` 4.6.1 declares `"@sentry/cli": "^2.57.0"` and was published when every matching release was BSD-3-Clause. Installing it today:

```bash
$ npm install @sentry/bundler-plugin-core@4.6.1 --ignore-scripts
$ npm ls @sentry/cli
demo@1.0.0
`-- @sentry/bundler-plugin-core@4.6.1
  `-- @sentry/cli@2.58.6
$ npm query '[license=FSL-1.1-MIT]' | jq -r '.[] | "\(.name)@\(.version)"'
@sentry/cli@2.58.6
@sentry/cli-linux-x64@2.58.6
```

The [lockfile](https://socket.dev/glossary/lockfile) is where a reviewer can catch it, because npm records each package's declared license there:

```json
"node_modules/@sentry/cli": {
  "version": "2.58.6",
  "resolved": "https://registry.npmjs.org/@sentry/cli/-/cli-2.58.6.tgz",
  "license": "FSL-1.1-MIT",
  "hasInstallScript": true
}
```

A project whose lockfile resolved 2.58.2 before December 10, 2025 still installs BSD-3-Clause code with `npm ci`. Lockfiles make existing installs deterministic; they do not freeze what the next resolution picks. The license changes at the next `npm update`, the next automated dependency bump, or the next install without the lockfile. It arrives as a [transitive dependency](https://socket.dev/glossary/transitive-dependency) that nobody in the project added by name.

### iframe-resizer: the metadata changed, the code did not

`iframe-resizer` 4.3.11, published April 22, 2024, declares MIT. Version 4.4.0, published May 17, 2024, declares `GPL-3.0` in `package.json`. Its tarball still ships the same MIT LICENSE file, its minified files still carry a `License: MIT` banner, and `js/iframeResizer.js` is byte-identical to the 4.3.11 file (SHA-256 `407bf2cb…0800e4`). Four more releases through 4.4.4 kept the GPL-3.0 metadata and the MIT file. Version 4.4.5, published July 10, 2024, declares MIT again and ships no LICENSE file at all. Releases from 5.2.3 onward declare GPL-3.0, with a commercial license sold separately.

For 54 days, from May 17 to July 10, 2024, a fresh install of `iframe-resizer@^4.3.0` resolved to a release whose metadata said GPL-3.0 and whose files said MIT. A scanner that reads `package.json` reports copyleft. A scanner that reads the LICENSE file reports MIT. On [issue #1265](https://github.com/davidjbradshaw/iframe-resizer/issues/1265), titled "License changed from MIT to GPL," the maintainer answered that the project is now dual licensed under the GPL or a commercial license. Which terms govern byte-identical code first released under MIT is a question for your lawyer. The engineering lesson is that one source of license data is not enough. The companion package `iframe-resizer-react` followed the same arc: 1.0.10 MIT, 1.0.11 GPL-3.0 on the same day, and MIT again in 1.0.13 on June 10, 2024.

Relicensing away from permissive terms is not new. [Redis's license change](https://socket.dev/blog/redis-license-shift-splits-community) in March 2024 moved Redis 7.4 and later from BSD-3-Clause to the source-available RSALv2 and SSPLv1, and contributors responded with [the Valkey fork](https://socket.dev/blog/valkey-open-source-redis-fork-backed-by-linux-foundation-aws). [The Elasticsearch license change](https://socket.dev/blog/developers-burned-by-elasticsearch-license-change-arent-going-back) in 2021 moved Elasticsearch from Apache-2.0 to the SSPL and the Elastic License, before Elastic announced in 2024 that it would add the AGPL as a third option. In each case, releases published earlier kept their permissive license. What the npm data adds is frequency, and how often the change lands in a release that version ranges treat as compatible.

## Enforcing a permissive-only policy

A permissive-only policy is an allowlist of licenses, evaluated against every resolved version of every dependency, every time resolution changes.

Each part of that definition is a place where real policies fail.

**Evaluate expressions, not strings.** `jszip` declares `MIT OR GPL-3.0-or-later`, and `dompurify` declares `MPL-2.0 OR Apache-2.0`. Both are usable under permissive terms, because `OR` gives you the choice. `pako` declares `MIT AND Zlib`, and you must satisfy both. A policy that blocks any expression containing a copyleft identifier blocks `jszip` for no reason. A policy that checks only the first identifier misses half of every `AND`.

**Check every resolution change, not just new dependencies.** The `@sentry/cli` and `iframe-resizer` cases never added a dependency. Each changed the license of an existing one inside its declared range. The check belongs on every pull request that changes the lockfile, including automated version bumps. Permissive-to-permissive changes count too: `tar` moved from ISC to BlueOak-1.0.0 in patch release 7.5.2, and a policy that allows only MIT, ISC, Apache-2.0, and BSD flags it.

**Read the files, not only the metadata.** `iframe-resizer` 4.4.0 shows metadata and files disagreeing in one direction. The other direction is more common: we found [Django 5.1.1](https://socket.dev/blog/socket-license-analysis) shipping seven licenses across ten license files, including a CC-BY-SA-4.0 file that PyPI's BSD-3-Clause listing does not show.

**Expect human review.** `caniuse-lite` is CC-BY-4.0, font packages such as `@fontsource/inter` are OFL-1.1, and `@sentry/cli` is FSL-1.1-MIT. None is permissive by the Blue Oak definition, and each is acceptable for many products. A policy without an exception path gets switched off.

Socket implements this as a [license policy](https://docs.socket.dev/docs/license-policy) built on the Blue Oak tiers. A team allows or denies whole tiers or individual licenses, and violations appear on the pull request with Block, Warn, or Monitor actions. The [Non-permissive License alert](https://socket.dev/alerts/nonpermissiveLicense) is not emitted when a package's `OR` expression offers a combination that avoids non-permissive licenses. When a reviewer accepts a license by hand, a [license overlay](https://socket.dev/blog/introducing-license-overlays) records the decision. Overlays do not apply to future versions by default, and an overlay is ignored when the license file it covers changes, because packages do change their terms. None of this replaces [license compliance](https://socket.dev/glossary/license-compliance) work. A dependency tree that is entirely permissive still owes every notice its licenses require when you ship it.

## Semver has no place for a license change

Registries and package managers treat a license as package metadata, and treat metadata changes as non-events. In our test, `npm update` printed "changed 2 packages" as it moved a dependency from BSD-3-Clause to a source-available license. npm caret ranges, Cargo's default caret requirements, and PEP 440's `~=` operator all accept a relicensed patch release as compatible. Every one of the 26 same-major transitions we found was a valid update under those rules.

A license change alters what you are allowed to do with the code, which makes it a breaking change by any reasonable definition. Until registries show license diffs between versions and package managers stop crossing them silently, the reliable control is the one you run yourself: compare the license of every version you resolve against the one you approved.