Many SaaS companies publish an open source acknowledgments page listing components, licenses and notices. Whether a license requires it for a hosted service depends on the license and your facts, so ask counsel. It is still a low effort way to show you track what you use. Not legal advice.
Why publish one
The notice duties in MIT, BSD and Apache 2.0 are written around redistribution. A hosted service may not redistribute anything, but your product often does: a browser bundle sent to users, a mobile app, a CLI, a container. For those, notices matter. A public page is one tidy place to keep them. It also gives customers and investors a quick view of how you handle licensing.
What the license texts ask for
The MIT license asks that the copyright and permission notice be included in all copies or substantial portions of the software. BSD 3 Clause asks that binary redistributions reproduce the copyright notice, conditions and disclaimer in the documentation or other materials provided with the distribution. Apache 2.0 includes conditions around keeping notices and including a NOTICE file where one exists. A page that carries these texts is one way to meet them for code you ship to browsers or devices.
What to put on the page
| Element | Notes |
|---|---|
| Component name and version | From the shipped bundle, not the repo |
| License identifier | SPDX identifier where possible |
| Copyright line | Taken from the package, not invented |
| License text | Grouped for identical texts |
| Contact | A way to ask questions about licensing |
| Date | When the list was generated |
For the build steps, see building a notices file from your SBOM.
What to leave out
Build only tools can stay off the page with an internal note explaining why. Do not list components you no longer ship. Do not add claims such as "fully compliant" that you cannot back up. Do not link logos of open source projects without checking their brand policies. See open source license names and logos.
Keeping it fresh
Generate the page from the SBOM in CI on release. A page that lags two years behind the product is worse than none, since it asserts a list that is wrong. Add the generation date so readers can judge freshness.
Where it helps in diligence
Reviewers often open the product and look for notices. A current page is a quick positive signal, and the same SBOM backs your data room files. See license evidence index.
Safeguard's SBOM and dependency scanning can supply the shipped component list, and there is a free scan at gold.safeguard.sh/scan. Choosing what to publish is a decision for you and your counsel.
Quick check
Is the page legally required for SaaS?
It depends on the license terms and what you distribute. Browser bundles and apps are distributed code. Ask counsel about your case.
Should the page list dev dependencies?
Usually not, if they are not shipped. Document the reason internally.
Sources
- Open Source Initiative, MIT license
- Open Source Initiative, BSD 3 Clause license
- Apache License 2.0 text
Last reviewed: 19 October 2026.
