License guide · Permissive
The MIT license, in plain English
MIT is the most permissive license in common use, and the answer to the question most people arrive with is simply yes: you can use MIT-licensed code in commercial, proprietary, closed-source software, for free, without publishing your own source. The whole license is about 170 words, and it asks for exactly one thing in return — keep the copyright and permission notice with the software.
Updated 31 Jul 2026 · by the depproof team
General information, not legal advice. The controlling text is the license itself as shipped with the dependency. Primary source: the MIT License at the Open Source Initiative.
What MIT actually grants
The operative sentence grants permission, free of charge, to “use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software.” That list is deliberately exhaustive — it covers essentially everything a commercial product needs to do with a dependency, including selling it as part of something proprietary.
What makes MIT permissive rather than copyleft is what the license does not say. There is no condition requiring you to release your own source, no share-alike term, and no clause that reaches outward into the rest of your application. Compare that with the copyleft family, where the license deliberately propagates.
The one obligation, and why teams still fail it
The condition is short: the copyright notice and the permission notice must be included “in all copies or substantial portions of the Software.” That is the entire compliance burden.
It is also the one MIT obligation teams routinely miss — not because it is hard, but because it is per-dependency. A mid-sized application can carry hundreds of MIT components, each with its own copyright line naming a different holder. Shipping “the MIT license” once does not discharge it; you need each component’s notice. That is why the practical answer is a generated third-party notices file rather than a hand-maintained one.
Can you…? The MIT decision at a glance
| Can you… | Under MIT? |
|---|---|
| Use it in closed-source, proprietary commercial software | Yes |
| Sell a product that includes it | Yes — “sell” is granted explicitly |
| Modify it and keep your modifications private | Yes |
| Relicense your combined product under your own terms | Yes — the MIT component keeps its own license |
| Run it as a SaaS without disclosing anything | Yes — no network clause |
| Ship it without the copyright and permission notice | No — this is the one condition |
| Rely on an express patent grant | No — MIT is silent on patents |
| Expect a warranty or any liability from the author | No — provided “as is” |
The patent gap
The most consequential thing MIT leaves out is patents. MIT is a copyright license and says nothing about patent rights. Whether an implied patent license follows from the right to “use” and “sell” is a matter of argument, not of text.
Apache-2.0 closes that gap deliberately: it contains an express patent grant from every contributor, plus a defensive termination clause that revokes the grant from anyone who sues over patents in the work. For most teams shipping ordinary software the practical difference is small — but if patent exposure is part of your risk posture, this is the single reason to prefer Apache-2.0.
BSD-3-Clause sits in the same position as MIT here — permissive, notice-only, and equally silent on patents. The practical difference between them is its no-endorsement clause, not anything about what you may ship.
Weighing the two for a project of your own? See MIT vs Apache-2.0 for the full side-by-side — patents, the NOTICE obligation, and GPL compatibility.
MIT in a mixed dependency tree
MIT is rarely the problem in a dependency audit — it is the baseline that makes the exceptions visible. The practical work is not deciding whether MIT is acceptable (it almost always is), but finding the handful of components in a tree of thousands that are not MIT: the copyleft library three levels down, the source-available package that is not open source at all, or the component with no declared license.
- Check your npm dependency licenses — classify every direct and transitive package straight from the lockfile.
- Check your Maven dependency licenses — the full transitive tree, with no build.
- The license guide — plain-English pages for every license family, from permissive to network copyleft.
Frequently asked questions
Is the MIT license safe for commercial use?
Yes. MIT is a permissive, OSI-approved license that explicitly grants the right to use, copy, modify, merge, publish, distribute, sublicense and sell the software, including inside closed-source commercial products. There is no copyleft, no requirement to publish your own source, and no fee. The single condition is that you keep the copyright notice and the license text with the software you distribute.
Do I have to open-source my code if I use an MIT dependency?
No. MIT imposes no copyleft. Your own source code can stay entirely proprietary, and you can distribute your product under whatever license you choose. The MIT-licensed component keeps its own license, and you must carry its copyright and permission notice along, but that obligation attaches to that component only — it never spreads to your code.
What are the actual obligations of the MIT license?
Essentially one: include the copyright notice and the permission notice in all copies or substantial portions of the software. In practice this means shipping a NOTICE or third-party-licenses file with your application, or including the license text in your distribution. There is no attribution-in-advertising requirement, no share-alike, no source disclosure and no registration.
Does the MIT license grant patent rights?
Not expressly. MIT is a copyright license; it says nothing about patents. Some argue an implied patent license follows from the right to "use" and "sell", but that is an argument rather than an explicit grant. Apache-2.0 differs here — it contains an express patent grant plus a defensive termination clause. If express patent protection matters to your risk posture, that is the main reason to prefer Apache-2.0 over MIT.
What is the difference between the MIT and BSD licenses?
They are functionally very close — both permissive, both requiring only that the notice be preserved. The historical differences are small: BSD-3-Clause adds a clause forbidding use of the contributors’ names to endorse or promote derived products, which MIT does not state explicitly. For most dependency-policy purposes MIT, BSD-2-Clause and BSD-3-Clause can be treated as the same category of low-obligation permissive license.
Is MIT compatible with GPL?
Yes, in the direction that matters: MIT-licensed code can be included in a GPL-licensed project, because MIT imposes no condition that the GPL forbids. The combined work is then distributed under the GPL. The reverse is not true — you cannot take GPL code into an MIT-licensed project and relicense it as MIT, because the GPL requires the whole combined work to stay under the GPL.
General information, not legal advice; confirm specific decisions with counsel.