# The Fork-Risk Score: Rating a COSS Project Before You Wire

*You can score any repo-backed company on fork-and-relicense exposure and turn that score into a keep, price-in, or walk decision.*

- Canonical URL: https://www.refolk.ai/guides/fork-risk-score-coss-diligence
- Pillar: Investing and deal sourcing
- Format: Framework
- Published: 2026-09-08
- Last reviewed: 2026-09-08
- Reading time: 14 min

Before you wire into a commercial open source company, you need one number: how exposed is the specific project behind the round to a community fork or relicensing backlash. This guide is for early-stage investors, platform and talent partners, and angels doing COSS due diligence. It gives you a scored, repeatable read on fork-and-relicense exposure that you grade from public repo evidence, then translates into keep, price-in, or walk.

Most public writing on open source relicensing treats it as either a compliance headache for enterprise users or a general moat essay for founders. Neither hands an investor a way to grade the project in front of them. The 2018-to-2026 relicensing wave gives us enough worked cases to build weighted dimensions: MongoDB, Elastic, HashiCorp, and Redis all changed their licenses, and all four drew forks. The pattern is legible, and the score below is built directly from it.

## What fork risk is, and why it is a valuation variable

Fork risk is the probability that a community fork or relicensing backlash strands the commercial entity's value. It is not a legal question about whether a fork is permitted; permissive and copyleft licenses guarantee that it is. It is a question about whether the fork can pull away the people and the distribution that made the asset worth its multiple.

The reason this belongs in a valuation model, not just a legal memo, is that community metrics and commercial value move together. A Linux Foundation, COSSA, and Serena report from August 2025 found that distinct contributors and the OpenSSF Criticality Score are strong correlates of pre-money valuation. The same report found that after a funding round, COSS projects average a 27% increase in distinct contributors, an 8x increase in dependent projects, and a 7x increase in package downloads. Read that backwards: a fork that drains contributors mechanically drains the very metrics an investor prices on. The fork risk and the valuation risk are the same variable.

**96% - Share of Elasticsearch commits from Elastic employees at the 2021 relicense**

Extreme concentration meant the OpenSearch fork could take users but few committers at first.

Here is the pattern the wave established, drawn straight from the relicensing events themselves.

| Project | From to To | Date | Fork | Steward |
|---|---|---|---|---|
| MongoDB | AGPL to SSPL | Oct 2018 | DocumentDB (API reimpl.) | AWS |
| Elasticsearch | Apache 2.0 to SSPL/ELv2 | Jan 2021 | OpenSearch | AWS, then Linux Foundation |
| Terraform | MPL 2.0 to BSL 1.1 | Aug 2023 | OpenTofu | Linux Foundation / CNCF |
| Redis | BSD-3 to SSPL/RSALv2 | Mar 2024 | Valkey | Linux Foundation |

Every one of these vendors kept its trademark and its commercial product. What differed was how much the fork could pull. MongoDB drew an API reimplementation rather than a code fork. Elastic's OpenSearch drew a flood of users. Redis's Valkey drew away actual maintainers. Grading that difference in advance is the whole job.

## The dimensions that decide the score

Fork risk resolves into five dimensions you can grade from public evidence. Three are structural preconditions for a relicense or fork to happen at all; two are the forces that make it likely and fast. Score each, then weight.

- **CLA/DCO posture.** Whether the contribution agreement lets the vendor relicense unilaterally. This is the enabling switch.
- **Contributor concentration.** The share of commits written by vendor employees. This decides whether a fork takes users or maintainers.
- **Governance independence.** Whether a foundation and a multi-company steering committee already hold the project, which caps how far a relicense can go.
- **Fork precedent and speed.** Whether the category has already been forked and how fast that fork reached general availability.
- **Hyperscaler motive.** Whether a cloud provider selling a managed version has both the reason and the payroll to bankroll a fork.

### The CLA is the actual relicensing switch

A single company can relicense a project only if it holds or controls the rights to all contributions. That is why the contribution agreement, not the current license, is the highest-signal document in the whole diligence. A copyright-assignment CLA aggregates those rights into the vendor's hands. MongoDB is the worked example: to contribute, a developer first signed MongoDB's contributor agreement, which assigned copyright ownership to MongoDB, so those contributors had already given MongoDB the right to relicense their code when it moved to SSPL in October 2018.

The counter-structure is the Developer Certificate of Origin, a lightweight sign-off that does not transfer any rights. A DCO does not authorize relicensing. If a project wants to change its license later and it runs on a DCO, it cannot, absent going back to every contributor. This is precisely why forks land at foundations: Valkey is governed by a foundation that cannot unilaterally change its license.

> **Rule:** Read the CLA text, not the license badge
>
> A copyright-assignment CLA is the strongest single enabler of unilateral relicensing. If the project runs one, the vendor can relicense at will; if it runs a DCO, it legally cannot. Grade this before anything else.

### Concentration decides who leaves

Contributor concentration tells you what a fork can actually take. The mechanism is simple: you can only fork away people who already have commit rights and an employer independent of the vendor. Where the vendor writes almost all the code, the fork starts with no maintainers.

At the time of Elastic's 2021 change, an independent commit analysis found that of roughly 1,612 contributors, the overwhelming majority who wrote the code, at least 96% of it, were Elastic employees. So OpenSearch launched with 45 contributors against Elasticsearch's roughly 1,610, at around one-tenth of the commit activity. It drew users, not committers.

Redis was slightly less concentrated at the top, and that mattered. Before its license change, only two of its five maintainers worked outside Redis Ltd, one at Amazon and one at Alibaba. Those two external maintainers led Valkey. So the Redis fork drained genuine maintainer capacity, not just users. The lesson for scoring: an external maintainer with commit rights and an independent employer is worth more to a fork than ten thousand drive-by contributors.

#### Concentration vs external-maintainer presence

Horizontal axis runs from Vendor writes most commits to Commits spread across employers. Vertical axis runs from No external maintainers to External maintainers with commit rights.

| Quadrant | What it means |
| --- | --- |
| Captive but leaderless | Fork drains users only; price a slow bleed (Elastic/OpenSearch shape) |
| Diffuse and led | Highest fork risk; a fork can ship day one, walk or heavily discount |
| Fully captive | Lowest structural fork risk; watch CLA and hyperscaler motive instead |
| Community-led already | The vendor is a steward, not an owner; different thesis entirely |

*Where the builders sit decides whether a fork takes users or the people who ship releases.*

## How fast a fork becomes real

A fork is a near-term discount, not a theoretical one, because permissive and copyleft forks start from a fully working codebase and hyperscaler payroll compresses the ramp. In the cases we have, the time from fork to a production-usable release was measured in months.

| Fork | Fork to GA | First-year community |
|---|---|---|
| OpenSearch | ~3 months (Apr to Jul 2021) | 496 contributors, 100M+ downloads |
| OpenTofu | ~5 months (Aug 2023 to Jan 2024) | 10M downloads by 2025, 3,900+ providers |
| Valkey | first release ~2 months | 150+ contributors, 1000+ commits in weeks; 346 active in 2025 |

OpenTofu announced its fork on 25 August 2023, the Linux Foundation accepted it on 20 September 2023, and it reached a production-ready stable release on 10 January 2024. Valkey was announced under the Linux Foundation on 28 March 2024 from Redis 7.2.4, and within weeks it had over 150 contributors and more than 1,000 commits; across 2025 it counted 346 active contributors who filed commits, issues, or pull requests. These are not slow-motion threats. When you price fork risk, price it as a discount that could land inside your holding period.

#### How a relicense converts into a live fork

| Stage | Figure | Note |
| --- | --- | --- |
| Relicensing event | 4 | MongoDB, Elastic, HashiCorp, Redis |
| Coalition or hyperscaler forms | 4 | AWS, cloud coalitions, Linux Foundation |
| Fork accepted at a foundation | 3 | OpenSearch, OpenTofu, Valkey |
| Production-ready release | 3 | ~2 to 5 months from fork |

*Each stage narrows, but the wave shows all four converting within months once motive exists.*

## Grading the community metrics without getting fooled

Pull the metrics the valuation research actually rewards, and weight distinct contributors and the OpenSSF Criticality Score above the vanity numbers. The Linux Foundation, COSSA, and Serena report names distinct contributors and Criticality Score as the strong correlates of pre-money valuation. Stars and downloads are noisier: the main open COSS dataset, Runa Capital's ROSS Index, collects repos with 1,000 or more GitHub stars and ranks on star growth alone, and stars accumulate with age, rewarding older projects regardless of current health.

The trap worth naming here is brand inertia. A relicensed project keeps its mindshare for years after governance has moved, and résumés lag license reality badly. Refolk's index makes the gap concrete.

| Skill | Profiles | Derived ratio |
|---|---|---|
| Terraform | 363,696 | baseline |
| OpenTofu | 380 | ~957x smaller than Terraform; 0.10% of its footprint |
| Valkey | 205 | OpenTofu is ~1.85x Valkey's footprint |

In Refolk's index of professional profiles, 363,696 people list Terraform as a skill and 380 list OpenTofu, a footprint roughly 957 times larger despite the license change. An investor who reads professional footprint as loyalty will systematically overvalue the relicensed entity and undervalue the fork's momentum. Pair the footprint number with contributor-migration data every time, and never let one stand in for the other.

> Résumés and job specs lag license reality by years, so market share is the loyalty metric that lies most.

There is a second [OURS] signal in the same index that points straight at who funds a fork. Among Valkey-skilled profiles sampled, the top employers were AWS and Google. Forks are staffed by the clouds that the new license locked out, so who employs the skill reveals who bankrolls the fork.

I ran this search: `Engineers who list both Redis and Valkey as skills, showing who migrated after the 2024 license change` - [see the full result list](https://www.refolk.ai/s/3md49y37d2).

*Returns the individual contributors who moved from the original project to the fork, so you can see whether real maintainers defected or only users adopted the alternative.*

Refolk turns the contributor-migration read from a git-log project into a plain-English query. When the diligence question is "did the people who ship releases leave," you want the profiles of the humans, not just the commit graph, and you want them filtered by current employer. That is the difference between a download count and a maintainer defection.

## The procedure: score a repo-backed company end to end

Run the seven steps in order. The first four are analyst work off public repos; the last three bring in a partner to weight the evidence and make the call. Attach the concentration percentage and the governance label to the final recommendation as your two load-bearing numbers.

#### Fork-Risk Score procedure

1. **Pull the license and CLA/DCO posture** - Read the LICENSE file and contribution policy. Know the current license and whether there is a copyright-assignment CLA, a lighter CLA, or a DCO. A copyright-assignment CLA is the strongest enabler of unilateral relicensing.
2. **Measure contributor-affiliation concentration** - Script the git log, merge author identities, and compute the share of commits from vendor-email domains. Output one number, like Elastic's at-least-96%. Record whether you used commits, lines, or distinct contributors.
3. **Score governance independence** - Decide whether the project is foundation-hosted with a multi-company technical steering committee or single-vendor controlled. Read the actual governance and CLA text, not the hosted-by badge. Output a keep/price-in/walk label.
4. **Pull community-vitality metrics** - Collect distinct contributors, OpenSSF Criticality Score, dependent projects, downloads, and stars. Weight distinct contributors and Criticality Score highest, since those are the valuation correlates.
5. **Check the fork precedent in the category** - Establish whether a comparable project was forked and how fast it reached GA. Benchmark against OpenTofu (~5 months) and Valkey (~2 months). Output an estimated time-to-viable-fork.
6. **Assess hyperscaler motive** - Identify any cloud provider selling a managed version who would bankroll a fork. Every successful fork here was hyperscaler-funded. Output named potential sponsors or a defensible none.
7. **Weight and total the score, then map to a decision** - Combine the dimensions into keep, price-in, or walk. Output a written recommendation with the concentration percentage and governance label attached.

To weight the dimensions, use a simple additive rubric and let the two hard-precondition dimensions dominate. Adapt the point values to your fund's risk appetite, but keep the CLA and concentration dimensions carrying the most weight, because they gate whether a relicense or fork can happen at all.

**Fork-Risk scoring rubric (0 = safe, higher = more exposed)**

```
CLA/DCO posture         0 = DCO only | 2 = light CLA | 4 = copyright-assignment CLA
Contributor concentration  0 = <60% vendor | 2 = 60-90% vendor | 3 = >90% vendor
Governance independence 0 = foundation + multi-company TSC | 2 = foundation logo only | 3 = single-vendor
Fork precedent in category 0 = none | 1 = fork exists, slow | 2 = fork reached GA in months
Hyperscaler motive      0 = no reseller | 1 = plausible sponsor | 2 = active managed reseller
---
Total 0-4   = KEEP     (structural fork risk low; underwrite normally)
Total 5-8   = PRICE-IN (discount the round for a credible near-term fork)
Total 9-14  = WALK     (a fork can strand the entity's value inside your horizon)
```

*Score each row, sum, then map the total to a decision band. Adjust weights but keep CLA and concentration heaviest.*

Note the deliberate asymmetry. A single-vendor project with a copyright-assignment CLA and an active hyperscaler reseller scores high on three dimensions before you even open the contributor graph. That is the MongoDB-Elastic-Redis silhouette, and it is the one that produced every fork in the wave.

## Where the score lies to you: failure modes

The score is only as good as your resistance to its false positives. Six recur, each with a check that defuses it.

> **Watch out:** Raw contributor count is the most common trap
>
> GitHub listed ~1,610 contributors for Elasticsearch, but at least 96% of commits came from Elastic staff. Thousands of one-line fixes make a captive project look diverse. Always weight by commits from vendor-email domains, not headcount.

- **Concentration read on raw headcount.** A repo looks community-diverse because thousands filed trivial fixes. Check: weight commits by vendor email domain, as with Elastic's 96%.
- **Foundation logo mistaken for safety.** A project can sit under a foundation and still run a relicensing-enabling CLA elsewhere in its stack. Check: read the actual CLA or DCO text, not the hosted-by badge.
- **Fork momentum mistaken for user migration.** Valkey and OpenSearch drew users fast, but downloads are not maintainer defection. OpenSearch had 100M-plus downloads in year one yet started with 45 contributors. Check: track active contributors, not downloads.
- **Downloads and stars as valuation proxies.** Star-ranked datasets reward age, not health. Check: use distinct-contributor and Criticality-Score correlates instead.
- **Assuming no hyperscaler means no fork risk.** Every successful fork here was cloud-funded, so a niche project with no obvious sponsor gets judged unforkable. Check: name any managed-service reseller with motive before you conclude none exists.
- **Skill-footprint lag.** The original brand keeps huge mindshare after the fork; Terraform still holds roughly 957 times OpenTofu's professional footprint. Check: pair the footprint number with contributor-migration data so decay does not hide behind brand.

One more failure mode deserves its own line because it changes how you price a recovery. Do not treat relicensing as reversible. Elastic re-added AGPLv3 after its SSPL move, but developers said the trust did not come back. If a company you are grading has reversed a relicense, do not price the reversal as a full recovery; price it as a project carrying a permanent trust discount and a live fork already in the field.

```stat
number: 957x
label: How much larger Terraform's professional footprint is than OpenTofu's
note: In Refolk's index: 363,696 Terraform-skilled profiles against 380 for OpenTofu, years after the license change.

## Frequently asked questions

### What is fork risk for a commercial open source company?

Fork risk is the chance that a community fork or relicensing backlash strands the commercial entity's value. It matters most for single-vendor open source companies whose revenue depends on being the canonical steward of a project. When a hyperscaler or coalition forks the last permissively licensed release and rebuilds the community elsewhere, the vendor keeps its trademark but can lose the contributors, distributions, and downstream projects that made the asset valuable.

### Why is the CLA more important than the current license?

Because relicensing requires aggregating rights to all contributions, and the contribution agreement is what grants those rights. A copyright-assignment CLA, like the one MongoDB used before its 2018 SSPL move, lets the vendor relicense unilaterally. A Developer Certificate of Origin does not authorize a later license change. So the CLA text tells you whether a relicense is even legally available, which the current license alone cannot.

### How fast can a fork actually reach production?

Months, not years. OpenTofu went from fork announcement in August 2023 to a production-ready stable release in January 2024, about five months. Valkey shipped its first release roughly two months after launch and hit 150-plus contributors within weeks. Permissive forks start from a fully working codebase, and hyperscaler payroll compresses the ramp, so fork risk is a near-term discount rather than a distant hypothetical.

### Does a foundation logo mean the fork risk is gone?

No. A project can be donated to a foundation yet still run a relicensing-enabling CLA elsewhere in its stack, and a foundation badge does not by itself prove multi-company governance. Read the actual CLA or DCO text and confirm there is a genuine multi-company technical steering committee. Forks land at foundations precisely because a foundation cannot unilaterally change the license, so the structure matters, not the logo.

### Can I use GitHub's contributor count to judge community diversity?

Not on its own. GitHub listed roughly 1,610 contributors for Elasticsearch, but at least 96% of commits came from Elastic employees, so the headline number hid extreme concentration. Weight contributors by commits from vendor-email domains instead of counting heads. Thousands of one-line drive-by fixes can make a repo look diverse when the actual builder base sits entirely inside the vendor.

---

*From the Refolk guide library. I revise these guides rather than replacing them, so the current version is always at https://www.refolk.ai/guides/fork-risk-score-coss-diligence*