Send a notices file that lists each shipped open source component with its name, version, license identifier and the copyright and license text that the license requires you to preserve. Generate it from your inventory so it matches the release.
Why customers ask
Many open source licenses require that copyright and license notices travel with the software. A customer who redistributes your software, or who must record third party terms, asks for the list. Their legal team may also be checking that nothing in the list conflicts with their own obligations.
The MIT license summary at choosealicense.com shows the pattern: conditions are limited to preserving the copyright and license notice, while larger works may be distributed under different terms and without source code. Other licenses add more conditions, such as source availability for strong copyleft licenses.
What belongs in the file
- Component name and version.
- License identifier, ideally an SPDX identifier.
- Copyright holder statement as published by the component.
- Full license text, or a link where the license permits.
- Any required notices for the license family.
SPDX describes itself as an open standard for communicating bill of materials information including license data, and its identifiers give you consistent license labels.
How to produce it
| Step | Detail |
|---|---|
| Start from the release inventory | Same version the customer runs |
| Resolve license fields | Pull from package metadata, flag unknowns |
| Review unknowns by hand | Missing or custom licenses need a person |
| Collect license texts | From the component sources |
| Publish with the release | Same artifact as the build |
Treat "unknown" as a work item, not a default. A file with unexplained blanks invites questions.
Common pitfalls
- Listing direct dependencies alone.
- Copying the license name without the required notice text.
- Producing the file once and never refreshing it.
- Including internal packages that do not belong in a public list.
Reply template
Attached is the third party notices file for version X, generated from the release inventory on date. It lists each component, version, license identifier and the associated notices. If you need a specific format, tell us and we will provide it.
Note that this is a practical process, not legal advice. For redistribution or mixed license questions, involve counsel. For the strong copyleft side of the question, read what to say when asked about GPL and AGPL.
Keeping the file current
A notices file goes stale when dependencies change. The most reliable approach is to generate it in the same build that produces the release, then ship it as a build artifact. That removes the manual step where someone forgets to update it before a customer asks.
Add a check that fails the build when a component has no license identifier, so unknowns are resolved at the time of adoption rather than discovered during a customer request. Over time the file becomes a by-product of normal work.
Quick check
Is an SBOM the same as a notices file?
No. An SBOM lists components and metadata. A notices file also carries the license and copyright text.
Do we need notices for build tools that do not ship?
Generally the file covers what you distribute. Confirm the scope with counsel for your case.
Sources
Last reviewed: 19 October 2026.
