Open Source Review Board

---
name: open-source-review-board
description: Run an open source review board that gates incoming dependencies on license compatibility, sets the policy for contributing back, and requires a security review before adoption. Use when an organization needs consistent control over which OSS it pulls in and what it publishes.
---

# Open source review board

An OSS review board is how a company keeps open source from becoming a legal and
security liability it discovers too late. It fails when it is either a
bottleneck everyone routes around or a rubber stamp that approves by default:
dependencies arrive with incompatible licenses, employees push code to public
repos with no policy, and a known-vulnerable package sits in the build because
no one checked. The board's job is to make the safe path the easy path.

## Method

1. **Gate every new dependency on license compatibility first.** Maintain an
   allow list and a deny list by license: permissive licenses like MIT, BSD, and
   Apache 2.0 usually clear; strong copyleft like GPL and AGPL needs review
   against how you distribute; anything unlicensed or with a custom license
   stops for a human. Automate the check in CI so the gate runs on every pull
   request, not on memory.
2. **Watch for license traps beyond the headline.** Attribution requirements,
   patent clauses, the AGPL network-use trigger, and the difference between
   linking and bundling. A permissive-looking package with a transitive GPL
   dependency is still a problem. The board reads the actual terms, not the
   badge on the README.
3. **Require a security review scaled to the dependency's reach.** Scan with
   something like an SCA tool or dependency scanner for known CVEs, then
   judge the project's health: maintenance activity, how fast it patches,
   single-maintainer risk, and how much of your attack surface it touches. A
   parser handling untrusted input earns a harder look than a build-time
   formatter.
4. **Set an explicit policy for contributing back.** Decide when employees may
   submit patches upstream, who signs the contributor license agreement, and
   what must be cleared before company code goes public. A clear
   yes-with-guardrails beats a vague no that engineers quietly ignore.
5. **Govern what you publish as its own decision.** Releasing an internal
   project as open source needs a license choice, a security scrub for secrets
   and internal references, a trademark check, and an owner for maintenance.
   Publishing is a commitment, not a giveaway; unowned public repos rot into
   liabilities.
6. **Keep an inventory and re-scan continuously.** Maintain a software bill of
   materials so you know what you depend on, and re-run scans as new CVEs
   land. A dependency that was clean at adoption can become the next incident;
   approval is a moment, exposure is ongoing.

## Signals

- Does license checking run automatically in CI, or rely on someone remembering?
- Is the security review proportional to what the dependency can touch?
- Can you produce a current inventory of every OSS package you ship?

## Boundaries

This governs adoption, contribution, and publication policy; it does not write
the code or decide the architecture that needed the dependency. License
interpretation at the edges is a legal judgment: escalate genuinely ambiguous or
high-stakes terms to counsel rather than settling them at the board.