A 10 person team needs six short rules on one page: who decides, which licenses are allowed, how components are recorded, how updates and vulnerabilities are handled, how employees contribute upstream, and how you retire a dependency. Anything longer will not be read, and an unread policy protects nobody.
Why one page
The Linux Foundation guide on creating an open source program warns about policy that grows until nobody can do anything: lawyers, security staff and business owners all add their concerns and you end up with a strait jacket. Its advice is a well-defined, minimal policy that is reviewed again and again, asking why each rule exists. A small team starts with that advantage. Keep it.
The six rules
| Rule | What it says | Example wording |
|---|---|---|
| 1. Owner | One named person decides open source questions | "Priya owns open source decisions. Backup: Sam." |
| 2. Licenses | Allowed, needs review, not allowed | A three tier list, see below |
| 3. Record | Every direct dependency is in a list the team can see | "Generated from the lockfile on every build." |
| 4. Updates | How fast you patch and who watches advisories | "Critical advisories reviewed within two working days." |
| 5. Contributing | Employees may send fixes upstream if the code is not confidential | "Tell the owner first for anything beyond a typo fix." |
| 6. Exit | How a dependency gets replaced when it dies | "Owner opens a ticket, replacement chosen within a sprint." |
The wording is an example, not a standard. Pick numbers your team can actually meet.
Rule 2 in detail: the license list
Do not write a legal essay. List license families under three headings: allowed without asking, ask first, and not allowed. A starting layout is in a three tier open source license policy. Have counsel look at the final list once, especially if you ship software to customers or distribute a mobile app.
Rule 3 in detail: the record
The policy line is the easy part. The hard part is that the record stays true. Generate it from lockfiles or an SBOM during the build rather than keeping a spreadsheet by hand. A hand-kept list is stale within a month.
Rule 5 in detail: contributing
The same guide suggests an internal review path as a safe place to get feedback before a first contribution, and checklists so developers can contribute without running into licensing or confidentiality issues. For ten people, that is a short message to the owner and a rule that proprietary code, customer data and credentials never appear in a public pull request. See corporate open source contribution policies for more.
What to leave out
- Approval boards. With ten people, the owner plus a second reader is enough.
- Training programs. A twenty minute walkthrough at onboarding will do.
- Metrics. Pick one number, such as direct dependencies with a known license, and check it monthly.
Make the policy enforceable
A rule that depends on memory fails on a busy Friday. Wherever possible, turn a sentence into a check in the pull request. Safeguard's policies, gates and guardrails can block a change that adds a component from the not allowed list, and its SBOM and dependency scanning keeps the record current. A free scan is available at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen. Watch how a rule from your page becomes a pull request check.
Quick check
Do we need a lawyer to write this?
Not for the draft. Ask counsel to review the license list and the contribution rule once, since those carry legal consequences.
How often should we review the policy?
Twice a year is reasonable for a small team, or after any incident or acquisition. Remove rules nobody follows.
Sources
Last reviewed: 19 October 2026.
