# The Company-Backed Dependency Standard: Safe to Build On

*You will grade a company-backed open-source project pass, conditional, or fail on relicensing and single-vendor continuity risk so two reviewers reach the same verdict.*

- Canonical URL: https://www.refolk.ai/guides/company-backed-dependency-standard
- Pillar: Engineering and open source
- Format: Standard
- Published: 2026-08-15
- Last reviewed: 2026-08-15
- Reading time: 17 min
- Keywords: is this open source project safe to depend on, relicensing risk assessment open source, how to evaluate company backed open source project, avoid open source rug pull before adopting, single vendor open source risk checklist

## Key takeaways

- Grade the dependency on Elephant Factor and copyright ownership, not star count; before Redis relicensed in 2024, only 2 of its 5 maintainers worked outside Redis Ltd.
- When one company employs the maintainers and holds copyright via a CLA, relicensing is a board decision, not a community one, so single-vendor concentration predicts the relicense.
- A viable fork is decided in weeks by employer diversity: Valkey drew founders from AWS, Ericsson, Oracle, and Google and passed 20 companies within months under neutral Linux Foundation ownership.
- The talent market lags the license by years. In Refolk's index, 9,418 US engineers list Terraform versus 10 listing OpenTofu, a 942:1 labeling gap that understates real switching cost.
- A vendor that flipped once will flip again: Redis moved BSD to SSPL to AGPLv3 in about a year, so past relicensing is a durable negative signal regardless of the current license.
- The BSL four-year conversion clock restarts on each version's release date, so a team that upgrades continuously never reaches conversion on the code it actually runs.

Before you add a company-backed open-source library as a core dependency, you need a defensible answer to one question: can the company behind it change the license or disappear in a way that breaks your product? This is the checklist an engineer opens before that commit, aimed at engineering managers, technical founders, and platform leads who have to justify the choice to a reviewer. It grades a project pass, conditional, or fail on relicensing and single-vendor continuity risk, using only public signals, so two engineers reach the same verdict.

This is not a code-quality review. Code quality is answerable from the code. What is not answerable from the code is whether the owner will flip the license out from under you, and whether the project survives if one company walks away. That is what this standard grades.

## What this standard grades and what it ignores

This standard grades two risks: relicensing risk, meaning the chance the owner moves the project from an open license to a source-available one that blocks your use, and single-vendor continuity risk, meaning the chance the project cannot survive without one company. It deliberately ignores code quality, performance, and API design.

The reason to separate these is that the signals that predict a relicense have almost nothing to do with the code. The clearest documented case is Redis: before its 2024 license change, only two of its five maintainers worked outside Redis Ltd. The code was excellent. The ownership structure was the risk. When one company employs the maintainers and holds the copyright, relicensing is a board decision, not a community one.

> Relicensing is decided in a boardroom, not a pull request; grade the ownership, not the code.

So the standard is built on public evidence about the company and its governance: who holds copyright and trademark, what the current license actually restricts, how concentrated contributions are, and whether a neutral home or a viable fork exists. Every input is checkable by two people from public sources, which is what makes the verdict reproducible.

## The relicensing pattern you are guarding against

The documented relicensing pattern is a move from a permissive or OSI-approved license to a source-available one, timed to a company's commercial pressure. Recognizing the shape of past events tells you what the next one looks like.

Four large transitions define the pattern. MongoDB went first, issuing the Server Side Public License for MongoDB Community Server on October 16, 2018, moving off AGPLv3. Elastic followed in January 2021, moving Elasticsearch and Kibana from Apache 2.0 to a dual SSPL and Elastic License model. HashiCorp changed Terraform, Vault, Consul, and its other tools from Mozilla Public License 2.0 to the Business Source License 1.1 on August 10, 2023. Redis moved from the permissive BSD-3-Clause license to a dual SSPL and Redis Source Available License model in March 2024.

| Project | Backer | From | To | Date | Reverted? |
|---|---|---|---|---|---|
| MongoDB | MongoDB Inc (Nasdaq: MDB) | AGPLv3 | SSPL | Oct 16 2018 | No |
| Elasticsearch | Elastic | Apache 2.0 | SSPL/Elastic | Jan 2021 | Added AGPLv3 2024 |
| Terraform | HashiCorp (now IBM) | MPL 2.0 | BSL 1.1 | Aug 10 2023 | No |
| Redis | Redis Ltd | BSD-3 | SSPL/RSALv2 | Mar 2024 | AGPLv3, 2025 |

Two things in this table matter for grading. First, the SSPL is not an open-source license: MongoDB submitted it to the Open Source Initiative in 2018, withdrew it in 2019, and in January 2021 the OSI stated that SSPL does not comply with the Open Source Definition. Second, reversals happen. Redis re-relicensed back to open source by adding AGPL-3.0 in 2025, and Elastic re-added AGPLv3 in 2024. But a reversal is not reassurance. A vendor that flipped once has shown the license is a lever it will pull again. Redis went BSD to SSPL to AGPLv3 in about a year. Past relicensing is a durable negative signal regardless of the current license.

> **Watch out:** A reversal is not a clean slate
>
> Redis moved BSD to SSPL to AGPLv3 in roughly a year. A vendor that has demonstrated it will flip the license once has told you it treats the license as a commercial lever. Grade past relicensing as a permanent negative even when the current license is open.

## Who can relicense: the ownership check

The single strongest control against relicensing is who holds the copyright and the trademark. If a single company holds both, often by having contributors sign a Contributor License Agreement that assigns rights to the company, it can relicense unilaterally. If a neutral foundation holds the assets and the mark, no one commercial actor can force it.

This is the first thing to check and the fastest. Read the LICENSE file, the CLA or DCO policy, and the trademark page. A CLA that assigns copyright to a company is the mechanism that makes a board-level relicense legally possible. Neutral foundation ownership is the documented antidote: maintaining a project under the Linux Foundation, as OpenTofu does, keeps it under the stewardship of multiple companies rather than at the whim of any one, similar to how Linux itself is managed. Valkey is backed by the Linux Foundation and operates under an open governance model for the same reason.

#### The relicensing control stack

1. **Neutral asset ownership** - A foundation, not a vendor, holds copyright and trademark
2. **Open governance** - A public multi-org steering committee decides direction
3. **Contributor diversity** - No single employer dominates commits
4. **OSI-approved license** - The current terms permit your use

*Each outer layer must hold for the layer below to be safe from a unilateral relicense.*

Watch for the false comfort here. A company can sponsor a foundation while keeping copyright and the trademark for itself. A foundation logo on the homepage is not foundation ownership. Confirm that the foundation, not the vendor, actually holds the assets and the mark before you credit the project for neutral governance.

> **Rule:** Ownership beats optics
>
> A project passes the ownership check only if a neutral foundation holds both the copyright and the trademark. Sponsorship, membership, or a logo does not count. If a single company holds copyright via a CLA, treat unilateral relicensing as possible by default.

## Reading the license restriction against your actual use

A source-available license does not block everyone equally; it blocks a specific competitive use, and the details decide whether you are affected. You must read the restriction against your own intended use and write down a yes or no, not read it in the abstract.

For the Business Source License, two clauses govern you. The Additional Use Grant is the competitive gate: BSL prohibits production use unless the licensor granted a use grant covering your specific case, otherwise you must buy a commercial license. The Change Date is the release valve: on the Change Date, or the fourth anniversary of a version's first public distribution, whichever comes first, the code automatically converts to the Change License, which must be GPL v2.0-or-later compatible. The BSL was created by MariaDB in 2013, and this four-year conversion is its defining feature.

Two traps live in these clauses. The first is the conversion clock. Each version's four-year clock starts at that version's own release date. A team that upgrades continuously never runs code old enough to have converted, so "it becomes open eventually" is structurally hollow for an active dependency. The second is grant revocability: a licensor may narrow or eliminate the Additional Use Grant in future versions. It is forward-looking only and does not apply retroactively, which means the grant you read today can shrink for the next release you pull. Pin the version and archive the exact license text you accepted.

For SSPL, the trigger is different. Section 13 fires when you offer the software as a service. If you host it for third parties, SSPL's obligations attach. If you only use it internally, the trigger may not fire, but confirm that against your deployment, because "internal" and "offered as a service" can blur in practice.

**License restriction verdict (record per dependency)**

```
Project + pinned version:
License family: [OSI-approved / BSL / SSPL / RSALv2 / Elastic]
OSI-approved? [yes/no, confirmed at opensource.org]
My intended use: [internal only / offered as a service / redistributed]
BSL Additional Use Grant covers my use? [yes/no + quote]
BSL Change Date for THIS version: [date]
SSPL Section 13 triggered by my use? [yes/no]
Verdict: permitted today [yes/no] / permitted after change date [yes/no]
```

*Fill one per pinned version. Archive the license text alongside this record.*

## Measuring single-vendor concentration

Single-vendor concentration is the quantitative core of continuity risk, and CHAOSS gives you two named metrics that two reviewers can compute the same way. Contributor Absence Factor, formerly called Bus Factor, identifies the smallest number of contributors responsible for 50% of contributions. Elephant Factor measures the minimum number of companies whose employees contribute a specified percentage of commits.

There is no published universal danger line. What the record gives you is calibration. The Apache Software Foundation reported an average bus factor of 2.7 in a 2024 sustainability study, so a healthy multi-company project sits around there. Before Redis relicensed, only two of its five maintainers worked outside Redis Ltd, which is the concentration profile that precedes a relicense. The practical red flag is a Contributor Absence Factor of one to two concentrated in a single employer. Grade on the Elephant Factor and the top employer's commit share, not on the star count.

**2 of 5 - Redis maintainers outside Redis Ltd before its 2024 relicense**

Concentration in one employer is the profile that precedes a board-level license flip.

Foundation membership does not make this metric go away. LFX data shows that even Valkey, a healthy neutral-governance project, has 3 organizations accounting for more than 51% of contributions and 5 contributors accounting for more than 51%. Neutral governance caps relicensing risk; it does not eliminate concentration risk. Grade the two separately.

You can measure this yourself once you know where to look. Contributor and organization concentration for foundation projects is published on LFX Insights; for any public repo you can compute it from commit history with tools like Cauldron. When you need to go the other way and identify the humans and employers behind those commits, that resolution is exactly what [Refolk](/) is built for.

I ran this search: `OpenTofu Technical Steering Committee members and their employers.` - [see the full result list](https://www.refolk.ai/s/98mfyzb1j5).

*Returns named committee members with current employers, so you can verify multi-org governance rather than trust a homepage claim.*

## The fallback fork and its real switching cost

A viable community fork is the escape hatch that turns a fail into a conditional, but only if it retains an OSI-approved license, lives under an independent foundation, and draws contributors from multiple employers. A fork run by a single rival vendor is not an escape hatch.

Two forks define the model. OpenTofu was announced by the Linux Foundation on September 20, 2023 as a community response to Terraform's license change, released its first independent version 1.6.0 in January 2024, and was accepted into the CNCF in April 2025. Valkey was announced March 28, 2024, continuing development on Redis 7.2.4 under the BSD 3-clause license, with a founding group from AWS, Ericsson, Oracle, and Google that grew past 20 companies within months. In 2025 Valkey reported 346 active contributors.

| Fork | Foundation | License | Founded | Contributors | Multi-org? |
|---|---|---|---|---|---|
| OpenTofu | Linux Foundation / CNCF | MPL 2.0 | Sep 2023 | multi-org TSC | Yes |
| Valkey | Linux Foundation | BSD-3 | Mar 2024 | 346 (2025) | Yes (20+ cos) |

A fork's survival is decided in weeks, and by employer diversity. Valkey reaching four major backers at launch is the mechanism; the Linux Foundation's neutral asset ownership is what let those rivals cooperate without one controlling the outcome.

But "a fork exists" understates your switching cost, and this is where the standard corrects a common error. The talent market lags the license by years.

| Segment | Count | Derived ratio |
|---|---|---|
| Terraform, US (eng titles) | 9,418 | baseline |
| OpenTofu, US (eng titles) | 10 | 0.1% of Terraform (derived) |
| Terraform, Germany (eng titles) | 1,387 | 14.7% of US (derived) |

In Refolk's index of professional profiles, 9,418 US software, DevOps, and platform engineers list Terraform as a skill against just 10 listing OpenTofu, a 942:1 labeling gap more than two years after the fork. Even when a safe fork exists, hiring inertia and accumulated knowledge keep teams on the relicensed original. So when you record a fallback fork as mitigation, note the labeling gap too. A fork you cannot staff is a weaker mitigation than the contributor count suggests.

**942:1 - Terraform vs OpenTofu skill labeling in Refolk's US index**

The safe fork exists, but the talent market has barely moved, which is itself a lock-in signal.

## The grading procedure

Run these eight steps in order and record the evidence at each one; the output is a pass, conditional, or fail that another reviewer can reproduce from the same public signals. Sources disagree on whether concentration or governance comes first: CHAOSS practitioners lead with metrics, governance-focused writers lead with ownership. The order does not change the verdict as long as both are completed.

#### Grade a company-backed dependency

1. **Identify copyright and trademark owner** - Read the LICENSE, the CLA or DCO policy, and the trademark page. A CLA assigning rights to a company means it can relicense unilaterally; a foundation holding assets means it largely cannot.
2. **Classify the current license** - Determine whether the license is OSI-approved or source-available (BSL, SSPL, RSALv2, Elastic License). Confirm OSI status against opensource.org, not just GitHub visibility.
3. **Read the competitive-use restriction against your use** - For BSL, locate the Additional Use Grant and Change Date; for SSPL, test whether Section 13 applies. Write a yes or no on whether your use is permitted today and after the change date.
4. **Measure single-vendor concentration** - Compute CHAOSS Contributor Absence Factor and Elephant Factor from commit history via LFX Insights or Cauldron, after de-duplicating identities and filtering bots. Record two numbers plus the top employer's commit share.
5. **Check governance ownership** - Determine foundation versus single-vendor ownership and whether a public multi-org steering committee exists. Name the governance body and the employers of its members.
6. **Locate the fallback fork** - Check for an OSI-licensed fork under an independent foundation with multi-company backing (OpenTofu, Valkey model). Record a named fork with license and contributor count, or 'none exists.'
7. **Assess backer continuity** - For a public backer read SEC filings; for a private backer record funding stage and acquisition status. Note any pending acquisition as a continuity signal.
8. **Grade pass, conditional, or fail** - Apply fixed thresholds to the evidence and record the full trail. Produce a verdict two reviewers can reproduce.

For backer continuity, public backers file with the SEC: MongoDB trades as Nasdaq MDB, and HashiCorp filed as HCP. Acquisition status is itself a continuity signal, as with IBM's reported $6.4B acquisition of HashiCorp, which you should verify against the filings. For private backers, funding stage and acquisition status are the references; specific figures are not always publicly established, so record what you can verify and flag what you cannot.

### Fixed thresholds for the verdict

Use these thresholds so the grade is not a matter of taste:

- **Fail** if a single company holds copyright via a CLA and the current license is source-available with no Additional Use Grant covering your use, or if the vendor has relicensed before and no viable fork exists.
- **Conditional** if a single company holds copyright but the license is currently OSI-approved and a viable foundation-backed fork exists, or if the license is source-available but the Additional Use Grant clearly covers your internal use for the version you pin.
- **Pass** if a neutral foundation holds copyright and trademark, the current license is OSI-approved, and the Elephant Factor is two or more, so no single employer can force a relicense.

## How this goes wrong: failure modes and false positives

Most bad verdicts come from trusting a signal that lies rather than from missing a signal. These are the documented ways the inputs mislead, and the check that catches each one.

| Failure mode | What it looks like | The check |
|---|---|---|
| "It's on GitHub, so it's open source" | Source-available code is visible and forkable but blocks commercial use | Read the LICENSE header; confirm OSI approval, not just visibility |
| Stale bus factor | Metric reads the same for an engaged maintainer and a departed one | Confirm top contributors committed in the last quarter |
| Identity fragmentation | Under-aliased IDs split one person across accounts, inflating the count | De-duplicate emails and accounts before counting |
| Bot and agent commits | Automation pads activity and noises up Elephant Factor | Filter Dependabot and automation before computing concentration |
| Foundation logo, vendor ownership | Company sponsors a foundation but keeps copyright and mark | Confirm the foundation holds the assets and the trademark |
| Change date frees you soon | Each version's four-year clock starts at its own release | Date the specific version you pin, not the project |
| Grant looks permissive | Additional Use Grant is forward-revocable in future versions | Pin and archive the exact license text you accepted |

Two of these deserve emphasis because they cut in opposite directions. A stale bus factor makes a dead project look healthy: the metric reports the same number for one engaged maintainer and one departed maintainer whose token still works. Identity fragmentation makes a concentrated project look diverse: under-aliased IDs spread one person's work across identities and produce a falsely reassuring number. Both distort the same metric, so you cannot fix one and ignore the other. Clean the contributor data before you compute anything, then confirm recency.

The change-date and grant-revocability traps are the ones reviewers most often wave away, because both sound like the license is getting more open over time. In practice, the conversion clock never catches a team that upgrades, and the grant can narrow on the next release. Treat both as reasons to pin and archive, not as reasons to relax.

## Verify before you commit

Run this checklist before you record the verdict. It is the difference between a grade you can defend to a reviewer and an opinion.

#### Before you call the dependency graded

- [ ] LICENSE, CLA/DCO, and trademark pages have all been read
- [ ] Copyright and trademark holder is named, and it is clear whether one company can relicense
- [ ] Current license is named and its OSI status confirmed against opensource.org
- [ ] A written yes/no exists on whether your use is permitted today and after the change date
- [ ] The BSL change date is dated against the specific version you pin, not the project
- [ ] Contributor identities de-duplicated and bots filtered before computing metrics
- [ ] Contributor Absence Factor and Elephant Factor recorded, with top employer's commit share
- [ ] Top contributors confirmed active in the last quarter
- [ ] Governance body named with member employers; foundation asset ownership confirmed
- [ ] Fallback fork recorded with license and contributor count, or 'none exists', plus its talent-market depth
- [ ] Backer continuity evidence recorded (SEC filing or funding stage and acquisition status)
- [ ] Verdict recorded as pass/conditional/fail with the evidence trail attached

## Keeping the verdict current

A grade is a snapshot, and the inputs move, so schedule a re-check rather than treating the verdict as permanent. The two inputs most likely to change are the license and the concentration metric, and both have public triggers you can monitor.

Re-run the concentration measurement each quarter, because the top employer's commit share drifts and a maintainer departure can move the Contributor Absence Factor without any announcement. Re-read the license on every major version bump, because the Additional Use Grant can narrow forward and each new version resets its own conversion clock. Watch backer continuity through acquisition and funding news, since ownership changes like an acquisition can precede a license change.

When a project you depend on relicenses or a maintainer team consolidates into one employer, the useful next move is to map the people, not just the code. Identifying which maintainers left for a neutral fork, or which companies are backing the alternative, tells you whether the escape hatch is real. Refolk resolves those maintainer and employer questions from public signals in one query, which turns "a fork exists" into a staffed, verifiable plan. Keep the graded record, the archived license text, and the last measurement date together, so the next reviewer inherits the trail instead of starting over.

## Frequently asked questions

### Is a project on GitHub automatically open source?

No. Public visibility on GitHub tells you nothing about licensing. Source-available licenses like the Business Source License and the Server Side Public License publish code that you can read and fork for non-production purposes but that blocks your commercial use until you buy a license or the change date passes. Always read the LICENSE header and confirm OSI approval at opensource.org rather than trusting that the repository is public.

### How do I know if a company can relicense a project I depend on?

Read the LICENSE file, the CLA policy, and who holds the trademark. If contributors sign a CLA assigning copyright to a single company and that company owns the mark, relicensing is a board decision it can make unilaterally. If a neutral foundation such as the Linux Foundation holds the assets and the mark, no single commercial actor can force a relicense. This ownership check is the single strongest predictor in the standard.

### Does the BSL four-year conversion clock make source-available code safe eventually?

Not for an active dependency. Under BSL 1.1 each version converts to a GPL-compatible license on its own anniversary, no more than four years after that version's release. A team that upgrades continuously never runs code old enough to have converted, so the conversion promise applies only to versions you have stopped using. Date the specific version you pin before relying on this.

### What contributor concentration counts as a red flag?

There is no published universal danger line, but a Contributor Absence Factor of one to two concentrated in a single employer is the practical red flag. For reference, the Apache Software Foundation reported an average bus factor of 2.7 in a 2024 study, and before Redis relicensed, only two of its five maintainers worked outside Redis Ltd. Grade on the CHAOSS Elephant Factor and top-employer commit share, not raw contributor count.

### Is a community fork enough to make a relicensed project safe to keep using?

A fork lowers risk only if it retains an OSI-approved license, lives under an independent foundation, and has multi-company backing, as OpenTofu and Valkey do. Even then, the talent market lags: Refolk's index shows a 942:1 Terraform-to-OpenTofu labeling gap in the US years after the fork. So a fork existing understates the real switching cost of hiring and retraining.

---

*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/company-backed-dependency-standard*