The Open-Source Control Signal Reference: Who Governs a Project

Before I let a product depend on an open-source project, I need to know who actually controls it and what they could change without asking me. This is a signal-by-signal lookup for engineering managers, technical founders, developer-relations leads, and technical sourcers: each row names an artifact you can check in ten minutes, says what it proves about control, and says how it misleads. Jump to the row you need, read it, and leave.

Governance models get explained in the abstract everywhere. This reference does the opposite: it keys control to the observable artifact on GitHub, in the trademark registry, or in a foundation charter, so you can write down a defensible answer instead of repeating a model name.

What "control" actually means for a dependency

Control of an open-source project is the ability to change something you depend on without your consent: the name, the license, the release cadence, or the roadmap. Whoever holds those levers can strand your product, and each lever lives in a different public artifact.

There are four levers, and they do not travel together. The trademark decides who can use the name. The contribution agreement decides who can relicense. The commit and merge graph decides who ships releases day to day. The governance artifact decides who sets direction. A project can be permissively licensed and still be fully controlled by one vendor because that vendor holds the mark, the copyright inflow, and the commit majority. Your job is to read all four and refuse to average them into a vibe.

The single most useful fact to internalize: releasing under an open-source license does not give the licensor the right to prevent others using the name. Trademark rights come from trademark law, either registration or common-law usage, not from the code license. So a project can be Apache 2.0 - whose Section 6 grants copyright and patent licenses but explicitly no trademark rights - and the vendor can still block a fork's name. Code and name are separate legal objects. Read them separately.

The trademark signal: who owns the name

The trademark is the hardest control lever, because under US trademark law you cannot effectively separate ownership of a project mark from control of the underlying open-source project. Whoever owns the name can copy nothing and still control everything.

Check the official US trademark registry and the European registry for the project name in the relevant goods class, and record the registrant of record. If the registrant is a foundation, the name is held neutrally. If it is a single company, that company can block a fork from using the name even when the fork copies all the code. The Mozilla-to-Iceweasel rename is the canonical case: the code was free, the name was not.

The false negative here is the one that catches people. Common-law marks are unregistered, so the registry shows nothing while the vendor still controls the name. Common-law rights are limited to the geographic area of actual use and harder to enforce, but they are real. So verify actual usage - is the vendor policing the name, does the project logo appear on the vendor's site - not just the registry hit.

The contribution-agreement signal: DCO vs CLA

The contribution agreement decides who can relicense the project, and it is the difference between "safe to build on" and "one board vote from a proprietary license." A DCO ties inbound license to outbound and cannot enable relicensing. A broad CLA can.

The Developer Certificate of Origin, introduced by the Linux Foundation in 2004, sets the inbound license of a contribution to be the same as the outbound license. Under a DCO, contributors retain full copyright and are only certifying they have the right to submit. There is no pooled right for anyone to relicense.

A CLA can create the opposite. When a CLA requires a contributor to assign unrestricted republishing rights, contributed code can be relicensed at the discretion of the project even when the CLA does not assign copyright. That distinction is the trap. People read a CLA, see no copyright assignment, and file it as harmless. The danger is the republishing grant, not the assignment clause. Read the grant, not the title.

This is not theoretical. In 2019 MongoDB used the rights granted by its CLA to move to a non-open-source license. The clause that enabled it was observable in the CONTRIBUTING flow for years before the switch.

The concentration signal: bus factor and employer share

Commit concentration is the one control risk you can put a number on. Compute the bus factor - the minimum number of developers whose cumulative share first reaches 50% of a project's commits - and the single largest employer's share of that work.

The number is diagnostic because a vendor that can relicense is usually also the dominant committer. One measurement surfaces both the knowledge-concentration risk and the control risk. Use a stable benchmark to read it: broadly distributed projects sit low, captured projects sit high.

The unstable set is at least roughly 2.7 times more concentrated than Rust. Across those 50 unstable repositories, 86% of activity was concentrated in a few maintainers, with the top three contributors over 50% of commits across five years. When you see a top-three share above 50%, treat the project as effectively controlled by whoever those three work for, and go find out.

The failure mode is an inflated bus factor from identity fragmentation. Under-aliased identities split one person's work across several identities, so the project appears to spread knowledge over more people than it really does. That produces a falsely reassuring number. Merge aliases before you count. The opposite hides too: personal-email committers who are actually vendor staff make concentration look lower than it is, so cross-check profiles against the employer table you built.

The governance signal: who decides, and is the artifact alive

The governance artifact - GOVERNANCE.md, a charter, a steering or PMC roster - names who decides releases and roadmap. It only counts if it is current and if formal authority is explicit, and for most projects it is neither.

At the Apache Software Foundation, authority is explicit and worth using as the model: committers can update code, but only the PMC as a body has authority to vote on formal releases. That is a clean separation of merge rights from release rights. Most projects do not have it. For the long tail there is often no meaningful governance body at all, which is why the 96.05% single-point-of-failure figure matters as much as any charter.

Check the last-commit date on the artifact. A charter naming a neutral steering committee can be years out of date while real merge power sits with one employer. A stale GOVERNANCE.md is worse than none, because it reads as reassurance while describing a structure that no longer runs the project. Cross-reference the roster against who actually merges pull requests this quarter.

Formal control roles are scarce enough that informal governance is the default rather than the exception.

In Refolk's index of professional profiles, US roles explicitly titled for open-source program management outnumber the same title in Germany eight to one, and developer-advocacy titles outnumber the program-office title roughly thirty-six to one. Treat these as directional, since they are exact-title matches only. The point stands: the role that would own trademark and CLA policy is rarely named, so on most projects no neutral governor exists to check.

Mapping maintainers to employers by hand is the slow part of this whole read, because affiliation is almost never accurate enough to use without manual cleanup - it usually comes from imperfect email domains and self-reported profiles. Asking Refolk for the maintainers and their employers collapses steps four and five into a single query you can then verify, rather than scraping commit emails and guessing at domains.

The foundation signal: verify, do not assume

A foundation home is a structural circuit-breaker, not a badge. It only protects you if the trademark transfer and neutral governance actually completed, so verify the registrant on the official registry rather than trusting the project's claim.

The CNCF Charter requires that any project added to the CNCF transfer ownership of its trademark and logo assets to the Linux Foundation, complete a Project Contribution Agreement before onboarding, and use the Apache 2.0 license or seek an exception. The Apache Software Foundation goes further procedurally: it does not allow corporations to participate directly in project management or governance, only individuals, and its board may apply extra scrutiny to PMCs dominated by individuals with a common employer. A PMC must have at least three active members, matching the three positive votes required for a release. These rules are exactly what single-vendor projects lack.

The false positive is a claimed transfer that never completed. Synadia accepted a $10,000 CNCF reimbursement for NATS trademark registration but never completed the transfer, which let the vendor of record try to reassert rights. The lesson is blunt: a project's claim of foundation membership is a claim about the code home, not proof about the mark. Check who the mark is registered to on the official registry, then confirm the governance is neutral in practice.

What relicensing looks like before it happens

Every documented relicensing was a single-vendor project that controlled copyright inflow via a CLA or assignment and also held the trademark. The signals are observable years in advance: one company holds the mark, a CLA grants broad or assigned rights, and commits concentrate in that company.

Confluent, Couchbase, Cockroach Labs, Elastic, MariaDB, MongoDB, and Sentry all adopted alternative licenses with commercial-use restrictions. Two recent cases show the full arc, including the community's fork response.

On 10 August 2023 HashiCorp announced Terraform, Vault, Nomad, and others would switch from MPL v2.0 to the non-open-source Business Source License. HashiCorp maintains control and can relicense Terraform again in future for any reason. Beginning 20 March 2024, starting with Redis 7.4, Redis became dual-licensed under RSALv2 and SSPLv1 and is no longer distributed under three-clause BSD.

The community response tells you how fast a captured dependency can be replaced when the neutral pieces exist. The Linux Foundation launched the Valkey fork in April 2024 with AWS, Google Cloud, and Oracle, reaching 150-plus contributors and 1000-plus commits within weeks. A fork this fast is only possible because the code was permissively licensed even though the name and copyright inflow were not.

Every relicensing was pre-announced by its own artifacts: one vendor holding the mark, a broad CLA, and a commit majority.

The procedure: reading control in about an hour

Run these eight steps in order and you produce a written control statement for any dependency. The order is not sacred - some practitioners lead with the license before the trademark - but every step is needed, and the conclusion does not change with order.

Project: __________
Name (trademark) held by: __________ (foundation / single company)
Relicensing power: __________ (DCO = none / CLA with republish grant = yes / assignment = yes)
Current license: __________  Prior relicensing events: __________
Merge and release authority: __________ (dominant employer share: ____%; bus factor: ____)
Governance artifact: __________ (last updated: ______; foundation-verified: yes/no)
If they change terms, the impact on us is: __________
Overall: safe to build on / build with an exit plan / do not adopt

Use a two-axis read to turn the statement into a decision. The two variables that matter most are who owns the name and who can relicense.

How this read goes wrong

The signals lie in predictable ways, and knowing the lie is worth more than knowing the signal. Each failure mode below is a specific false positive or false negative with a concrete check.

• Trademark search false negative. The registry shows nothing, yet the vendor controls the name through an unregistered common-law mark. Common-law rights are limited to the geographic area of actual use and harder to enforce, but they exist. Check: verify actual usage and name-policing, not just the registry.
• "It's in a foundation" false positive. A claimed transfer may never have completed, as in the NATS dispute where the vendor of record could reassert rights. Check: confirm the actual registrant on the trademark registry, not the project's claim.
• Bus factor looks healthy but is inflated. Identity fragmentation splits one person across aliases, producing a falsely reassuring number. Check: merge aliases before you count.
• DCO present, but relicensing still possible. A DCO blocks relicensing only for DCO-covered commits; earlier CLA-covered code or vendor-held copyright still enables a change. Check: read the full contribution history, not just the current CONTRIBUTING file.
• CLA misread as harmless. Not all CLAs assign copyright; the danger is the unrestricted republishing grant, which lets code be relicensed at the project's discretion even without assignment. Check: read the grant clause, not the agreement's title.
• Affiliation mapping wrong. Email-domain affiliation is almost never accurate without manual cleanup, and personal-email committers who are actually vendor staff hide concentration. Check: cross-reference against self-reported profiles.
• Stale GOVERNANCE.md. A charter naming a neutral steering committee can be years out of date while real merge power sits with one employer. Check: the last-commit date, then who actually merges now.
• "Not retroactive" complacency. Relicensing spares old versions but freezes you: staying on your current version has no impact until you need a new release. BUSL Terraform source files convert back to MPL 2.0 after four years, which sounds safe but still restricts every release in that window. Check: model your upgrade needs, not just today's version.

Keeping the read current

A control statement is a snapshot, and control moves. Re-run the read on a schedule, not once at adoption, because the artifacts that flip control - a new CLA, a trademark transfer, a maintainer changing employers - all leave public traces you already know how to find.

Before you file any control statement as done, verify it against the checklist below.

Two re-check triggers deserve a standing watch. First, watch who employs the top maintainers, because a vendor consolidating the commit majority is the leading indicator of everything else. Refolk answers this as a plain query - the maintainers with merge rights and their current employers - so you can re-run it quarterly rather than rebuilding an affiliation table each time. Second, watch the contribution agreement for changes; a project quietly moving from a DCO to a CLA is announcing a future it has not named yet. The four levers do not travel together, so audit each one on its own cadence, and never let a foundation logo or a permissive license stand in for a read you have not actually done.