Approve employee contributions in tiers. Small fixes to projects you already use can be self-serve with a checklist. Larger features need the program owner. Releasing your own code or contributing company-specific code needs legal review too. The higher the confidentiality or license risk, the more reviewers.
Why tiers
If every contribution needs a legal sign-off, employees stop contributing or do it quietly from personal accounts, which is worse. The Linux Foundation guide says guidelines and checklists should help developers contribute without running into licensing or confidentiality issues, and that an internal review process is a useful safe place to get feedback, especially for new contributors.
The tiers
| Tier | Example | Approval |
|---|---|---|
| 1: Trivial | Typo, documentation fix, small bug fix to a project you use | Self-serve, follow the checklist |
| 2: Substantive | New feature or larger fix to a project you use | Team lead plus program owner |
| 3: Sensitive | Anything derived from proprietary code, customer data, or security-sensitive design | Program owner plus legal, and security if relevant |
| 4: New release | Publishing a company project as open source | Full review, see below |
The self-serve checklist for tier 1
- The change contains no proprietary code, customer data, credentials or internal URLs.
- It is your own work or from compatible licensed code.
- You are contributing under the project's license and its sign-off rule. See the DCO explained.
- You use your work account or disclose affiliation as the project asks.
- A security fix goes to the project's private reporting route, not a public pull request.
Tier 4: releasing company code
The guide lists policy topics: how approvals are received, how to prepare for releases, and rules that determine when code should be released or kept as intellectual property. A release review usually covers ownership and license of every file, secrets in history, dependency licenses, trademarks, security review, support expectations and who maintains it. A simple form with these questions beats an email thread.
Speed rules
- Publish a service level: tier 2 in three working days, tier 3 in ten.
- Make silence a yes for tier 1, since a checklist is the control.
- Log all requests so you can count them and spot patterns.
- Pre-approve projects you contribute to often.
Scaling by size
- Around 10 people: tiers 1 to 3 handled by the founder or owner in a message thread.
- Around 100: a form, with legal on call.
- Around 1,000 or more: local reviewers decide tiers 1 to 3 and a central group handles tier 4, in line with the guide's description of large programs moving decisions to local reviewers.
For more on corporate policy, see corporate open source contribution policies.
Where Safeguard fits
Safeguard's policies and gates can run checks on pull requests in your own repositories, and its dependency scanning surfaces license and advisory data for what you ship. A free scan is available at gold.safeguard.sh/scan.
Quick check
Do employees need permission to fix a typo upstream?
Not with a clear tier 1 policy. A checklist is enough for trivial changes.
Who owns code an employee contributes on company time?
That depends on employment terms and local law. Have counsel confirm your agreements say what you intend.
Sources
Last reviewed: 19 October 2026.
