Open source review board

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.