Before each release, build the inventory, classify each license, decide what you distribute, then produce notices, source offers and records for exactly what ships. SaaS and mobile differ mostly in what counts as distribution. Hosted code is not usually handed to users, while an app binary is. Not legal advice.
Definition: the trigger is distribution
Most open source duties, such as source release and notice delivery, attach when you give copies to others. The GNU FAQ states that the GPL lets you modify and use software privately, including inside an organization, and that release duties begin when you release it to others. Network licenses such as the AGPL differ, and browser delivered code counts as distribution.
| Delivery model | Do copies reach users? | What usually applies |
|---|---|---|
| Hosted backend | No | Network copyleft licenses, internal use rules |
| Browser bundle | Yes | Notices and any copyleft source duties for shipped code |
| Mobile app | Yes | Notices screen, source offers for copyleft code |
| Desktop installer | Yes | Notices, source offers, bundled runtimes |
| Firmware or device | Yes | All of the above plus installation information for GPLv3 |
The checklist
- Inventory. Generate a component list for the exact build, including transitive packages, native libraries, fonts, icons and models.
- Identify licenses. Record an SPDX identifier per component. Flag blank, custom or conflicting entries.
- Classify. Use tiers such as allow, review and deny. Copyleft families go to review when the component ships.
- Decide on shipping. For each reviewed component, say whether it reaches users, how it is linked, and whether you modified it.
- Notices. Produce a third party notices file or screen with licenses and copyright lines. Keep Apache NOTICE contents where they apply.
- Source duties. For copyleft code you distribute, prepare corresponding source for the exact release and a way to get it.
- Assets. Check creator credits for CC BY style assets and confirm no non commercial item is in a commercial build.
- Exceptions. Record approved exceptions with an owner and an expiry date.
- Archive. Store the SBOM, the notices and the decisions with the release tag.
- Gate. Make the build fail when a denied license appears or an unreviewed one arrives.
Who does what
Engineering owns the inventory and the gate. Legal owns tier decisions and exceptions. Product owns the shipping decision. Releases go smoother when each task has a named owner and the record lives next to the code.
Common failure points
- Transitive packages that update silently.
- Vendored code that scanners do not read.
- Mobile apps with a notices screen generated from metadata that omits assets.
- Docker base images that add packages after your scan.
- Old notices left in place after a dependency is removed.
Try it yourself
The pull request gate demo shows a check holding a merge until a rule passes. Click through it and picture step 10 of this checklist as that rule.
Click through it at your own pace, or open it full screen.
Safeguard's SBOM and dependency scanning generate the inventory in step 1, and policies, gates and guardrails can enforce step 10 in pull requests. You can start with a free scan at gold.safeguard.sh/scan.
Quick check
Do SaaS companies have open source license duties?
Yes, though many duties depend on distribution. Browser code, agents, SDKs and network copyleft licenses can still apply.
How often should I run this checklist?
Run the inventory and gate on every pull request, and the full checklist on every release.
Does a mobile app need to list licenses?
Most open source licenses ask for notices when you distribute copies, and an in app screen is a common way to deliver them. Check the licenses you use.
Sources
Last reviewed: 19 October 2026.
