A good open source usage policy can be short. The TODO Group's guide to using open source code suggests six simple rules: get approval before integrating, audit third-party software, review all dependencies, meet license obligations before release, treat approvals as product-specific, and re-review changed components.
What a usage policy is for
A usage policy is the set of rules that decides whether a component may enter a product. The TODO guide says it ensures software, whether proprietary, third-party or open source, has been audited, reviewed and approved, and that the company has a plan to meet the license obligations before products reach customers. It adds that the document does not need to be lengthy or complicated.
The six rules, in plain words
The guide lists these rules. We have restated them, and added a note on what each means in practice.
- Approval before integration. Engineers get sign-off from the review board before using open source code in a product. In practice, this means a request step that happens before the merge, not after.
- Audit third-party software. Software you receive from suppliers must be checked for the open source inside it, so obligations can be met before shipping.
- Review everything, including proprietary components. Proprietary code can contain borrowed open source, so it is not exempt.
- Meet obligations before the customer receives the product. Notices, source offers and similar duties are release tasks.
- Approval is specific to a product. The guide states that approval to use a component in one product is not approval for another deployment, even if the component is the same.
- Changed components go back through review. An upgrade or modification re-triggers the process.
Turning rules into checks
Rules are only useful if someone can tell whether they were followed. Map each one to an observable signal.
| Rule | Signal you can check |
|---|---|
| Approval before integration | Every new dependency in a pull request links to an approved request |
| Audit third-party software | Supplier SBOMs or scan results on file |
| Review everything | Inventory covers proprietary and vendor code |
| Obligations before release | Release checklist includes notices |
| Product-specific approval | Approvals recorded per product and version |
| Re-review on change | Version or license change opens a ticket |
If you cannot name the signal, the rule is a wish. Start by automating the first one, since a gate on new dependencies is the most direct way to enforce it. See an open source policy template for enterprises for a longer starting document.
Keep the process light
The same guide quotes an open source leader warning that an overly burdensome review process slows innovation and gives developers an excuse to go around it. Aim for a policy a new engineer can read in five minutes, and a request form with mostly drop-down answers.
Try it yourself
Click through it at your own pace, or open it full screen. Watch how a pull request is blocked or allowed by a rule, which is how rule one becomes automatic.
How Safeguard fits
Safeguard offers policies, gates and guardrails, plus SBOM and dependency scanning, so rules like these can run on pull requests. The free scan at gold.safeguard.sh/scan shows what a first inventory looks like.
Quick check
Is the policy legal advice?
No. Have your own counsel review how license terms apply to your products. This post covers process, not legal interpretation.
Do the six rules apply to internal tools?
The guide frames them around products that ship. Many teams apply a lighter version to internal tools. Decide that explicitly and write it in the policy.
Sources
Last reviewed: 19 October 2026.
