To build a third party notices file, take your SBOM as the component list, collect each component's copyright notice and license text, group identical texts, and ship the file with your product. Licenses such as MIT, BSD and Apache 2.0 ask you to keep notices when you redistribute. Not legal advice.
Why the file exists
The MIT license says the copyright notice and permission notice shall be included in all copies or substantial portions of the software. BSD 3 Clause asks that redistributions in source form retain the copyright notice and conditions, and that redistributions in binary form reproduce them in the documentation or other materials provided with the distribution. Apache 2.0 has its own redistribution conditions, including carrying along a NOTICE file when the project has one. A single notices file is the common way to meet these duties for many components.
Steps
- Start from the shipped inventory. Generate the SBOM for the artifact you ship, not for the repo. A mobile app bundle and a backend service have different lists.
- Resolve license identifiers. Turn messy names into SPDX identifiers. See normalizing license names.
- Fetch the texts. For each component, take the license file and copyright line from the package itself, not from a generic template. The SPDX package fields include a copyright text field for this purpose.
- Group by license text. Many components share identical MIT text with different copyright lines. Keep each copyright line, group the rest.
- Include NOTICE content. If a component ships a NOTICE file under Apache 2.0, include its content. The checklist in Apache 2 NOTICE file redistribution helps.
- Ship it. Put the file where recipients can read it: in the installer, an About screen, a docs page, or a path in the container image.
- Regenerate on every release. A stale file is a common finding.
Layout that reviewers like
| Section | Contents |
|---|---|
| Header | Product, version, generation date |
| Index | Component, version, SPDX identifier |
| Notices | Copyright lines and the grouped license texts |
| Appendix | NOTICE file contents, special terms |
Common gaps
Transitive dependencies are the usual miss, since they never appear in your manifest. Vendored code is the second, because no package metadata describes it. Build only tools are not shipped, so they normally do not belong in the file, but record why you left them out. The post on build time or shipped licenses explains the split.
Automate the check
Generate the file in CI and fail the build if a component has no resolved license. That turns the notices file into a release control instead of a yearly scramble. During diligence you can then show the file for each release.
Safeguard's SBOM and dependency scanning supply the shipped component list that this process starts from, and there is a free scan at gold.safeguard.sh/scan for a first pass. The texts and wording remain your responsibility.
Quick check
Do we need a notices file for a hosted SaaS?
The notice duties in these licenses are tied to redistribution. Whether a hosted service counts depends on the license and facts, so ask counsel. Many companies publish an acknowledgments page anyway.
Can one generic MIT text cover every MIT component?
The license asks that the copyright notice be included, and each project has its own copyright line. Group the license text but keep each notice.
Sources
- Open Source Initiative, MIT license
- Open Source Initiative, BSD 3 Clause license
- Apache License 2.0 text
- SPDX 2.3.1, package information
Last reviewed: 19 October 2026.
