Can a company license its codebase for AI training?
Yes, if your company owns the code and can separate out the parts it does not own. A codebase is more than its current files. The commit history, the pull requests, the review threads, the linked issues and the incident write-ups record how your engineers reasoned about a system over years. Much of a company's data already lives in third-party software. Licensing it means re-licensing what already exists, and getting paid for it rather than giving it away for free. For code, that software is your Git host and issue tracker, such as GitHub, GitLab, Bitbucket, Jira or Linear, and the history in it is already structured.
GitHub's own terms show why the private part matters. Code you make public can be viewed and forked by other users, and the licence users grant under these terms lets GitHub and its affiliates use their content to train AI models, with no payment for those rights (GitHub Terms of Service, s. D.3 to D.5, effective Apr 27 2026). Private repositories are treated differently: GitHub considers their contents confidential to you, its staff access them only in listed cases or with your consent, and it says it will not use them to develop or improve its service, apart from private content you give its AI features as input, which you can opt out of (s. E.2 and E.3). That private history is the part only your company can license.
Why do AI labs and agent builders value engineering history?
Because coding agents learn from how real work changed a codebase, not only from finished files. SWE-bench, a research benchmark for coding agents, is built from 2,294 real GitHub issues and the pull requests that resolved them, across 12 Python repositories, and a model passes a task by editing the codebase to fix the issue (SWE-bench, arXiv). Your history may hold many tasks of that shape, from systems nobody has published.
The parts that teach the most:
- Review history. A comment that asked for a change, and the revision that answered it, shows what good work looks like in your codebase and why.
- Decisions. Design docs, architecture decision records and RFC threads explain trade-offs the code alone hides.
- Edge cases and failures. Bug reports, reverts, incident post-mortems and the fixes that followed them.
- Procedures. Runbooks, deployment checklists, on-call notes and CI configuration show how the system is actually operated, step by step.
- Domain systems. Internal code for billing, claims, logistics, trading or compliance, the kind of software that rarely appears in open source.
What makes a codebase more valuable?
Engineering history is worth more when it is complete and its parts link to each other. In rough order of impact:
- Full Git history. Every commit since the start, with branches and tags, rather than a snapshot of the main branch.
- Linked outcomes. Issues that point to the pull requests that closed them, pull requests that point to the tests and deploys that followed, incidents linked to their fixes.
- Review depth. Real review threads, with requested changes and the revisions that answered them.
- Documentation beside the code. Design docs, READMEs, wiki pages and runbooks, with their own version history.
- Scarcity. Business Insider reported that demand is lower for a codebase a rival lab already has (Business Insider, Oct 13 2026). So code that has never been published or licensed is likely to be in more demand than code anyone can clone.
- Clean structure. Exports that keep timestamps, file paths, roles and the link between a review comment and the line it refers to.
What gets excluded or de-identified from a codebase?
You approve the scope, so a client's repository, a security-sensitive service or a period of history need not be part of it. fearofgod.ai de-identifies the data before it goes to buyers. Raw data is deleted according to a schedule agreed with the partner.
What owners usually check before deciding the scope:
- Secrets. API keys, passwords and tokens committed by mistake stay in Git history after they are deleted from the current files. GitHub's secret scanning, for example, scans the entire Git history on all branches for hardcoded credentials (GitHub Docs). Rotate anything you find, whatever you decide to license.
- People. Engineers' names, emails and usernames in commits and reviews, and any customer data that ended up in fixtures, test files or logs.
- Client-owned work. Code built for a client under a contract that assigns it to them.
- Third-party code. Vendored dependencies, generated code and anything under someone else's licence.
Your company's name stays confidential until the agreement is fully signed, and a completely anonymous partnership is also possible. Your company can keep ownership of its data. This is agreed case by case.
What rights and licences does a codebase need?
The first question is who owns the code, and the answer depends on who wrote it. This is general information, not legal advice.
- Employees. In the US, the employer is the author and initial owner of a work made for hire, which includes work an employee prepares within the scope of their employment, unless the employer has signed a written agreement to the contrary with the employee (US Copyright Office, Circular 30). In the UK, the employer is the first owner of copyright in a work an employee makes in the course of employment, subject to any agreement to the contrary (Copyright, Designs and Patents Act 1988, s. 11).
- Contractors. In the US, a commissioned work is made for hire only if it falls in one of nine statutory categories and a written agreement signed by all parties says so; otherwise it is not a work made for hire (Circular 30). For freelancer and agency code, look for a written assignment of copyright.
- Clients. Development agreements often assign code to the client or limit reuse, and confidentiality clauses can cover a repository even where you own the code.
- Open-source code. Code you did not write stays under its authors' licences. GitHub's terms put the duty on you: if you post content you did not create, you are responsible for complying with any applicable licences (GitHub Terms, s. D.3). Even permissive licences carry conditions: Apache 2.0 requires anyone distributing copies to pass on the licence and keep the original notices (Apache License 2.0, s. 4).
- Provenance. Dataset builders check licences. The Stack, a 3.1 TB public code dataset, was limited to permissively licensed source code and came with a process for developers to have their code removed (The Stack, arXiv). Expect any serious licensee to ask how you know the code is yours.
What is a codebase worth?
Public reference points are few and far apart, and none is a fearofgod.ai price. Buyers quote wildly different numbers, because valuations rest on estimates of how many useful tasks a given amount of code yields, according to the person who leads an AI data company's work on agent training environments (MIT Technology Review, Oct 13 2026).
| Reference point | Market side | Figure and source |
|---|---|---|
| A wound-down startup's codebase | Reported sale, Oct 2026 | roughly $25,000 for the code, plus a still-pending amount, likely around $15,000, for its workspace data (MIT Technology Review) |
| Bankrupt airline's archive, including code and operational records | Court-process bids, Aug–Sep 2026 | a $7.5 million bid, topped by a $10 million bid, then a $12.5 million proposal; no sale court-approved as of Sep 14 (Fortune) |
| A data buyer's programme for midsize companies | Published buyer offer, reported Oct 2026 | $100,000 to $2 million for anonymised data (Business Insider); the buyer's own tiers are $100K–500K and $500K–2M |
What moves code up the range is depth: years of linked history, real review threads and domain systems nobody else holds. Partnerships typically range from $50K to $3M+.
How does licensing a codebase work with fearofgod.ai?
You license code and engineering history your company already keeps, securely, and earn additional, long-term revenue from it. It already lives in your Git host and issue tracker. No new data collection is needed. Your company can be paid more than once, through renewals and repeat licences.
The steps are the partnership form, a conversation, scope and terms, data preparation, then delivery and payment. Talk to our team when you are ready. Engineering teams that also keep a help desk or Slack history can read licensing support tickets and licensing chat and email archives.
Selling codebases to AI companies
A company that owns its code can sell its codebase and engineering history to AI companies by licensing them with fearofgod.ai, securely and for long-term revenue. Partnerships typically range from $50K to $3M+. Partners can be paid more than once, through renewals and repeat licences.