Every time a developer submits a pull request to an established open source project, an invisible legal apparatus engages. In the simplest case it is a one-line sign-off (Signed-off-by) affirming the Developer Certificate of Origin. In more elaborate cases it is a Contributor License Agreement, sometimes executed through a CLA bot that checks for signatures, sometimes via a PDF that must be signed and returned to the foundation. For compliance-conscious enterprises, the mechanics of these agreements are not background noise. They determine what intellectual property is transferred, what licenses the project can adopt in the future, and whether corporate counsel will ever need to revisit a pull request submitted five years ago.
The 2023 HashiCorp relicensing made the stakes of CLA design newly concrete. Contributors who had signed HashiCorp's CLA discovered, when the Terraform license moved to BSL 1.1 in August 2023, that their CLA gave HashiCorp the rights to make that change. Some contributors felt blindsided. Others pointed to the text of the CLA they had signed, which had granted broad rights all along. The episode triggered a wave of internal reviews at OSPOs about which CLAs they were signing on behalf of their engineers.
The Landscape, Briefly
Contributor agreements cluster into four main shapes.
The Developer Certificate of Origin is the lightest-weight option. It is a short public statement, popularized by the Linux kernel in 2004, that the contributor asserts the right to submit the code under the project's license. It is asserted by a "Signed-off-by:" line in the commit message. It transfers no additional rights beyond what the project's license already requires. The Linux kernel, Git, Docker, and many Cloud Native Computing Foundation projects operate on DCO.
The Apache Individual Contributor License Agreement is the most influential CLA template. Version 2.0, which has been in use since the early 2000s, grants the Apache Software Foundation a broad, irrevocable patent and copyright license. It does not assign copyright. The contributor retains copyright and the ASF can license the work under the Apache 2.0 license (and other compatible terms) going forward. A separate Corporate CLA exists for company contributions.
The Eclipse Contributor Agreement is closer to Apache's ICLA in structure but includes stronger IP representations and is enforced via the Eclipse Foundation Agreements System. Eclipse's IP due diligence process makes ECA signatures a mandatory gate before contributions can be accepted.
Corporate-specific CLAs are the wildcard. Google, Microsoft, Facebook, and dozens of other companies operate their own CLAs for projects they host. These vary considerably. Google's CLA is relatively narrow and does not permit unilateral relicensing. Some corporate CLAs, including versions that HashiCorp has used, reserve broader rights, including the ability to relicense contributed code.
What a CLA Actually Grants
The legal core of most CLAs is a combination of a copyright license, a patent license, and representations of originality.
The copyright license is typically broad: the contributor grants the project "a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute the contribution." The "sublicense" right is the critical one for relicensing. If the CLA grants the project a sublicensable copyright license, the project can technically re-release the contribution under any compatible license, including a future non-OSI license.
The patent license grants the project a license to any patents the contributor holds that would be infringed by the contribution. This protects downstream users from patent assertions by contributors.
The representations affirm that the contributor has the right to make the contribution, that it is original, that employer rights have been handled, and that no third-party IP is being introduced without appropriate flagging.
DCO, by contrast, includes none of these separately. It asserts that the contributor has the right to contribute under the project's existing license, and nothing more. The project cannot unilaterally relicense without going back to each contributor.
The Relicensing Risk
The HashiCorp episode and a string of earlier events (including MongoDB's 2018 SSPL move and Elastic's 2021 ELv2 move) have made the relicensing risk concrete. Enterprises are now asking three specific questions about any CLA before signing on behalf of their engineers.
Does the CLA permit relicensing to non-OSI licenses? Some CLAs, including the Apache ICLA, effectively do, because the broad sublicense grant allows downstream relicensing under a much wider range of terms than a strict OSI subset. Google's CLA constrains this more narrowly. Others explicitly reserve relicensing rights to the project steward.
Can the project unilaterally terminate or revoke? Most CLAs grant irrevocable licenses (to the project), but there is asymmetry: the project or foundation may have stronger termination rights over the contributor's ongoing participation than vice versa.
What is the governance of the entity holding the CLA? An ASF-held CLA has very different governance context than a single-company-held CLA. Foundation CLAs are constrained by foundation bylaws. Corporate CLAs are constrained only by corporate discretion.
Enforcement and Defensibility
CLAs are sometimes questioned on enforceability grounds: can a click-through agreement signed by an anonymous GitHub user really grant legally defensible IP rights? The case law is thin but not empty. SCO v. IBM and related Linux kernel litigation in the early 2000s was partly concerned with contribution provenance. More recent IP disputes around openSUSE, OpenAI's GPT training data, and various Android forks have touched on contributor agreement enforcement.
The practical consensus among OSS-focused law firms is that well-drafted, consistently-collected CLAs are defensible. DCO-only projects are defensible when the DCO sign-off is consistent and the contribution chain is auditable. The weak spots are projects that have inconsistent practices (CLAs required for some contributions but not others, DCO sign-offs missing for older commits) and projects whose CLA text has changed over time without clear versioning.
The DCO Camp's Position
The Linux kernel has famously refused to adopt a CLA. Greg Kroah-Hartman and other kernel maintainers have argued that DCO is sufficient, that CLAs add legal friction that discourages casual contribution, and that concentrated CLA-based rights create a structural risk (the relicensing risk, among others). The kernel's success is the strongest empirical argument for the DCO-only approach.
CNCF projects have largely aligned with this posture. Kubernetes, for instance, operates on a DCO model. The CNCF does not require a CLA for contributions to most of its hosted projects. This has simplified corporate contribution workflows at companies whose OSPOs have flagged broad-rights CLAs as a risk.
What Enterprise Legal Teams Should Check
For any CLA a company signs on behalf of its engineers: version the CLA text, retain a copy at signing time, and re-review when the upstream project changes stewardship. Check the relicensing clause specifically. Flag single-company-held CLAs for enhanced review. Prefer foundation-held CLAs where available. And for projects with no CLA, confirm that the project's DCO practice is consistent and auditable before treating contributions as low-risk.
How Safeguard Helps
Safeguard tracks contributor agreement posture for every open source project in your SBOM, surfacing whether a dependency operates under DCO, a foundation CLA, or a single-vendor CLA with broad relicensing rights. Our policy engine lets compliance teams require specific CLA profiles for regulated workloads, or block contributions to projects whose CLAs reserve unilateral relicensing rights. When a project updates its contributor agreement, Safeguard flags the change and highlights which of your internal projects have active contribution relationships affected by it. That gives legal and OSPO teams a continuous view of contributor agreement exposure, rather than a once-a-year audit.