MIT License

The MIT License is a short, permissive software license. It grants broad permission to use, copy, modify, merge, publish, distribute, sublicense, and sell covered software, subject to one express preservation condition: copies or substantial portions must include the copyright notice and permission notice. The text also supplies an "as is" warranty disclaimer and limitation-of-liability language.^[1] The Open Source Initiative (OSI) lists the license as approved, and the SPDX License List assigns it the identifier MIT.^[1][2]

The license is noncopyleft.^[5] A distributor may place a larger work, including a proprietary work, under different terms, but the MIT notice must remain with the copied MIT-licensed material when the license's preservation condition applies. The license does not require publication of source code, use of the same license for modifications, or a notice identifying changed files.^[1] Its brevity also means that it lacks the detailed patent, trademark, contribution, and NOTICE-file provisions found in some longer licenses.^[1][10] These distinctions make the exact license text, not just an informal label such as "permissive," important when evaluating a project.

Overview

Scroll sideways for more →

This table summarizes the standard text published by OSI and SPDX.^[1][2] It is not a substitute for reading the notice that accompanies a particular copy. Projects can contain third-party files, generated artifacts, datasets, model weights, documentation, or other components under different terms.

Name and scope

MIT, Expat, and X11

"MIT License" has both a standardized modern meaning and a historically broader use. SPDX uses MIT for the short license text reproduced by OSI.^[1][2] The Free Software Foundation calls that text the Expat License, classifies it as a permissive noncopyleft free-software license, and considers it compatible with the GNU GPL. The foundation also warns that the name "MIT License" has been used for more than one text.^[5]

The ambiguity is most visible in comparisons with the X11 License. The SPDX X11 entry contains the MIT-style permission grant, notice condition, and disclaimer, followed by an additional restriction on using the X Consortium's name in advertising or promotion. Its template can also contain a sentence identifying X Window System as a trademark.^[6] That makes X11 a related but distinct license, not an interchangeable spelling of MIT. The distinction matters when software from the X Window System lineage is identified or redistributed.

MIT-0, whose SPDX name is "MIT No Attribution," is another distinct text. It retains the broad permission grant and disclaimer but omits the paragraph requiring preservation of the copyright and permission notices.^[7] A project marked MIT-0 should therefore not be silently normalized to MIT, and an ordinary MIT notice should not be shortened to MIT-0 terms without authorization from the relevant rightsholder.

What the license covers

The standard grant refers to "this software and associated documentation files" and defines that material as the "Software."^[1] In a repository, however, the practical scope is established by the license notice, file placement, package metadata, copyright notices, and any documented exceptions. A top-level MIT file may be intended to cover the repository's original code, but that fact alone does not prove that every bundled dependency, font, image, dataset, model parameter, or vendor file is under MIT.

The SPDX matching template recognizes limited replaceable or optional text, including the copyright line and certain wording variations.^[2] Those matching rules help identify equivalent license texts. They do not authorize a recipient to rewrite substantive conditions or to assume that any short permissive notice is MIT.

History

The modern MIT family emerged from software distribution practices at the Massachusetts Institute of Technology rather than from a single legislative or standards process. Jerome H. Saltzer's 2020 account in IEEE Annals of the History of Computing traces an early form to the Computer Systems Research Group at the MIT Laboratory for Computer Science. In fall 1983, the group was receiving requests for networking software from university and commercial users and was deciding whether to require contracts or fees.^[3]

Saltzer and Larry Allen drafted proposed language in January 1984 after discussions with MIT's outside attorneys. Saltzer described four guiding principles:

1. permission for any purpose, including commercial use;
2. no signed agreement or license fee;
3. redistribution rules covering credit, retention of the notice, and restrictions on promotional use of MIT's name; and
4. distribution of the software without warranty.^[3]

After legal review, the refined notice was first used for the February 1, 1984 distribution of the PC/IP networking software. Saltzer described it as probably the first notice appropriately identified as an "MIT License." A scan preserved by MIT shows the contemporaneous copyright and permission notice used with that distribution.^[3][4]

A related drafting process took place for the X Window System. Saltzer reports that a reworded notice was first applied to X Window System Version 10 Release 3 in February 1986. He characterized it as a second version in the license family. Later organizations adopted many variants, while the label "MIT License" was used both for particular texts and for permissive notices with shared ancestry.^[3] The present SPDX identifiers MIT, X11, and MIT-0 provide a way to distinguish three of those texts precisely.^[2][6][7]

Permission grant and condition

Rights granted

The operative grant is deliberately broad. It covers dealing in the software "without restriction" and then gives a nonexclusive list of activities: use, copying, modification, merging, publication, distribution, sublicensing, and sale. It also permits recipients to authorize other people to exercise the same permissions.^[1][2]

Several practical consequences follow directly from that wording:

• Commercial use and sale are permitted.
• Modified and unmodified copies may be distributed.
• The software may be combined with code under other terms.
• A recipient may grant downstream permissions within the scope of the MIT grant.
• The license does not reserve use to research, education, nonprofit activity, or a particular field.

These are copyright permissions. They do not establish ownership of unrelated project names, trademarks, data, patents, or third-party material. They also do not erase requirements imposed by another license that applies to a different component of the same distribution.

Notice preservation

The grant is expressly "subject to" a condition. The copyright notice and permission notice must be included in "all copies or substantial portions" of the software.^[1] The standard text does not prescribe a single filename, screen, or physical location for the notice. Common implementations include a LICENSE file in source distributions and a third-party notices document or accompanying documentation in binary distributions, but the adequacy of any implementation depends on the material distributed and the governing law.

The condition applies when copying or distributing covered material, including substantial portions. The standard text does not define "substantial." That makes a bright-line rule based only on line count or percentage unsupported. A compliance review should identify the actual copied material and preserve the notice conservatively rather than rely on an invented numerical threshold.

The condition does not say that every source file must contain the full license. SPDX in fact reports that there is no standard MIT license header.^[2] File-level identifiers can improve traceability, but a tool-specific header convention should not be confused with an additional term of the license.

Disclaimer

The final paragraph supplies the license's warranty disclaimer and limitation-of-liability language. It says the software is provided "as is," disclaims express and implied warranties including merchantability, fitness for a particular purpose, and noninfringement, and states that the authors or copyright holders are not liable under the listed theories for claims or damages connected with the software.^[1]

The text should be described as a disclaimer, not as a guarantee that no claim can ever succeed. The legal effect of disclaimer language can depend on jurisdiction, consumer-protection rules, the facts of a transaction, and separate agreements. The MIT License also permits parties to negotiate or enter other agreements; it does not prevent a vendor from separately offering support, indemnity, or warranties.

Redistribution and larger works

The MIT License is often described as allowing proprietary redistribution. More precisely, it does not impose a same-license rule on a larger work or require disclosure of corresponding source. A distributor can apply different terms to its own additions while continuing to satisfy the MIT notice condition for the copied MIT material.^[1]

This distinction separates license of the component from license of the whole distribution:

• The original MIT-covered portion remains available under the permissions granted by its rightsholder.
• New code can carry different terms if the distributor has authority to choose them.
• A recipient's separate terms for a larger distribution do not replace the MIT notice or its permission grant for the MIT-covered material.
• Notices and obligations for other included components remain separate.
• Merely announcing that an entire product is "MIT licensed" is unreliable when some components have exceptions or different licenses.

The MIT text does not require a distributor to mark modified files, publish modification history, provide installation information, or make source code available. A project can request those practices through contribution rules or documentation, but requests outside the license text are not automatically MIT conditions.

The absence of a license is not equivalent to MIT permission. In the United States, the Copyright Office states that copyright protection attaches automatically to qualifying original works and that computer software is among the protected categories.^[29] Statutory limitations and exceptions still apply, but public access to a repository by itself does not supply the broad rights listed in the MIT grant.

Comparison with related licenses

Scroll sideways for more →

These rows compare the published texts, not every compatibility scenario. Whether two components form one derivative work, an aggregate, or separate programs can be fact-dependent. Version-specific terms and license exceptions can also change the analysis.

Compatibility and relicensing

The Free Software Foundation lists the Expat text, its name for the standard MIT License, as compatible with the GNU GPL.^[5] Its broader compatibility framework says lax permissive licenses such as X11, Expat, and Apache 2.0 are generally compatible with one another and usually with copyleft licenses. It identifies Apache 2.0 as incompatible with GPL version 2 because of its patent clauses, but compatible with GPL version 3. In a combined program, the permissively licensed parts retain their licenses while the program as a whole can carry the applicable copyleft license.^[12]

Compatibility does not mean that the source license vanishes or that every work can be freely "relicensed" by a recipient. The foundation distinguishes compatibility from relicensing and notes that relicensing permission can be asymmetric.^[12] A recipient can distribute a combined or modified work under terms that satisfy all applicable grants, but an independent new license for the original material requires authority from the relevant rightsholder. If a project has many contributors, changing the license for the original contributions may require authority from each relevant rightsholder or another established legal mechanism.

Dual licensing is different again. An expression such as MIT OR Apache-2.0 offers a choice, while MIT AND Apache-2.0 says both sets of terms apply. SPDX defines OR, AND, WITH, and the version suffix operators so software metadata can represent these relationships without relying on informal punctuation.^[13]

Patent, trademark, and contributor issues

The standard MIT text does not contain a section expressly granting patent rights. It also has no patent-litigation termination clause. By contrast, Apache License 2.0 grants a patent license from each contributor for specified claims necessarily infringed by the contribution or its combination with the work, and terminates certain patent licenses when specified litigation is filed.^[10] This textual difference is one reason the licenses should not be treated as interchangeable.

Silence is not the same as an express denial. The existence and scope of any implied rights, defenses, exhaustion, or separate patent licenses are legal questions that depend on facts and jurisdiction. A factual description of MIT should therefore say that the text lacks an express patent-license section, not make a universal claim that it grants no patent rights at all.

The MIT text is likewise silent about trademarks and project names. It grants rights in the defined software, not an express right to present a modified product as official or endorsed. X11, BSD 3-Clause, and Apache 2.0 address names or trademarks more directly, but in different ways.^[6][9][10]

Finally, the text does not include an inbound-contribution clause. A project may use a contributor license agreement, a developer certificate of origin, or repository terms to document contributions. Those mechanisms are separate from the permissions a downstream recipient receives in the published MIT notice.

Machine-readable identification

SPDX

SPDX assigns the canonical short identifier MIT to the standard text.^[2] SPDX license expressions can describe a single license, a choice using OR, simultaneous requirements using AND, or a listed exception using WITH. Parentheses control precedence.^[13] Examples include:

• MIT
• MIT OR Apache-2.0
• MIT AND BSD-2-Clause
• GPL-2.0-or-later WITH Bison-exception-2.2

An SPDX identifier is metadata, not a substitute for preserving the license text when the license requires the notice. It is also not evidence that an entire repository has only one license. File-level identifiers, package metadata, and a complete license inventory should agree.

REUSE and package ecosystems

The REUSE Specification 3.0 describes a repository convention in which license texts are stored in a LICENSES directory and copyright and licensing information is expressed with SPDX identifiers in file headers or adjacent metadata.^[14] This can make a multi-license repository easier for people and automated tools to audit.

Package ecosystems use related conventions:

• npm documentation directs packages using common licenses to place a current SPDX identifier in the package.json license field and uses SPDX expressions for multiple-license choices.^[15]
• Python Core Metadata 2.4 defines License-Expression as a valid SPDX expression and License-File as a repeatable path to license-related files. The specification warns that the expression describes the containing distribution archive, not automatically every release artifact or the project as a whole.^[16]
• Cargo treats the manifest license field as an SPDX expression and provides license-file for the license text or a nonstandard license. Cargo's documentation gives MIT OR Apache-2.0 as an example.^[17]

These fields improve discovery, but a correct identifier paired with missing notices can still leave a distribution incomplete. Conversely, a text file with modified terms may no longer match the stated SPDX identifier.

Adoption and measurement

The MIT License is common in public software, but a universal current market share is difficult to establish. Measurements vary by hosting service, package ecosystem, unit of analysis, duplicate handling, license detector, and treatment of repositories without recognizable license files.

A 2015 GitHub analysis examined public, nonfork repositories and used the Licensee detector on files named LICENSE. Among repositories where its method detected a license, MIT accounted for 44.69 percent. The same article said only about 20 percent of the examined projects were licensed at all. GitHub explicitly noted that the method missed license information placed in README files or source-file comments and recognized only a limited set of licenses.^[18] Those figures describe that historical dataset, not all software and not current GitHub.

OSI reported a different measurement for 2025: human pageviews of its license pages. The MIT page led the listed OSI-approved licenses with 1.53 million pageviews and about 925,000 visitors. OSI explained that the figures aggregate human pageviews, exclude much bot traffic, and can undercount visitors using blockers or affected by regional access constraints.^[19] Pageviews measure interest in license documentation, not adoption.

Empirical research reinforces the need for methodological caution. The 2022 edition of the Software Heritage License Dataset contains about 6.9 million unique files whose names were likely to convey licensing information, plus a manually annotated sample of 8,102 documents. The authors selected files from the Software Heritage archive by filename pattern and used ScanCode for automated characterization.^[20] They explicitly described the dataset as an incomplete snapshot: source headers and many README files are underrepresented, the archive is not all-encompassing, and public licensing practice is a moving target.^[20]

A separate SANER 2024 study constructed a taxonomy of 22 license terms and labeled 453 SPDX licenses. The authors found that three popular license-summary platforms used inconsistent term sets and interpreted 9 of 11 shared terms inconsistently. Their validation exercise reported 83.68 percent agreement across 864 term-label decisions from nine retained questionnaires.^[21] The result shows why exact license text and qualified expert review are safer than treating simplified permission badges as complete legal analysis.

Use in AI projects

MIT is used by software projects that support machine learning and AI development. The official repositories for OpenAI's CLIP, LangChain, and LlamaIndex each publish a root LICENSE file containing the MIT text.^[23][24][25] These examples establish the licensing statement made by each repository; they do not imply that every model, dataset, service, dependency, or output associated with the project has the same terms.

The distinction becomes especially important for open-source AI and open weights. OSI's Open Source AI Definition 1.0 evaluates the preferred form for making modifications to an AI system, including data information, code, and parameters. It requires data information and parameters under OSI-approved terms and code under OSI-approved licenses, while acknowledging that different legal mechanisms may govern parameters.^[22] A software repository carrying MIT therefore does not, by itself, establish that the related training data and model parameters are open.

DeepSeek provides a useful scope example. The DeepSeek-R1 README states that both the repository code and model weights are licensed under MIT, then separately identifies the Qwen and Llama bases and their upstream licenses for the distilled models.^[26] The detailed statement is more informative than a single badge because it distinguishes original artifacts from derivatives with additional terms.

Academic authors have also questioned whether software-license terminology maps cleanly to every AI artifact. The Model Openness Framework paper observes that producers sometimes apply MIT or Apache 2.0 to model parameters and argues that parameters are better handled with licenses designed for data. That is the authors' proposed framework, not a settled rule of copyright law.^[27] The narrower factual lesson is that an AI release should identify the scope and license of code, parameters, data, documentation, and third-party components separately.

Enforcement

There is no need to claim that every MIT condition has received identical judicial treatment. A frequently cited United States appellate decision, Jacobsen v. Katzer, involved the Artistic License, not the MIT License. In 2008, the U.S. Court of Appeals for the Federal Circuit held that the Artistic License's "provided that" restrictions were conditions limiting the scope of the copyright license. It vacated the denial of a preliminary injunction and remanded for further proceedings.^[28]

The opinion is relevant to public licensing because it rejected the idea that distribution without a fee makes license conditions economically meaningless. It does not constitute a holding that every sentence in every permissive license is an enforceable copyright condition in every jurisdiction. The decision itself turned on the Artistic License's language, the alleged conduct, and the governing legal framework.^[28]

For the MIT License, the source-bounded statement is simpler: the broad permission grant is expressly made subject to preservation of the copyright and permission notices.^[1] A redistributor should comply with that text and should seek qualified legal advice for a disputed or high-risk interpretation.

Practical review checklist

Before publishing or redistributing material described as MIT-licensed:

1. Identify the exact text. Confirm MIT, X11, MIT-0, or another license by reading the notice and checking its SPDX identifier.^[2][6][7]
2. Identify the covered artifacts. Determine whether the notice applies to source code, binaries, documentation, weights, data, or only a subset.
3. Inventory exceptions. Review subdirectories, vendored dependencies, generated files, fonts, media, datasets, and model cards for separate terms.
4. Preserve the notice. Include the copyright and permission notices with copies or substantial portions of MIT-covered software.^[1]
5. Keep metadata consistent. Align repository notices, file-level identifiers, package manifests, and release archives.^[13][14]
6. Do not infer absent rights. Check patents, trademarks, contribution terms, privacy commitments, and service terms separately.
7. Describe measurements narrowly. Attach a date, dataset boundary, and detection method to any adoption statistic.^[18][20]
8. Recheck every release artifact. A source repository, package, container image, hosted service, model checkpoint, and dataset can have different licensing scopes.

References

1. ^Open Source Initiative, "The MIT License" opensource.org/...mit
2. ^SPDX License List, "MIT License" spdx.org/...MIT
3. ^Jerome H. Saltzer, "The Origin of the 'MIT License'," IEEE Annals of the History of Computing, volume 42, issue 4, 2020, doi:10.1109/MAHC.2020.3020234 web.mit.edu/...MITLicense.pdf
4. ^Massachusetts Institute of Technology, scan of the February 1, 1984 PC/IP copyright and permission notice web.mit.edu/...mit-license-1984.pdf
5. ^Free Software Foundation, "Various Licenses and Comments about Them," Expat and X11 entries gnu.org/...license-list
6. ^SPDX License List, "X11 License" spdx.org/...X11
7. ^SPDX License List, "MIT No Attribution" spdx.org/...MIT-0
8. ^Open Source Initiative, "The 2-Clause BSD License" opensource.org/...bsd-2-clause
9. ^Open Source Initiative, "The 3-Clause BSD License" opensource.org/...bsd-3-clause
10. ^Apache Software Foundation, "Apache License, Version 2.0" apache.org/...LICENSE-2.0
11. ^Free Software Foundation, "GNU General Public License, version 3" gnu.org/...gpl-3.0.en
12. ^Free Software Foundation, "License Compatibility and Relicensing" gnu.org/...license-compatibility.en
13. ^SPDX Specification 3.0.1, "SPDX license expressions" spdx.github.io/...spdx-license-expressions
14. ^Free Software Foundation Europe, "REUSE Specification, version 3.0" reuse.software/spec-3.0
15. ^npm Documentation, "package.json," license field docs.npmjs.com/...package-json
16. ^Python Packaging Authority, "Core Metadata Specifications," License-Expression and License-File packaging.python.org/...core-metadata
17. ^Rust Project, "The Manifest Format," license and license-file fields doc.rust-lang.org/...manifest
18. ^GitHub, "Open source license usage on GitHub.com," March 9, 2015 github.blog/...-source-license-usage-on-github-com
19. ^Open Source Initiative, "Top Open Source Licenses in 2025," December 17, 2025 opensource.org/...top-open-source-licenses-in-2025
20. ^Jesus M. Gonzalez-Barahona, Sergio Montes-Leon, Gregorio Robles, and Stefano Zacchiroli, "The Software Heritage License Dataset (2022 Edition)," Empirical Software Engineering 28, 2023, doi:10.1007/s10664-023-10377-w arxiv.org/...2308.11258
21. ^Tao Liu et al., "Catch the Butterfly: Peeking into the Terms and Conflicts among SPDX Licenses," 2024 IEEE International Conference on Software Analysis, Evolution and Reengineering, pages 477-488, doi:10.1109/SANER60148.2024.00056 arxiv.org/...2401.10636
22. ^Open Source Initiative, "The Open Source AI Definition 1.0" opensource.org/...open-source-ai-definition
23. ^OpenAI, "CLIP License" github.com/...LICENSE
24. ^LangChain, "LangChain License" github.com/...LICENSE
25. ^LlamaIndex, "LlamaIndex License" github.com/...LICENSE
26. ^DeepSeek AI, "DeepSeek-R1 README," License section github.com/...README.md
27. ^Matt White et al., "The Model Openness Framework: Promoting Completeness and Openness for Reproducibility, Transparency, and Usability in Artificial Intelligence," 2024 arxiv.org/...2403.13784
28. ^United States Court of Appeals for the Federal Circuit, Jacobsen v. Katzer, 535 F.3d 1373, decided August 13, 2008 cafc.uscourts.gov/...08-1001.pdf
29. ^United States Copyright Office, "Copyright in General: Frequently Asked Questions" copyright.gov/...faq-general