Software Development Agreements: IP and Commercial Guide | LegalDocuments.co.uk

What this document is

A software development agreement is a commercial contract between a client (the party commissioning the software) and a developer (the individual, agency or company building it). It governs how the work will be carried out, what the deliverables are, when they're due, how much they cost, and, crucially, who owns the resulting code and related materials once the project completes.

In England and Wales, these contracts sit at the intersection of contract law, copyright law (primarily the Copyright, Designs and Patents Act 1988), and, where relevant, patent and trade mark law. They can take various forms: fixed-scope build contracts, time-and-materials arrangements, agile statements of work sitting under a master services agreement, or hybrid models.

Regardless of structure, the intellectual property provisions are usually the most commercially significant part of the document, because they determine who holds the long-term value created by the project. Getting them right at the outset is far easier and cheaper than arguing about them afterwards.

How to use this document

1. Decide who should own the IP. Before drafting begins, both parties need to agree whether the client takes full ownership of the developed software or whether the developer licenses it. Ownership gives the client maximum control and resale rights; a licence is often cheaper but limits what the client can do. This commercial decision drives everything else in the IP section.
2. Address pre-existing and background IP. Most developers reuse libraries, frameworks and in-house tools they've built previously. The contract should distinguish between foreground IP (created specifically for this project) and background IP (brought to the project), and set out clear licence terms so the client can continue using the software without hitting ownership gaps later on.
3. Cover third-party and open-source components. Modern software almost always incorporates open-source libraries, each with its own licence terms (MIT, GPL, Apache and others behave very differently). The agreement should require the developer to disclose what's included, warrant that licences are compatible with the client's intended use, and indemnify against third-party infringement claims where appropriate.
4. Build in confidentiality and data protection. Development projects typically involve sharing commercially sensitive information, customer data and sometimes trade secrets. Confidentiality clauses should survive termination, and where personal data is processed, the agreement needs UK GDPR-compliant data processing terms setting out roles, security measures and subprocessor arrangements.
5. Plan for delivery, acceptance and what happens at the end. Even the best IP clause is worthless if the client never actually receives the source code. The contract should address acceptance testing, source code escrow or delivery, warranty periods, post-completion support, and exit provisions, including what happens to IP and data if the relationship ends early or the developer becomes insolvent.

Common questions