Can our GitHub history be licensed to AI companies, and how do we get it out?

Updated October 25, 2026 · How we research

What lives in GitHub, and why is it valuable?

GitHub holds source code and its full change history, plus issues, pull requests, code review comments, releases, and wikis. Together they show how software was written, reviewed, and fixed over time.

AI companies building coding tools value private, real-world codebases because they differ from public open-source code. Pull requests with review discussion, and bug fixes linked to issues, are especially useful.

How do you get code and history out?

As of October 2026, GitHub's documentation describes these options:

• Mirror clone: copies a repository's files and full revision history. Files stored with Git LFS (Large File Storage) need a separate fetch. Wikis can be cloned the same way.
• Migration archive: created through the REST API (application programming interface). GitHub's migrator docs list users, teams, repositories, wikis, issues and comments, pull requests and reviews, commit comments, and releases among the data included.
• GitHub says anything not on its list of migrated data cannot be migrated, including Git LFS assets; discussions and packages are not on that list. Archives are deleted automatically after seven days and must be under 20 GB.

Who has to do it?

GitHub says exporting a migration archive requires owner permissions on the organization's repositories, plus a token with repo and admin:org scopes. For a license, an organization owner should run the export or approve the access, not an individual developer.

Do buyers need an export?

Some buyer programs ask for read-only access instead, such as an app installed on selected repositories. Read-only access avoids moving large archives and can be removed when the work ends. Confirm which repositories it can see, whether it reads issues and pull requests too, and how the buyer deletes copies.

What should stay out?

Code carries hidden risks that are easy to miss in a quick review. Old commits, configuration files, and test data are the usual places where sensitive material sits. Common exclusions include:

• Secrets: API keys, passwords, certificates, and tokens, including in old commits.
• Open-source or third-party code under licenses you cannot relicense.
• Code written for clients under contracts that give them ownership.
• Customer data in test fixtures, logs, or database dumps.
• Security-related issues and vulnerability reports.

What rights questions apply?

Owning a repository does not mean owning every line. Contractor agreements, client work-for-hire clauses, and open-source licenses all affect what you can license. Commit history also names the people who wrote the code. See our guide on who owns the data and talk to your lawyer.

Where should you start with GitHub data?

List your repositories and mark which are wholly your own work, which contain client code, and which are forks of open-source projects. Run a secrets scan across full history, not just the current branch. One or two internal repositories with pull request discussion make a sensible first sample; see What is a data sample, and should you share one?.

General information, not legal, tax or financial advice.