How Source-Code Ownership Works in Custom Software Projects
Ownership of custom software is determined by your contract, not by who has a copy of the code — many agreements only grant a licence to use software the vendor still legally owns, unless the contract explicitly assigns intellectual property to you. Verifying real ownership means reading the actual clause, not assuming from the file transfer.
Ownership, Licences and Third-Party Code Are Three Different Things
Having a copy of the source code files is not the same as owning the intellectual property in them — ownership is a legal status defined by your contract, and unless that contract explicitly assigns the IP to you (commonly through a "work for hire" or IP-assignment clause), the vendor may retain ownership even after handing over every file. A licence, by contrast, grants you the right to use the software under specified terms without transferring ownership at all — which can still be perfectly workable, but is a materially different position to be in.
Almost every custom build also includes third-party components — open-source libraries, paid UI kits, commercial APIs — that were never yours or the vendor's to fully own in the first place. Each of these carries its own licence terms, and those terms travel with the code regardless of what your contract with the vendor says about the code the vendor wrote themselves.
The Contract Terms Worth a Lawyer's Time
A handful of specific clauses determine what you actually end up with: the IP-assignment or work-for-hire language (does ownership transfer, and when — at final payment, or progressively), any licence-back terms (some vendors assign IP to the client but retain a licence to reuse general components in other projects, which is normal for reusable frameworks but worth understanding), and what happens to ownership if the contract ends early or a payment is disputed.
These are genuinely contract-law questions, and the specific wording matters more than general principle — this article describes what to look for, not a substitute for having the actual clauses reviewed by your own lawyer before signing anything significant.
Who Actually Controls the Repository, Deployment and Accounts
Legal ownership and practical control are also two different things, and the gap between them is where most disputes actually happen. Practical control means: whose account is the code repository under, who holds the login for the hosting provider and domain registrar, and who administers any third-party services (payment gateway, SMS provider) the software depends on.
Imagine an e-commerce brand that received a "final delivery" zip file from its developer at project handover and assumed that settled the matter — only to discover, months later, that the hosting account, domain, and a paid UI-component licence were all still registered in the developer's name, with no clean way to transfer the domain without the original registrant's cooperation. The code files were never the actual point of leverage; the accounts were.
What a Proper Handover Includes
A complete handover covers more than the codebase: the full commit history (not just a final snapshot, which loses the record of who changed what and when), all environment configuration and credentials needed to actually run the system, a list of every third-party dependency and its licence terms, and — critically — a transfer of the repository, hosting, domain and any related accounts into your own organisation's ownership, not just access to someone else's.
This should be specified in the contract before work starts, not negotiated as a favour at the end of the project when the vendor has the most leverage and the least incentive to make the process smooth.
A Verification Checklist Before You Sign Off
Before considering a project fully handed over, check each of the practical items directly rather than taking a vendor's word that "it's all yours now."
Do this verification while the vendor relationship is still active and cooperative, not months later when a gap has become urgent — a missing item is a quick fix during handover and a much harder conversation once you actually need something the vendor still controls.
- Is the code repository under an account your organisation controls, with the vendor's access removed or downgraded?
- Is the hosting account, domain registration and any payment-gateway or SMS-provider account registered to your organisation, not the vendor's?
- Do you have a documented list of every third-party library or paid component used, with its licence terms?
- Does your contract's language actually assign IP ownership to you, or only grant a licence to use the software — and have you had that specific clause reviewed?
- Do you have the full commit history and environment configuration, not just a final code snapshot?
Code-and-account handover checklist
A verification checklist covering five categories of handover — repository access, hosting and domain accounts, third-party licences, IP-assignment contract language, and commit history/configuration — with a column for who currently controls each item, so a reader can identify gaps before treating a project as fully closed out.
Frequently asked questions
Does receiving code prove ownership?
No — having a copy of the files proves you have access, not that you own the underlying intellectual property. Ownership is determined by your contract's IP-assignment language, and unless that language explicitly transfers IP to you, the vendor may retain legal ownership even after a full file handover.
What happens to third-party licences?
They stay in effect regardless of your contract with the vendor — open-source libraries, paid UI kits and commercial APIs each carry their own licence terms that travel with the code. A handover should include a documented list of these, since your rights to keep using each one depend on its own licence, not on your project contract.
Have a specific situation to work through?
This article covers the general case. Tell us what you're actually dealing with and we'll respond directly.