The MIT License has one main condition. The copyright notice and the permission notice must be included in all copies or substantial portions of the software. If you redistribute MIT code, those notices travel with it. Otherwise the license lets you use, copy, modify, merge, publish, distribute, sublicense and sell.
The single condition
According to the license text, notices "shall be included in all copies or substantial portions of the Software." That is the whole duty for redistribution. There is no NOTICE file mechanism and no requirement to mark changes, unlike Apache 2.0.
Simple does not mean automatic. Across a product with hundreds of MIT packages, keeping the notices is a real task.
Where the notices should live
The license does not say where, only that they accompany the copies. Common places:
- A third party notices file in the download or container image.
- An "open source licenses" screen in a mobile or desktop app.
- A documentation page linked from the product.
Pick the place your recipients will actually look, and keep it current with each release.
Bundled and compiled code
Front end bundlers often strip comments, including license headers, to reduce file size. If your build removes the notice from a bundled MIT library, you can lose the very thing the license requires. Configure the bundler to emit a license file, or generate a notices file separately from the package metadata.
A practical process
- Produce a list of all components in the shipped artifact, not only direct dependencies.
- For each MIT component, capture the copyright line and the permission text from its license file.
- Write them to a combined notices file during the build.
- Fail the build if a component lacks a license file, and review it by hand.
- Include the notices file in what customers receive.
- Re-run on every release, because dependency versions change.
Edge cases
Some packages say MIT in the manifest but have no license file in the tarball. Others have a license file with a modified copyright line. When the manifest and the file disagree, trust the file after reading it, and tell the maintainers.
If a package is dual licensed, for example MIT OR Apache-2.0, you pick one. Record your choice. See SPDX OR versus AND.
Why it still matters
Missing notices are among the easiest license problems for a reviewer to spot, and the easiest to avoid. A buyer's diligence team may ask for your third party notices. Having a generated file ready answers the question quickly. Related reading: MIT license meaning in plain English and the Apache 2.0 checklist.
Safeguard's SBOM and dependency scanning supply the full component list, and you can try a free scan.
Quick check
Do I have to credit every MIT package in my app?
If you redistribute them, the copyright and permission notices must be included with the copies.
Do I need to mark my modifications?
MIT does not require it. Check any other licenses in your tree, since some do.
Sources
Last reviewed: 19 October 2026.
