Software And Intellectual Property: How To Draft Contracts That Suit Your Business

In software contracts, the intellectual property (IP) clause often determines whether a deal thrives or becomes a source of disputes. At its core, it answers two simple but crucial questions: what is being created or supplied, and what rights does the customer actually receive?

Misalignment on these points is where most conflicts arise. Is the deal a licence to an existing product, a bespoke module, or a full development? Does the customer simply use the software, or do they expect ownership and freedom to exploit it? The answers shape how IP clauses should be drafted.

A practical way to think about IP is to divide it into four categories. First, background IP: what each party owns before the contract. Second, third-party IP, including open-source or licensed components. Third, developed IP, created under the contract. And fourth, data, including outputs generated during use. Once these categories are clear, allocating rights becomes far more straightforward.

Licensing: the supplier owns, the customer uses

In a standard licence, whether SaaS or on-prem, the supplier keeps ownership while granting the customer the right to use the software. Problems arise when licence terms do not reflect reality. For example, a licence may allow only internal use, but the customer uses the software to provide services to clients. Without proper wording, this could technically be a breach.

Licences should align with business needs: territory, permitted users, and purpose of use. If the customer will use the software as part of services it delivers to its clients, say so. If group companies or contractors will need access, or if the customer needs to use the software worldwide, say so.

Third-party IP deserves more attention than it usually gets. Most modern software includes external libraries or open-source components with licence obligations. Contracts should ensure the supplier has the right to grant the licence and that the customer can comply with third-party requirements.

Development for customers – supplier retains ownership

The next common scenario is a development project where the supplier builds new features or code for a particular customer but wants to keep ownership so it can reuse that work for others. This model allows the supplier to maintain a coherent product roadmap and keep pricing sustainable, while still delivering tailored solutions.

The challenge is managing expectations. Customers may feel they own what they pay for. A practical solution is to offer generous usage rights: for example, a perpetual licence to the developed features, no additional fees for ongoing use, and perhaps temporary exclusivity in a defined sector or region. At the same time, the contract should make clear that ownership of the IP remains with the supplier.

Equally important is separating the supplier's IP from the customer's materials. The supplier's background IP and any developed components must remain clearly identified, while customer-specific inputs, proprietary business logic, or confidential data should remain the customer's property. Defining these boundaries upfront prevents disputes over which parts of the code or solution the supplier may reuse for other customers.

Development for customers – customer owns the IP

In this model, the customer commissions bespoke software and, under the contract, acquires full ownership of all IP created. This approach is common when the software is strategically important or intended for commercialisation.

Simply paying for work does not automatically transfer IP. The contract must include a clear assignment of the intellectual property rights in the work created by the supplier. It should also ensure that the supplier has obtained all necessary rights from its subcontractors or contributors so that the assignment to the customer is effective. The customer may also require the supplier to complete any formalities necessary to effect the IP transfer.

The contract should also address dependencies. Developed software often incorporates pre-existing supplier components, libraries, or open-source code, which are not transferred to the customer and remain under the ownership or licence of the original holder. The contract should give the customer the rights necessary to use, operate, maintain, and update the delivered software, so that the software can be fully used for its intended purpose without infringing the supplier's or third-party rights.

Joint development and co-ownership problems

Joint development is where IP clauses become genuinely high-risk. Joint ownership sounds balanced on paper – both parties contribute, both parties own – but in practice it often leads to stalemate. Each side may be unsure whether it can move ahead with a product launch, raise investment, or pivot the product without first getting the other party's consent. That uncertainty alone can be enough to kill momentum.

A more workable structure often to avoid true joint ownership and instead agree a split ownership backed up with cross-licences. One common pattern is that each party owns the developments that build on its own existing products or technology, while anything created together is allocated to one party, with a broad licence back to the other. Who takes ownership should follow the commercial reality: who will take the product to market, who will invest in further development, and who can realistically enforce the IP rights if there is infringement.

Where joint ownership really cannot be avoided, the contract has to do more than simply label the IP as jointly owned. It should set out, in plain terms, what each party may do with the jointly owned IP. Can either party license it to third parties without consent, or do they need agreement from the other? Is there any obligation to share revenues or profits, and on what basis? Who leads on enforcement, and how are costs and any damages shared?

A few drafting habits that pay off

When it comes to software IP, small drafting habits can prevent big problems. The first is clarity and consistency. Define key concepts—such as Background IP, Foreground IP, and Deliverables—once and use them consistently throughout the contract, including any statements of work, change orders, or schedules. Avoid introducing new labels for the same concept mid-document. Clear and consistent drafting ensures everyone involved—legal teams, product managers, and client representatives—understands what is owned, licensed, or restricted.

The second is understanding the deal in context. IP clauses should reflect the commercial reality and anticipate how the relationship may evolve. Think about scenarios such as early termination, replacement of the solution, or scope changes. Ask: can the customer use the software as intended? Are there any restrictions on users, territories, or purposes that could block business operations? Are there any restrictions that would prevent the supplier from developing similar solutions for other clients? Who may commercialise or license the deliverables, and are any revenue-sharing or territorial restrictions in place? Are third-party or open-source components properly accounted for, with the necessary rights granted to the customer? Drafting with these questions in mind avoids surprises, reduces operational risk, and ensures the IP provisions support the business rather than create friction later.

Take 20 minutes to speak with our technology lawyers and explore how your software contract can be structured to align with your business goals. With extensive experience in technology transactions across multiple sectors, and working with both smaller businesses and multinational clients, we can help you think through practical approaches to IP and related clauses.

The content of this article is intended to provide a general guide to the subject matter. Specialist advice should be sought about your specific circumstances.