# The COSS Code-Title Standard: Clean, Remediable, or Encumbered

*Grade a target's public repos as Clean, Remediable, or Encumbered on six fixed criteria, and produce the same written gap list for counsel that a colleague would.*

- Canonical URL: https://www.refolk.ai/guides/coss-code-title-standard
- Pillar: Investing and deal sourcing
- Format: Standard
- Published: 2026-10-24
- Last reviewed: 2026-10-24
- Reading time: 22 min
- Keywords: open source startup IP due diligence checklist, CLA vs DCO relicensing risk for investors, how to check contributor ownership of a GitHub repo, COSS startup chain of title open source, can an open source company relicense its code, AI-generated code ownership due diligence

## Key takeaways

- Mozilla, the only public relicensing precedent, treated 95% author coverage as enough but relicensed only files where every copyright holder agreed, so grade agreement coverage in aggregate and uncovered code file by file.
- A DCO Signed-off-by trailer proves a contributor certified their right to submit code, not that the company can relicense it; only an assignment or a CLA with a broad grant does that.
- Relicensing rights do not prevent forks: Redis and HashiCorp both had them, and forks appeared 8 and 15 days after their license changes because already-published code keeps its old license.
- The trademark, not the code, decides what a fork may call itself, which is why Elastic kept its name and the community fork shipped as OpenSearch.
- Missing AI co-author trailers prove nothing, because the Copyright Office test is human expressive control, which commit metadata does not record, so AI findings can move a verdict to Remediable but never to Encumbered.
- In Refolk's index, 803 US profiles list Open Source Licensing but only 57 list Software Composition Analysis, so most funds will need to borrow the scanning skill rather than hire it.

Before a term sheet goes to an open-source startup, someone at the fund should know whether the company owns, or can relicense, the code its paid product depends on. This standard is for early-stage investors, platform and talent partners, and angels who need to answer that question from public repositories at the first-meeting stage. It gives you six criteria with fixed thresholds, one verdict (Clean, Remediable, or Encumbered), and a written gap list to hand to counsel.

## What code title means for an open-source startup

Code title is the company's legal ability to control, and if necessary relicense, the code its business model relies on. For an open-source company, title depends less on who wrote the code than on what each outside author agreed to when their contribution merged.

A few terms, defined once:

- **Core repo:** a repository the paid product cannot ship without. Docs, examples, and demo repos are out of scope.
- **Outside contributor:** anyone who wrote code still present at HEAD while not employed by the company. Mozilla's relicensing FAQ states the employee rule plainly: if the authors are all employees writing on company time, the organization owns the copyright.
- **Relicense:** to release the same code under a different license, open-source or commercial, than the one it currently ships under.
- **CLA (contributor license agreement):** a contract each contributor signs that grants the project owner a license to their contribution, usually a very broad one.
- **Assignment:** an agreement that transfers copyright in the contribution outright to the company.
- **DCO (Developer Certificate of Origin):** a per-commit certification that the contributor has the right to submit the code, recorded as a Signed-off-by trailer in the commit message.
- **Copyleft inflow:** third-party code under GPL, AGPL, or MPL that has been copied or vendored into a core repo.
- **Uncovered line:** a surviving line written by an outside contributor who did not sign an assignment or a relicensing-capable CLA.

### Why grade from the outside

Most material on open source startup IP due diligence is a law-firm checklist that tells founders what to put in the data room. That is useful later. At the first meeting you have no data room, but you do have the commit history, the CLA bot's records on merged pull requests, the license headers, the repo owner, and the trademark registries. Those are enough to find most title problems before you commit to a price, rather than during confirmatory diligence.

### The three verdicts

- **Clean:** all six criteria grade Clean. Nothing visible from the outside contradicts the company's claim to title.
- **Remediable:** at least one gap exists, and each gap has a known fix the company can carry out itself. Examples: a named author signs, a file is rewritten, or a founder assigns a repo or mark.
- **Encumbered:** at least one gap the company cannot close by its own action before closing. This goes into price, closing conditions, or a pass. It is not automatically a pass.

### What this standard cannot see

This is an outside-in grade. It cannot see employment agreements, contractor IP clauses, private repositories, or signed CLA records that the bot does not expose. It flags gaps. Counsel decides what they mean.

## Which contribution agreements let a company relicense its code?

An assignment, or a CLA whose grant is broad enough, lets a company relicense contributed code. A DCO does not, because DCO projects run on an inbound=outbound model: each contribution comes in under the same license it goes out under, and the contributor keeps the copyright.

| Mechanism | Copyright holder | Relicense? | Public artifact |
|---|---|---|---|
| Assignment CLA | Company | Yes | CLA text, bot status |
| Broad-grant CLA (e.g. Elastic) | Contributor | Yes, via the grant | CLA text, bot status |
| DCO | Contributor | No (inbound=outbound) | Signed-off-by trailer |
| None | Contributor | No | Absence of both |

The middle row is where analysts most often get the answer wrong. Elastic's contributor agreement does not assign copyright, yet it permits Elastic to distribute contributions without restriction. A CLA that grants unrestricted republishing rights allows relicensing at the project's discretion even when the contributor keeps the copyright. MongoDB is the other public example: it used rights granted under its CLA to move to a license that is not open source.

Two cases you will see cited are not established well enough to use as precedent:

- **HashiCorp:** an archived CLA page is cited in public discussion, but I have not verified its text.
- **Redis:** I could not establish which contribution agreement Redis used.

### How to verify the mechanism

1. Read CONTRIBUTING and any linked CLA. Find the grant clause and classify it as assignment, broad grant, narrow grant, or none.
2. Check the CLA bot's status on a sample of merged pull requests from outside contributors.
3. For DCO projects, look for Signed-off-by trailers on outside commits.
4. Record the date the CLA bot was first enabled. Coverage before that date has to be proven some other way.

I have not verified how specific CLA bots store their signature records, so confirm on the target's own repo how the bot reports status before you count anything. A Signed-off-by trailer proves certification. It does not prove a relicensing right, and you should never count it as one.

## The six criteria and their thresholds

Grade each of the six criteria on its own as Clean, Remediable, or Encumbered, then take the worst grade as the verdict. The cutoffs below are Refolk's policy. No market standard exists, and the only public precedent is narrower than it looks.

That precedent is Mozilla. It treated 95% author coverage as sufficient for its relicensing effort, but its own FAQ says it relicensed only the files for which it had permission from every copyright holder. So 95% describes how many authors were reached, not a line-share cutoff, and the file was the unit of decision. This standard uses both halves of that: the 95% bar for aggregate author coverage, and an all-holders test at the file level.

| Criterion | Clean | Remediable | Encumbered |
|---|---|---|---|
| Agreement coverage | 100% of outside authors covered | 95% or more covered, gaps named | Below 95% covered |
| Uncovered lines per file | No core file has any | Some files, none wholly uncovered | A core file wholly uncovered |
| Copyleft inflow | None in core | MPL 2.0 only, or isolated vendored code | Third-party GPL or AGPL in shipped files |
| Repo ownership | Company Organization account | Founder's personal User account | Org the company does not control |
| Trademark | Registered or pending, owner is the company | Founder-owned or not filed | Owned by an unrelated party |
| AI-generated code | Written AI-use policy found | No written policy | Never assigned from outside evidence |

### What each criterion proves, and how it lies

- **Agreement coverage** proves the company holds a relicensing right from most of the people who wrote the code. It lies when the CLA bot was added partway through the history, so early pull requests look covered by policy but are not covered by signature.
- **Uncovered lines per file** proves no single file depends entirely on someone who never granted rights. It lies when reformatting or vendoring commits reassign blame to whoever ran the formatter.
- **Copyleft inflow** proves third-party copyleft terms will not follow the code into a source-available or commercial edition. It lies when vendored code has had its license headers stripped. MPL 2.0 is a file-level copyleft that applies only to the covered files when they are distributed, which is why it caps at Remediable. I found no source that lists which licenses block a source-available edition, so the scan only flags files. Counsel makes the call.
- **Repo ownership** proves who controls the canonical project and its history. It lies when an Organization account is in fact controlled by a single founder's login, so record who the admins are where you can see them.
- **Trademark** proves who controls the name a fork would want to use. It lies when a matching mark belongs to an unrelated company in another class or country.
- **AI-generated code** proves only whether the company has thought about it. Absent markers prove nothing, which is why this criterion never produces Encumbered on its own.

The agreement-coverage criterion counts the company's own employees as covered, because employer ownership does not depend on a CLA. That makes the employee/outsider split the most consequential call you make, and the one most exposed to error.

> **Rule:** The worst grade is the verdict
>
> Never net one criterion against another, and never downgrade a grade because the company seems trustworthy. Only counsel may change a grade, in writing, after reviewing the gap.

#### Outside share against agreement coverage

Horizontal axis runs from Low outside line share to High outside line share. Vertical axis runs from Low agreement coverage to High agreement coverage.

| Quadrant | What it means |
| --- | --- |
| Clean candidate | Confirm the bot's enable date, then run the file-level test |
| Covered but exposed | Verify every outside line merged before the bot was enabled |
| Small gap | Name the uncovered authors, collect agreements or rewrite their files |
| Encumbered risk | Send to counsel before any term sheet goes out |

*High outside share is survivable when coverage is real, and low outside share is not safe when coverage is missing.*

## Why repo ownership and trademark carry their own weight

Owning the code protects the company's next edition, not the code it has already published, because an open-source license cannot be revoked on copies already released. Once a fork exists, the controls that still matter are the canonical repository and the name.

Every vendor in the cases below could relicense its code, and every one of them still got forked:

| Case | License change | Fork milestone | Days |
|---|---|---|---|
| Redis | 2024-03-20 | Valkey launched | 8 |
| Terraform | 2023-08-10 | Fork announced | 15 |
| Terraform | 2023-08-10 | Linux Foundation launch | 41 |
| Elastic | 2021-01-14 | Named OpenSearch | 88 |
| Elastic | 2021-01-14 | OpenSearch 1.0 GA | 179 |

The intervals come from public release and announcement dates. When the Linux Foundation launched OpenTofu, it cited pledges from more than 140 organizations and 600 individuals. A company with full code title still has no way to stop a fork of the last permissively licensed release.

**8 days - From the Redis license change to the Valkey fork launch**

Code title did not prevent the fork, so the investor's question is what the company still controls on day nine.

What it still controls is the name. Elastic kept the Elasticsearch name, so the fork had to rebrand as OpenSearch. The Linux Foundation's own OpenTofu release refers to "Terraform™", using the vendor's mark. When the fight continued, it was over what sat in the new edition: HashiCorp sent OpenTofu a cease and desist alleging it had copied code released under the new license, which OpenTofu denied.

#### What each layer of title protects

1. **Trademark** - Decides what a fork may call itself
2. **Repo and org ownership** - Decides who controls the canonical project, issues, and history
3. **Relicensing right** - Lets the company license its next edition on new terms
4. **Already-published code** - Keeps its old license, so anyone can fork it

*Each inner layer is weaker against a fork than the one outside it, which is why trademark and repo ownership are graded separately from code.*

> Owning the code protects the next edition. The name and the repo are what survive a fork.

### How to check repo ownership

The GitHub API reports an owner `type` for every repository: Organization or User. Record it for every core repo, along with the owner's name. A founder's User account grades Remediable because the founder can transfer it. An organization the company does not control grades Encumbered.

### How to check the trademark

Candidate registries are USPTO Trademark Search, EUIPO eSearch, and the WIPO Global Brand Database. I have not tested their coverage for this standard, so confirm they cover the markets the target sells into. For each hit, record the owner field and whether the mark is registered or pending. Then compare the owner name against the company's legal entity, character by character. A founder-held mark leaves the company with less leverage than its code title suggests, even when the code title is perfect.

## How to treat AI-generated code from the outside

Flag AI-generated code for counsel and never grade it Encumbered on outside evidence. Ownership turns on human authorship, and commit metadata does not record whether a human exercised expressive control.

The legal mechanism, as the public record stands:

- The US Copyright Office's report on copyrightability concluded that generative AI output is protected only where a human author has determined sufficient expressive elements.
- The D.C. Circuit's human-authorship ruling in Thaler v. Perlmutter stands, because the Supreme Court declined to hear the appeal.
- No court has said how much human involvement is enough for an AI-assisted work.

My reading, which counsel should confirm: code with no qualifying human author may carry no copyright for the company to own, and so nothing for it to license exclusively. That weakens the exclusivity a relicense is supposed to deliver.

Look for agent Co-authored-by trailers, bot accounts in the author list, and a written AI-use policy in the repo. I have not verified which of those markers are reliable, so treat them as reasons to ask, not as findings. A company with a written policy grades Clean on this criterion. A company without one grades Remediable, and the gap list asks for the policy. That will make Remediable common, which is honest. Most companies have not documented this.

> **Note:** Re-check the law, not just the repo
>
> The human-authorship rule is settled, but the sufficiency line is not. Before each deal, check for new Copyright Office guidance or appellate rulings on AI-assisted works, and update this criterion if the line moves.

## How to grade a target, step by step

The procedure has eight steps and takes roughly an afternoon. The time estimates are my own and not sourced, and no published source sets this order. Steps 4 and 5 are interchangeable. Two analysts should run it independently and compare verdicts at the end.

#### Outside-in code-title grade

1. **Scope the core repos** - List every repository the paid product cannot ship without, excluding docs, examples, and demos. Done when the second grader agrees with the named list (about 15 minutes).
2. **Check repo ownership** - Record whether each core repo sits under an Organization or a User account, and who the owner is. Done when owner type and name are recorded per repo (about 10 minutes).
3. **Measure outside authorship share** - Run blame on HEAD, group surviving-line authors by email domain and known affiliation, and compute non-employee line share and commit share per repo and per file. Done when each repo has a percentage and a named list of its largest outside authors (1 to 2 hours).
4. **Check contribution-agreement coverage** - Read CONTRIBUTING and the CLA grant clause, find the CLA bot's enable date, and sample merged outside PRs for bot status or Signed-off-by trailers. Done when the grant type is classified and the covered share of outside authors is known (about 1 hour).
5. **Scan for copyleft inflow** - Run ScanCode Toolkit over manifests and file headers, and flag third-party GPL, AGPL, and MPL files and vendored code. Done when there is a written list of copyleft file paths (about 1 hour).
6. **Check trademarks** - Search the registries for the product name and record the owner, jurisdiction, and registered or pending status. Done when the owner has been matched against the legal entity (about 20 minutes).
7. **Look for AI markers and policy** - Search trailers and author lists for agents and bots, and look for a written AI-use policy. Done when both are recorded, without treating absence as proof (about 20 minutes).
8. **Grade and write the gap list** - Grade all six criteria, take the worst grade as the verdict, and fill in the gap list with the commit SHA you graded. Done when two independent verdicts match.

### Commands for one repo

**Outside-in title commands for one core repo**

```
# 1. Owner type (GitHub API): GET /repos/OWNER/REPO, read owner.type -> "Organization" or "User"

# 2. Surviving-line authors for one file (repeat per core file)
git blame --line-porcelain -w -M -C HEAD -- path/to/file | grep '^author-mail' | sort | uniq -c | sort -rn

# 3. Outside commits carrying a DCO sign-off
git log --grep='Signed-off-by' --format='%h %ae %ad'

# 4. Commits carrying co-author trailers (inspect for AI agents and bots)
git log --grep='Co-authored-by' --format='%h %ae %ad %s'

# 5. License and copyright scan (check ScanCode docs for current options)
scancode --license --copyright --json-pp scan.json path/to/repo
```

*Run from a fresh clone at HEAD. The -w -M -C blame options are meant to ignore whitespace and follow moved or copied lines, but confirm them against your git version's documentation before trusting the counts.*

### The authorship step, in detail

I found no published procedure for measuring surviving-line share by employer, so what follows is my method rather than a sourced standard. Group blame output by author email, then assign each author to "employee" or "outside" for the dates of their commits. Email domain is a starting point and nothing more. Founders and early engineers often commit from personal addresses, and contractors sometimes get company addresses. For the largest outside authors, check their employment history against the commit dates. [Refolk](/) resolves a GitHub author to their public professional history across GitHub, LinkedIn, and the open web, which turns that cross-check into a lookup rather than an hour of searching.

Compute two numbers per repo, and keep the per-file breakdown:

- **Outside line share:** surviving lines by outside authors divided by all surviving lines.
- **Outside commit share:** commits by outside authors divided by all commits. A large gap between the two usually means old outside code was rewritten, or that formatting commits are distorting blame.

When the gap list is written, the next step is someone who can read it. Licensing counsel who have done software diligence for funds are a small group, and they are hard to find by title alone.

Ask me this: `Open source licensing counsel in the US who have advised venture funds on software due diligence` - [run the search](https://www.refolk.ai/start?q=Open%20source%20licensing%20counsel%20in%20the%20US%20who%20have%20advised%20venture%20funds%20on%20software%20due%20diligence).

*Returns named attorneys with open-source licensing experience and evidence of fund-side diligence work, with their firm and profile links.*

## How this standard goes wrong

Most grading errors come from trusting a proxy: an email domain, a blame line, a policy page, an aggregate percentage, or a missing marker. Each failure below has a specific check, and a grade that skips the check should not be signed.

1. **Email-domain attribution.** Employees who commit from personal addresses get counted as outsiders, which inflates the gap. Contractors on the company domain get counted as insiders, which hides it. *Check:* cross-check the top authors against employment history and commit dates. Contractor code is not employee code unless counsel confirms the contractor agreement assigns it.
2. **Blame undercounts.** Reformatting, file moves, and vendoring commits reassign authorship to whoever made the mechanical change. *Check:* use the whitespace and move/copy options, exclude known formatting commits, and confirm the flags in the git documentation, since I have not verified them.
3. **The 95% bar misread.** Mozilla's 95% was author coverage across the project, while its archive says it relicensed only files where every holder agreed. A 95% aggregate can hide a file that is entirely outside-authored. *Check:* always run the per-file test, and never report the aggregate alone.
4. **A CLA that exists only on paper.** The CLA bot was added partway through the history, so every outside pull request before that date has no recorded signature. *Check:* find the bot's enable date and measure outside lines merged before it as uncovered, unless the company can produce signatures.
5. **Reading the title, not the grant.** "No assignment" is not the same as "cannot relicense". Elastic's agreement has no assignment yet permits unrestricted distribution. *Check:* classify the grant clause itself, and quote it in the gap list.
6. **A trademark false positive.** A matching mark turns up, but it belongs to an unrelated company or to a founder personally. *Check:* match the owner name to the legal entity exactly, and grade a founder-held mark Remediable, not Clean.
7. **No AI markers read as no AI.** Missing trailers mean nothing. The Copyright Office test is human expressive control, and commits do not record it. *Check:* grade on the presence of a written policy, never on the absence of markers.

> **Watch out:** Never report the aggregate alone
>
> A target at 97% author coverage can still have a core file written entirely by someone who never signed. Report the per-file result next to every aggregate figure, or the second grader will reach a different verdict.

Two quieter failures are worth naming. First, scope drift: one analyst includes a plugins repo, the other does not, and their numbers diverge. Step 1 exists to stop this, which is why both graders sign off on the repo list. Second, grading a moving target: the repo changes between first look and confirmatory diligence. Record the commit SHA you graded on every gap list.

## Handing counsel the gap list and keeping it current

The deliverable is a one-page gap list: the verdict, the six grades, every gap with a file path and a named author or asset, and the questions for the data room. Two analysts grading the same company should produce the same list. If they do not, the standard has not been followed.

**Code-title gap list for counsel**

```
CODE-TITLE GAP LIST
Target (legal entity):
Graders (first / second):
Commit SHA graded, per core repo:
Core repos in scope:

OVERALL VERDICT: Clean / Remediable / Encumbered
(Worst criterion grade. Only counsel may change a grade, in writing.)

1. Agreement coverage: __% of outside authors covered (floor 95%) | Grade:
   Mechanism: Assignment / Broad-grant CLA / DCO / None
   Grant clause (quoted):
   CLA bot enable date:
2. Uncovered lines per file: __ files with uncovered lines; __ wholly uncovered | Grade:
3. Copyleft inflow: GPL __ / AGPL __ / MPL __ files; vendored dirs: | Grade:
4. Repo ownership: Organization / User / Third-party org; owner name: | Grade:
5. Trademark: registry, status, owner name vs legal entity: | Grade:
6. AI-generated code: written policy found Y/N; markers found: | Grade:

GAPS
G1. File/asset: | Uncovered author(s) or holder: | Lines: | Proposed fix:
G2. File/asset: | Uncovered author(s) or holder: | Lines: | Proposed fix:

QUESTIONS FOR THE DATA ROOM
- Signed CLA records for outside PRs merged before the bot enable date
- Employment and contractor IP terms for the top outside authors
- Assignment of any founder-held repo or mark to the company
- Written AI-use policy for code contributions

LIMITS OF THIS GRADE
Outside-in only. No employment agreements, contractor terms, or private repos reviewed.
```

*One per target. Fill every line; write "none found" rather than leaving a line blank, and quote the CLA grant clause verbatim.*

### Who reads it

Outside-in grading has no natural owner inside most funds, and the market numbers explain why. In Refolk's index of professional profiles, licensing specialists are concentrated in the US, and practitioners of software composition analysis (automated license and component scanning) are far scarcer:

| Skill | Country | Profiles |
|---|---|---|
| Open Source Licensing | US | 803 |
| Open Source Licensing | Germany | 107 |
| Software Composition Analysis | US | 57 |

That is 7.5 times as many licensing profiles in the US as in Germany, and 14.1 times as many US licensing profiles as US composition-analysis profiles. In a sample of 25 US licensing-skill holders, the titles were mostly founders and executives, with no title appearing more than once, at companies including Mend.io, AWS, and NVIDIA. Composition-analysis practitioners tend to be security engineers, not deal teams.

**803 - US profiles listing Open Source Licensing in Refolk's index**

Against only 57 US profiles listing Software Composition Analysis, so most funds will borrow the scanning skill rather than hire it.

In practice, the platform partner runs the grade and outside counsel reads the gap list. When you need counsel with fund-side diligence experience, or an engineer who has run ScanCode at scale, describing that person to Refolk in plain English is faster than filtering titles that, as the sample shows, rarely repeat.

#### Before you sign the grade

- [ ] Both graders signed off on the same written list of core repos.
- [ ] Owner type and owner name are recorded for every core repo.
- [ ] Every one of the largest outside authors was checked against employment history for the commit dates, not just email domain.
- [ ] The CLA grant clause is quoted verbatim and classified as assignment, broad grant, narrow grant, or none.
- [ ] The CLA bot's enable date is recorded, and outside lines merged before it are counted as uncovered unless signatures exist.
- [ ] The per-file uncovered result is reported next to the aggregate coverage figure.
- [ ] Every flagged copyleft file is listed by path, with MPL kept separate from GPL and AGPL.
- [ ] The trademark owner name has been matched exactly against the company's legal entity.
- [ ] The AI criterion is graded on whether a written policy exists, not on the absence of markers.
- [ ] The commit SHA graded is recorded for every core repo.
- [ ] Two independent verdicts match, or the disagreement is written down for counsel.

### Keeping the grade current

A grade is valid only for the commits it read. Re-run steps 3 to 7 at confirmatory diligence against the current SHA, and compare gap lists line by line: new outside contributors, a CLA bot change, or a new vendored directory can each move a criterion. Re-check the trademark registries at the same time, because pending marks get granted, abandoned, or opposed. Re-check the AI criterion against current law before each deal, since the sufficiency line is the part most likely to move. And if your fund tightens or loosens the 95% coverage floor, write the new number into this document, because the cutoff is your policy and not a market standard.

## Frequently asked questions

### Can an open source company relicense its code if contributors only signed a DCO?

Not on the strength of the DCO alone. A DCO works on an inbound=outbound model: each contribution comes in under the same license the project ships under, and the contributor keeps the copyright. The Signed-off-by trailer proves the contributor certified their right to submit, not that they granted a relicensing right. The company can still relicense code its employees wrote on company time, so the real question is how much surviving code came from outsiders under DCO only.

### What outside-contributor share is too high for an open-source startup?

No public market threshold exists, so any cutoff is your fund's policy. This standard grades the uncovered share rather than the raw outside share. Below 95% of outside authors covered by an assignment or relicensing-capable CLA is Encumbered, and so is any core file written entirely by uncovered outsiders. The anchors come from Mozilla, which treated 95% author coverage as enough but relicensed only files where every copyright holder agreed.

### Does a Clean grade mean we can skip confirmatory IP diligence?

No. A Clean grade means nothing visible from the outside contradicts the company's claim to title. The grade cannot see employment agreements, contractor IP clauses, private repositories, or signed CLA records the bot does not expose. Treat Clean as permission to move to a term sheet without a title condition. Keep the standard IP representations and the counsel review in confirmatory diligence, and re-grade at the commit SHA current at that point.

### How do I tell whether a GitHub repo is owned by the company or a founder?

Check the owner type through the GitHub API, which reports whether the owner is an Organization or a User account. A core repo under a founder's personal User account grades Remediable, because the founder can transfer it to a company organization before closing. A repo under an organization the company does not control, such as a foundation or a former employer, grades Encumbered, because the company cannot fix that on its own.

### Does AI-generated code make an open-source startup uninvestable?

Not on outside evidence. The US Copyright Office's position is that AI output is protected only where a human author determined enough of the expressive elements. The courts have left the human-authorship rule in place without saying how much human involvement is enough. Commit metadata cannot show human expressive control, so this standard caps AI findings at Remediable and sends them to counsel with a request for the company's written AI-use policy.

### How long does an outside-in code-title grade take?

Roughly an afternoon per target, going by my own estimates, which are not sourced. Scoping and the ownership check take about 25 minutes. Authorship measurement takes 1 to 2 hours, agreement coverage about an hour, and the license scan about an hour. Trademarks and AI markers take about 20 minutes each. Repos with long histories, heavy vendoring, or many outside contributors will run longer, mostly in the authorship step.

---

*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/coss-code-title-standard*