open-source-review-boardlisted

# 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