Disclaimer: This post is for informational purposes only, and should not be used in place of legal advice.
Overview
Before we dive into the specifics of the MIT License, let’s talk first about what it means to have an open source license. Unlike proprietary software, open source allows for use, modification, and distribution, within the legal constraints defined by the license. It’s important to understand and fully comply with license terms and conditions, because they protect both software creators and the users.
Open source licenses can be roughly categorized as either “permissive” or “copyleft.” Copyleft licenses require developers to use the same distribution terms if they use, modify, and redistribute the open source code, while permissive licenses (like the MIT License) permit users to redistribute source code with a different license or set of terms and conditions.
MIT License: Terms and conditions
The MIT License, first developed at Massachusetts Institute of Technology (MIT) in the late 1980s, is an extremely simple and permissive software license. Like the Apache 2.0 and BSD family of licenses, the MIT License imposes relatively few limits on usage. For example, it does not impose limits on using, copying, modifying, merging, publishing, distributing, sublicensing, or selling copies of the open source code, as long as the copyright notice and permission notice is included in all copies or substantial portions of the software. This means that developers modifying MIT-licensed code for use in their own software projects are allowed to make their code closed source or charge money for their products.
Notably, the MIT License is also provided “as is,” which means that the authors / creators of the open source code governed by the license can’t be held liable for the software’s functionality or reliability.
Ruby on Rails, jQuery, and Node.js are all examples of popular open source software projects that use an MIT License.
MIT License variations
Since the MIT License was first created, several variations have been introduced to serve specific software licensing needs. Below is a list of those variations.
MIT No Attribution License (MIT-0)
The MIT-0 License is roughly the same as the original MIT License, but it does not require attribution. It’s most helpful for people who want to reuse the open source code for teaching samples, templates, or references, because it doesn’t require inclusion of the original copyright notice and permission notice in software copies.
The X11 License (MIT/X Consortium License)
The X11 License gets its name from the X Window System (X11) from MIT. Like the JSON License, it is identical to the original MIT License, but it adds an extra clause that constrains developers from using source code author’s name in any advertising or promotional materials without prior authorization. It provides more assurance against legal liability than the original MIT License.
JSON License
The JSON License—developed by Douglas Crockford, who created the popular JSON data format—includes the same language as the MIT License, with one additional clause: "The Software shall be used for Good, not Evil."
How can I use the MIT license?
To use the MIT License, you’ll need to include the following in any copies or substantial portions of your software:
1. The original copyright notice
2. A copy of the license itself
It’s common for developers to include this information in a LICENSE.md or LICENSE.txt file in their source code repository (see Ruby on Rail’s LICENSE.md file here). Developers also commonly include a short license summary at the top of each source file referencing the license and linking to its full text.
Is the MIT License compatible with other licenses, like GPL?
Your software project may reuse and distribute code governed by different licenses, like the MIT License and GNU GPL license. The MIT License is generally compatible with the GNU GPL license family. But keep in mind that, if you’re reusing and distributing code that is governed by a GNU GPL license, your final project must be GPL-compliant and publicly available.
How is the MIT License different from the GNU GPL license?
Unlike the MIT License, which is highly permissive, the GNU GPL license is a “copyleft” license. This means that developers can use, modify, and redistribute GPL-licensed code only if the distribution terms are unchanged. The goal is to keep any modifications to GPL-licensed software free and open.
How is the MIT License different from other permissive licenses, like the Apache 2.0 License and the BSD licenses?
Both the Apache 2.0 License and the BSD license family are permissive licenses, like the MIT License. All of these licenses allow users to modify and distribute the software, including changing distribution terms, like making the code closed source or proprietary. But there are some key differences in both the Apache 2.0 License and the BSD licenses.
The Apache 2.0 License is more explicit than the MIT License in terms of legal protections and contributor requirements. For example, it includes a patent license that grants users the ability to use any patents held by the contributors to the software, and it includes trademark protection and more explicit contribution terms.
The BSD license, on the other hand, does not include explicit patent, trademark, or contribution terms. The 2-clause BSD license is very similar to the MIT License, while the 3-clause BSD License adds more requirements or restrictions related to reuse and other terms.
How do I make sure I stay in compliance with the MIT License?
To make sure that you know what dependencies are governed by an MIT License and make sure they’re compatible with dependencies governed by other license types, here are two suggested actions:
Create a mapping of your open source dependencies
To understand which dependencies governed by an MIT License, you first need to understand what dependencies are in your software—including both direct dependencies and transitive dependencies, which are the dependencies of your dependencies.
You can generate a Software Bill of Materials, or SBOM, for your software program to get a list of all of your dependencies, including package names, versions, and licenses. If you're already using an SCA (Software Composition Analysis) tool, you can likely use this tool to generate an SBOM automatically. You can also use free and open source tools like Syft or Tern to generate SBOMs from container images, filesystems, and Dockerfiles.
Enforce policies for license usage
Implementing policies to allowlist or block certain types of open source licenses can help make sure that you're staying compliant with your organization's requirements. Many commercial SCA tools include automated license scanning capabilities. FOSSology is an open source license compliance toolkit that can execute license and copyright scans.
Final considerations
The MIT License is the simplest and most straightforward permissive license. Because of that, it's often the license of choice for developers working on smaller open source projects.
However, when choosing a license for your open source software project, make sure you consider how you want your software to be consumed; understand the different license types available to you; and choose accordingly. And before consuming open source software, you need to be aware not only of the license for the library or framework you’re using, but also the licenses of the dependencies used to build that library or framework. Accessing the software’s SBOM can help you understand this and identify any potential legal risks.
Looking for information on open source software licenses? Stacklok offers a free-to-use web app, Trusty, that provides license data and supply chain risk analysis for packages across five different language ecosystems. Try it out now at www.trustypkg.dev.
