Can you sell your GitHub history?

Separate the repository from the rights

A repository can contain company code, open-source dependencies, contractor work and contributions from people outside the company. Issues and pull requests can include customer material, screenshots and copied excerpts. Check each category rather than treating the account owner as the owner of everything.

GitHub’s permissions for public repository viewing and forking are different from permission to license content for a new commercial purpose. An existing software licence can grant certain uses, but its obligations and scope still matter. Review the applicable terms and get advice where the proposed use is unclear.

• Identify employees, contractors and outside contributors.
• Locate IP assignment agreements and any contributor licence agreements.
• Keep a component and licence inventory; mark unresolved items.

What history adds beyond a code snapshot

A current snapshot shows what software looks like now. Linked commits, issue reports, reviews and tests can show how a problem was diagnosed and changed. That sequence may be relevant to AI development or evaluation, depending on the buyer’s task.

The useful unit may be a documented issue and its resolution, not every commit in a large repository. Broken links, missing discussion context and generated changes can limit usefulness. Describe authentic history and its gaps; do not manufacture extra reviews or outcomes.

Check the history for hidden exposure

Deleting a secret from the latest file does not remove it from earlier commits. History can preserve API keys, passwords, internal URLs and credentials. Scan all intended exports, rotate any exposed credentials and verify the cleaned result before sharing.

Author names, email addresses, review comments and support details can be personal data. Replacing a name with an identifier may only pseudonymise the data; if people remain identifiable, data-protection obligations can still apply. Obtain a privacy review rather than assuming removal of names is enough.

Create a scoped preparation plan

Begin with a description of languages, approximate history span, repository structure and the kinds of linked work available. The initial AssetGate assessment needs no repository access or data upload.

If a later authorised review is justified, define the proposed export in advance. Separate company-owned material from dependencies, omit unrelated branches and customer content, and record the cleaning steps. A confidentiality agreement is useful but does not fix missing ownership or a lack of lawful basis.

• Set an explicit repository, branch and date scope.
• Export only permitted code and associated history.
• Review comments, attachments and author metadata separately.
• Validate that useful issue-to-change links survive cleaning.

Agree what the buyer can do

Discuss whether the licence permits evaluation, training, deployment or redistribution. Clarify rights to derivatives and trained models, access controls, retention and onward sharing. Non-exclusive licensing generally differs from transferring IP ownership.

Uncertain rights do not automatically end the conversation. They identify a review task and may require excluding content or obtaining permission before any licence. Never represent an unresolved rights chain as cleared.