Globally, apps are booming.

Increasingly, businesses and retailers are being attracted to the benefits and opportunities of having their own app. In 2020, 36% of customers globally used in-app messaging to contact a business so, while some business leaders may simply be experiencing a ‘fear of missing out’, apps are an important platform to consider.

However, there are important points to consider before launching an app, and one of the most important is around ownership. It all centres on code.

If you write code, you own it. Even if you write the programme for a paying customer. Like novels, songs and works of art, source code and object code enjoy copyright protection. That means software and app developers de facto gain copyright of their work.

The UK does not have a register for copyright, so you don’t need to use the © symbol in the UK to invoke copyright in your code; it’s simply an indication of an author’s intention to protect their work. But how, then, does copyright for code work when a client naturally expects they will own what they pay for?

Expectation vs Reality

Customers who ask for programmes and websites to be built make the mistake of thinking that just because they pay for the work to be done, it means they will own all of it – usually including the source code. But the law says otherwise.

The starting point for all copyright protection is that the person who created it is the legal owner of it. When it is created by an employee in the course of their employment, it’s owned by their employer. It doesn’t matter how much the customer pays – even if it’s over the industry norms – the price paid does not determine whether the customer owns the app that’s created.

When a customer pays for something to be made, the law implies a licence for the customer to use it. But they don’t own it. What they can do with the code is limited, and crucially, they can’t license it or sell it to their own customers.

Hiring Developers

The traditional approach, adopted by most businesses and lawyers, is to agree that whoever pays for the development of the code owns it. The argument is over what is, and is not, developed for a particular job.

Most developers have a library of code they use as a basis for each project. They want to ensure they can keep using this code for future projects and don’t relinquish ownership of it when selling a project.

To manage this, contracts usually distinguish between the code that existed before the project and what is bespoke for the customer. It is known as Background and Foreground Intellectual Property respectively.

Recommended

• DIGIT Movers and Shakers | January 2022
• Inform low-income families of ‘social tariffs’ to fight living costs, says Ofcom
• Edinburgh hospitality tech firm finds success despite sector downturn

Contracts can then stipulate that the Background IP remains the property of the developer and the ownership of the Foreground IP is transferred to the customer once full payment has been made. This approach satisfies both parties, however if a contract is silent on who owns the code, the default applies and the developer owns it all.

Protecting the Finished Article

Even if a developer isn’t transferring ownership of Foreground IP to a customer, it is still wise to consider entering into a contract.

A company with the right to use an app (even if it’s just a licence) is also allowed to decompile* the software, make backup copies and study the functioning of the programme. These rights cannot be removed by a contract.

However, the rights imposed by law are limited. In the case of decompilation, it can only be to facilitate inter-operability between programmes. While a contract can’t protect your code from decompilation entirely, it can regulate how it’s done.

A contract can prohibit a customer from making amendments to the app once it has been decompiled. This is particularly important when the developer intends to provide maintenance services.

Without a contract expressly prohibiting amendments, a customer is free to correct errors as they wish and to whatever skill level. The risk is, if they sub-licence to other people, the developer’s reputation is still on the line – despite edits.

All too often, people don’t know where they stand on protecting their work or gaining ownership of purchased subject codes and apps. It’s easy to get lost amongst the legal jargon and negotiations can indeed get fraught. But asking questions earlier rather than later can make all the difference. After all, it is your expertise and reputation at stake.

*Compilation is the act of transforming a high-level language, into a low-level language such as machine code or bytecode. Decompilation is the reverse. It is the act of transforming a low-level language into a high-level language.