Software development and intellectual property

As with any commercial arrangement, a written contract is important to document the intentions of the parties and manage commercial and legal risks and liabilities. The contract can change the default or implied position which would otherwise arise at law (for example on intellectual property ownership and associated liabilities).

A written contract does not just provide legal certainty, but can also assist with the commercial relationship; if both parties are clear on requirements and limitations up-front, this can avoid misunderstandings and disputes down the line.

It may seem obvious, but the contract should clearly describe what you are developing for the customer. This is central to the whole purpose of the agreement and to what the other terms relate, but is too often taken for granted. Parties have frequently had in-depth discussions on the product prior to considering the legal terms and therefore both supposedly know what they are talking about. This can lead to use of the magic term “Software” within the agreement, without providing a clear definition. If the customer then decides they aren’t happy with what they’ve been given, there is no decisive description of what was actually intended to easily resolve the dispute.

A good description sets the contractual obligation and is an opportunity to confirm that what you are planning to provide matches what the customer thinks they are getting.

Issues to consider:

• Is your solution completely bespoke, or a variation of a standard product of yours? Are you providing the software itself (with/without source code?) or a SaaS (software as a service) solution?
• Are you providing any related services after the initial development, e.g. support, bug-fixing, upgrades?
• What are the main aspects of functionality and key specifications? Consider why the customer is buying the product and what it will be used for – are you able to guarantee the aspects which are important to them? Are there specific acceptance criteria and procedures?
• How will the software be run, accessed and/or used? Will the customer be responsible for ensuring it has a compatible operating system and any additional required software/hardware? What other responsibilities will the customer have in relation to development or use of the product?
• If the software is core to the customer’s operations, will you make escrow or similar arrangements for access to the source code if needed?

Businesses tend to place a lot of focus on deciding who is to “own” a software product. It can be more practical first to consider the different elements comprising the software and what rights the respective parties will want or need to the finished product. The product may derive from a combination of inputs. For example, it could be developed from a customer’s designs, incorporating your original code together with third party components.

There are further complications in considering the different types of intellectual property which potentially subsist. Copyright may arise in relation to the expression of the coding and any artistic or literary output¹. Depending on the nature of the solution, database and design rights should also be considered. For highly innovative developments, we enter the complex and costly realm of patent protection for inventions implemented using software. This is a topic of hot debate with variations in the law and its application across different countries.

The resulting software product may therefore be a complex bundle of different intellectual property rights, owned by you, the customer and/or third parties. The rights to be granted to the customer may be restricted by known limitations to your rights (e.g. the terms of third party licences), or even unknown factors (e.g. third party patents). Intellectual property terms therefore need to be carefully drafted on a case-by-case basis; clearly highlighting the extent of the customer’s and your rights to use the resulting product and/or its different elements, and avoiding too “broad-brush” promises on ownership.

If the contract does not set out the intended rights, the legal assessment is made more complex. Licences are likely to be implied (which may be exclusive or non-exclusive) and, in some cases, an assignment of beneficial ownership may be inferred. It is therefore preferable to include specific provisions in the contract.

Issues to consider:

• What specific rights are you giving your customer? For example, will they be permitted to make their own modifications to the software or only to use the finished product? Is this consistent with the terms of your third party licences?
• What rights will you retain? Will you still be able to re-use essential elements and your “tools of the trade” for other customers?
• There may be different options for giving your customer exclusive rights, for example: assigning ownership, an exclusive licence to the finished product (or specific elements), protection of confidential information, non-compete obligations (although other legal issues arise with these).
• If you do intend to assign ownership of any rights, which rights (e.g. copyright), and are you sure you are able to assign them? Will such assignment restrict your intended activities going forward (see note above on rights you retain)?
• Have you included any open source elements in the software? The terms of open source licences can restrict the way in which you exploit any resulting works.
• Are you giving any warranties on the extent of the ownership or rights to the software? How much control you have over the risks? For example, agreeing to write your own code and not copy from elsewhere is narrower than promising your code won’t infringe any third party intellectual property (e.g. patents).

On a related point, if you are using sub-contractors to assist you with development, you will want to ensure that you are obtaining from them the rights and guarantees which you need in order to fulfil your obligations to the customer. In relation to intellectual property, this may mean requiring them to assign their rights to you, and providing similar warranties on originality etc.

To the extent the code is developed by your employees, it would be prudent to communicate the key requirements of the contract to them, and undertake checks to ensure these are met.

The contractual terms should of course address many more legal and commercial matters than those outlined above. Many provisions will link to the issues raised above; for example you should consider including limitations in your liability should you not meet the agreed requirements. You may also wish to link payment terms to provisions granting intellectual property rights to the customer; seeking to ensure that if you don’t get paid, the customer does not have the right to use your product.