When a developer at a large company wants to fix a bug in a project their team depends on, the path from "I see the problem" to "my patch is merged upstream" often runs through a set of internal gates that most outsiders never see. Those gates, codified in corporate open source contribution policies, exert an outsized influence on who participates in open source and what they are allowed to contribute. Understanding these policies matters not just for employment law reasons. It shapes the actual contributor pool of every major project.
The public open source world is largely built by employed engineers. Tidelift's 2023 maintainer report found that more than half of maintainer hours are either fully or partially compensated, most often through employment rather than sponsorship. This is especially true for the projects that enterprises actually depend on: Kubernetes, Node.js, PyTorch, the Linux kernel. Who gets to contribute, under what conditions, and with what IP assumptions, is determined by corporate policy at employers like Google, Microsoft, IBM/Red Hat, AWS, and thousands of others.
The Pre-Approval Model
The oldest and most conservative corporate model requires pre-approval for any external contribution. An engineer identifies a project, submits an internal request, and waits for clearance. Clearance typically involves legal review of the project's license, security review of the contribution itself, and a determination that the work does not touch protected intellectual property.
IBM, prior to its Red Hat acquisition, operated on a pre-approval model for decades. The IBM Open Source Steering Committee reviewed contributions against a matrix of license compatibility and business alignment. This produced consistent IP hygiene but slow velocity. A trivial typo fix could take weeks.
Oracle has historically operated a similar model. The 2024 leak of Oracle's internal OCLA workflow documents (shared publicly by former employees in various forums) illustrated a multi-step approval process that included manager sign-off, legal review, and export control screening for each contribution.
The pre-approval model is defensible when contributions are rare and the stakes of an accidental IP leak are high. It is unsustainable when a company depends on a living ecosystem of contributions.
The Default-Allow Model
Google pioneered what became the dominant model at engineering-heavy tech companies: default-allow contribution with post-hoc oversight. Google's open source policy, documented publicly through the Google Open Source office since 2017, permits engineers to contribute to approved projects without per-contribution review, subject to a set of standing rules: CLAs must be signed through Google's corporate CLA process, contributions must not include Google-confidential information, and certain sensitive areas (search ranking, ad targeting) are simply off-limits.
Microsoft moved to a similar default-allow posture after the 2014 Satya Nadella transition, documented in the 2018 launch of Microsoft's OSPO and the May 2019 release of the GitHub integration that allowed employees to link corporate and personal accounts with automatic CLA handling.
Meta, Netflix, Stripe, and most other engineering-first companies operate versions of this model. The key properties are: a small list of explicitly blocked projects, an allowlist of projects with standing CLA coverage, automated tooling to sign CLAs on behalf of employees, and a lightweight channel for engineers to request coverage for new projects.
The Red Hat / Upstream-First Model
Red Hat's contribution policy is distinctive because Red Hat's business model depends on upstream contribution. Red Hat engineers are not just allowed to contribute; they are frequently required to. The "upstream first" principle, articulated in Red Hat engineering documentation since at least 2010, states that changes to Red Hat products must land in the relevant upstream project before shipping in a Red Hat product wherever feasible.
This is reflected in Red Hat's contributor footprint. Red Hat has been among the top corporate contributors to the Linux kernel for years, has dominated contribution to systemd, Gluster, Kubernetes (especially OpenShift-related areas), and has staff committers across many Apache and CNCF projects.
The policy is enabled by a mature Developer Certificate of Origin process (rather than a per-project CLA), in-house legal expertise that reviews upstream projects at scope rather than per-contribution, and a performance review structure that explicitly credits upstream work.
IBM has largely adopted this posture since the 2019 Red Hat acquisition, though legacy parts of IBM still follow older processes.
The Security Review Layer
Every corporate policy worth its salt includes a security review dimension that goes beyond legal review. The question is not just "can we legally contribute this?" but "does this contribution expose vulnerabilities in our internal systems?"
Two patterns dominate. The first is contribution allow-listing for known-safe projects, where engineers can contribute to (say) Kubernetes without per-patch review, but contributing to a security-critical project requires additional sign-off. The second is reverse review, where contributions that touch security-relevant code paths (cryptography, authentication, parsing) get an additional security review beyond whatever the upstream project performs.
Microsoft's SDL (Security Development Lifecycle) has been extended to cover open source contributions since 2020, requiring that employees who contribute changes to security-sensitive projects have the same threat modeling training as they would for internal code.
Google's security review for open source contributions includes automated SAST scanning via their OSS-Fuzz program, which has reported thousands of vulnerabilities upstream since its 2016 launch.
The CLA vs. DCO Debate
A persistent tension in corporate contribution policy is whether to require signed Contributor License Agreements or to operate under the Developer Certificate of Origin (a simple sign-off line in Git commits). CLAs give the project (or foundation) stronger rights, including the ability to relicense. DCOs are lighter-weight and more popular with individual contributors.
The Linux kernel famously refuses CLAs, operating entirely on DCO. Apache and Eclipse require CLAs. CNCF projects vary. Corporate policies typically accommodate both, but some companies (notably some in the enterprise Java space) prefer CLA-only to reduce the risk of inbound contributions being questioned later.
The HashiCorp relicensing event of August 2023, where a CLA that permitted relicensing was invoked to move the projects from MPL 2.0 to BSL 1.1, created a lasting chill on broad-rights CLAs. Some corporate OSPOs have since added language to their internal CLA-signing workflow flagging projects that retain unilateral relicensing rights.
The Shape of a Good Policy
The corporate contribution policies that work over the long term share a small set of properties. They are defaults-on, not defaults-off, because an environment that treats every contribution as exceptional will not produce sustained upstream participation. They automate CLA handling through tooling rather than requiring humans to shuffle PDFs. They distinguish between low-stakes contributions (documentation, bug fixes, test additions) and high-stakes ones (new subsystems, security-relevant changes), applying proportional review. And they grant engineers explicit time to do this work, rather than treating upstream participation as a hobby to be squeezed around other priorities.
How Safeguard Helps
Safeguard's policy engine lets organizations encode their contribution posture, including CLA/DCO requirements, allowed licenses, and banned project lists, and evaluate every dependency and internal change against those rules. When your engineers adopt a new upstream dependency, Safeguard checks whether the project's CLA and governance meet the standards your OSPO has codified, rather than leaving that to manual review. The platform also tracks changes to upstream contribution requirements (new CLAs, relicensing, governance transitions) and flags projects where your internal policy is drifting out of alignment. That converts OSPO policy from a static document into an enforced input to the development workflow.