If you paid someone to build your software and the contract does not say who owns it, the answer may not be you. In the US, the UK and India, the default rules around source code ownership lean toward whoever wrote the code or employs the people who did, not toward whoever paid the invoice. The fix is simple and cheap: the right clause in the contract, and a handover that covers more than a zip file of code.
This article explains the default rules, what a good ownership clause says, and gives you a handover checklist you can use whether you are starting a project or ending one.
Paying for software is not the same as owning it
Copyright in code normally belongs first to its author. Employment changes that: when an employee writes code as part of the job, the employer owns it. But an outside agency or freelancer is not your employee, so the default does not help you.
- United States. A commissioned work can be a "work made for hire" only if it falls into one of nine listed categories and both parties sign a written agreement saying so. Software is not one of the nine categories in the US Copyright Office's circular on works made for hire. In practice, contractor-written code usually needs a written assignment of copyright rather than a "work for hire" label alone.
- United Kingdom. Under section 11 of the Copyright, Designs and Patents Act 1988, the author is the first owner, and the employer is the first owner of work an employee makes in the course of employment, subject to any agreement to the contrary. There is no general rule that the person commissioning the work owns it.
- India. The Copyright Act, 1957 also makes the employer the first owner of employees' work unless agreed otherwise, so an Indian agency owns what its developers write until it assigns it. An assignment must be in writing and signed; if it states no period it is deemed to last five years, and if it states no territory it is presumed to cover India only. We cover this in more detail in our guide to working with Indian development firms.
The common thread: without a signed assignment, you may have a license to use the software but not the right to sell it, license it to others or stop the developer reusing it. This is general information, not legal advice. Have a lawyer check the clause under the law that governs your contract.
What a good source code ownership clause covers
A solid clause is usually half a page. It should deal with six things:
- Assignment of the deliverables. All rights in the code, database design, interface designs and documentation made for you are assigned to you, worldwide, for the full term of copyright.
- When it takes effect. Many vendors assign ownership as each milestone is paid. That is reasonable. Assignment only on final payment is weaker for you, because a dispute over the last invoice can leave you owning nothing.
- The vendor's existing tools. Agencies reuse their own libraries, starter kits and components. They will want to keep those, which is fair. In return you need a permanent, royalty-free license to use them inside your product, including after you part ways.
- Open-source components. Most software includes open-source packages that stay under their own licenses. Ask for a list of them and their licenses, so nothing in there restricts how you can sell or distribute your product.
- Paid third-party assets. Fonts, stock images, premium plugins and paid APIs should be licensed in your company's name, not the agency's.
- Delivery of the source. The clause should say you receive the source code, not just a compiled app or a hosted site, and where it will live.
Before you sign, read the vendor's terms against this list. Ours are in our terms of service, and we would rather you read them closely than skim them. When we build for a client, the client owns the source code and has access to the repository.
The code is only half of what you need to own
Owning the code does not help much if the domain, the server and the app store listing belong to someone else. The situation we would most want you to avoid is this: the code is legally yours, but the app is published under the agency's developer account, the domain is registered to a former freelancer, and the payment gateway sends money to an account you cannot log in to.
Set these up in your company's name from day one and give the developers access, rather than the other way round. Moving things later is possible but slower. Transferring an app between Google Play accounts, for example, needs details from both accounts and does not carry over financial reports.
Handover checklist
Use this at the end of a project, when switching vendors, or as a quarterly check that you could switch if you had to.
Code and build
- Repository in your organization, with full history, all branches and tags.
- A README that explains how to install, configure and run the project on a fresh machine.
- Build and deployment scripts, and the CI/CD configuration if there is one.
- A list of open-source dependencies and their licenses.
Infrastructure and accounts
- Admin access to hosting or cloud accounts, billed to you.
- Domain registrar and DNS access in your name.
- Google Play and Apple developer accounts owned by your company, plus the signing keys or signing configuration the stores need.
- Owner access to email delivery, payment gateway, maps, analytics and any other third-party service.
Data and secrets
- A recent database backup you have restored at least once, so you know it works.
- All environment variables, API keys and certificates, handed over in a password manager, not by email or chat.
- Where backups run, how often, and how long they are kept.
Knowledge
- A short architecture note: main components, how they talk to each other, and anything unusual.
- Known bugs, technical debt and anything half-finished.
- A recorded handover call with the lead developer.
Once everything is in your hands, rotate the passwords and keys and remove the departing team's access.
Testing the handover before you need it
Imagine an outdoor gear retailer running a custom web shop built by an agency two years ago. The owner is happy with the agency but wants to know they could move if they had to.
They ask a second developer for a four-hour paid exercise: clone the repository, follow the README, and get the shop running on a laptop with a copy of the database. It takes six hours, not four. The README skips a queue worker the shop needs to send order emails, and one API key is only in the live server's settings, not in the handover notes.
Both gaps take the original agency 30 minutes to document. Found during a calm week, they cost almost nothing. Found after the agency has gone, they would have meant days of guesswork while order emails silently stopped. That is why we recommend running this test once a year even when nothing is wrong.
Handover is a habit, not an event
The easiest handover is the one that has been happening all along. Ask for repository access in the first week. Keep accounts in your name. Ask for the README to be updated whenever setup changes. If you are still choosing a vendor, the ownership questions in our list of questions to put to a development company before signing will show you quickly who is comfortable with this and who is not.
Pick one item from the checklist this week, probably the backup restore or the domain registrar login, and confirm you actually have it.
If you have inherited a site or app and are not sure what you are holding, our website management team can work through this checklist with you and list what is missing before anything goes wrong.
