Code ownership sounds like a legal detail until a founder discovers that the app they paid for sits in a freelancer’s personal account, the hosting is on the agency’s card and nobody has the password to the domain. Getting it right costs almost nothing at the start of a project. Fixing it later can mean lawyers, lost months or rebuilding from scratch. This guide explains how Git works, what owning your code involves in practice, and what to agree before work begins.
Git in plain English
Git is a version control system: it records every change to a project’s code, who made it and when, as a series of saved snapshots called commits. The full history lives in a repository. Developers keep copies on their own machines and share changes through a hosted service such as GitHub, GitLab or Bitbucket.
For a founder, two facts matter. First, the hosted repository is the master copy of your product. Second, whoever owns the account that holds that repository decides who can see it, change it, or delete it.
Code ownership has two halves
There is legal ownership (who holds the copyright) and practical control (who holds the accounts). You need both, and each can fail without the other.
Legal ownership
Copyright in code usually belongs to whoever wrote it unless an agreement or the law says otherwise, and the rules differ from country to country. In the UK, the Copyright, Designs and Patents Act 1988 makes the author the first owner, with an exception for work made by an employee in the course of employment, which belongs to the employer unless agreed otherwise. A freelancer or agency is not your employee.
In the US, commissioned work counts as “work made for hire” only if it falls into one of nine listed categories and both parties sign a written agreement saying so (US Copyright Office, Circular 30). Software is not one of the nine categories, which is why contracts commonly include an assignment of copyright as well.
India, the UAE and other countries have their own rules. The safe approach everywhere is the same: a written contract that assigns all intellectual property in the work to your company, signed before work starts, and checked by a lawyer where you operate.
Practical control
A signed contract does not help if you cannot get into the repository. Practical control means the accounts are yours.
Set it up right from day one
- Create an organisation account on GitHub or a similar host, using a company email address. Make at least two people from your business owners, so one lost phone does not lock you out.
- Have the repository created inside your organisation, and invite developers as members with the access they need.
- Open hosting, database, domain, app store, email and analytics accounts in the company’s name, paid for with a company card. Add your developer as a user, not as the owner.
- Keep a register of every service and who has admin rights.
- Turn on two-factor authentication for every account.
If your code is already in someone else’s account
Ask for the repository to be transferred to your organisation. On GitHub, the person needs admin access to the repository, and you need permission to create repositories in the receiving organisation. According to GitHub’s documentation, a transfer moves the commit history along with issues, pull requests and the wiki, and links to the old location redirect to the new one. Settings for webhooks, secrets and deploy keys stay attached.
Say a founder in Riyadh paid an agency to build a booking app, and the code sits in the agency’s account. A polite request for a transfer, backed by a contract clause, is often enough. If there is no contract, ask for a written assignment of copyright as part of the final payment.
What a proper handover includes
- The full repository with history, in your organisation.
- Admin access to every account the product uses, with the developer’s access reduced or removed.
- A list of secrets and where they are stored, with keys rotated after access changes.
- Setup and deployment instructions a new developer could follow.
- A note of third-party code and its licences. On GitHub’s own guidance, code published without a licence falls under default copyright, so check what you are relying on.
At Emberoot, the client owns the code, accounts and documents at handover. If you are unsure who owns your product today, our technology advice service can audit it, or contact us to talk it through.
This article is general information, not legal or professional advice.
Frequently asked questions
If I paid for the code, do I own it?
Not automatically. In many countries copyright starts with the person who wrote the code, and payment alone does not transfer it. A freelancer or agency is usually not your employee. You need a written contract that assigns the intellectual property to your company, ideally signed before work begins and checked by a local lawyer.
Can a developer keep my code in their own GitHub account?
They can during a project, but it is better to avoid it. Ask for the repository to be created in your company’s organisation account from the start, with the developer invited as a member. If the code is already in their account, ask for a transfer, which keeps the history, issues and pull requests.
What should a software handover include?
The full repository with its history in your own account, admin access to every service the product uses, a list of where secrets are stored with keys rotated afterwards, setup and deployment instructions, and a note of third-party code and licences. The developer’s access should then be reduced to what any ongoing support needs.