Anyone who works with open source software (OSS), whether as a developer, a contributor, or a business, has to know at least a little bit about open source licenses. In a nutshell, an open source license tells you what you can and can’t do with the open source code. And if using the code comes with any requirements and/or responsibilities, the license outlines those as well.

The most popular open source license as of this writing is the MIT license. MIT is what’s known as a permissive license, meaning you can use software under the MIT license with minimal restrictions.

But what, exactly, are the terms of the MIT license, how is it different from other permissive licenses, and what do open source developers and organizations need to know?

We’ll tackle these questions and more in this guide to the MIT license.


Read More: License Notices, Copyright Notices, and Automation: What Compliance Teams Should Know


MIT License: The Basics

The world of open source software licensing can seem pretty daunting at first. After all, there are hundreds of open source license options out there, and the topic involves enough legalese to leave any non-lawyer scratching their head. Also, any mistake or mismanagement can be serious, as the Supreme Court has ruled that these licenses are binding and legally enforceable.

So it's important to start with a solid grasp of the fundamentals.

Basically, every OSS license falls into one of two categories: permissive and copyleft. As the names imply, copyleft licenses are stronger than permissive. These require anyone who releases a modified open source program to also release the source code for that program. This type of license generally allows users to change and re-share your creation as long as they also include their source code for others, too.

On the other hand, permissive licenses give users of the open source code permission to do pretty much whatever they want with it.

As mentioned, the MIT license falls into the permissive category. It also happens to be simpler and easier to digest than many common licenses. In fact, you can read all 172 words of it right here.

Requirements

As a permissive license, the MIT license doesn’t have much by way of requirements. All you need to do is include two things in your copy and/or modification of the code:

  1. The original copyright notice
  2. A copy of the license itself

The way the MIT license works, the licensor actually applies the license with the copyright notice filled in, which can further simplify compliance.

Unlike a copyleft license, such as GPL v2 or the Mozilla Public License 2.0 the MIT license does not require those who modify the original code to also release their modification(s) under the same license. There’s no reciprocity or “pay it forward” requirement, even if you substantially rework the code. Your updated version can remain proprietary.

Can’s and Can’ts

One of the purposes of an open source license is to outline what others can and can’t do with the code. In the case of the MIT license, users are allowed to:

  • Use the code in commercial applications: For example, a company can create a proprietary piece of software that includes all or part of the original open source code, then charge money for that software.
  • Modify the code: In other words, developers can change/update the code however they’d like.
  • Distribute copies of the code and any modifications: As long as the original copyright notice and the license itself are included, an organization can distribute and sell copies or modified versions of the code.
  • Sublicense the code: This means you can incorporate the original code into a modification with a stricter license.

So, what can’t you do with MIT-licensed code? The answer is “not much,” with a few exceptions. For one, you can’t hold the code author(s) legally liable for any reason. You also can’t delete the copyright notice and original license from your version of the code.

MIT vs. Other Permissive Licenses

The MIT license isn’t the only permissive license out there, or even the only popular one. In this section, we’ll compare the MIT license with two other well-known permissive licenses: Apache 2.0 and BSD.

MIT vs. Apache 2.0

Like the MIT license, the Apache License 2.0 requires any reuse of the code to include the original copyright notice and a full-text copy of the license. However, those aren’t the only requirements. The Apache License 2.0 also states that anyone who significantly modifies the code must describe their changes. In addition, if the open source library contains a "NOTICE" file with attribution notes, users of the code must include that NOTICE as well.

Along with these restrictions come a few additional benefits. Apache 2.0 explicitly grants copyright holders the right to claim patents on their work. (Though many experts argue that the text of the MIT license provides similar patent protections.) Also, anyone who uses the code can place a warranty on the licensed software.

MIT vs. the BSD License

These OSS licenses are extremely similar and include the same basic requirements. The BSD license, however, has more variations (the BSD 3-Clause License is the most popular variant) and includes language that’s a bit less permissive. As a result, the MIT license remains the more popular of the two.

MIT License Use Cases

Whether you’re a developer, a FOSS contributor, or a tech company, the MIT license and any open source projects licensed under it offer a number of benefits.

For Developers

If you’re a developer building a new open source code project, there are several good reasons to select the MIT license for your code. For one, it’s extremely quick and easy to add the license to your project, meaning you can get V 1.0 of your creation out the door and into the hands of prospective users right away.

Also, the MIT license is very popular and likely already vetted by and familiar to your target audience. Choosing a more obscure or burdensome license might cause developers or businesses to think twice about using your code.

Do you want other companies (maybe even famous enterprises) to use your open source code in their own software? If so, the MIT license is a great choice because it allows for commercial reuse and modification of your work. After all, a well-known software company isn’t going to include your code in their propriety offerings if they have to release their modifications to the whole world.

For Companies

If a business is looking to use open source code as a component of their commercial software, libraries licensed under the MIT license are appealing options for several reasons. First, all a business needs to do is to include the copyright notice and license text as part of their release. (And, as mentioned, the way the MIT license works, the licensor applies the license with the copyright notice filled in.) For companies looking to avoid burdensome compliance requirements, this license is ideal.

And of course, your company can use the open source code in commercial applications, meaning you can make money off of it without any liability or legal concerns. Also, the MIT license allows you to keep any significant code changes under wraps, helping you keep your competitive advantage.

Well-Known Uses of the MIT License

A number of notable open source projects use the MIT license. For example, anyone who works with JavaScript has likely come across jQuery, Node.js, and/or Babel, all of which are licensed under MIT. Other examples include programming language Lua, web development framework Ruby on Rails, and the X Window System (X11).

The Future of the MIT License

The MIT license shows no signs of slowing down. Whether you decide to incorporate it into your open source project or your team’s proprietary software, it’s helpful to know the basics of this frequently used and influential license. You’re more than likely to interact with it, either directly or indirectly, over your open source career.

Want a handy cheat sheet on the basics of the MIT license? Check out tl;dr Legal.