What disqualifies a repository from being licensed?
Four things end it outright: someone else owns the intellectual property, the code was previously public or forked from something public, it is covered by an NDA or holds confidential data, or you cannot actually establish that you have the right to license it. Everything else is a deduction rather than a disqualification.
Most of what developers worry about here does not matter, and the thing that actually rules repositories out is something most people have not checked.
The four that end it
Someone else owns the intellectual property. Usually a client, via a work made for hire clause or an assignment in a services agreement. This is by far the most common disqualification and the one people are least certain about. It does not matter who typed the code.
It was public, or forked from public. Already collected, already in training corpora, no scarcity left. This includes a private repository that started as a fork of an open source project, for the forked portion.
It is under an NDA or holds confidential data. Client confidentiality, personal data belonging to real people, or anything you agreed in writing not to disclose. Out, regardless of who owns the copyright.
You cannot establish the right to license it. This is the quiet one. If you cannot find the contract, cannot remember the terms, or are working from a vague sense that it was probably fine, that is not a basis for the warranty you would be giving.
repo │ ├── client or employer owns the IP ──────► out ├── was public, or forked from public ───► out ├── NDA, or holds confidential data ─────► out ├── rights you cannot establish ─────────► out │ └── otherwise ───────────────────────────► in, value varies
What people worry about that does not disqualify anything
Bad code. Not a factor. The training value is in realism. A model learns more from the commit where you gave up and hardcoded the edge case than from anything you would put in a portfolio.
Secrets in the repository. Not your problem to solve. Credentials and personal data are stripped from the copy pulled for review, in the code and in the history, and that is verified before any buyer sees it. Your repository is not touched. You should not go rewriting history to clean this up, because rewriting history is genuinely destructive to value.
No tests, no documentation, no README. Fine. Most real software is like this.
Abandoned, unfinished, or never shipped. Fine, and often better. A product that did not find a market still has the full engineering record of building it.
An old or unfashionable stack. Better than fine. Scarcity is the argument, and there is far less public code in the languages quietly running large companies than there is in whatever is currently popular.
┌─ WORTH CHECKING ─────────────────────────────────────────────────────┐ │ │ │ Private, finished, owned by you, and doing nothing. │ │ │ │ [ See what your repos are worth ] │ │ │ └──────────────────────────────────────────────────────────────────────┘
What reduces the number without ruling you out
Vendored and generated code. node_modules, vendor/, Pods/, lock
files, compiled output, minified bundles, data dumps and binaries. None of it
counts. It is excluded from the valuation, so a repository that is mostly
dependencies is counted down to what is actually yours.
Shallow history. A repository with one initial commit containing a finished codebase is worth its source and nothing else, and source is the smaller half by a wide margin.
Squashed or rewritten history. Same problem, self-inflicted. If you squashed a year of work into one commit to keep the log clean, that year is gone.
Duplication across your own repositories. Five projects sharing the same boilerplate scaffold are not five copies of value.
The check worth running first
Before you estimate anything, answer one question per repository: can I say, without hedging, that I own this or hold the right to license it?
Not “the client never asked for it back”. Not “we didn’t have a formal contract”. Not “it was years ago”. Either the answer is a clean yes, or the repository does not go in.
The obligation attached to that answer is real and uncapped. You are warranting ownership to buyers who rely on it, and if the warranty is wrong you can be asked to return payments and cover the claims that follow. Nobody should be talked into optimism about this by a website.
If you are not sure, that is the normal state and there is a way through it. Start with who owns the code you wrote for a client.
What to read next
- Who owns the code you wrote for a client, the disqualifier that catches most people
- What AI labs pay for code, if the repo clears the filter
- Can you license private repositories, on what private actually has to mean
Common questions
- Does messy code disqualify a repository?
- No. Realism is the point. Workarounds, dead code, inconsistent style, and commits that say 'fix' are what real software looks like, and that is precisely the value.
- What if my repository contains API keys?
- It is not a disqualification and it is not your job to fix. Secrets and personal data are stripped from the review copy, in code and in history, and verified before a buyer sees anything. Your own repository is not modified.
- What if I only have the right to some of a repository?
- Then do not submit it. Partial rights are the hardest case to establish and the warranty you give covers the whole submission. If you cannot say cleanly that you hold the rights, leave it out.
- Does a public fork of my private work count?
- No. Anything previously published or forked from public code has already been collected, so there is nothing scarce left to license.
- Is a repository with no commit history worth anything?
- Less than you would hope. History is the large majority of the token volume and therefore of the value. A single initial commit containing a finished codebase is worth only its source.