The MIT License is a short permissive open source license that allows anyone to use, copy, modify, merge, publish, distribute, sublicense and sell software, on the single condition that the copyright notice and the license text are included in all copies or substantial portions of it. In software licensing, it is one of the most widely used licenses for open source projects, valued for its brevity and its minimal obligations.
The license originated at the Massachusetts Institute of Technology, which gives it its name. It is approved by the Open Source Initiative and recognized as a free software license, and it is compatible with almost every other license, including the GPL.
What the MIT License grants and requires
The license text has three parts: a permission grant, a notice condition and a warranty disclaimer. Its full text is only a few short paragraphs, which is a large part of its appeal.
| Part | Content | Practical meaning |
|---|---|---|
| Permission grant | Free of charge, to deal in the software without restriction | Commercial and private use, modification and resale are allowed |
| Notice condition | Keep the copyright notice and permission notice | The only real obligation for users |
| Warranty disclaimer | Software provided as is, without warranty | Authors are not liable for damages |
Equally important is what the license does not require. Users need not publish their source code, need not release modifications, need not use the same license for derived work and need not notify the original authors. A closed-source commercial product may include MIT-licensed code as long as the notice travels with it.
Permissive licensing compared with copyleft
Open source licenses fall into two broad families. Permissive licenses such as MIT impose few conditions, while copyleft licenses such as the GPL require that derived works be distributed under the same terms with source code available.
| Property | MIT License | Apache License 2.0 | GPL v3 |
|---|---|---|---|
| License family | Permissive | Permissive | Strong copyleft |
| Use in closed-source products | Allowed | Allowed | Only without distributing the combined work |
| Source disclosure on distribution | Not required | Not required | Required for the whole derived work |
| Explicit patent grant | No | Yes, with patent retaliation clause | Yes |
| Notice of changes | Not required | Modified files must be marked | Required |
| Length | A few paragraphs | Several pages | Many pages |
The missing explicit patent grant is the main technical difference between MIT and Apache 2.0. Some lawyers argue that the broad permission wording implies a patent license, but because this is not settled, organizations concerned about patents often prefer Apache 2.0.
Compatibility works in one direction. MIT-licensed code can be incorporated into a GPL project, because the GPL’s conditions are a superset of MIT’s. The reverse is not possible: GPL code cannot be relicensed under MIT by anyone except its copyright holders. This one-way compatibility is why MIT is often chosen for libraries that should be usable in as many projects as possible.
How to apply the MIT License to a project
Applying the license is simple, which is one reason it is a common default for new repositories. The essential step is to publish the full license text with a correct copyright line.
- Create a file named LICENSE or LICENSE.txt in the root of the project.
- Insert the standard MIT text with the year and the copyright holder’s name filled in.
- Optionally add an SPDX identifier such as
SPDX-License-Identifier: MITat the top of source files. - Declare the license in package metadata, for example the license field of a package manifest.
- Ensure that all contributors agree to license their contributions under the same terms.
The copyright holder is the person or organization that owns the code, often the employer when code is written as part of a job. Using the license does not transfer copyright; it only grants permissions to others.
Complying when using MIT-licensed code
Compliance is light but not zero. The most common failure is dropping the notice when code is bundled, minified or compiled into a product.
| Situation | What to do | Common mistake |
|---|---|---|
| Shipping a desktop or mobile app | Include the notices in an about screen or bundled file | Omitting notices of dependencies |
| Distributing a library | Keep the original LICENSE file and copyright lines | Replacing the original copyright with one’s own |
| Bundled or minified web code | Preserve license comments or ship a notices file | Build tools stripping all comments |
| Copying a single file | Keep its header or add the license text | Treating short snippets as notice-free |
| Internal use only | No distribution, so obligations are minimal | Forgetting notices if the tool is later shared |
Software composition analysis tools can scan dependencies and generate a list of licenses and notices automatically, which is the practical approach for products with hundreds of dependencies.
Limitations and misconceptions
- MIT does not mean public domain: the author keeps copyright, and the notice condition is legally binding.
- No trademark rights: the license covers code, not project names or logos.
- No support or warranty: users accept the software as is and bear the risk of defects.
- Relicensing is limited: a downstream user may apply additional terms to their own version, but cannot remove the original notice or the rights others already received.
- Variants exist: related licenses such as the Expat and X11 wordings differ slightly, and the SPDX identifier MIT refers to one specific text.
A plain-language summary
The MIT License is a short permission note that a programmer attaches to their code. It says, in effect: anyone may use this code for anything, including in products they sell. The only requirement is to keep the note that says who wrote it.
It also says the code comes with no guarantee. If it breaks something, the author is not responsible. Because it asks for so little, it is one of the easiest licenses to work with, for companies and hobby projects alike.
An example from practice
A small company builds a commercial mobile app for scheduling appointments. Its developers use about 60 open source packages, most of them under the MIT License, along with a few under Apache 2.0. The app’s own code remains proprietary and closed.
Before release, the team runs a license scanner in its build pipeline. It produces a notices file listing each package with its copyright line and license text. The app shows this file under an “Open source licenses” entry in its settings menu. The company keeps its source code private, satisfies every MIT notice condition and passes a customer’s procurement review without delay.