Generate the list from your lockfile or SBOM, record each package's license as an SPDX identifier, flag packages with a missing or unusual license, and give the result to the client with a note on who reviews meaning. The inventory is a factual record. Interpreting licenses is a job for counsel.
This is not legal advice.
Why clients ask
Clients who resell, embed or acquire software want to know what is inside it. Many procurement forms include a question about open source licenses. An inventory answers it with data instead of reassurance, and it protects the agency if the question comes up a year later.
Use standard identifiers
The SPDX License List catalogs commonly found licenses and exceptions. Each entry has a short identifier, such as MIT, Apache-2.0, BSD-3-Clause or GPL-3.0-only. Exceptions are combined with the WITH operator in expressions like GPL-2.0-or-later WITH Autoconf-exception-2.0. The list exists so everyone can refer to a license the same way, and the site recommends short identifiers in source code.
The npm documentation says package authors should specify a license, ideally with an SPDX identifier, and to use UNLICENSED for private packages with no license. Your own client-specific packages should follow that rule.
Steps
- Start from the committed lockfile or an SBOM generated in CI. Both list direct and transitive packages.
- Export the license field for each package. SBOM tools and many scanners do this.
- Normalize to SPDX identifiers. Map odd strings to the closest identifier and note where you were unsure.
- Sort into groups: permissive, weak copyleft, strong copyleft, unknown, none.
- Investigate unknown or none. Check the repository or ask the maintainer. A package with no license is not free to use by default.
- Record the date and tool.
- Deliver the list with the handover pack.
| Column | Example |
|---|---|
| Package | example-package |
| Version | 1.3.0 |
| Direct or transitive | Transitive |
| License (SPDX) | MIT |
| Source of license data | package metadata |
| Notes | Verified in repository |
Common gaps
- Dual-licensed packages listed with an expression, such as MIT OR Apache-2.0. Keep the whole expression.
- Metadata that disagrees with the repository's license file.
- Fonts, images and icons, which do not appear in a package manager but have licenses too.
- Code copied from tutorials or snippets sites.
What not to say
Do not tell a client that a license is safe or compatible with their plans. SPDX itself says it records facts and does not make legal interpretations. Describe what the license is, and recommend counsel review for anything beyond permissive.
Try it yourself
Click through it at your own pace, or open it full screen.
Open the inventory and look for the license information on each component. That is the data you will export.
Quick check
Do I need licenses for development dependencies?
List them separately. They may not ship, but some clients want the full tree.
What if a package has no license?
Treat it as a gap to resolve before delivery: contact the maintainer or replace it.
Sources
Last reviewed: 19 October 2026.
