What this license is
This is the absence of a license, not a kind of license. When an author publishes code and says nothing about terms, copyright law fills the gap, and the default in most countries is that all rights are reserved. Putting the code on a public registry does not change that. Publishing to npm grants npm and its users the rights npm's own terms describe, for running the registry. It does not grant you a license to put the code in your product. A large share of small repositories on GitHub are in this position.
Why it matters for your product
With no license you have no permission to copy, modify, redistribute or ship the code. That holds however convenient the package is, and however long it has been in your build. An internal-only tool carries lower practical exposure, but the legal position is the same. Treat accepting it as a decision somebody writes down, not as an assumption. The worst case is a library or SDK you hand to other developers, because there you would be passing on rights you never had. Ask the maintainer, or replace the dependency.
You are meeting the terms when
- You have looked where a license actually hides before concluding there is none: the README, the file headers, the package manifest, and the source repository.
- You have asked the maintainer in writing and have their answer. A polite issue asking them to add a license works more often than people expect.
- You have replaced or removed the dependency when no permission arrives. For anything you ship, that is the only reliable answer.
- You have written down the decision and the evidence if your organization accepts the exposure for an internal tool. An accepted exposure is a decision, not an assumption.
- You have kept it out of any product, binary or library you hand to someone else, where you would be sub-licensing rights you do not hold.
Where teams get it wrong
- Teams read no LICENSE file as no license. The terms may sit in the README, in the file headers, or in the package manifest, and any of those counts.
- Teams read no license as public domain. It is the opposite: with no license the author keeps every right, and public domain gives them all away.
- Teams confuse UNLICENSED in a package manifest with the SPDX id Unlicense. The first means deliberately not licensed, the second is a public domain dedication.
- Teams treat a not found result as proof of absence. It can also mean the artifact was too large to inspect, which is a limit of the fetch and not a fact about the package.
How SourceTrust handles this license
SourceTrust separates three findings that look alike. The package declares no license and no license file is found anywhere: the resolution lands on the proprietary state, which is the all rights reserved reading. An id is declared but the text for that exact version is missing: the result is unconfirmed, and the terms are almost certainly the ordinary ones for that id. The fetch cannot produce text at all: the result is not found, and it carries a cause. Only the first is really no license. Read Auto-fetch license text.
- The not found cause tells you which situation you are in: the artifact ships no license file, the version was never published, or the artifact was too large to inspect.
- None of these states fills in license text by itself. Only confirmed does that, so a person accepts every other outcome explicitly.
- The evidence links the fetch collected, the registry page and the source repository, sit next to the finding so you can go and look for yourself.