We record the license of every package we compile. The distribution is unsurprising and worth stating plainly: **245 of 343 are MIT (71%)**, 51 are Apache-2.0 (15%), and the rest are a long scatter including 11 with no machine-readable license at all.
What MIT actually grants
Permission to use, modify, and distribute, including commercially, provided you keep the copyright notice. For a directory, that means every MIT package here can be adopted by a company without a legal conversation.
Apache-2.0 adds a patent grant and a change-notification requirement. For most users the difference does not matter; for a company with a patent portfolio, it does.
The 11 packages with no detected license are the ones to look at before adopting. No license is not the same as permissive — legally it is the opposite.
What the license does not tell you
**Whether the project is maintained.** A permissively licensed abandoned project is still abandoned. License and liveness are orthogonal and both appear in our package table for that reason.
**Whether the published version is what the repository contains.** A registry package can drift from its source; that gap is where supply-chain problems live.
**Whether the dependencies are safe.** MIT on the wrapper says nothing about the twelve packages beneath it.
The real question for a directory
License is the easiest field to collect and the least predictive, which makes it a good example of the general problem: mechanical data is cheap and shallow. It earns its place in a table — you do need to know if you can use something — but it cannot be the thing a listing is built on.
That is why our reviewed entries lead with what the server does and who should not use it, and the license is a line in the sidebar. Priority in a page is a claim about what matters.
A practical rule
Check the license before adopting, and check the last commit before relying. One is a legal constraint, the other is an engineering one, and neither substitutes for the other.