MIT License
Last reviewed
Sources
28 citations
Review status
Source-backed
Revision
v3 · 4,737 words
Improve this article
Add missing citations, update stale details, or suggest a clearer explanation.
Suggest edit
CtrlK
Last reviewed
Sources
28 citations
Review status
Source-backed
Revision
v3 · 4,737 words
Add missing citations, update stale details, or suggest a clearer explanation.
The MIT License is a permissive free software license, originating at the Massachusetts Institute of Technology in the 1980s, that grants nearly unrestricted permission to use, copy, modify, and redistribute software in exchange for retaining the copyright notice and license text. It is the most widely used open source license in the world: GitHub's own license usage data and the Open Source Initiative (OSI) report it as the single most common license among public repositories, where it accounts for roughly 30 percent or more of all licensed projects and has held the top spot since the mid-2010s. [1][7][24][25] The standard form fits on a single page (about 170 words), and the OSI lists it as an approved open source license under the SPDX identifier MIT, while the Free Software Foundation classifies it as a free, GPL-compatible license. [1][2][7]
In the open source AI world, MIT and Apache 2.0 have become the two default choices for code repositories, while AI model weights tend to drift toward custom licenses with use restrictions. Notable AI codebases under MIT include LangChain, LlamaIndex, OpenAI's CLIP, OpenAI's GPT-2 reference implementation, and many smaller utilities across the Hugging Face ecosystem. [14][15] DeepSeek attracted considerable attention in early 2025 by releasing both the code and the open weights of DeepSeek-R1 under the MIT License, which made the model unusually permissive by current frontier standards. [16][17]
| Property | Value |
|---|---|
| Type | Permissive free software license |
| SPDX identifier | MIT |
| OSI approved | Yes |
| FSF free | Yes |
| GPL compatible | Yes |
| Copyleft | No |
| Patent grant | No (no explicit grant) |
| Trademark grant | No |
| Origin | MIT, late 1980s |
| Canonical name (SPDX) | MIT License (Expat) |
| Other common names | Expat License, MIT/X11, MIT-Expat |
| Length | About 170 words |
| Popularity | Most-used license on GitHub (~30%+ of licensed repos) [24][25] |
The MIT License is what people usually mean when they say "MIT License" without further qualification. The text approved by the OSI is the variant historically used by the Expat XML parser, sometimes called the Expat License. [1][2] A handful of related but distinct licenses also carry the "MIT" label, which has caused confusion since the early 1990s. [5]
The MIT License is used to release source code with the broadest practical freedom while keeping the legal text minimal. Because the only obligation is to preserve the copyright and license notice, MIT-licensed code can be embedded in proprietary commercial products, combined with code under almost any other license, and redistributed without source-disclosure requirements. This makes it the default for fast-moving developer tooling, sample code, and library code that is meant to be pulled into deeply nested dependency graphs. In AI specifically, it sits at the bottom of many Python dependency trees and, since 2025, on the weights of frontier open models like DeepSeek-R1. [16][17]
The story of the license is messier than the popular telling suggests. Multiple texts have been called "the" MIT License, and the canonical version that everyone uses today is technically a slightly later variant of the family. [5][6]
According to Jerome Saltzer, a longtime computer scientist at the MIT Laboratory for Computer Science, the earliest precursor was drafted in late 1983 and circulated to MIT attorneys in a memorandum dated January 10, 1984, for use with a TCP/IP implementation produced by the Computer Systems Research (CSR) Group. [5][26] The team wanted to make the software available without negotiating individual licensing agreements, so they chose to give it away with a copyright notice and a short, permissive grant of rights. That January 1984 wording was used in software releases starting February 1, 1984. [5][26] Saltzer summarized the design goal plainly: the idea was "copyrighting the software but including with the copyright notice a permission notice that allowed anyone to use it for free." [26]
A second wave of drafting happened around 1985 in connection with the X Window System and Project Athena. The X protocol reached version 11 in September 1987, which is why the version of the license shipped with X11 is sometimes called the X11 License, the X Consortium License, or the MIT/X11 License. [3][6] This was the version that included an extra clause restricting use of the copyright holders' name in advertising or promotion. SPDX tracks it separately under the identifier X11. [3]
The variant that is now universally referred to as "the MIT License" came into wide use through the Expat XML parser, written by James Clark in the late 1990s. [6] The Expat text drops the advertising clause from the X11 form and is shorter and cleaner. When the OSI added "MIT License" to its list, this is the form they used, and SPDX calls it MIT. [1][2] The Expat License is therefore the de facto standard, and the X11 License is now mostly historical. [6]
The Free Software Foundation has long argued that calling the Expat license "the MIT License" is misleading since MIT itself has used several different texts under that name. The FSF still recommends the more specific term "Expat License" in formal contexts. [7] In practice, the SPDX naming has won, and most projects label their LICENSE file as "MIT License" without distinguishing the variant. [2]
The text is short enough to read in under a minute, but it does several distinct things. The standard form is structured as a single header line plus three paragraphs. [1]
Copyright (c) <year> <copyright holders>
This is just a conventional copyright notice. It establishes who owns the work and from when. The license itself does not transfer copyright; it grants a permission on top of the existing copyright.
The core grant gives "any person obtaining a copy" of the software permission to deal in it "without restriction." The list that follows is exhaustive in the legal sense and is meant to leave no doubt: use, copy, modify, merge, publish, distribute, sublicense, and sell copies. [1] Sublicensing is important. It allows downstream recipients to relicense the code as part of a larger work without going back to the original authors for permission. This is one of the reasons MIT-licensed code shows up inside proprietary commercial products without anyone being able to point to a violation.
The one real obligation is that the copyright notice and the permission notice "shall be included in all copies or substantial portions of the Software." [1] If you ship a binary, the convention is to include a NOTICES, LICENSES, or third-party-licenses file that lists the MIT-licensed components and their copyright holders. "Substantial portions" is intentionally vague; in practice almost any reuse beyond very small snippets is treated as substantial.
This is the entire compliance story for the MIT License. There is no NOTICE file requirement (Apache 2.0 has one), no source-disclosure obligation, no patent provisions, and no requirement to mark modifications. [1][12]
The last paragraph, written in all-caps in the canonical text, is a standard warranty disclaimer. The software comes "AS IS," with no warranties of merchantability, fitness for a particular purpose, or non-infringement, and the authors and copyright holders disclaim all liability. [1] This language is common to almost every open source license; courts in the United States generally enforce it against commercial users as well.
MIT, BSD, ISC, and Apache 2.0 are sometimes lumped together as "permissive licenses," and for many small projects they are functionally interchangeable. The differences matter in three places: patents, attribution, and what you have to ship alongside binaries. [9][10]
| License | SPDX | Length | Patent grant | Attribution required | Notes |
|---|---|---|---|---|---|
| MIT (Expat) | MIT | About 170 words | No | Yes | Most popular permissive license |
| X11 (MIT/X Consortium) | X11 | About 200 words | No | Yes | Adds no-use-of-name-in-advertising clause |
| BSD 3-Clause | BSD-3-Clause | About 230 words | No (implicit) | Yes | Adds non-endorsement clause |
| BSD 2-Clause | BSD-2-Clause | About 180 words | No (implicit) | Yes | Functionally similar to MIT |
| BSD 0-Clause | 0BSD | About 110 words | No | No | Public-domain-equivalent |
| MIT-0 | MIT-0 | About 150 words | No | No | MIT with attribution clause removed |
| ISC | ISC | About 130 words | No | Yes | Used by OpenBSD; functionally similar to MIT |
| Apache 2.0 | Apache-2.0 | About 1,800 words | Yes (explicit) | Yes (NOTICE file) | Includes patent retaliation clause |
The practical sorting that lawyers and developers use is roughly: BSD 2-Clause, MIT, and ISC are nearly identical in effect; BSD 3-Clause adds a non-endorsement clause; X11 adds a no-advertising clause; Apache 2.0 is heavier but provides patent and trademark protections that MIT does not. [9][10]
This is the comparison that most modern AI labs care about, and it is the one that has gotten the most attention since 2023. Apache 2.0 differs from MIT in five concrete ways:
The upshot is that Apache 2.0 is heavier on paperwork but offers stronger protection against patent litigation. For corporate codebases, especially in fields like machine learning where patent portfolios are a real concern, this often tips the choice in Apache's favor. For small projects, the lighter MIT text is preferred for its simplicity.
The MIT License is permissive; the GNU General Public License is copyleft. The two are often presented as opposites. Under MIT, you can take the code, modify it, and ship the result under any license you like, including a fully proprietary one. Under GPL, any derivative work that you distribute must itself be licensed under the GPL, with source code provided. [8]
The FSF lists the MIT (Expat) License as compatible with the GPL, meaning code under the two licenses can be combined and the combined work distributed under the GPL. [7] Compatibility runs only one way: combining MIT code into a GPL project is fine, but you cannot take a GPL project and relicense the result under MIT alone. [8][10]
In AI specifically, this asymmetry matters because most ML libraries are permissive. A model trained using GPL-licensed code in the training pipeline does not necessarily make the resulting weights "GPL," but the training code itself would have to remain GPL when distributed. Most labs avoid the question by sticking to permissive licenses end to end.
MIT is one of the most license-compatible texts in existence. The general rule is: [10]
SPDX expressions like MIT OR Apache-2.0 are common in Rust crates, which lets downstream users pick whichever fits their project. Dual-licensing is allowed because the grant in each license is independent of the other. [2]
The practical question for an AI engineer is which licenses live in the bottom of the dependency tree. Most of the modern Python ML stack is split between MIT and Apache 2.0, with a couple of holdouts on BSD-3-Clause for historical reasons.
| Project | License | Year | Notes |
|---|---|---|---|
| PyTorch | BSD-3-Clause | 2016 | Inherited from the Torch lineage |
| TensorFlow | Apache 2.0 | 2015 | Released by Google with explicit patent grant |
| Hugging Face Transformers | Apache 2.0 | 2019 | Same for datasets, tokenizers, accelerate |
| scikit-learn | BSD-3-Clause | 2010 | One of the older Python ML libraries |
| NumPy | BSD-3-Clause | 2006 | Numerical computing foundation |
| Matplotlib | Matplotlib License (BSD-style) | 2003 | PSF-derived, BSD-compatible |
| Jupyter | BSD-3-Clause | 2015 | Project Jupyter's standard license |
| LangChain | MIT | 2022 | Application framework for LLMs |
| LlamaIndex | MIT | 2022 | Document indexing and retrieval framework |
| vLLM | Apache 2.0 | 2023 | High-throughput inference engine |
| CLIP | MIT | 2021 | OpenAI's vision-language model |
| GPT-2 | Modified MIT | 2019 | Reference implementation by OpenAI |
| DeepSeek-R1 | MIT (code and weights) | 2025 | Both code and open weights under MIT |
| DeepSeek-V3.2 | MIT | 2025 | Followed R1's licensing |
| Mistral 7B | Apache 2.0 | 2023 | First Mistral open-weight release |
| Mixtral 8x7B | Apache 2.0 | 2023 | Sparse mixture of experts |
| Mixtral 8x22B | Apache 2.0 | 2024 | |
| Qwen (most variants) | Apache 2.0 | 2023, 2024, 2025 | 3B and 72B variants under Qwen License |
| Llama 2 | Llama 2 Community License | 2023 | Source-available, not OSI-approved |
| Llama 3 | Llama 3 Community License | 2024 | Adds 700M MAU restriction |
| Stable Diffusion | CreativeML OpenRAIL-M | 2022 | Use-restricted, not OSI-approved |
A few things stand out from this table. First, the framework layer is mostly Apache 2.0 or BSD, while the application layer (LangChain, LlamaIndex) tends toward MIT. The heavier Apache text is more common where contributors are corporate and where patent protection is a real concern. The MIT-style licenses are more common in fast-moving developer-focused tooling.
Second, frontier model weights are split. The European labs (Mistral) and Chinese labs (Alibaba's Qwen, DeepSeek) lean strongly into permissive licenses. [18][22] Meta treats Llama as "open weights" in practice but ships them under a custom community license that fails the Open Source Definition; the OSI has been explicit that Llama is not open source, writing in 2024 that "Llama 3.x is still not Open Source by any stretch of the imagination." [19] Image and video models, including Stable Diffusion, often use Responsible AI licenses like OpenRAIL-M that include behavioral use restrictions.
Third, the absence of an explicit patent grant in MIT is a real trade-off in this space. Major AI patents are being filed at high rates, and a contributor or third party with patents that read on a model could in principle assert them against MIT-licensed users. Apache 2.0 users would have the patent grant and the patent termination clause to fall back on. MIT users would not. [10] In practice this risk is often treated as acceptable because most contributors do not actually want to enforce patents against users of their own code, but it is the single biggest reason large enterprises sometimes prefer Apache.
The DeepSeek release deserves a closer look because it changed the conversation about model licensing in 2025. On January 20, 2025, DeepSeek released DeepSeek-R1, a reasoning model with open weights, under the MIT License. [16][17] The MIT terms applied to both the code repository and the model weights, with explicit permission to use the weights for any purpose, including commercial use, modification, and distillation into derivative models. [16][17] The release notes put it bluntly: "Code and models are released under the MIT License: Distill & commercialize freely!" [16] That last point was deliberate. The license explicitly allows training other LLMs from DeepSeek-R1 outputs, which had been a sore point in earlier model releases from other labs, and DeepSeek paired the MIT relicensing with a product-agreement update that "explicitly allow[s] users to utilize model outputs for training other models through distillation techniques." [16]
The original DeepSeek-V3 release in late 2024 had used a custom "DeepSeek License" with restrictions. DeepSeek-V3-0324 in March 2025 switched to MIT, and DeepSeek-V3.2 continued under MIT. [16][17] By making the move during a high-attention release, DeepSeek raised the floor for what counts as "open" in the LLM space. Several commentators framed it as a direct contrast with Meta's Llama Community License, which limits commercial use above 700 million monthly active users and forbids using Llama outputs to train competing models. [19]
Whether MIT is the right license for model weights is a separate philosophical question. The license was written for software in 1984, not for trained model parameters that may have been trained on copyrighted data, and applying it to weights raises questions that the text itself does not address. [5] The legal status of weights as a copyrightable work is itself unsettled in many jurisdictions. Still, the practical effect of using MIT for weights has been to give downstream users about as much freedom as is currently practical to grant.
The MIT License is short, which is its main virtue, but the brevity does cut some corners. The most common issues:
No explicit patent grant. Already discussed above. If a contributor holds a patent that reads on their contribution, they can in theory still sue. Whether courts would imply a patent license from the act of contributing under MIT is jurisdiction-dependent and not well-tested. [10]
No trademark provisions. MIT does not grant any rights to use the trademarks, service marks, or product names of the copyright holders. It also does not explicitly disclaim them, though that is the default reading. [1]
No contributor terms. Apache 2.0 includes a Contributor License Agreement-like clause that says contributions submitted to the project are licensed under the same terms unless explicitly stated otherwise. MIT has no such clause, so projects that want this guarantee usually adopt a separate CLA.
No defensive termination. If someone uses MIT-licensed code and then sues you over an unrelated patent, your MIT license to their code stays valid. Apache 2.0 would have terminated the patent grant in that case. [10]
"Substantial portions" is undefined. The notice requirement only applies to "substantial portions of the Software." [1] There is no test for what counts as substantial, and very small snippets used inline are sometimes treated as below the threshold. Most projects err on the side of always including the notice.
The license travels with the code, but not with the API. If you re-implement an MIT-licensed library from scratch using its public API as a reference, you do not need to comply with the MIT license, since you are not copying any of the original code. This is the same as for any other software license, but it sometimes surprises new contributors.
The SPDX License List is the standard registry that most tools (npm, PyPI, Cargo, Maven, etc.) use to refer to licenses in metadata. The relevant identifiers in the MIT family are: [2]
| Identifier | Name | OSI | FSF | GPL compat |
|---|---|---|---|---|
MIT | MIT License (Expat) | Yes | Yes | Yes |
MIT-0 | MIT No Attribution | Yes | Yes | Yes |
MIT-CMU | CMU License | No | No | Unclear |
MIT-feh | feh License | No | No | Unclear |
MIT-Modern-Variant | MIT License Modern Variant | Yes | Yes | Yes |
MIT-open-group | MIT Open Group variant | No | No | Unclear |
X11 | X11 License | Yes | Yes | Yes |
X11-distribute-modifications-variant | X11 with modifications variant | No | No | Unclear |
In package manifests the canonical form is the SPDX expression. For a single license: "license": "MIT". For dual-licensed work: "license": "MIT OR Apache-2.0". Most build and audit tools (FOSSA, Snyk, GitHub's dependency graph) parse these expressions. [2]
Several closely related texts are sometimes referred to as MIT or grouped with it. The OSI has approved several of them as separate licenses with separate SPDX identifiers. [1][2]
| Variant | SPDX | Difference from canonical MIT |
|---|---|---|
| Expat | MIT | The canonical form; what most people mean by "MIT" |
| X11 / X Consortium | X11 | Adds clause restricting use of names in advertising |
| MIT-0 (No Attribution) | MIT-0 | Removes the requirement to include the license in copies |
| MIT-CMU | MIT-CMU | Carnegie Mellon variant; similar with extra non-endorsement |
| MIT-feh | MIT-feh | Variant used by the feh image viewer |
| MIT Click-Through | (none) | Rare variant requiring active acceptance; not OSI approved |
| MIT-Modern-Variant | MIT-Modern-Variant | Slightly clarified wording approved by OSI in 2021 |
The MIT-0 variant is worth mentioning specifically because it is approximately the simplest still-recognized free software license. It removes the attribution requirement entirely and is functionally equivalent to a public-domain dedication. [4] Amazon Web Services published it in 2018, and the OSI approved it through its legacy approval process on August 5, 2020. [4][27] Some projects use it for sample code where carrying around a copyright notice would be more friction than the notice is worth.
There is not much MIT-specific case law, partly because MIT compliance is so easy that violations are rare and partly because the warranty disclaimer is so broad that contract claims are hard to bring. The most cited case for open source license enforcement generally is Jacobsen v. Katzer, decided by the United States Court of Appeals for the Federal Circuit in 2008. [20][21] The case involved the Artistic License rather than the MIT License, but the holding (that open source license terms are enforceable copyright conditions, not just contract terms) applies to permissive licenses including MIT. [20][21] The parties settled in 2010, reaching agreement on February 16, 2010, with a payment of $100,000 to Robert Jacobsen, lead developer of the Java Model Railroad Interface (JMRI) project, plus a permanent injunction. [20][28]
The practical effect of Jacobsen is that if someone strips the copyright notice from MIT-licensed code and ships a derivative work, the original copyright holder can sue for copyright infringement, not just breach of contract, with statutory damages and injunctive relief on the table. [20][21] This is the enforcement mechanism that the MIT License relies on, even though the text never mentions it.
The MIT License has dominated permissive licensing for a few practical reasons. It is short enough to read in one minute, which lawyers and developers both appreciate. The grant is broad enough that almost no one finds a reason to negotiate around it. It is GPL-compatible, so MIT code can flow freely into copyleft projects. [7] It places almost no maintenance burden on downstream users, which is ideal for tightly nested dependency graphs where every project pulls in dozens of transitive dependencies. These properties have made it the most-used license on GitHub for most of the past decade. [24][25]
For open source AI specifically, the cultural fit is strong. The community has settled on a norm of permissive licensing for code, with the heavier debates reserved for model weights and training data. MIT slots cleanly into the role of "the default license you choose if you have not thought about it," while Apache 2.0 plays the role of "the default license your lawyer recommends when you have thought about it."
For smaller projects the trade-off rarely matters. For frontier AI labs with patent portfolios and large user bases, the choice can change which protections survive into derivative works. The choice of MIT for DeepSeek-R1 was a signal as much as a legal decision: by adopting the simplest possible open license, DeepSeek positioned the release as maximally open, which contrasted directly with the more restricted licensing on Llama 2 and Llama 3. [16][19]
The text below is the canonical MIT (Expat) License as published by SPDX and OSI. The <year> and <copyright holders> placeholders are filled in by each project. [1][2]
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.