A startup open source policy can fit on one page. It needs scope, license tiers (allow, review, deny), a named approver, an exception log, contribution rules and a review cadence. Short and followed beats long and ignored. This is general information, not legal advice.
Why a one page policy is enough at this stage
OpenChain describes ISO/IEC 5230 as a standard that identifies the key places to have license compliance processes, how to assign roles and responsibilities, and how to keep the processes going. It calls the standard lightweight. A seed or Series A team does not need a full program, but those three ideas (processes, roles, sustainability) are a good skeleton for one page.
The sections
- Scope. Which repositories, products and hosted services the policy covers. Say whether it covers build tools.
- License tiers. Allow, review, deny. Permissive licenses such as MIT, BSD and Apache 2.0 often sit in allow. Weak and strong copyleft usually sit in review or deny, depending on how the product is delivered. Keep the real lists in a file next to the policy.
- Approver. One named role, such as the engineering lead, with counsel as the escalation path.
- Exception process. Who can grant one, how long it lasts, and where it is logged. See license exception waivers with expiry.
- Contribution rules. What staff may publish or contribute to external projects, and what sign off is needed.
- Inbound code checks. Where scans run (pull request, nightly, release) and what happens on a deny result.
- Review cadence. A date for the next review, so the policy does not rot.
Example tier table
| Tier | Typical action | Example handling |
|---|---|---|
| Allow | Merge freely | Keep attribution notices |
| Review | Approver decides | Record reason and scope in the log |
| Deny | Block the merge | Replace the component or request an exception |
Which license lands in which tier is a business and legal choice, not a technical fact. Write down your choice and the date.
Make the policy checkable
A policy investors can trust is one a tool can enforce. If the deny list lives in a pull request check, the policy is a control and not just a document. The post on turning on a license gate without breaking builds covers a gradual rollout.
Try it yourself
Open the demo and watch how a pull request gate evaluates a change against a rule. Imagine the rule is your deny list.
Click through it at your own pace, or open it full screen.
Safeguard policies, gates and guardrails can enforce a rule like this at pull request time, and the SBOM and dependency scanning give the inventory behind it. Your counsel still owns the tier decisions.
Quick check
Do we need ISO/IEC 5230 conformance to raise a round?
No source I fetched says so. OpenChain presents it as something an organization can adopt, through self certification or an independent assessment. Use it as a reference, not a gate.
How long should the policy be?
One to two pages. If nobody can recite the allow, review and deny tiers, it is too long.
Sources
- OpenChain, ISO/IEC 5230 license compliance
- Open Source Initiative, MIT license
- Open Source Initiative, BSD 3 Clause license
Last reviewed: 19 October 2026.
