MIT License and Commercial Use: What 483 Dependencies Actually Oblige You To Do

Yes — the MIT license allows commercial use, including selling software built on MIT-licensed code, without publishing your own source. The permission is unconditional. The obligation is not: you must reproduce the copyright notice and license text in every distribution. This storefront depends on 483 MIT packages, so that obligation is 483 notices, not one.

The whole license, in two halves

The MIT license is roughly 170 words, and only two sentences do any work. The first grants permission "to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies." That is where commercial use comes from, and it is not hedged — no field-of-use limit, no revenue threshold, no requirement to open your own code.

The second is the price:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

Every practical MIT question resolves to one of those two sentences. "Can I sell it?" is the first. "What do I owe?" is the second. The second is the one that gets skipped, because at the scale a modern JavaScript project operates it stops being a copy-paste job and becomes an inventory problem.

What one commercial Next.js codebase actually depends on

Counted on 2026-08-26 by walking every package.json under node_modules in this repository — the ASoc storefront, a production Next.js 16 + Tailwind v4 marketplace (Tailwind's own MIT grant is narrower than the name suggests once Tailwind Plus and a seller's EULA enter the picture — see the three licences hiding under "Tailwind"):

551 packages total, 513 of them (93.1%) MIT or ISC — two licenses whose obligations are identical in practice. That concentration is why "is MIT okay commercially" is a question that answers itself for most teams: if it were not okay, essentially no commercial JavaScript product could ship.

The 26 direct dependencies are even more lopsided — 24 MIT, one ISC (lucide-react), one Apache-2.0 (typescript). Every transitively-pulled non-permissive package in this tree arrived underneath a build tool, not from a deliberate choice: the two LGPL entries are @img/sharp-libvips-linux-x64 and its musl sibling (Next's image pipeline), the four MPL-2.0 entries are lightningcss and its platform binaries plus axe-core, and the single CC-BY-4.0 is caniuse-lite.

None of those are a problem for shipping a commercial product, and it is worth being precise about why rather than hand-waving. MPL-2.0 is file-level copyleft: it obliges you to publish the source of MPL-licensed files you modify, and we modify none of them. LGPL obliges you to let a user swap in their own build of the library; a dynamically-linked native binary invoked by a build tool satisfies that without touching your application code. CC-BY-4.0 on a browser-support dataset obliges attribution. In all three cases the obligation lands on the dependency, not on your source.

MIT versus the licenses it gets confused with

Two rows explain the whole table. Apache-2.0 exists because MIT is silent on patents — MIT grants copyright permission and says nothing about whether a contributor can later assert a patent against you, whereas Apache-2.0 grants patents explicitly and terminates that grant if you sue. GPL-3.0 exists because MIT lets you take without giving back, and GPL does not.

A common misreading: because MIT is silent on patents, people conclude it grants none. Most legal analysis treats "to deal in the Software without restriction" as carrying an implied patent license, but "implied" is doing work in that sentence, and it is why organisations with real patent exposure prefer Apache-2.0. Neither position changes whether you may sell the software.

The obligation, and where it actually breaks

The notice requirement is the part that fails audits, and it fails for a mundane reason: nothing in a standard toolchain does it for you. next build produces a .next directory containing minified bundles from hundreds of MIT packages and not one line of license text. There is no warning, no build failure, and no lint rule.

It is also not uniformly easy to comply with. Of the 483 MIT packages installed here, 462 ship a LICENSE file in the published tarball and 21 do not — those 21 declare "license": "MIT" in package.json and leave you to reconstruct the copyright line from their README, their repository, or the SPDX template plus the author field. That gap is the single most useful number to know before you promise an enterprise customer a complete attribution report, because it is the part no script gets right on the first pass.

What compliance actually looks like, in ascending order of effort:

1. Ship the node_modules license texts alongside the build — correct and trivially automatable for a self-hosted app, useless for a browser bundle.
2. Generate an attribution file at build time from the installed tree and serve it at a stable URL. This is the normal answer for a web product, and it is why so many apps have a "Third-party licenses" page nobody visits.
3. Vendor the notice into the artifact — a licenses block in the bundle footer. Required when you distribute a file rather than a service.

The distinction that decides which one you owe is distribution, not commerce. A SaaS product that never hands the user a copy has a much thinner obligation than a template you download as a zip. Which is exactly the case this storefront sits on.

Two licenses in one product, which is normal

This is where MIT stops being an abstract question. The ASoc catalog ships 111 premium products, each delivered as a versioned zip from a private bucket. Every one of them is built on the same permissive dependency tree measured above, and every one of them is sold under a proprietary end-user licence agreement — the tiered EULA at src/app/license/page.tsx, which limits developer seats and end-user monetisation rather than domains.

Those two facts are not in tension, and the reason is the first sentence of MIT: sublicensing is explicitly permitted. You may take MIT-licensed React, build something on it, and license your work however you like. What you may not do is strip the notices of what you built on.

The free editions published on GitHub go the other way: they are MIT, which is a genuinely different offer rather than a smaller version of the commercial one. MIT means a recipient may redistribute them, resell them, and use them for clients with no seat limit — permissions the paid EULA does not grant. Vendors who describe their free tier as "MIT" and then attach usage restrictions to it are describing something that is not MIT. The full tier-by-tier reading of the commercial licence covers what the paid side does restrict.

Mistakes and how they show up

Frequently asked questions

Can I sell software that uses MIT-licensed code without paying anyone? Yes. The grant explicitly includes the right to "sell copies," with no royalty, revenue share, or notification. This entire storefront — 111 commercial products — rests on that clause, alongside essentially every commercial JavaScript product shipped in the last decade.

Do I have to open-source my own code if I use MIT dependencies? No. MIT has no copyleft provision of any kind. That is the whole difference between it and the GPL family, and it is why 87.7% of the packages in this tree are MIT: it is the license that imposes the least on the person downstream.

Where exactly do I have to put the copyright notice? "In all copies or substantial portions of the Software" — meaning wherever you distribute the code. For a web app served rather than distributed, a third-party-licenses page reached from your footer is the accepted practice. For anything a user downloads as a file, the notices belong inside the artifact. If you are unsure which you are doing, ask whether the user ends up with a copy on their disk.

Is ISC different from MIT in any way that matters? Not for a distributor. ISC is a shorter drafting of the same bargain — the OpenBSD project removed language it considered redundant under the Berne Convention. lucide-react, the icon set every page of this site renders, is ISC, and it is handled identically to the 483 MIT packages beside it.

Does MIT let me use the project's name or logo in my marketing? No, and this is the trap MIT's brevity sets. The license covers copyright, not trademark. You may ship the code and say your product is built with it; you may not imply endorsement or use the mark as your own. Apache-2.0 says this out loud in section 6; MIT leaves it to trademark law, which reaches the same answer.

Templates that ship this dependency tree

ASoc Catalyst, ASoc Chain and ASoc Cognition are built on the same permissive stack measured above — Next.js, React and Tailwind, all MIT — and are delivered under the tiered commercial licence rather than MIT, which is precisely the sublicensing arrangement the first sentence of MIT permits.

Browse the full sets: Next.js landing page templates and Tailwind landing page templates. For what the commercial side of that arrangement restricts, read template licenses explained; for how the licence interacts with refunds and delivery, the digital-product refund policy.