The MIT licence explained: what you can do, and the one thing you must

Every open-source project in our catalogue uses the MIT licence. It's one of the shortest and most popular software licences in the world, and one of the most generous. In a few lines it gives you almost every right you could want, asks for one thing in return, and makes clear that the software comes with no guarantees. Here's what that means in practice.

What the MIT licence lets you do

The licence grants permission, free of charge, to anyone who gets a copy of the software to deal in it without restriction. It then spells out what that includes. You may:

• Use it, for personal, commercial or any other purpose.
• Copy it.
• Modify it.
• Merge it into other software.
• Publish it.
• Distribute it.
• Sublicense it, which means including it in a product you release under different terms.
• Sell copies of it.

In other words, you can build a paid, closed-source product on top of MIT code. You don't have to publish your changes, and you don't have to release your own code under MIT.

The one condition

The copyright notice and the permission notice must be included in all copies or substantial portions of the software. In practice that means keeping the project's LICENSE file, or its text, with the code you ship. If you bundle an MIT library into an app, many teams list it in a “third-party notices” or “open-source licences” screen or file.

No warranty

The last part of the licence says the software is provided “as is”, without warranty of any kind, and that the authors aren't liable for any claim or damage arising from it. If an MIT library has a bug that costs you money, the licence gives you no claim against its authors. That's standard for open source, and it's a good reason to test and review what you depend on.

What MIT doesn't cover

• Trademarks. The licence covers the code, not the project's name or logo. Using a project's brand to market your own product is a separate question.
• Patents. MIT doesn't mention patents explicitly. Licences like Apache-2.0 include an express patent grant, which some companies prefer.
• Other files in the repo. Images, fonts, datasets or bundled third-party code may come under different licences. Check before you reuse them.

How MIT compares

The big divide is between permissive and copyleft licences. Permissive licences like MIT, BSD and Apache let you do almost anything as long as you give credit. Copyleft licences like the GPL require that if you distribute software built on the code, you share your source under the same licence. Neither is better in the abstract: copyleft keeps derivatives open, permissive maximises reuse. A related licence, the AGPL, extends the GPL's sharing requirement to software offered to users over a network.

OOpen-source license review checklistPromptA checklist for reviewing licences before you depend on a project.Free promptReactOpen sourceOne of many widely used projects released under MIT.★ 252k · MITNext.jsOpen sourceAnother MIT-licensed project you can build commercial sites on.★ 143k · MIT

A quick checklist for using MIT code

1. Confirm the licence. Check the LICENSE file in the repository, not just the label on a website.
2. Keep the notice. Include the licence text with your distribution, or in a notices file.
3. Check bundled extras. Assets and vendored dependencies may have their own licences.
4. Respect the brand. Don't imply the original authors endorse your product.
5. Test it. There's no warranty, so its quality is your responsibility once you ship it.

Common questions

Do I have to credit the project inside my app?

The licence asks for the notice to be included with copies of the software, not for a visible credit in your interface. Shipping the licence text in a notices file or an “open-source licences” screen is the usual way to meet it. A thank-you in your docs is a nice extra, not a requirement.

Can I put my own licence on a project that uses MIT code?

Yes for your own code and for the combined product, which is what the sublicense permission allows. What you can't do is remove the original authors' copyright and permission notice from the parts they wrote.

What if the authors change the licence later?

Authors can release future versions under different terms. Copies you already received under MIT remain under MIT, so you can keep using, and even maintain, the last MIT-licensed version. Keep a record of the version and licence you depend on.

Do I have to share my improvements?

No. Contributing fixes back is encouraged and often saves you maintaining a private fork, but MIT doesn't require it.

Why our catalogue uses MIT

We list only MIT-licensed repositories in the open-source section so you can assume the same simple terms on every page: use, change and ship freely, keep the notice. Agent skills come from a wider set of permissive licences, including Apache-2.0, BSD and several Creative Commons and public-domain options, and each skill page shows its own licence. Whatever the label says, the licence file in the download is the one that counts.