Systems and records
Who owns code in a founder's personal GitHub account?
By SourceX Editorial · Reviewed by Noah Loul ·
Short answer
The GitHub account that hosts a repository does not decide who owns the code. Ownership turns on who wrote it, when, and under what agreement. If company code sits in a founder's personal account, get a signed assignment covering past and future work, then transfer the repository to a company-owned organization so issues, pull requests and history move with it.
Key takeaways
- Hosting is not ownership: a repository's location on GitHub says nothing about who holds the copyright.
- Code a founder wrote before the company existed generally stays with the founder until it is assigned in writing.
- Contractor code usually needs a written assignment; a paid invoice alone may not transfer ownership.
- Transfer repositories to a company organization rather than re-uploading code, so commit history, issues and pull requests stay intact.
- Diligence teams compare the contributor list in git history against signed agreements, so gaps surface early.
Does the account that hosts a repository own the code?#
The account that hosts a repository controls access to it, but ownership of the code is decided by copyright law and contracts. A founder's personal GitHub account can hold code the company owns outright, code the founder still owns, or a mix of both, and nothing in the repository settings tells you which.
Under US copyright law, work an employee creates within the scope of employment is generally treated as the employer's, and other work generally belongs to its author until it is assigned in writing. That is why dates matter: whether the founder was an employee, a contractor or not yet working for any company when each part of the code was written.
Control still matters commercially. Even where the company clearly owns the code, a repository under a personal account means one individual can delete it, change who can see it or leave holding the only admin rights.
When founder code belongs to the company, and when it may not#
Founder code generally belongs to the company when it was written as an employee or was assigned by a signed agreement. The harder cases are code written before incorporation, code written without any employment or assignment agreement, and code that mixes in material from elsewhere.
| Situation | Likely starting position | Typical fix |
|---|---|---|
| Written after hire, under an invention assignment agreement | Company owns it | Confirm the agreement is signed and on file |
| Written before the company was formed | Founder owns it until assigned | Technology assignment covering pre-formation work |
| Written while the founder had no employment or assignment agreement | Unclear; depends on the facts | Confirmatory assignment drafted by counsel |
| Written by contractors or agencies | Contractor often owns it absent a written assignment | Assignment from each contractor or agency |
| Copied from open-source projects | Original authors keep copyright; the license sets conditions | License inventory and compliance review |
| Written while the founder worked for another employer | Prior employer may claim it under its agreement | Counsel review of the prior employment agreement |
IP assignment checklist before any transfer#
Before any repository transfer, collect the signed IP assignments, because moving a repository changes who controls it but does not transfer copyright. The checklist below is what counsel and a buyer's diligence team usually want to see.
Wording matters more than people expect. An agreement that says a person agrees to assign future work is weaker than one that says the person hereby assigns it, and counsel will usually want the second form, signed and dated, for every material contributor.
- A founder technology assignment that expressly covers work created before the company was formed.
- Invention assignment agreements for every employee who committed code, with present assignment wording.
- Written assignments from contractors and development agencies, matched to the repositories they touched.
- A contributor list pulled from git history, with each commit email mapped to a person and an agreement.
- An open-source license inventory, including copied snippets and vendored libraries.
- A note of any personal projects or prior-employer work the founder excluded when joining.
- Board or investor approvals where the assignment is tied to equity or other consideration.
How to move the repository without losing history#
A repository transfer moves the repository itself, so the commit history moves with it and authorship stays exactly as recorded. GitHub documents that a transfer also carries issues, pull requests and the wiki and redirects the old address; confirm the current details in GitHub's documentation before relying on them.
Avoid the shortcut of downloading the code and pushing it to a fresh company repository. That keeps the files but can drop issues, pull request reviews and discussion, which are the records that show how the software was built and why. Do not rewrite history to change author emails either: authorship is evidence, and altering it looks like tampering in diligence.
After the transfer, work through the items that depend on the old owner.
- Repository secrets, deploy keys and webhooks: check how GitHub's documentation says they carry over, review who can still see them, and rotate any the old owner could access.
- GitHub Apps, CI integrations and package registries tied to the old owner.
- Branch protection rules and team permissions in the new organization.
- Forks held by the founder or contractors, and whether they should be removed.
- Documentation, scripts and build files that hardcode the old repository URL.
What acquirers check in software diligence#
Acquirers check that every repository the business depends on sits under a company-controlled organization, and that the people who wrote the code signed agreements covering it. For software holding groups that buy and keep vertical businesses, this check repeats with every acquisition, so a standard evidence list saves time.
Secrets deserve their own note. Old commits often contain API keys and passwords, and open-source scanners can find them before a buyer does. Gitleaks scans git repositories for secrets such as passwords, API keys and tokens, though its maintainer said in May 2026 that it is feature complete and will get security patches only. TruffleHog can also try a found credential to confirm whether it is still live, which sends real login attempts, so run that check only with approval. Rotating exposed credentials matters more than scrubbing them from history.
| Evidence | What it proves |
|---|---|
| List of repositories with owner account and purpose | Which code the business relies on and who controls it |
| Organization owner and admin list | That control sits with the company, not individuals |
| Signed founder, employee and contractor assignments | Chain of title for the code |
| Contributor-to-agreement map from git history | No author is missing an agreement |
| Open-source license report | Obligations attached to third-party code |
| Secrets scan results and rotation log | Credentials left in history have been found and replaced |
Illustrative: a holding group finds the core repository under the founder's name#
Illustrative: a fictional software holding group agrees to buy a small company that makes inspection software for commercial roofing contractors. Diligence shows the main application repository, its issues and years of pull request reviews sit under the founder's personal GitHub account, along with a prototype built before the company was formed.
The founder is staying on as general manager and cooperates. At closing, the founder signs a confirmatory technology assignment covering the prototype and all later work, then transfers the repository to a new organization owned by the operating company. The founder keeps access as an organization member, and the group's IT team rotates every secret and webhook.
The outcome is a clean chain of title. When the group later reviews which engineering records could be licensed, the issue history and code review threads can be considered, because ownership and control are documented.
Why ownership comes first when licensing code and engineering records#
Code, code reviews and issue histories can only be licensed by a company that can show it owns or controls them. In the SourceX five-step transaction, Supply, Rights, Preparation, Approval and Delivery, the Rights step confirms chain of title and carves out customer-owned code, third-party code and anything the founder kept.
Each repository in scope gets an entry in the SourceX Evidence Packet, with the assignment documents that support its provenance and licensing rights. The initial fit check covers metadata only, such as how many repositories exist and how many years of history they hold, so no code is shared at that stage.
Frequently asked questions
Will transferring the repository change who appears as the author of old commits?
No. Commit authorship is stored in the git history and stays as recorded after a transfer. That is useful: authorship is evidence of who wrote what and when. Ownership is established by the assignment documents, not by rewriting author names.
What if the founder has left and will not sign?
Start with the agreements already on file; an earlier invention assignment may cover more than people remember. If gaps remain, counsel can assess options, including negotiation and contract claims. A hosting provider generally will not decide an ownership dispute between a company and an individual.
Does the same apply to GitLab or Bitbucket?
Yes. The legal question is the same on every platform: who wrote the code and what they signed. The practical steps differ, so check each provider's documentation for how project transfers handle issues, merge requests, CI variables and permissions, and record what moved in the transfer log.
Can a founder keep a personal copy of the code?
Only if the agreements allow it. Once the company owns the code, a personal copy is usually governed by confidentiality and assignment terms. Many companies ask founders, whether staying or leaving, to confirm in writing that they hold no copies outside company systems.
Should the founder's personal account stay an owner of the company organization?
Usually it should be a member, not the sole owner. Keep more than one company-controlled owner account, tied to company email addresses and protected with strong authentication, so control never depends on a single person. Review the owner list whenever someone with admin rights leaves the business.
Sources
- Gitleaks detects secrets such as passwords, API keys and tokens in git repositories; a May 2026 README update states it is feature complete and future releases will be security patches only. Source
- TruffleHog is an open-source secret scanner that, for secrets it can classify, can log in to confirm whether the secret is live. Source
Related resources
See if your company qualifies
A short company assessment. No data uploads are needed.