Code ownership and IP transfer in offshore contracts: What to check before signing

Most software contracts contain a clause saying the client owns the intellectual property. Most buyers read it, nod, and sign. The clause is usually true and usually insufficient, because ownership of code is not the same as the ability to use it.

The gap between those may be too costly. Use this checklist to close it before the engagement starts.

Ownership transfers at a moment. Find out which one

Contracts differ when ownership moves. The common options:

On creation. The client owns each commit as it is written.
On payment. Ownership of deliverable transfers when its invoice is settled.
On completion. Ownership transfers when the project is accepted.

All three are defensible. Only the first two are safe for the buyer in an engagement that might end early. “On completion” means that if the relationship breaks down in month four of a six-month project, the legal status of four months of work is pure negotiation.

Ask directly: if we stop next month, having paid everything invoiced to date, what do we own? The answer should be short.

Work for hire does not travel well

The phrase “work made for hire” is a concept from one legal system. It does not automatically mean the same thing in the jurisdiction where your engineers actually sit, and in offshore software development that mismatch is the normal case rather than an edge case.

What matters in practice is whether each individual contributor has assigned their rights to the entity you are contracting with. A vendor that subcontracts, or that works with independent contractors rather than employees, needs a chain of assignments reaching every person who touched the code. Ask whether such assignments exist and whether they cover contractors as well as staff. UK guidance on copyright ownership draws the line plainly: work produced under a contract for services usually stays with the person who produced it unless they agreed otherwise in writing.

This is not a theoretical risk. It surfaces during due diligence, when an acquirer asks who wrote a given module and whether their rights were properly transferred. The same scrutiny falls on data and licensing when a business changes hands. Answer the question before the code is written.

Where the code lives is a separate question from who owns it

You can own code that you cannot reach. It happens more often than it should.

Establish, in writing:

Whose accounts host the repositories. If the answer is the vendor’s, you are depending on their goodwill for access.
Who holds the administrative rights on those accounts.
Whether CI pipelines, secrets, infrastructure definitions and deployment credentials are inside the same boundary as the code.
What happens to all of it on the day the contract ends.

The cheapest arrangement implies that the client owns the organization, the vendor engineers are members of it, and access is removed when the engagement ends. Anything else requires a migration at handover, which is one of the practical tests worth applying when choosing an outsourcing partner rather than after the contract is signed.

Third-party components need their own answer

Modern code is assembled as much as it is written. Your ownership of the code your vendor produced says nothing about the licenses of the libraries they pulled in.

Two requirements are worth putting in the contract:

A machine-generated inventory of dependencies and their licenses, delivered with each release rather than on request.
A list of license categories that are not acceptable for your use case, agreed up front.

Pre-existing material and reusable frameworks

Many vendors bring their own accelerators: internal libraries, project templates, and boilerplates. This is usually good for you because it reduces costs. It also creates a category of code that you did not commission and may not own, which is the same ownership question that sits behind the choice between building with your own developers and buying a finished tool.

The workable arrangement is explicit: pre-existing material stays in the vendor’s property, and you receive a broad, perpetual, irrevocable license to use, modify and sublicense it as part of the delivered system. What you must avoid is a system that depends on a component you can neither own nor license after the relationship ends.

Ask for a list of such components before work starts. If the list is empty, say so in the contract. If it is not, read it.

What “handover” should mean

Handover is usually described in a single sentence, and that sentence is usually optimistic. Define it as a deliverable with contents:

Source code in a repository you control, with full history rather than a squashed snapshot.
Infrastructure definitions, not just a description of the infrastructure.
Build and deployment instructions that a new engineer can follow.
Credentials rotated and transferred.
A written map of external services, accounts and who pays for them.
Known defects and workarounds, honestly listed.

Note the phrase “full history.” A repository delivered as a single initial commit is technically the code and practically a different thing: you lose the ability to understand why anything is the way it is.

Confidentiality runs both directions

Non-disclosure agreements usually protect the client’s information. Consider what protects the vendors because an agreement that is unreasonable in one direction tends to be ignored in both.

More useful than the NDA text is the operational question: what client data touches developer machines, and does it need to? Work that can be done against synthetic or masked data should be, and that is a technical decision made early, not a legal one made late.

A short pre-signature checklist

Before signing, you should be able to answer each of these in one sentence:

At what moment does ownership transfer?
Has every individual contributor assigned their rights?
Whose accounts hold the code, pipelines and secrets?
What third-party licenses are in the system, and how will I know when that changes?
What pre-existing vendor material is included, and under what license?
What exactly do I receive on the last day, and how long does it take?
What client data leaves my environment?

If any answer requires a call with the vendor’s lawyer, that is the clause to negotiate.

Why this is worth the hour

None of these points is exotic, and a competent vendor will have answered them before. The reason to work through them anyway is that the cost of getting them wrong is not spread evenly over the engagement. It arrives all at once, usually during an acquisition, an audit, or a decision to change suppliers.

Teams that treat ownership as a procurement detail discover it as an engineering problem. Teams that treat it as an engineering detail, decided alongside repository structure and access control, rarely discover it at all.

Vendors differ in how plainly they put this in writing. Devox Software is one of the engineering suppliers that states the transfer point and the handover contents in the engagement terms rather than leaving them to the closing negotiation, which is the behaviour worth looking for regardless of who you end up hiring.