MIT License

The MIT License (SPDX identifier MIT, also called the Expat License) is a permissive open source license that lets anyone use, modify, sell, and sublicense code. Its one condition is that the copyright and permission notice accompany every copy. It is declared by 77% of npm packages downloaded over a million times a week, and it disclaims all warranty.

The notice condition is where the MIT License fails in practice, and it fails twice. It fails at publish time. On October 25, 2026 we opened the npm tarball of every MIT-declared package on npm's high-impact list, 12,180 in all: 1,502 ship no license file, and 19 ship a license file without the MIT grant, from LGPL-3.0 text to an "MIT License" heading with the permission paragraph deleted. It fails again at build time. A minified esbuild bundle of four MIT packages kept one of four copyright lines and none of the four permission notices. Our position: a declared MIT license is a claim, not evidence. Read the license files in the packages you install, and generate the notices you owe in your build, because no default toolchain does either.

The MIT License is a 162-word copyright grant with one condition and a warranty disclaimer. To see why it has to exist, start from the default. Copyright attaches to code the moment it is written and reserves copying, modification, and distribution to the author. Code without a license is not free to use, even in a public repository. A license is the author's written permission to do the reserved things.

The MIT License grants that permission in three paragraphs. This is the text that the SPDX License List and the Open Source Initiative publish as MIT:

MIT License

Copyright (c) <year> <copyright holders>

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "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, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

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

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

The first paragraph is the grant. It goes to "any person obtaining a copy," with no signature, registration, or fee, and it names eight rights: use, copy, modify, merge, publish, distribute, sublicense, and sell. The clause "to permit persons to whom the Software is furnished to do so" lets each recipient pass the same rights on. Permission flows to everyone downstream without anyone contacting the author.

The second paragraph is the only condition. Every copy, or every substantial portion, must carry the copyright line and the license text. The third paragraph is the disclaimer: the authors promise nothing and accept no liability.

What the MIT License leaves out matters as much as what it says. The MIT License never mentions patents, trademarks, or source code. It does not say what license your own product must use, whether you must publish changes, or whether the grant can be revoked. That silence makes it a permissive license: its conditions cover notices, never what you do with your own code. It is also why companies that care about patents choose the Apache License 2.0, which grants patent rights in writing.

The SPDX identifier MIT matches a template, not one exact string. SPDX's template marks "(including the next paragraph)" as optional text in the condition sentence, so a LICENSE file that adds those words, as the Octokit packages and seroval do, is still MIT. 22 of the packages we scanned use that wording.

The MIT License began as a notice for TCP/IP software at MIT. Jerome Saltzer, who co-drafted it, reconstructed its history in IEEE Annals of the History of Computing in 2020. In January 1984, Saltzer and Larry Allen of the MIT Laboratory for Computer Science drafted permission wording with MIT's outside attorneys. It first shipped on February 1, 1984, with PC/IP, a TCP/IP stack for the IBM PC.

A second group of attorneys reworded the notice for the X Window System, and the new wording first shipped with X Version 10 Release 3 in February 1986. Saltzer records the reasoning behind giving X such open terms: "The conclusion was that the X Window System might be more influential if adopting it could be simpler." He also names the confusion that followed: "The term 'MIT License' has been used both specifically to refer to the X10R3 license and generically."

The generic use never stopped. As of SPDX License List 3.29.0, released September 16, 2026, 15 license identifiers begin with MIT and 4 more begin with X11. Only three of the 19 are OSI-approved: MIT, MIT-0, and MIT-Modern-Variant. Two variants matter in practice.

X11 keeps the MIT grant and condition, then adds a clause: the X Consortium's name "shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Software." That clause is an extra restriction, so an X11 LICENSE file is not the license an SPDX MIT field declares.

MIT-0, the MIT No Attribution license, deletes the condition sentence. Nobody who copies MIT-0 code owes a notice.

On npm, MIT in a license field means the SPDX MIT text above. The old ambiguity survives in metadata anyway: five packages on npm's high-impact list declare MIT/X11, which is not a valid SPDX expression.

The MIT License is free for commercial use. Its grant includes the rights to "sell copies of the Software" and to "sublicense," all "free of charge." You may ship MIT code inside a closed-source product, charge for that product, and keep your changes private. You owe the authors no royalties, no source code, and no report of what you built.

Sublicensing is the right that makes closed-source distribution clean. It lets you pass MIT code to customers under your own end-user license, rather than making the MIT License their only grant. Sublicensing does not remove the condition. The copyright notice and permission notice still go wherever the MIT code goes, including inside your commercial product.

The MIT License works the same way for the author. A maintainer can release the next version under different terms, and every earlier MIT version stays MIT. ua-parser-js moved from MIT to AGPLv3 in its 2.0 release, while its 1.x line kept the MIT License. Our permissive license entry measured how often such a change lands inside a version range a project already accepts.

MIT code flows one way into copyleft projects. MIT code can be included in a GPL program, because the GPL's terms satisfy the MIT notice condition. GPL code cannot be included in an MIT-licensed program, as our copyleft license entry explains.

The disclaimer is the commercial clause people skip. "AS IS" means the author owes you no fix, no security patch, and no promise that the next release contains the code you reviewed. Every MIT dependency places that risk on the team that installs it.

The MIT License requires the copyright notice and the permission notice in "all copies or substantial portions of the Software." In practice, that means the full LICENSE text, copyright line included, for every MIT component inside whatever you hand to someone else. A desktop app, a mobile binary, a container image that customers pull, and a JavaScript bundle served to browsers all hand copies to someone else.

Most MIT packages keep their notice in exactly one place: a LICENSE file at the package root. Their source files usually carry no header. That arrangement breaks when a bundler turns hundreds of packages into one file, because bundlers copy code, not LICENSE files. esbuild keeps only what it calls legal comments: comments "that contains @license or @preserve or that starts with //! or /*!."

We bundled four MIT packages with esbuild 0.28.2's default production settings:

import ms from 'ms';                   // 2.1.3:  Copyright (c) 2020 Vercel, Inc.
import clsx from 'clsx';               // 2.1.1:  Copyright (c) Luke Edwards
import { nanoid } from 'nanoid';       // 6.0.2:  Copyright 2017 Andrey Sitnik
import { createElement } from 'react'; // 19.3.1: Copyright (c) Meta Platforms, Inc.
console.log(ms('2 days'), clsx('a', { b: true }), nanoid(), createElement('div'));

$ npx esbuild app.js --bundle --minify --format=esm --outfile=out.js
$ grep -o -i 'copyright[^*]\{0,50\}' out.js
Copyright (c) Meta Platforms, Inc. and affiliates.
$ grep -c 'Permission is hereby granted' out.js
0

The figure as text. Before bundling, each of the four packages ships a LICENSE file with its copyright line and the MIT permission notice, and React also marks its source header with @license. After esbuild --bundle --minify, the 10,800-byte out.js contains one copyright line, React's, preserved because of its @license marker. It contains none of the four permission notices, and nothing at all from the ms, clsx, or nanoid licenses.

React's surviving header still omits the MIT permission notice. It says the code "is licensed under the MIT license found in the LICENSE file in the root directory of this source tree," and the bundle includes no such file.

React is the exception, not the rule. We could locate the main entry file, the file named by main or else index.js, for 8,899 of the MIT-text packages in our scan. Only 755 of those files, 8.5%, contain any of the comment markers esbuild keeps. For the rest, a default bundle carries nothing of their notice. esbuild's --legal-comments=external option moves marked comments into a separate file. It cannot recover comments nobody marked.

The fix is a build step that reads LICENSE files rather than comments. The step walks every package that ends up in the bundle, collects each LICENSE file, and writes a third-party notices file that ships at a stable URL or behind an about screen. A software bill of materials tells you which packages went into the build, but it records a license identifier, not the notice text you owe. Socket can generate attribution data for a whole dependency set, through a package's License panel or the API, from the license and author information its analysis finds in each package's files.

The license field in package.json is a string the publisher types. The npm registry stores it per version and displays it on the package page. Neither the npm CLI nor the registry rejects a package whose field and files disagree. With npm 12.2.1, we dry-run published a package that declares MIT and ships the LGPL's title as its LICENSE file:

$ cat package.json
{"name":"mit-mismatch-demo","version":"1.0.0","license":"MIT","main":"index.js"}
$ head -1 LICENSE
GNU LESSER GENERAL PUBLIC LICENSE
$ npx npm@12.2.1 publish --dry-run
npm notice 58B LICENSE
...
+ mit-mismatch-demo@1.0.0

npm printed no warning. To see how often the field and the files disagree in real packages, we took the 15,916 packages in npm-high-impact 1.13.0's top-downloads list, each downloaded at least 1,000,000 times a week when the list was compiled. On October 25, 2026, 15,910 had a resolvable latest version. 12,234 of those, or 76.9%, declare exactly "license": "MIT". We downloaded each one's latest tarball, skipped 54 larger than 50 MB unpacked, and read every license or copying file at the package root of the remaining 12,180.

The figure's data, with the mismatches broken out by what the file actually contains:

The 1,502 packages with no license file are not obscure. 265 have platform-specific names, such as the native binary @esbuild/linux-x64. Many are monorepo packages, whose LICENSE sits at the repository root and never reaches the package directory npm publishes. @next/env, storybook, and metro all declare a monorepo subdirectory and ship without one, and so does the pnpm package itself. npm's documentation says LICENSE is always packed "regardless of settings," but only a LICENSE file that exists in the directory being packed.

The 19 mismatches are the more serious finding, because each says MIT in metadata while the file says something else or grants nothing. Four examples follow. One is keyv, whose 6.0.0 release opened the keyv and Cacheable compromise in August 2026, though its license defect is older and unrelated.

telnet-client shows the gap most plainly. The registry metadata and the file in the same tarball disagree:

$ curl -s https://registry.npmjs.org/telnet-client/2.2.14 | jq .license
"MIT"
$ npm pack telnet-client@2.2.14 && tar -xzOf telnet-client-2.2.14.tgz package/LICENSE | head -4
Copyright (c) Mario Kozjak, kozjakm1@gmail.com

node-telnet-client is an Open Source project licensed under the terms of
the LGPLv3 license. Please see <https://www.gnu.org/licenses/lgpl-3.0.html>

telnet-client's LICENSE file switched from MIT text to that LGPLv3 notice in 1.2.10, a patch release. Its README says "This library is licensed under LGPLv3." Its license field has said MIT in all 40 releases from 1.2.10 on. A scanner that reads package.json reports a permissive license. The file reports weak copyleft and a commercial upsell. Which terms govern is a question for a lawyer, and the engineering lesson is that one source of license data cannot answer it.

keyv has a quieter problem. keyv's LICENSE file kept the "MIT License" heading and lost the permission paragraph in 6.0.0-beta.4. The repository's LICENSE still reads that way as of October 2026, and @keyv/bigmap and @keyv/redis ship the same file. Without the grant, the file states a copyright and a disclaimer and permits nothing. What keyv grants now rests on its package.json field and a README line, "MIT © Jared Wray," that links to the grantless file. The other four packages in this group name MIT by heading or link, without the grant: dijkstrajs, path-platform, emoji-toolkit, and @storybook/expect, whose LICENSE file holds only its bundled dependencies' banners.

The MIT-text group has smaller defects. 69 packages ship the grant with no copyright line, so "the above copyright notice" refers to nothing. Most of them use a template that opens "This software is released under the MIT license:", including minimist. Six still contain template placeholders, such as react-responsive-carousel's Copyright (c) [year] [fullname]. And 114 contain more than one MIT grant, often because a maintainer collected bundled dependencies' notices into one file. That is the compliance behavior this entry argues for.

You can run the same check against your own node_modules. The script is deliberately minimal: it reads the license field and root license files, and it does not parse SPDX expressions.

import { readdirSync, readFileSync, existsSync } from 'node:fs';
import { join } from 'node:path';

const GRANT = /permission is hereby granted, free of charge/i;
const LIC = /^(licen[cs]e|copying)/i;

function* pkgs(dir) {
  if (!existsSync(dir)) return;
  for (const name of readdirSync(dir)) {
    if (name.startsWith('.')) continue;
    const p = join(dir, name);
    if (name.startsWith('@')) { yield* pkgs(p); continue; }
    if (existsSync(join(p, 'package.json'))) yield p;
    yield* pkgs(join(p, 'node_modules'));
  }
}

for (const dir of pkgs('node_modules')) {
  const { name, version, license } = JSON.parse(readFileSync(join(dir, 'package.json')));
  if (license !== 'MIT') continue;
  const files = readdirSync(dir).filter((f) => LIC.test(f));
  const text = files.map((f) => readFileSync(join(dir, f), 'utf8')).join('\n');
  if (!files.length) console.log(`${name}@${version}: declares MIT, ships no license file`);
  else if (!GRANT.test(text.replace(/\s+/g, ' '))) console.log(`${name}@${version}: declares MIT, ${files.join(', ')} has no MIT grant`);
}

$ node check-mit.mjs
@esbuild/linux-x64@0.28.2: declares MIT, ships no license file
@pkgjs/parseargs@0.11.0: declares MIT, LICENSE has no MIT grant
imurmurhash@0.1.4: declares MIT, ships no license file
stream@0.0.2: declares MIT, ships no license file
telnet-client@2.2.14: declares MIT, LICENSE has no MIT grant

A real tool has to go much further, because license data also hides in source headers, README files, nested directories, and vendored code. Socket's license analysis reads license, copyright, and attribution data from every file in a package rather than the manifest alone. Its License panel shows each license it found and where it found it. Those are exactly the cases above, where the manifest says one thing and the files say another. A license compliance program built on the manifest alone approves code it has not read.

The MIT License competes with its own variants and with the Apache License 2.0. Counts are latest versions on npm's high-impact list that declare exactly that expression, with the dual license counted in either order.

Our verdict: use MIT for small libraries, where an express patent grant costs more ceremony than it is worth. Use MIT-0 for snippets, templates, and helpers that end up inside other people's builds, because nobody should have to ship a notice for a ten-line function. Use MIT OR Apache-2.0 for a widely embedded library from an organization that holds patents. Avoid X11 and the other variants for new code, because they read as MIT to people and behave differently in policy engines. Whichever you choose, put the LICENSE file in the directory you publish, with your copyright line filled in.

The npm registry accepts any string in the license field. In our sample, froala-editor 5.5.0 declares the license https://www.froala.com/wysiwyg-editor/pricing, five packages declare MIT/X11, and npm 12.2.1 prepared a package declaring MIT with an LGPL LICENSE file without a warning. A registry that detected the license in each tarball's files, and showed it next to the declared one, would surface all 19 of our mismatches on the package page. A publish-time warning would stop most of them from shipping at all.

Bundlers have the same blind spot one layer later. A bundler already knows every package that goes into a bundle, and it keeps only the comments a maintainer remembered to mark. A bundler that treated each package's LICENSE file as a build input, the way it treats imported CSS, would satisfy the MIT condition by default. Until registries and bundlers do this, the most common license on npm runs on an honor system: a metadata field nobody verifies, and a one-sentence condition that a default production build does not meet.