To prepare your open source licenses before a sale, build a complete inventory, resolve every unknown license, sort findings against a written policy, fix the few that matter most, and assemble notices and evidence in one place. Starting early turns diligence questions into documents you already have.
Why run your own review first
A buyer's audit will find what it finds. If you run one first, you choose the order and the timing. You can fix a problem quietly, or at least explain it with a plan, instead of defending it under time pressure.
Seven steps
- Inventory. Generate a component list for every product, from lock files and from built artifacts. Include containers, mobile apps and firmware if you ship them.
- Unknowns. For each component with no clear license, read the files in the source, find the origin and record it. See blank license fields.
- Classify. Apply a policy with allow, review and deny tiers. See three tier license policy.
- Context. For anything in review or deny, note whether it ships, how it is linked, and whether you changed it.
- Fix. Replace, isolate or rewrite the ones that matter. See GPL finding remediation paths.
- Notices. Collect the license texts and notices for shipped products, and check that releases carry them.
- Evidence. Put the inventory, policy, decisions and notices in an index so you can hand it over.
What the folder should contain
| Document | Purpose |
|---|---|
| SBOM per product release | Shows what is in each release |
| License policy | Shows the rules you apply |
| Decision log | Shows each flagged item and what was done |
| Notices file | Shows attribution is handled |
| Contact for questions | Saves time during the review |
Common gaps
- Copied code with no origin recorded.
- Libraries added by a contractor and never reviewed.
- Container base images ignored.
- Fonts, icons and data sets missed.
- A decision made verbally and never written down.
Timing
Do the first pass well before any process starts. Quick fixes are easy early. Replacing a core library under deal pressure is not. See also security due diligence for sellers and what to produce for an SBOM in diligence.
Safeguard does dependency scanning and SBOM generation across your repositories, and you can set policies and gates on what may merge. You can try a free scan of a public repository to see what a component inventory looks like.
Try it yourself
Open the inventory demo and treat it as your step one list. Look for entries where you would need to confirm the license.
Click through it at your own pace, or open it full screen.
Quick check
How long before a sale should I start?
As early as you can. The work is mostly inventory and cleanup, and both go better without a deadline.
Do I disclose every finding?
What you disclose and how is a question for counsel and your advisers. Have the facts and decisions documented first.
Last reviewed: 19 October 2026.
