Who Should Own the Source Code?

There is no single ownership model that fits every software project. A business commissioning a genuinely bespoke operational system may reasonably seek ownership of the custom code. A customer subscribing to a standard SaaS product would not normally own the provider's platform. Between those positions are licences, shared components and supplier tools.

The decision should protect the business's ability to operate, maintain and replace the system without demanding rights that add cost but little practical value.

Decide what the code represents

Before negotiating ownership, separate the code into meaningful categories:

When customer ownership is usually valuable

Ownership or equivalent broad rights are especially important when the application:

• implements distinctive business processes;
• is expected to remain in use beyond the original supplier relationship;
• contains a substantial custom investment;
• must be maintained by alternative suppliers;
• forms part of a product the business intends to sell or license;
• is critical enough that supplier failure would create serious disruption.

Even then, ownership should be defined precisely. “All code” may accidentally include tools the supplier developed before the project or components it cannot legally assign.

When a licence can be sufficient

A licence may provide the required protection if it is broad enough. Check whether it is:

• perpetual or linked to a continuing subscription;
• irrevocable except for clearly defined serious breach;
• valid for the intended users, territories and business entities;
• transferable during a sale, group reorganisation or supplier change;
• wide enough to permit maintenance, modification and hosting by another provider;
• supported by access to the material needed to exercise those rights.

A nominal right to modify code is not useful if the customer never receives the code or the build process.

Do not assume payment transfers copyright

In UK practice, the creator is generally the first copyright owner unless an exception or agreement applies; work created by an employee in the course of employment is treated differently. Commissioning and paying an external supplier does not by itself settle ownership. A transfer of copyright should be documented properly in writing and should identify what is being transferred.

Because the outcome depends on the contract and working relationships, obtain legal review for important projects rather than relying on an invoice, proposal or informal email.

Ownership is not the same as control

A customer can own custom code and still be unable to use it. Check that the business also has:

• access to the current source-code repository and history;
• the version running in production;
• dependency and licence information;
• build, deployment and environment instructions;
• cloud, domain, database and integration access;
• documentation and test assets;
• a route for obtaining business data in a usable format.

Protect both sides of the relationship

A fair arrangement can allow the supplier to retain background tools while giving the customer durable control of its system. Document the boundary instead of arguing over an undifferentiated phrase such as “all IP”.

For example, the supplier might retain a generic reporting component but grant the business a continuing licence to use and maintain the version embedded in its application. The customer might own the business-specific workflows, configuration and custom modules.

Acceptance checks

Build an ownership schedule

Create a one-page asset schedule listing custom code, supplier background components, third-party software, repositories and hosting accounts. Ask the supplier to mark who owns each asset, what licence applies and what will be delivered at handover. Resolve contradictions before signing or accepting the project.