What "you own the source code" should mean in your contract

"You will own the source code" is one of the easiest sentences for a software vendor to say, because on its own it commits them to almost nothing. Whether it means anything depends entirely on what the contract says underneath it, and most contracts say very little.

This is not usually dishonesty. It is that nobody on either side thought about what a handover actually requires until the day it was needed.

Three things that get confused

They sound similar and they are not.

• **A licence to use.** You may run the software. You may not change it, and you may not give it to anyone else to change. If the vendor stops trading, you have a running system you cannot touch.
• **Escrow.** The code sits with a third party and is released to you if the vendor fails. Better than nothing, but escrow releases are slow, and what gets released is frequently a snapshot that nobody has tested deploying.
• **Ownership.** The code is yours. You can change it, give it to another vendor, or publish it. This is the one worth having.

If a contract says "the client will own the deliverables", ask what "deliverables" is defined as. If it is not defined, it means whatever is convenient later.

What a handover has to include

Code alone is not enough to run a system. The clause should list the materials, not just the intent.

• **The full source, with its version history.** A repository, not a zip file. History tells the next developer why something is the way it is, which is often the difference between a two-day change and a two-week one.
• **The database schema and a full data export**, in a documented, restorable format.
• **Deployment documentation** detailed enough for someone else to follow — server requirements, configuration, environment variables, scheduled jobs.
• **Third-party accounts and credentials.** Payment gateway, SMS provider, mail service, domain, SSL, analytics. These are commonly registered in the vendor's name and are quietly the hardest part of a handover to unpick.
• **Any build or deployment scripts.** If the software cannot be built without a tool only the vendor has, you do not have a working handover.

The clause that makes it testable

Feature lists can be verified on delivery day. Ownership usually cannot, because nobody tries to use it until they need it, by which point the relationship may have ended.

The fix is to make it testable, in one sentence:

A handover is complete when a third party, using only the delivered materials and without contacting the original vendor, can deploy and run the system.

That single line converts a promise into an acceptance criterion. It also changes vendor behaviour during the build, because documentation written at the end to satisfy a clause is always worse than documentation written as you go to satisfy a test.

What you take on

Ownership is a responsibility as much as an asset, and a vendor who explains only the upside is not being straight with you.

• **Security patches become yours.** The framework, the language runtime and the server all get updates on a schedule nobody controls. An unmaintained system is a liability on a predictable timeline.
• **You need somebody who can read it.** Either an internal developer, or a maintenance arrangement with someone.
• **Custom code has no community.** When a widely used product breaks, thousands of people hit it and the fix is public. When yours breaks, you are the only one who has seen it.

This is the honest case for a maintenance contract alongside ownership — not because you cannot leave, but because most organisations should not want to do the work themselves. The point of ownership is that you *can* leave, and that the price of staying is therefore a fair one.

Questions worth asking before signing

1. Is ownership stated as ownership, or as a licence?
2. What exactly is included in the handover — is it listed, or implied?
3. In whose name are the third-party accounts registered?
4. Does the contract define what a complete handover is, in a way that could be tested?
5. What does it cost to get a full export and handover if we end the contract early?

That last question is the most revealing one. A vendor building something maintainable will quote it as routine work. A vendor building a dependency will price it, or describe it, in a way that tells you a great deal.