Document three things: your policy on contributing to open source, a list of public repositories your staff and company maintain, and the approvals or agreements that cover them. Buyers want to know that no one has published company code by accident and that you know where your own code lives. Ask counsel about ownership terms.
Why buyers ask
Open source flows in both directions. You use other people's packages, and your engineers may publish fixes or tools. Diligence teams look for two risks. One is leakage: proprietary code, secrets or customer data ending up in a public repository. The other is uncertainty: code in a public project whose ownership or license is unclear.
This is not legal advice, and ownership of employee work depends on contracts and local law, so review the specifics with a lawyer. The engineering side is to make the facts visible.
What to put in the data room
| Item | Purpose |
|---|---|
| Open source contribution policy | Shows rules exist |
| List of company owned public repositories | Shows what you publish |
| List of outbound contributions by staff | Shows what flows to other projects |
| Approval records or a lightweight review process | Shows control |
| License chosen for each published project | Shows intent |
| Contributor agreements you require or sign | Shows legal hygiene |
Steps to build the list
- Search your source control organisation for public repositories and record each with owner and license.
- Ask the engineering team to list projects they have contributed to on work time or using work systems.
- Check the organisation's list of members and outside collaborators, and remove anyone who should not have access.
- Scan public repositories for secrets and internal hostnames. Rotate anything you find, and do not rely on deleting history.
- Add a license file to each published project. The Scorecard documentation describes a license check and suggests naming license files with SPDX identifiers.
- Write the policy in one page: who approves, what must not be published, how to handle a request from a customer to contribute.
A light approval process
For a small team, a short written request works: what code, why, license, and whether it touches customer data. One named approver. Keep the answers in a folder. This is enough to show intent without slowing people down.
Personal projects
Engineers often have side projects. Your policy should say what is allowed, how to avoid overlap with company work and what to do if a personal project uses an idea from work. Decide this before a buyer asks.
Red flags
Company code in a personal account. A public repository containing credentials or customer names. An abandoned internal tool published without a license. A product built on a library whose maintainers are two employees who have since left.
How to answer
"We publish three projects under the Apache 2.0 license from the company organisation. Staff contribute upstream with manager approval. A one page policy governs this, reviewed in March." Make sure it is true, then attach the proof.
Quick check
Do we need approval for every upstream bug fix?
That is a policy choice. Many companies allow small fixes under a standing rule and ask for approval on larger contributions.
Does this replace legal advice on IP ownership?
No. It is the inventory that your lawyer will want to see.
Safeguard's dependency scanning and asset discovery can help find forgotten repositories and components. A free scan is a way to try it.
Sources
Last reviewed: 19 October 2026.
