How Source-Code Ownership Works in Custom Software Projects

Holding the files is not owning them. Ownership is a legal status set by the contract, and unless an IP-assignment or work-for-hire clause transfers it, the vendor may keep ownership after delivering every file. A licence is different. It grants the right to use the software on stated terms without moving ownership, which can still be workable but leaves the vendor holding the real asset.

Third-party code complicates this. Almost every build includes open-source libraries, paid interface kits and commercial APIs, and each carries its own licence terms that travel with the code whatever your contract says. Neither side owns those parts.

Ask for the list. Request a bill of materials naming every open-source package and paid component with its licence, because some licences restrict what you may do with the finished product.

Three clauses matter most. The first is the assignment language: does ownership transfer, and when, at final payment or progressively as each milestone is paid for? The second is a licence-back term, where the vendor assigns the work but keeps the right to reuse general components, which is normal for frameworks. The third covers early termination. It should say who owns the partly finished work if the contract ends early or a payment is disputed, because that is when vague wording gets tested.

Wording beats general principle. This article describes what to look for, but have your own lawyer read the actual clauses before you sign anything significant, because the rules differ by jurisdiction.

Ask about reuse too. If the vendor intends to reuse code written for you in another project, the contract should say whether that is allowed, because silence often favours whoever wrote the code.

Legal ownership and practical control differ. Practical control means knowing whose account holds the code repository, the hosting login, the domain registrar and any payment gateway or SMS provider the software depends on.

Suppose an online shop reached handover. It received a zip file, assumed that settled everything, and later found the hosting account, the domain and a paid interface licence still registered in the developer’s name. The accounts were the pressure point, not the code files, and the developer suddenly held all the bargaining power in the conversation that followed.

Check the domain separately. A domain registered by the developer under a personal email can lapse unnoticed, taking the website and every address on it offline until someone with the login renews it.

A handover covers more than the codebase. It includes the commit history, not a final snapshot, every environment setting, the credentials needed to run the system, and each dependency with its licence terms. Accounts must move too. The repository, hosting, domain and related accounts should be transferred into your organisation’s ownership, not merely shared with you as a guest of the vendor’s.

Put this in the contract. Negotiating handover as a favour at the end is a weak position, because the vendor then holds the bargaining power and has little reason to make it smooth.

Test the handover once. Ask a colleague to clone the repository, build the project on a clean machine and deploy to staging using only the documents supplied. A missing step shows within an afternoon.

Check each item yourself. Do not take a vendor’s word that everything is yours now, and run the checks while the relationship is still active and cooperative.

Gaps are easy to fix now. Months later, once you need something the vendor still controls, the same gap becomes a hard conversation held on the vendor’s terms.