Who owns the code a dedicated team writes?
Not you, unless the contract says so in the right words. Paying an invoice does not transfer copyright in most jurisdictions when the author is a contractor rather than your employee, and a clause saying the client owns all deliverables is weaker than it sounds if the individual engineers never assigned their rights to the supplier in the first place. This is a paperwork problem with a cheap fix, and it is almost always discovered at the worst possible moment.
Why does ownership not pass automatically?
Because copyright generally vests in the person who wrote the code, and only moves by written assignment. Employment usually changes that: work created by an employee in the course of their job commonly belongs to the employer by default. Contractors and outsourced suppliers are not employees of yours, so the default runs the other way.
That produces a chain rather than a single relationship. The engineer must have assigned rights to their employer, the supplier, and the supplier must assign to you. A perfect clause in your contract with the supplier does nothing about the first link, and the first link is invisible to you unless you ask.
The question to ask, in writing, is whether every person who will touch the code has a present assignment of intellectual property to the supplier, including subcontractors and anyone engaged through a personal service company. Suppliers who run this properly answer immediately. The hesitation is the finding.
What does a usable assignment clause contain?
Present-tense assignment rather than an agreement to assign later, covering all work produced under the engagement, worldwide, for the full term of the rights. Language promising that the supplier will assign on request creates an obligation you may have to enforce, possibly against a company that no longer wants to help you.
It should cover more than source code. Designs, database schemas, infrastructure definitions, test suites, documentation, build scripts and any generated assets are all part of what you are buying, and clauses drafted around deliverables sometimes miss the things that never appeared on a deliverables list.
It should also address moral rights, which in several jurisdictions cannot be assigned but can be waived, and it should state when ownership transfers. Transfer on payment is common and reasonable; transfer on final acceptance can leave you owning nothing during a dispute, which is precisely when you need to own something.
| What it covers | Weak wording | What to ask for |
|---|---|---|
| Timing | Supplier shall assign on completion | Supplier hereby assigns, on creation, transferring on payment |
| Chain of title | Silent on individual engineers | Warranty that all personnel and subcontractors have assigned to the supplier |
| Scope of works | Deliverables only | Source, infrastructure code, schemas, tests, docs, designs, build scripts |
| Background IP | Unmentioned, or supplier retains all | Named list, plus a perpetual, irrevocable, transferable licence |
| Open source | Unmentioned | Warranty on licence compatibility and a dependency inventory |
| Moral rights | Unmentioned | Waived where waivable, consent given where not |
What is background IP and why does it matter?
Background IP is anything the supplier owned before your project or built for other clients and reuses in yours: internal libraries, project scaffolding, deployment tooling, component kits. It is common, it is often genuinely useful, and it is not something you can reasonably demand ownership of.
The problem is not its existence, it is silence about it. A system containing an unlisted supplier library works fine until you leave, at which point you either lose functionality, pay for a licence you did not know you needed, or rewrite a component under time pressure. None of those are expensive if you knew in advance.
The workable position is a named list of background IP plus a perpetual, irrevocable, worldwide licence to use it in the delivered system, transferable if you sell the business. Ask for the list before signature. A supplier who cannot produce one either has no reusable assets, which is a different concern, or has not thought about the question.
What about open source components?
Open source is in your system whether or not anyone discussed it, and the licences differ in ways that matter commercially. Permissive licences impose little beyond attribution. Copyleft licences can require you to publish source under the same terms if you distribute the software, and some network-facing variants extend that to software offered as a service.
This rarely causes problems for internal tools and can cause real ones for a product you licence to customers or plan to sell. The failure mode is discovering an incompatible dependency during due diligence, when the buyer's lawyers run a scan and you have two weeks to replace something that has been in the codebase for two years.
The practical control is an inventory rather than a rule. Ask the supplier to maintain a dependency list with licences, generate it automatically in the build, and state in the contract which licence categories are not acceptable without written approval. That converts an audit crisis into a routine check.
Who should hold the accounts and repositories?
You, from the first day, and this is separate from the ownership question. Owning the copyright in code you cannot access is a legal position rather than a practical one, and the gap between the two is where most real disputes actually happen.
That means the source control organisation, the cloud accounts, the domain registrar, the CI system and any third-party service subscriptions are registered to your company with your billing details, and the supplier's engineers are granted access as members. Convenience pushes the other way during setup, and reversing it later is administratively painful and occasionally contentious.
The same principle applies to credentials and secrets. If the only copy of a production key lives in the supplier's password manager, you have an operational dependency that no clause addresses. A quarterly check that a named person inside your company can reach every system without asking anyone is a reasonable habit.
What should you check before signing?
Five things, in an afternoon. Does the assignment clause use present tense and cover everything, not just deliverables? Does the supplier warrant that every individual and subcontractor has assigned rights to them? Is background IP listed, with a perpetual licence? Is there an open source warranty and a dependency inventory obligation? And are accounts and repositories in your name?
Then ask one question that is not in the contract: what happens if the supplier is acquired or becomes insolvent. Assignments already made survive both, which is exactly why present-tense assignment matters more than a promise to assign, and why account custody matters more than either.
None of this is a substitute for advice from a lawyer in the relevant jurisdiction, particularly where the supplier is in a different country and the contract nominates a governing law you have never dealt with. It is, however, the list that makes that conversation short.
Common questions
- Do I automatically own code I paid a development agency to write?
- Usually not. Copyright generally vests in the author and moves only by written assignment. Employment often changes that default in the employer's favour, but an outsourced supplier's engineers are not your employees, so the default runs the other way. Ownership requires a present-tense assignment clause in your contract, plus assurance that the individual engineers assigned their rights to the supplier in the first place.
- What should an IP assignment clause say?
- It should assign in the present tense rather than promise assignment later, cover all work produced including infrastructure code, schemas, tests, documentation and designs rather than only listed deliverables, apply worldwide for the full term of the rights, address moral rights by waiver or consent, and state that ownership transfers on payment rather than on final acceptance.
- What is background IP in a development contract?
- Anything the supplier owned before the engagement or built for other clients and reuses, such as internal libraries, project scaffolding or deployment tooling. Reuse is normal and often beneficial, and demanding ownership of it is unreasonable. The workable arrangement is a named list of what has been reused plus a perpetual, irrevocable, transferable licence to keep using it in the delivered system.
- How do open source licences affect ownership of my software?
- Open source components do not change ownership of your own code, but their licences impose conditions. Permissive licences mainly require attribution. Copyleft licences can require publishing source under the same terms when software is distributed, and some extend that to software offered over a network. Problems typically surface during due diligence, so maintain an automatically generated dependency inventory with licences from the start.
- Should the client or the supplier own the repositories and cloud accounts?
- The client, from day one, registered to the client's company with the client's billing details, with the supplier's engineers added as members. Owning copyright in code you cannot access is a legal position rather than a practical one, and account custody is where most real disputes actually occur. The same applies to production credentials, which should never exist only in a supplier's password manager.
