Under the Copyright, Designs and Patents Act 1988, the developer who writes the code owns the copyright unless they are your employee, and an assignment to you only takes effect in writing and signed. So the most important clause is a written assignment of IP to you, backed by the repository and hosting being in your name from day one. Then check for an attached specification, acceptance testing, written change control, a warranty, sensible liability limits, an Article 28 data processing agreement and a defined handover on exit.
Who owns the code: the default rule
Under section 11 of the Copyright, Designs and Patents Act 1988, the author of a work is the first owner of its copyright, and computer programs are protected as literary works. The main exception: where an employee writes code in the course of their employment, the employer owns it.
So code an agency, contractor or freelancer writes for you belongs to them unless the contract transfers it. Under section 90(3) an assignment of copyright only takes effect if it is in writing and signed by or on behalf of the assignor. An email saying "of course you own it" is not enough.
Without a written assignment, a court may find you have an implied licence to use the code for its intended purpose. That may not let you modify it, bring in another developer or sell the business with it. One clause avoids the argument.
| Who wrote it | Owner by default | What you need |
|---|---|---|
| Your employee, as part of their job | Your company | An employment contract that confirms it |
| A freelancer or contractor | The freelancer or their company | A written, signed assignment |
| An agency's employees | The agency | A written, signed assignment from the agency |
| An agency's subcontractors | The subcontractor | Assignments from the subcontractor to the agency, and from the agency to you |
The last row catches people out. If your agency uses freelancers, it needs assignments from them, or it has nothing to assign to you. Ask.
Assignment or licence: what each lets you do
Some suppliers offer a licence rather than ownership. That can be reasonable for a product they sell to many customers. For software built to your specification, expect an assignment.
| What you want to do | Assignment | Exclusive licence | Non-exclusive licence |
|---|---|---|---|
| Modify it, or have another developer modify it | Yes | Depends on the terms | Often no |
| Stop the supplier giving it to a competitor | Yes | Yes, within its scope | No |
| Transfer it with your company | Yes | Only if transferable | Usually no |
| Keep using it if the supplier goes bust | Yes | Usually | At risk |
| Show clean title in due diligence | Yes | Weaker | Weak |
A clean clause assigns all copyright and other IP in the deliverables "with full title guarantee", on creation, with a promise by the supplier to sign any further documents needed. Assignment on creation means the code is yours at every stage, including if the relationship breaks down halfway. The right to be identified as author does not apply to computer programs, but moral rights can apply to designs and documentation, so ask for a waiver there.
Our own rule, written into our contracts and set out on our how we work page: copyright in the code we write is assigned to the client, and the repository, hosting and third-party accounts are in the client's name from day one.
Background IP and open source licences
No supplier writes everything from scratch, and the contract should treat each kind of code differently.
- Foreground IP: the screens, logic and integrations written for you. Assigned to you.
- Background IP: the supplier's own reusable components, such as a login module. Stays with the supplier, licensed to you permanently and irrevocably, with the right to modify it and let other suppliers work on it.
- Third-party and open source: frameworks like React or .NET and libraries from npm or NuGet. Listed, and used in line with their licences.
Background IP is where hidden lock-in lives. If that licence ends when your support contract ends, your own system stops being yours. Check it survives termination and transfers with the software.
Open source licence families
| Family | Examples | What it means for you |
|---|---|---|
| Permissive | MIT, BSD, Apache 2.0 | Use, modify and keep your code private; keep the notices. |
| Weak copyleft | LGPL, MPL 2.0 | Changes to the library itself may need sharing; your own code usually does not. |
| Strong copyleft | GPL v2, GPL v3 | If you distribute software that includes it, you may have to release your source under the same licence. |
| Network copyleft | AGPL v3 | Can apply when users only reach the software over a network, as with a web app. |
Ask for a warranty that strong or network copyleft components need your written approval, and for a list of every component, version and licence at launch. That list also makes security patching far easier later.
Specification and acceptance testing
Most disputes are not about law. They are about whether the software does what was agreed. The contract should attach the specification as a schedule and define how each release is accepted:
- Acceptance criteria per feature, written so a tester can say yes or no.
- A test environment that mirrors live, where your team checks each release.
- A testing window, often 5 to 10 working days per release.
- Deemed acceptance if you report no defects within the window or start using the software live. Fair, if the window suits your team.
| Severity | Meaning | Blocks acceptance? |
|---|---|---|
| Critical | A core process cannot be used; data is lost or exposed | Yes |
| Major | A feature does not work as specified, with no reasonable workaround | Yes |
| Minor | Works, with a workaround or a cosmetic fault | No: fixed in the warranty period |
Acceptance works best in small pieces. We demo working software on a test link every two weeks, so a client accepts a sprint's worth of features at a time rather than a whole system in one sitting. A written specification underpins all of this, which is why larger builds start with a discovery and specification phase.
Change control as a process
Every project changes. The contract cannot stop that, but it can make every change visible, agreed and tested:
- Request in writing from a named person on your side, not a passing comment in a meeting.
- Impact assessment from the supplier within an agreed number of working days: the effort, the effect on the timetable, any features that move or drop out, and any new security or data protection risk.
- Written approval from you before work starts.
- An updated specification and acceptance criteria, so testing covers the change.
- A change log kept with the contract.
Watch for two things. Wording like "reasonable changes will be accommodated" sounds generous and means nobody knows what was agreed. And the line between a defect (the software not meeting the specification) and a change (the specification moving): the contract should say how disagreements about which is which get settled.
On sprint-based projects the backlog is the main change mechanism. The contract should say who on your side can reprioritise it and how the specification stays in step with what is being built.
Warranties and indemnities
In a business-to-business contract for services, the law already implies that the supplier will act with reasonable care and skill (Supply of Goods and Services Act 1982, section 13). Look for these specific warranties too:
- The software will conform to the specification for a warranty period after acceptance, with defects fixed by the supplier. Ours is 30 days after launch.
- The work will be done by suitably skilled people, in line with good industry practice.
- The deliverables will not knowingly contain viruses, time locks or disabling code.
- The supplier has the right to assign the IP, including from any subcontractors.
An IP indemnity is the supplier's promise to cover your losses if a third party claims the software infringes its rights. It is common for the foreground code, usually excluding infringement caused by your own materials or changes.
Expect other implied warranties, such as fitness for an unwritten purpose, to be excluded. That is normal, and another reason the specification should say what the software is for.
Limitation of liability
Almost every software contract limits the supplier's liability. A limit is reasonable; the questions are where it sits and what falls outside it. Good contracts define the cap by reference to the contract itself rather than an arbitrary figure, and apply it to both parties.
| Item | Common position |
|---|---|
| General cap | An aggregate cap defined by reference to the contract |
| Indirect and consequential loss | Usually excluded; argue for loss or corruption of data to count as direct loss |
| Death or personal injury caused by negligence | Cannot be excluded (Unfair Contract Terms Act 1977, section 2(1)) |
| Fraud | Cannot be excluded |
| IP indemnity | Often uncapped or under a separate, higher cap |
| Data protection breaches | Often a separate, higher cap, heavily negotiated |
| Confidentiality | Often uncapped |
Check whether the cap is per claim or in total, and whether it resets each year on a long support agreement.
Where one side's standard terms are used, exclusions and caps must be reasonable under the Unfair Contract Terms Act 1977. A cap that is tiny next to the size of the project may fail that test, but you do not want a court to be where you find out. Negotiate before signing.
Service levels and support after launch
The build contract ends at launch; the software does not. Support usually sits in a separate schedule, and it deserves the same care. A useful one defines:
- Severity levels, matching the acceptance definitions.
- Response and fix targets for each level, kept separate. A reply within the hour is not a fix within the hour.
- Hours of cover: UK business hours, extended hours or round the clock.
- Availability target for hosted systems, how it is measured and which maintenance windows are excluded.
- Routine work: security patching, dependency updates, backups and restore tests, monitoring.
- Notice to end, with a handover obligation.
Multi-year minimum terms deserve a hard look. Our support and maintenance plans run with 30 days notice, and we reply to every request within one working day.
Data protection: the Article 28 agreement
If the supplier handles personal data on your behalf, such as customer records in the database or data copied for migration testing, it is your processor, and Article 28 of the UK GDPR requires a written contract with specific terms. It can be a schedule to the main contract or a separate data processing agreement (DPA). It must describe the processing and require the supplier to:
- Process the data only on your documented instructions.
- Bind its staff to confidentiality.
- Take appropriate security measures (Article 32).
- Use sub-processors only with your authorisation, on the same terms.
- Help you with data subject requests, breach notification and impact assessments.
- Delete or return the data at the end of the contract.
- Allow audits and give you what you need to show compliance.
Add the hosting region (UK or EU), a list of sub-processors, how quickly the supplier will report a breach, and the transfer mechanism if any data leaves the UK. The ICO's guidance on controller and processor contracts is worth reading. Our security and UK GDPR page sets out how we handle this.
Confidentiality and subcontracting
A supplier building your system sees your processes, customers and plans. The confidentiality clause should cover all of it:
- A wide definition, with the usual exceptions (already public, independently developed, required by law).
- Use only for the project, shared only with people bound by the same terms.
- Survival after the contract ends, indefinitely for trade secrets and personal data.
- Return or deletion on exit, confirmed in writing.
Subcontracting is where confidentiality, IP and data protection meet. The contract should allow it only with your prior written consent, keep the supplier responsible for its subcontractors as if their work were its own, and require every subcontractor to assign IP up the chain. A subcontractor handling personal data is a sub-processor under your DPA, and an offshore team is a data transfer that needs safeguards.
Ask a supplier plainly who will write your code, where they are based and who employs them. A good one answers in a sentence.
Termination, handover and source code escrow
Plan the end when you sign, because that is when you have the most bargaining power:
- Termination for convenience: your right to end on notice, keeping everything produced to date.
- Termination for breach: after written notice and a period to put things right, often 30 days.
- Termination for insolvency if the supplier enters administration or liquidation.
- Survival: the IP assignment, background IP licence, confidentiality and data protection terms outlast the contract.
Spell out the handover pack: the repository and its full history, setup and deployment instructions, architecture notes, a list of environments and third-party services, every admin credential, the open source list and a current database backup, plus reasonable help to a new supplier. If the repository and accounts are already in your name, most of this is automatic.
Source code escrow is a three-way agreement where the supplier lodges the code with an independent agent, released to you on events such as insolvency. It matters for software you license but do not own. When the code is assigned to you and pushed to your own repository daily, it adds little. Our guide to what happens if your software developer goes bust covers escrow and the steps to take from day one.
Clause checklist
| Clause | What good looks like | Red flag |
|---|---|---|
| IP ownership | Assigned to you on creation, in writing | A licence only, or assignment only at the end |
| Background IP | Perpetual, irrevocable, transferable licence | Ends with the support contract |
| Acceptance | Criteria, testing window, defect categories | Acceptance on delivery |
| Change control | Written request, impact assessment, approval | "Reasonable changes will be accommodated" |
| Liability | Mutual cap by reference to the contract, sensible carve-outs | A token cap |
| Data protection | Article 28 terms, hosting region, sub-processors | "Both parties will comply with GDPR" |
| Accounts and hosting | In your name from day one | In the supplier's name |
| Exit | Termination for convenience, defined handover pack | Nothing handed over until the end |
This guide describes the law of England and Wales from the supplier's side of the table. It is not legal advice; have a solicitor who works on technology contracts review anything that matters to your business.
The standard we hold ourselves to, and what we think marks out the UK's leading software development companies, is a contract your solicitor can read in an afternoon with nothing hidden in it. If a contract has already gone wrong, or a supplier will not hand over code, our software project rescue service starts with an audit of what you own and can access. To choose a supplier well, see how to choose a software development company, or talk to us.
Questions
Who owns the code if there is no written contract?
Under UK law, the person or company that wrote it, not the client who asked for it. Copyright belongs to the author unless the author is an employee, and an assignment must be in writing and signed. Without one you may have an implied licence to use the code, but possibly not to change it or move it to another developer.
Do I own the source code my developer wrote for me?
Not automatically. Having work done for you does not transfer copyright in the UK. You own the code only if the contract assigns the copyright to you in writing, signed by the supplier, or if your own employees wrote it as part of their jobs. Check for an assignment clause, not just a licence, and check the repository is in your account.
Can a developer reuse code they wrote for me?
If you own the copyright, they cannot reuse your specific code without permission, though they can reuse their general skills, ideas and their own background components. If they kept the copyright and gave you a licence, they may be able to reuse it for other customers, including competitors. Read the IP and background IP clauses together.
What is a reasonable liability cap in a software contract?
A mutual cap set by reference to the contract itself, with indirect loss excluded, is common. IP indemnities, confidentiality and data protection often sit outside the general cap or under a separate, higher one. Liability for death or personal injury caused by negligence, and for fraud, cannot be excluded at all. A solicitor can advise what is reasonable for your project.
Do I need a data processing agreement with my software developer?
Yes, if they will handle personal data on your behalf, for example in a live database, a data migration or support work. Article 28 of the UK GDPR requires a written contract covering instructions, security, sub-processors, deletion and audits. It can be a schedule to the development contract, and it should name the hosting region.
What should happen to the code if the contract ends early?
You should receive everything produced so far: the code and its history, documentation, credentials and access to every account. If copyright is assigned on creation and the repository is in your account from day one, this is automatic. Avoid contracts where nothing is handed over until the project is finished, because a dispute can then leave you with nothing.