Who owns the code? Intellectual property when you outsource software development

"We own the code" is one of the most common statements in due diligence and one of the least often verified. Ownership of outsourced software depends on what the contract says, on where the code physically lives, on what it depends on, and on whether anyone outside the vendor can understand it. This guide is written for the people who have to be sure: founders, investors, acquirers and the engineering leaders who inherit outsourced systems. It is not legal advice; it is a practical checklist of what to look for and what to ask, so that the conversation with your lawyer is short.

Ownership has four layers

When people say they own outsourced code, they usually mean only the first of four layers. All four matter.

1. Legal title. Who holds the intellectual property rights in the delivered work, by what mechanism, and from what moment.
2. Possession. Whether you hold the code as the work progresses, or only receive a copy at the end.
3. Independence. Whether the code runs and can be changed without the vendor: no proprietary platform in the critical path, no licence that expires with the engagement, no secret build step.
4. Understanding. Whether someone other than the vendor can maintain it: architecture, documentation, tests and readable history.

A contract can give you perfect legal title to code you do not possess, cannot run without the vendor and nobody can understand. Each layer needs its own check.

Layer one: legal title

Assignment, not just licence

The strongest position is an assignment of the intellectual property in the deliverables to you, in writing, effective on delivery or on payment. A licence, however broad, leaves title with the vendor and introduces conditions. Read the clause for the word "assigns" (or the equivalent in the governing law) rather than "grants a licence".

The default rule is not in your favour

In most jurisdictions, copyright in work created by an independent contractor stays with the contractor unless assigned in writing. The fact that you paid for it does not, by itself, transfer ownership. This is why the clause must be explicit, and why it must cover the vendor's own subcontractors and staff: the vendor can only assign what it owns, so it must have obtained the rights from the people who wrote the code.

Moral rights and background IP

Two further items for the lawyer: a waiver of moral rights where the governing law allows it, and a clear statement of the vendor's background IP, meaning pre-existing tools, libraries or methods the vendor uses across clients. Background IP normally stays with the vendor, with a licence to you for whatever is embedded in the deliverables. That is reasonable; what matters is that it is listed, so nothing essential turns out to be vendor property later.

Our own position is stated plainly in our terms: full intellectual property in the deliverables transfers to the client on full payment; the delivery system, tooling and methodology used to produce them remain with AIPOS OÜ; any pre-existing AIPOS OÜ component included in a deliverable is licensed to the client perpetually for use in that product.

Layer two: possession

Code in your hands at every milestone

The simplest protection is structural: the vendor hands over the product's code at agreed milestones, as a package you can store, run and audit, rather than only an archive at the end. This gives you the code at every stage, its complete git history, and an acceptance process that happens incrementally. If the relationship ends early, you hold everything delivered so far.

Ask when deliveries happen, what each package contains (code, tests, documentation, history), and what happens to the vendor's working copy after the engagement. In our model a test report and the code at that point arrive at every milestone, the complete code follows final payment, and all of it is written into the terms.

Access direction

A related security point that also affects ownership: a vendor does not need to connect to your systems to build your software. Development that happens entirely in the vendor's own environment, with existing code supplied by you as a package, leaves nothing of yours connected to anyone else and nothing to revoke afterwards. That is the model we use; the broader checklist is in security when AI agents build your software.

Layer three: independence

Third-party and open-source components

Every modern codebase depends on third-party components. You cannot own them, but you must be able to use them. Ask for a list of dependencies and their licences, and have someone check for licences that are incompatible with your intended use, particularly copyleft licences in software you plan to distribute. A good vendor produces this list as part of the documentation.

Vendor platforms in the critical path

The subtle form of lock-in is a vendor's proprietary framework, generator, runtime or service that the delivered code depends on. The code may be yours; the thing it needs to run is not. Ask directly: "Can the delivered system be built, tested, deployed and modified by a third party using only what is in the repository and publicly available tools?" If the answer has exceptions, each exception is a dependency on the vendor.

AI-generated code

Where a vendor uses AI models to produce code, ask how the output is treated. In our case the work runs through commercial AI model APIs under terms set out in the contract; the deliverable is reviewed, tested and committed as ordinary code, and the IP assignment covers it like any other deliverable. The point to confirm with any vendor is that nothing in the production method creates a claim on the output.

Layer four: understanding

Code you cannot maintain is only nominally yours. Three artefacts make outsourced code genuinely transferable:

• Architecture documentation: what the system is made of, why, and how the parts interact. Written by the person who designed it, not reconstructed afterwards.
• Tests: an automated suite that passes on the delivered code and that a new team can run to know whether their changes break anything.
• Readable history: commits that describe what changed and why, delivered with the code so that you hold the full history yourself.

Insist on these in the scope, not as an afterthought. Under our model the architecture and specification are designed in-house by AIPOS OÜ and agreed with you in writing before anything is built, every change must pass the test suite and an independent review before it is committed, and documentation is part of each delivery, which is the reason a client's own team can take over the codebase at any point.

Due diligence: how to verify the four layers quickly

For an investor or acquirer reviewing an outsourced codebase, the following checks cover most of the risk in an afternoon:

1. Read the IP clause: assignment, effective date, coverage of subcontractors, background IP schedule.
2. Confirm the company holds the complete code and its history itself, and that nothing essential sits only with the vendor.
3. Request the dependency and licence list; scan for incompatible licences and for vendor-proprietary components.
4. Ask a neutral engineer to build, test and run the system from the delivered package without vendor help.
5. Read the architecture documentation and judge whether a new team could extend the system from it.
6. Check that the test suite exists, runs and passes.

If any step fails, the company does not fully own its software in the practical sense, whatever the contract says, and the cost of fixing that belongs in the valuation.

Questions to ask a vendor before signing

• Do you assign the intellectual property in the deliverables to us, in writing, and from what moment?
• Have you obtained the rights from everyone who will write the code, including subcontractors?
• What background IP of yours will be in the deliverables, and under what licence?
• When do we receive the code: at every milestone, and in full when?
• Do you need any connection to our systems at all? (The strongest answer is none.)
• Can a third party build, test, deploy and modify the delivered system using only the delivered package and public tools?
• Will we receive architecture documentation, an automated test suite and a dependency list as part of the delivery?
• How is AI-generated code treated in the assignment?

A vendor with clean answers will give them in writing without hesitation. Ours are in the terms of service and on how it works; the investors page and the large software projects page describe the engagement, and the request form is the starting point.

Frequently asked questions