What do you mean the software isn’t mine? I paid for it!

What IP is there in software?

Intellectual property rights are broadly defined as “creations of the mind”, with trade marks, patents, copyright and designs being the most common form of IP right.

When it comes to software, the most likely IP right that will attach from the outset is copyright. For copyright to attach to a work, the work in question must be:

·       original (the author’s “own intellectual creation”);

·       fixed (recorded in a material form); and

·       fall within a list of specified works.

Software (more specifically, its source and object code) is treated under copyright laws as a literary work, which can be anything written, spoken or sung.  Copyright subsists on fixation and typically lasts for the author’s life plus 70 years.

It is also possible for the inventive step of software (or other technology that relies on it) to be registered as a patent, if it is novel (new), inventive (broadly summarised as not involving technology that already exists) and is capable of industrial application. Generally, software inventions are hard, but not impossible, to patent. It is always worth considering the patentability of any invention before the prototype stage (and before the technology in question has been publicly disclosed!).

Finally, the inner workings of a piece of software (source code, algorithms, implementation techniques) will almost always be privy between the customer and developer and therefore not in the public domain.  It is possible that the software may benefit from protection under confidentiality and trade secret laws.

In this article we will broadly refer to IP as meaning copyright and any other IP rights to the extent that they subsist (it is ultimately a very fact-specific question).

Competing Intentions of Customers and Developers

On the one hand, the customer will have paid for development work to be carried out and will expect a software product that they can freely exploit without restriction.  On the other hand, many developers prefer a licensing model, where the customer is granted a (most commonly, non-exclusive) licence to use the software during a defined licence term, likely in return for recurring licensing, hosting and/or support fees (this is very common with SaaS and PaaS offerings).  Occasionally, developers will grant perpetual licences and provide the source code on payment, however, this doesn’t necessarily mean that ownership of the copyright in the source code will pass to the customer.

Who owns the IP?

This then leaves the burning question, who owns the IP in the software between the customer and the developer?

The default position under the Copyright, Designs and Patents Act 1988 (CDPA) is that the first owner of copyright in literary works is their author (the person that created them). If the author is an employee, the first owner will be their employer (unless their employment contract says otherwise).

In order for copyright to be assigned (transferred) from the developer to the customer, the CDPA requires an agreement to be signed and in writing on behalf of the developer. This also applies in relation to trade marks, patents and design rights (if there are any). Copyright in future works can also be assigned with the correct drafting.

Customers should beware of supplier terms and conditions, which are often prepared on the standard basis that ownership of IP will ultimately rest with the supplier.

Commissioned Works – the grey zone

Knowing what we now know, the default position is that the developer will own the IP, unless there is an agreement in writing to the contrary with the customer.  However, could a customer have an equitable claim over the IP, due to an informal agreement they had with the developer, or taking into account the circumstances surrounding the development?

This is the “grey zone”, an increasingly common scenario where there is no formal agreement between the parties as to who will own the IP.  Customers often only realise they are in the grey zone when it comes to seeking investment or an exit from their business (where they believe they have a tangible product to sell with it).

If the circumstances of the matter show that the customer was intended to be the owner of the IP, then an equitable right over the IP might arise.  A clear example of this would be where the developer makes a clear representation that the customer would own the IP once created.

Simply paying for the software won’t in itself lead to the conclusion that ownership of the IP to the software was intended to be assigned.  What a court would need to consider is the intention of the parties at the time the contract between them was formed (which raises a host of contractual formation questions).  In short, commissioned works are a grey zone for a reason, because the answer to the question of “Who owns the IP?” is never straightforward to find (and often comes at significant time and financial expense).

Practical Takeaways

No business wants to end up in the grey zone.  Reaching an agreed position on the following fundamental questions at the pre-contract stage will help avoid lengthy negotiations and minimise the prospect of a dispute arising in the future:

1.      Once paid for, will the IP rights in the software be assigned or licensed to the customer?

2.      If there is a combination of bespoke and non-bespoke software, will the IP rights in the bespoke software be assigned to the customer?

3.      If the developer can only grant a licence, will that licence be exclusive in the customer’s industry or a particular channel or territory?

4.      If licensed, what will the duration of the licence be and what is the mechanism for renewal?

5.      If the developer agrees to assign the IP rights to the customer, should increased consideration be paid (or ongoing royalty payments)?

6.      What about developer insolvency?  Particularly relevant with licensed SaaS / PaaS products, should the developer place the source code for the software into escrow, to be released on an insolvency event?

In a bespoke software development relationship, there is very rarely a “one size fits all” approach that will satisfy both parties, therefore it is important to ensure that the fundamentals of what is agreed commercially is reflected in a written agreement.

If you have any queries on any of the above, please do not hesitate to get in touch with our Intellectual Property Team.