Main issues in software licensing and maintenance contracts, Practical Law UK Practice...

Main issues in software licensing and maintenance

contracts
by Practical Law IP&IT, with thanks to Chris Holde
*** Start Section
...r, Rebecca Andersen and Katy Gibson, Bristows

Practice note: overview | Maintained | England, Wales

This note contains a brief summary of the nature of computer software and its treatment under UK law, and then
discusses in detail the main issues to be considered by suppliers and customers when negotiating and drafting
software licences and software maintenance contracts. The focus of this note is on business-to-business transactions
and the licensing of on-premise software.

Scope of this note

This note contains a brief summary of the nature of computer software and its treatment under the law of England
and Wales, and then discusses in detail the main issues to be considered by suppliers and customers when
negotiating and drafting software licences and software maintenance and support agreements.

The focus of this note is on business-to-business transactions. While much of the content may be relevant to
business-to-consumer transactions, these transactions are subject to more stringent rules around such matters as
exclusion and limitation of liability. For more information, see Practice notes, Consumer contracts: is it a consumer
contract? and Consumer contracts: which rules apply?).

This note also focuses on traditional, on-premise software licensing (where a licence is granted by the software
supplier to the customer to install and run the substantial components of the software on servers and computers
under the customer's control, in circumstances where the customer will have physical possession and control over
the software's object code). This is opposed to software-as-a-service, which is commonly understood to mean
the major components of the software reside on the supplier's servers (rather than the user's computer) and are
accessed by the user through a generic piece of software such as a web browser (see Software as a service). For
more information on the legal issues likely to arise in practice when dealing with software as a service, see Practice
note, Cloud computing: overview. See also Sector note, Task guide: cloud service provision.

What is software?
From the corporate user's point of view, software refers to the computer programs necessary to produce, in
conjunction with the hardware and the user's business data, the results the user wants from a computer system.

A confusing variety of terms surrounds the concept of software. Most lawyers believe they have a good idea of what
is meant by the term "software" but have more difficulty with terms such as "firmware" and "middleware". The
majority of these terms refer to software in some form or other, either by reference to the manner of its "residence"
in the machine (so that firmware is normally software that resides in a less transient part of the computer's memory
than a hard disk or DVD) or its function in relation to other software (so that middleware is normally software
that mediates between other pieces of software and allows them to perform some function together). In addition,

© 2021 Thomson Reuters. All rights reserved. 1

Main issues in software licensing and maintenance contracts, Practical Law UK Practice...

previously clear boundaries between different types of software are progressively being eroded, for example, as
operating systems are sold with integrated applications (such as web browsers and entry-level word-processors),
and groups of mini-applications perform the functions previously performed by large stand-alone applications.

For the purposes of this note, the terminology requires clarification. At the risk of oversimplification in what is a
constantly changing field, software may be seen as divided into three basic layers:

• The first layer of software is the operating system. This runs the basic functions of a computer and enables
it to support the other layers of software. Hardware is useless without software. A computer can be
switched on without software, but the only visible response will be to illuminate the "on" light, if one is
fitted.

• There is normally a second layer of software which may be called utility software. Utility software adds
functions to the operating system but most of those functions are invisible to the user and are the sole
concern of the professional IT manager. Examples of utility software are network management software
(which monitors the "health" of a network and can re-route traffic on the network if one of the nodes is
defective) and virus protection software (which monitors a computer or network for the presence of
computer viruses).

• Finally, there is the layer of applications. These are the software that visibly perform a business function,
such as word-processing, accounting, producing management reports, sending email or browsing the web.
So far as the user is concerned, the applications are the system's raison d'etre. The hardware, the operating
system and the utility software only exist to enable the user to enjoy the functionality provided by the
applications.

How is software purchased?

This will depend on the type of software:

• Operating systems. These are often bundled with hardware. When they are not, they are normally
sold on a package basis, that is, in standard form rather than customised to meet the customer's specific
requirements. In either case, it would be exceptional for them to be sold other than on the supplier's
standard terms, which means that their use is licensed to the customer and subsequent use must be in
accordance with the terms of the licence.

• Utility programs. These, by their nature, will normally be intended to be used widely and so will be sold in
a similar manner to operating systems. Again, their use will be licensed to the customer. However, bespoke
(that is, written specifically for the customer) utility programs exist and they are dealt with in a similar
manner to bespoke applications.

• Applications. The vast majority of such programs are sold off-the-shelf as packages on the supplier's
standard terms, the products of Microsoft being the most obvious example. However, higher value
applications are occasionally bespoke and, increasingly frequently, are a mixture of package and bespoke,
with a basic core of package software being adapted to the user's specific needs. Package software is
frequently referred to as commercial off-the-shelf software (COTS software).

One of the most successful areas of the software market since the mid-1990s has been the large integrated
system composed of various pre-existing programs or modules, or building blocks, which are combined together
in the way most suited to the customer's business structure and then fine-tuned to suit the customer's particular

© 2021 Thomson Reuters. All rights reserved. 2

Main issues in software licensing and maintenance contracts, Practical Law UK Practice...

requirements. The analysis required for the design and implementation of this software (sometimes called
"enterprise software") often drives or accompanies changes in the customer's business structure, so that the
structure to which the software is finally adapted is different from the one which existed before the software was
first considered. The products of the German company, SAP AG (particularly SAP ERP (formerly SAP R/3)), are
among the best-known examples of this modular approach.

Software as a service
The remainder of this note deals with software licences, and licences of software applications, in particular.
Licensing is still the main method by which most businesses and individuals obtain the right to use applications.
However, there is an increasing tendency for the use of applications and other software to be purchased "as a
service".

As with most terms relating to IT, "software as a service" is used in different ways by different vendors.

The most common usage is to describe an agreement under which a customer buys the right to use the software
for a certain period under a subscription agreement. Such an arrangement has obvious points of similarity with
software licensing (which also grants the use of software for an agreed period), but in "software as a service" the
major components of the software often reside on the supplier's servers (rather than the customer's computer)
and are accessed by the user through a generic piece of software such as a web browser so that, when the
subscription comes to an end, the user's ability to use the software (practically as well as legally) also comes to
an end.

Another less common practice is to use "software as a service" to describe a service agreement which is fulfilled
by the use of particular software. Such an agreement would probably be better described as "providing services
using a particular piece of software" than "software as a service", as it often does not require any use of software
by the customer (because it is the supplier rather than the customer who employs the software to perform the
services) and the terms are similar to the terms found in a services agreement.

While the two types of agreement sound very different, they have some significant similarities: in neither case does
the customer have to invest in special hardware or commit to a licensing term that is longer than their intended
period of use (sometimes licences for on-premise use are only offered on a perpetual basis to protect against future
misuse), and there are usually gains in flexibility, time savings and reductions in cost for the customer.

This note primarily focuses on the traditional, on-premise licensing of software. For more information on the legal
issues likely to arise in practice when dealing with software as a service, see Practice note, Cloud computing:
overview.

Legal protection of software

For a review of the legal protection of software, including the application of the law of copyright to software
and a discussion of the other intellectual property rights affecting software, see Practice note, Legal protection
of software.

Software licences
Software purchased as a package on its own will normally be purchased on the supplier's standard terms, with
or without amendment depending on the respective bargaining strengths of the parties.

© 2021 Thomson Reuters. All rights reserved. 3

Main issues in software licensing and maintenance contracts, Practical Law UK Practice...

What is essentially package software may sometimes be "customised" (that is, adapted) to a greater or lesser
extent in order to meet the customer's specific requirements. Again, the software will generally be licensed on the
supplier's standard terms but, because the software has been customised, and the supplier will therefore be
charging more for it, those terms are more likely to be the subject of negotiation. For a discussion of the contractual
issues that parties need to address where the supplier undertakes to customise software to meet the customer's
requirements, see Practice note, Main issues in systems integration contracts.

The key issues arising in relation to licences of essentially standardised or package, non-bespoke, software are
discussed below.

For specimen licences, see Standard document, Software licence agreement (pro-supplier) and its
accompanying drafting notes and Standard document, Software licence agreement (pro-customer) and its
accompanying drafting notes.

Consequences for licensors and licensees in the light of UsedSoft decision

The case of UsedSoft GmbH v Oracle International Corp (Case C-128/11) EU:C:2012:407 has had a significant
impact on the interpretation of drafting licences in terms of the exhaustion of rights. For more information, see
Practice note, Assignment rights in software licences after UsedSoft. See also Continuing relevance of EU case
law.

Permitted use

Suppliers will generally only be prepared to grant licences of package software on non-exclusive terms so that
they can grant licences of the software to multiple customers.

A supplier will also often restrict the use of the software in certain ways, for example, by reference to:

• The identity of the customer or a group of users associated with the customer.

• The identity and number of machines or operating system environments on which the software is loaded.

• The geographical location of the machines on which the software is loaded.

• The purpose for which the software is used.

• The number of concurrent users of the software.

• The volume of processing handled by the software.

The type of restrictions will depend on the nature of the software (the supplier may have developed the software,
for example, for use in conjunction with a particular operating system or other software) and the manner in
which the supplier typically licenses its software. The customer should ensure that any applicable restrictions
are acceptable, taking into account its current and future business requirements, since use of the software in
breach of such restrictions will constitute a breach of the licence and may entitle the supplier to damages, an
injunction preventing use or termination (or all three). It is therefore important that the customer knows exactly
what rights they are buying. Technological changes can have a serious impact on licensing. For example, if software
is licensed for use on a single server, one must consider the consequence if that server is included within a virtualised
environment in which it can be made to function as a number of independent mini-computers or, if software is

© 2021 Thomson Reuters. All rights reserved. 4

Main issues in software licensing and maintenance contracts, Practical Law UK Practice...

licensed for use on a specified server or at a specified location, one must consider the consequence of replacing or
moving that server. Therefore, customers should be careful to ensure that their usage rights are future-proofed so
far as possible.

The supplier will often wish to ensure that use of the software is restricted to the company with which it is
contracting. Typically, this is achieved by prohibiting sub-licensing and assignment under the licence. For the
customer, this can cause problems in the case of groups of companies. Software that is licensed in the name of one
group company may well be accessed by another group company, whether as intended, as a result of inadvertence or
as a consequence of an organisational change. Such access may constitute a breach of the licence unless the licence
permits use among group companies. This is a particular problem with utility software where what constitutes
"use" or "access" may be unclear. For example, see SAP UK Ltd v Diageo Great Britain Ltd [2017] EWHC 189 (TCC).
If there is a virus protection program on a network, is it used or accessed by everyone whose PC is connected to
the network? Consequently, the customer should ensure, where necessary, that the licence extends to all other
companies in its group that are likely to use the software.

Similarly, if outsourcing is contemplated by the customer or the customer intends to engage other external service
providers to provide services to the customer (for example configuration or support services), the software may
need to be used by, or assigned to, the external service provider. If such use or assignment is not permitted by
the terms of the licence, then the supplier may charge a significant fee (occasionally in six or seven figures) for
agreeing a change of or additional use. Some of the earlier outsourcing transactions were severely disrupted by
demands for additional software fees. However, with the increase in the outsourcing market, the amount and
incidence of fees is more predictable, at least where large software suppliers are involved. The use of the software
by external service providers is also increasingly factored into licences at the start. Therefore, where outsourcing or
the engagement of any other external service provider is, or may be, contemplated, the customer must ensure that
the licence will permit any existing or future external service provider to use the software on the customer's behalf.

Finally, wherever possible the customer should seek rights to amend, repair, update or develop the software itself,
and to permit its consultants and agents to do so on its behalf (see Third-party maintenance providers).

From the supplier's perspective, it is difficult to police the use of the software (to ensure, for example, that no
illegal copying is taking place), and enforce the terms of the licence, against unconnected third parties. In order to
ensure that the customer remains within the terms of the licence throughout its term, the licence could include an
obligation on the customer to inform the supplier where there is any change in or additional use of the software
and a right for the supplier to audit the use of the software remotely or by entry to all premises on which the
software is used (the extent of which will be subject to negotiation and the respective bargaining strengths of the
parties). Further, certain terms may be included in the licence to protect the supplier in the event that it is willing
to agree to use of the software by third parties.

For example, it could grant the customer the right to sub-license the use of the software and impose an obligation on
the customer to ensure that the terms of the sub-licence mirror those of the head licence (the supplier could even
reserve the right to approve sub-licences in advance) and include a term to the effect that the customer remains
responsible for compliance with the terms of the sub-licence by third parties (this could be given in the form of
an indemnity in favour of the supplier). Any extra work involved (for example, in terms of administration or in
policing the use of the software) could be reflected in the licence fees.

Clear drafting of licence scope is key. The move to the cloud, application program interfaces and interoperable
systems makes clearly drafted licence scope terms critical. See, for example, SAP UK Ltd v Diageo Great Britain
Ltd [2017] EWHC 189 (TCC).

© 2021 Thomson Reuters. All rights reserved. 5

Main issues in software licensing and maintenance contracts, Practical Law UK Practice...

Acts specifically permitted

Standard terms for package software will normally restrict the licence to use of the software and will expressly
prohibit the customer from copying, modifying, adapting or decompiling it except in certain limited circumstances.
This is because suppliers are naturally concerned to prevent their customers from interfering with the software
that constitutes their means of livelihood, if only because such interference increases the risk of illegal copying of
the software and issues with its operation.

However, there may be occasions when access to the inner workings of the software is legitimately required by
the customer. This could occur where the software requires maintenance or amendment and the supplier is not
engaged to provide such services.

In recognition of this, Directive 91/250/EEC on the legal protection of computer programs was introduced (and
was implemented in the UK by means of amendments to the Copyright, Designs and Patents Act 1988 (CDPA),
as amended by the Copyright (Computer Programs) Regulations 1992 (SI 1992/3233) (see sections 50A, 50B and
50C, CDPA) and the Copyright and Related Rights Regulations 2003 (SI 2003/2498) (see section 50BA, CDPA).

The following rights are conferred on software licensees:

• The right to decompile (or effectively reverse-engineer) a program if, broadly, it is necessary in order to
operate the program with another program. This right cannot be excluded by contract (section 50B, CDPA).

• The right to make a back-up copy of a program if necessary (as opposed to prudent) for its lawful use. Again,
this right cannot be excluded by contract (section 50A, CDPA).

• The right to copy or adapt the program if necessary for its lawful use (section 50C, CDPA). This gives a
limited right to correct errors but can be excluded by an express provision in the licence, and frequently is
where the supplier is seeking to sell maintenance and support.

• The right to observe, study or test the functioning of a program in order to determine the ideas and
principles which underlie any element of it (section 50BA, CDPA). This right cannot be excluded by contract.

However, even where these rights cannot be excluded, they are generally regarded as unsatisfactory because they
are limited in their expression and untested by the courts. For example, establishing what is a "necessary" back-up
copy is not easy, and will depend on the particular circumstances of the customer.

Further, there is an exception to the decompilation right which provides that decompilation of licensed software
can be prevented if the supplier makes the information necessary to achieve interoperability readily available
to the customer (section 50B(3), CDPA). Suppliers may take advantage of this exception by providing in their
licences that this information will be made available on request to customers who wish to exercise their legal rights
to decompile. In this way, access to valuable source code is kept to a minimum.

Most standard software licences include a right for the customer to make back-up copies which are necessary
for lawful use of the software, reflecting the terms of the CDPA. However, as indicated above, for the customer, it
will not always be clear what is "necessary" in these circumstances. A back-up copy which is simply stored on disk
and only used if the original copy is corrupted or destroyed is arguably "necessary", but making a second copy of
the software and running it on a second computer would require specific consent. Some suppliers of consumer
package software may permit a customer to load and personally run the software on two computers (typically
the customer's office and home computers) on the basis that, as the customer cannot be in two places at once,
only one use is being licensed. But a second copy of the software is unlikely to be viewed as a back-up copy and

© 2021 Thomson Reuters. All rights reserved. 6

Main issues in software licensing and maintenance contracts, Practical Law UK Practice...

this is still unusual. Normally making a second copy, other than as is necessary for back-up purposes, constitutes
an infringement. Customers should consider whether the licence should permit them to make a specified or a
"reasonable" number of back-up copies (or copies for use on multiple computers, although this is less likely to be
agreed) and also whether specific permission should be granted for testing duplicate copies (for example, in a disaster
recovery environment).

Where necessary, the customer should also seek specific rights to alter the software in certain circumstances (for
example, to enable maintenance or amendment of the software if the supplier is not engaged to provide such
services), although the customer's ability to alter the software without incurring disproportionate cost will usually
depend on the customer being allowed access to the source code of the software (see Source code and Escrow
agreement).

Open-source software

It is increasingly the case that software, including packaged software, incorporates open-source software (OSS).
In brief, OSS is software that is made available under a licence that grants the user certain freedoms to use and
redistribute the OSS. The use of OSS is usually free of charge and free of many of the use restrictions that apply to
proprietary software.

Broadly speaking, licences of OSS fall into two categories: permissive OSS licences and restrictive OSS licences.
The main difference between the two types of licence is how they treat amendments, improvements and adaptations
of the OSS:

• Permissive OSS licences usually only require that distribution of the original OSS be on the same terms
as those on which it was provided. Any amendments, improvements or adaptations of the original OSS can
be distributed on such terms as the software developer wishes, including the same terms that apply to
any proprietary software incorporated in the software. As such, permissive OSS licences are generally
compatible with commercial proprietary licences.

• Restrictive OSS licences, however, impose restrictions on the terms on which the original OSS and any
amendments, improvements and adaptations of the original OSS can be distributed. The specific restrictions
vary from licence to licence. However, these types of restrictions often inadvertently subject proprietary
software that is incorporated into software with the original OSS or amendments, improvements and
adaptations of the original OSS, to the terms of the restrictive OSS licence. This is a concern for both
owners of proprietary software combined with OSS and customers using OSS. Software owners may be
unable to adequately protect, and so secure a return on, the proprietary software they have invested so
heavily in. Customers may not be able to use and develop the software they have purchased in the manner
they anticipate. This concern has led to some customers (such as some UK Government departments)
refusing software incorporating OSS, which has the effect of precluding software developers and
suppliers from certain opportunities or procurement processes.

Customers should, therefore, request details of any OSS that may be incorporated in packaged software and review
the applicable licence terms before purchase for any potential issues. A supplier should ensure that it has this
information so that it can respond to the customer's queries.

The use of OSS can also have other contractual implications. Having not developed the OSS itself and given the
nature of OSS licences, software developers and suppliers are rarely willing to provide the same rights and
protections in respect of OSS that they are willing to provide in respect of their proprietary software. For example:

© 2021 Thomson Reuters. All rights reserved. 7

Main issues in software licensing and maintenance contracts, Practical Law UK Practice...

• The OSS and, depending on the applicable OSS licence, amendments, improvements and adaptations of
the original OSS, may be licensed on the terms of the applicable OSS licence (rather than standard terms
for proprietary software). Sometimes, the applicable OSS licence terms may be extended to all of the
software (including proprietary software). In other cases, proprietary software may be licensed on
separate standard terms. As noted above, the customer should review the applicable licence terms before
purchase for any potential issues. This applies to all elements of the software.

• OSS may be carved out of warranties and indemnities given in respect of the software (for example,
regarding the functionality and non-infringement of third-party rights). Instead, OSS may be provided on an
"as is" basis. The customer should consider whether this is acceptable in respect of undisclosed OSS that it is
not aware of (or whether it requires contractual comfort that the packaged software does not contain any
OSS or any undisclosed OSS).

• OSS may be carved out of commitments in respect of source code (for example, to provide copies of, or put
into escrow, the OSS source code). This may be argued on the basis that the supplier does not have ready
access to the OSS source code or that the customer can access the OSS source code itself. However, again,
the customer should consider whether this is acceptable as it may affect the customer's ability to use and
maintain the software.

For further details of the origins of, ways of licensing and legal challenges presented by, OSS, see Practice note, Open-
source software. Also see Practice note, Open-source software toolkit for resources to assist in understanding
the nature of OSS licensing and managing its use within an organisation.

Scope of the software

The software licensed to the customer will usually be a particular version of the software, which may be updated by
the supplier over time to fix issues and add functionality. Depending on the supplier, the updated software may
be made available as a "new version" (which could be "major version" or "minor version"), a new "release" (which
could be "maintenance release" or "performance release"), or as an "updated version". Sometimes the update is
effected by way of a "patch" or "fix" that is applied to the software, rather than updated software. None of these
(or similar) terms have universally recognised meanings, but are used to signify, and implement, changes to the
software. For example, a supplier may issue "version 1.0" of the software, fix an issue in a "patch", then add
some minor functionality in a "version 1.1" or "version 1.0, release 2" of the software, and finally add substantial
new or improved functionality and make this available to the market as "version 2.0" of the software.

From the customer's perspective, it will usually want to have access to the latest updates to the software so that it
benefits from the improvements that they contain, including in respect of performance and functionality. Updates
that fix performance issues will be particularly important. The supplier, on the other hand, will want to reserve the
right to charge for what it views to be significant improvements, so that it can recover its costs of, and maximise its
return on, the development work involved in them. It is, therefore, important for both parties to be clear as to the
version of the software, and the updates to it, that are to be licensed to the customer by the supplier.

Description

Package software is ready-made and is bought by description (unlike bespoke software, which is designed and
built to a specification (see Practice note, Main issues in systems integration contracts: Specification)).

The supplier's published description of the software is important to the customer, as it is on this that the
customer will probably base its decision about whether to enter into the software licence. Further, the supplier's

© 2021 Thomson Reuters. All rights reserved. 8

Main issues in software licensing and maintenance contracts, Practical Law UK Practice...

contractual warranty regarding the performance of the software is normally given by reference to that document
(see Warranties). The usual warranty available from the supplier for the software is that the software will, for
a limited period, conform in all material respects to its published description.

Business-related software
With business-related software, the published description will often be a detailed functional specification which
is available from the supplier and which should either be appended to or otherwise specifically identified in
the licence agreement. This may be supplemented by a further specification or statement of the customer's
requirements if, for example, the software is to be adapted specifically for the customer (see Practice note, Main
issues in systems integration contracts: Specification).

Often, elements of the software will be configurable to meet the customer's particular needs, and configuration may
either have to be carried out by the supplier or be capable of being carried out by the customer. Such configuration
should be distinguished from alteration of the software. Configuration normally does not require access to the
source code underlying the software. For example, a personnel records system may be configurable to allow the
addition of extra fields if, say, the customer wishes to record the foreign languages spoken by members of its staff.
The configuration exercise might be sufficiently complex to require the attention of someone with a fair degree of
specialist knowledge, but it can be performed without infringing the integrity of the core software. Configurability,
in this sense, is itself a function of the software.

A buyer of business-related software must read the published descriptions carefully to make sure that the
software is suitable for the purpose to which it is to be put. Further, since the software performance warranty
is critical to the customer, the customer should ensure that the document describing the software referred to
in the warranty is sufficiently detailed to particularise the functionality the customer requires and the technical
environment in which the software is intended to operate. A warranty referring to an agreed description of
the software, which is reasonable in its extent, can also benefit the supplier as it promotes certainty; the
supplier knows when entering into the licence what functions the customer is expecting the software to perform.
(Suppliers often describe their software's functionality by reference to documents that appear on their website.
As websites are frequently refreshed without any record of the changes that have been made, it is important that
the customers keep an electronic or printed copy of the documents that appeared on the website at the time it relied
on it.)

If configuration is to be carried out by the supplier, it may be the subject of a separate agreement, in which case
the customer's requirements for the configuration should also be clearly stated. The customer should take the cost
and risks of configuration into account in assessing the value of the application and the applicable terms.

Package software for consumer use

Software of this kind was commonly supplied by means of a "shrink-wrap" licence. The software is provided
on disks, CDs or other media, with a user manual and a form of licence in a packet or box sealed by means of
outer shrink-wrap packaging. A printed notice visible through the shrink-wrap states that the opening of the package
constitutes acceptance of the licence terms. In this case, sometimes the only available published description is
contained in the user manual, which cannot be inspected until after purchase. However, a buyer can often now
inspect more detailed specifications on the supplier's website before purchase.

More recently, the concept has been expanded to include:

© 2021 Thomson Reuters. All rights reserved. 9

Main issues in software licensing and maintenance contracts, Practical Law UK Practice...

• "Click-wrap" licences where the licence terms are stored at the front end of the software so that it is the
first thing that is displayed on the screen when the user tries to install the software.

• "Web-wrap" licences (where the software is sold and distributed electronically (for example, via the
internet)) and where the user will be requested to read the licence terms on the screen and to indicate their
acceptance or rejection of them by clicking on an "Accept" or "Reject" button.

These click-wrap and web-wrap licences are becoming increasingly common in respect of software for consumer
use and are now widely used in respect of business-related software (particularly smaller, lower value software).

For some years the legal nature and enforceability of shrink-wrap licences was the subject of much academic debate
and little judicial scrutiny, the main subject of debate being the incorporation of terms. The issue is resolved, in the
case of business-to-consumer contracts, by the Consumer Rights Act 2015 which, as regards the unfair terms regime
and transparency requirements in Part 2 of that Act, accords similar treatment to contractual and pre-contractual
terms (see Practice note, Consumer contracts: supplying digital content and Consumer contracts: unfair terms
and transparency) and also applies in respect of click-wrap and web-wrap licences.

Duration

Whether the term of the licence should be indefinite (that is, for the full period of the copyright in the software)
or for a fixed period will depend on the nature of the software and the supplier's licensing practice. Consumer
package software normally comes with a licence that is unlimited in time as it is not generally subject to frequent
replacement, the supplier can recoup its investment in the development of such software over a potentially huge
number of consumers and it can be more difficult to police consumers' use of software. More expensive business
software may be licensed for a shorter period. Due to the pace of technology and rapid changes in business practice,
suppliers often need to be able to recoup their investment in the development of complex software over short
periods and want to be able to re-negotiate licences for significantly improved technology. In practice, the non-
availability of maintenance for software which is getting long in the tooth is normally a greater incentive to replace
it than the expiry of a long licence period.

From the customer's perspective, its ability to assign more expensive software is likely to be limited (see Permitted
use). As such, there is a balance to be struck between a long licence term at agreed fees, which fixes the price but
may cause difficulties if the customer wishes to assign or terminate before expiry of the period (for example, because
of a business sale or corporate re-organisation), and a shorter term, which allows the customer flexibility but gives
no certainty as to the level of fees that can be demanded on renewal. Where there is a highly competitive market
in software of the type in question (for example, a prevalence of interchangeable products), a short period may
be preferred, on the basis that the fees may well come down on renewal and, if not, an alternative can be sourced
relatively easily. Conversely, where the software supplier has a practical monopoly, the security of a longer term
may be preferred to ensure that the software remains available to the customer and at a reasonable price.

Installation and testing

In the case of expensive package business software, especially where some customisation is to be performed by the
supplier, the supplier may install the software on the customer's system. Where the supplier agrees to provide
installation services (or configuration services), the fees for doing so may be reflected in the licence fees or dealt
with as a one-off charge. In either case, scope of such installation services (or configuration services), and the terms
on which they are to be provided, should also be clearly stated in the software licence or a separate agreement,
which adequately takes into account the risks associated with such services (and their non-performance). Such
services will be subject to many of the same considerations as any other provision of services. For further details of

© 2021 Thomson Reuters. All rights reserved. 10

Main issues in software licensing and maintenance contracts, Practical Law UK Practice...

issues to be considered in respect of configuration or installation services, see Practice note, Main issues in systems
integration contracts and, in particular Apportionment and management of risk. For some example provisions
that deal with the installation and customisation of the software by the supplier on the customer's behalf, see
Standard document, Systems integration agreement (pro-customer), and, in particular clause 9 to clause 13 of
that document and its integrated drafting notes.

Where any installation is performed by the supplier, the supplier will normally conduct acceptance testing to
ensure that the installed software appears to be working. In most cases, these tests will not be extensive and the
customer's main remedy for failure will be to exercise its rights under the warranty given by the supplier. This will
normally extend for a few weeks or months after installation. (This is also the position where the customer installs
the software itself.)

However, the customer may require the supplier to carry out more formal acceptance tests before accepting
delivery of the software (for example, where the supplier has carried out a significant amount of customisation
or configuration or the software is business critical to the customer). From the customer's point of view, successful
completion of these tests should be a condition of payment of a retained proportion of the licence fee to incentivise
successful completion. The supplier, however, will argue either for no retention to be applicable to testing or for
the retention to be limited to a modest amount representing the cost of configuration and installation on the basis
that the customer will have the benefit of a warranty in respect of the software (see Warranties).

For further discussion of acceptance testing, see Practice note, Main issues in systems integration contracts, where
the remedies for failure are discussed in more detail.

However, where installation or configuration services are to be performed, or acceptance testing is to be carried
out, they should be subject to an agreed specification and timetable. This promotes certainty for both parties. In
particular, the customer should ensure that the acceptance testing comprises relevant and measurable tests that
establish that the software is working and the supplier should ensure that the proposed timetable is a realistic
one, taking into account the amount of work involved.

If the timetable is critical, for example, where the software is being introduced to comply with a time-limited
statutory requirement, the customer will need to consider what remedies are available if delivery does not materialise
or the software fails its tests. Provision may be made for both of the following:

• The customer to have the right to terminate the agreement or licence and to reclaim any money already
paid to the supplier.

• The supplier to meet the additional cost of replacement software or to pay liquidated damages for delay.

A liquidated damages obligation will not be enforceable if it offends the rule against contractual penalties. In
Makdessi v Cavendish Square Holdings BV [2015] UKSC 67, the Supreme Court considered that the ultimate
question to be answered is whether the clause in question is extravagant, exorbitant or unconscionable by imposing
a detriment for breach that is out of all proportion to the legitimate interest of the non-breaching party. For further
discussion on this topic, see Practice note, Agreed remedies: The rule against penalties.

Notwithstanding any enforceability concerns, the mere presence of a liquidated damages provision is likely to
concentrate the supplier's mind on the need for prompt delivery. The supplier, for their part, may object to
liquidated damages on principle or may take the view that a reasonable liquidated damages provision, in which
liquidated damages are the exclusive remedy, gives a degree of certainty to both sides. Much will depend on the
overall commercial context. In any event, neither of these possibilities will necessarily provide an entirely satisfactory

© 2021 Thomson Reuters. All rights reserved. 11

Main issues in software licensing and maintenance contracts, Practical Law UK Practice...

solution for the customer. First, alternative software may not be available for the customer to purchase, at least
in the time required. Second, the customer may not be able to negotiate a level of liquidated damages that reflects
their true loss. Whether that is possible will depend on the relationship between the price which is being paid and
the losses that might be suffered. For example, a software supplier is unlikely to accept liability for liquidated
damages at a level which could, if they were two days late in delivery, not only eliminate their profit on the sale but
also eat into their cost base.

Payment

Provision for payment will vary according to the type of licence:

• In the simplest case, such as a sale of package consumer software, there is a one-off licence fee payable at
commencement.

• In other cases, such as is often the case in respect of the sale of business software (package or otherwise),
there is a one-off licence fee payable at commencement and a recurrent annual fee as well. That fee may
be classified as a licence fee, or a maintenance, support or upgrade fee, or both, although note that the
distinction between licence and maintenance or support fees is observed strictly. The initial and recurrent
licence fees will normally vary by reference to the permitted use of the software. Any variation in any
of the factors defining use, such as in the number of permitted users or the number of sites at which the
software is installed, will normally lead to a variation in the fee (see Permitted use). The customer will
usually want to understand in advance how such additional fees will be calculated and, if appropriate,
require the basis for the calculation of such fees to be set out in the licence.

Discounts are common. Even in the case of consumer package software, discounts will be offered for volume
purchases. Often as the unit cost of the software increases, so the potential for negotiation becomes greater.

Software purchasers need to be aware that non-compliance with licence terms through over-deployment of users
risks incurring extra fees. See, for example, SAP UK Ltd v Diageo Great Britain Ltd [2017] EWHC 189 (TCC).

Warranties

A supplier of package software is normally expected to provide the following warranties as a minimum:

• An undertaking to repair or replace defective software, if the defect is notified within a specified period
(which may be a matter of days) after delivery. This "warranty" is normally accompanied by the exclusion of
all other warranties, whether express or implied under statute or at common law (see Limitation of liability
as to the effectiveness of such an exclusion). A defect for this purpose is generally expressed as a failure to
conform to the specification or a failure in the medium (such as a CD or DVD) on which the software is
delivered. The period of the warranty will vary depending on the type of software being licensed and the
negotiating strength of each party. If the customer has sufficient negotiating power, they may be able to
obtain a longer warranty period and, perhaps, a broader definition of defects or faults, for example, so as
to include failure to integrate with the customer's existing software or, where applicable, the customer's
requirements. As indicated above, such a warranty assumes a degree of detail in the specification and the
customer should check, before signing the licence, that the specification is sufficient for warranty purposes
(see Open-source software).

© 2021 Thomson Reuters. All rights reserved. 12

Main issues in software licensing and maintenance contracts, Practical Law UK Practice...

• A warranty that it has the right to grant the licence, although this issue is also often covered in a clause
containing an indemnity by the supplier if the licensed rights are found to conflict with those of a third
party (see Intellectual property and indemnities).

Other specific warranties may also be included. Historically, express warranties on "Year 2000" and the "euro" (often
in very unspecific terms) were common. Of course, in many programs, the manner in which the program handled
the Year 2000 and handles currencies will be important. However, there is no obvious reason why these elements
of functionality should be selected to appear in the warranty section when all other elements of functionality (often
of greater critical importance) appear in the specification unless a higher level of compliance is required (such
as absolute, rather than material, compliance in this respect). With the advent of the General Data Protection
Regulation ((EU) 2016/679) (GDPR) (which, became the UK GDPR in the UK following the end of the UK-EU
transition period, see Data protection regime in the UK following Brexit) and Network and Information Systems
Regulations 2018 (SI 2018/506) (NIS Regulations) and customers' potentially significant exposure under them,
warranties concerning data protection and cybersecurity issues are increasingly being included (see Data protection
and cybersecurity).

From the customer's point of view, warranty clauses always require careful consideration. It is not unusual for
clauses to contain a mixture of warranties and exclusions, particularly as the quid pro quo for an express warranty
is normally the removal of certain statutory warranties and the customer should check that the express warranties
compensate appropriately for any exclusions. For a discussion of the supplier's main concerns in this respect, see
Limitation of liability.

Suppliers should also ensure that warranties cannot also be viewed as representations (see Sycamore Bidco
Ltd v Breslin [2012] EWHC 3443 (Ch) and Legal update, High Court considers whether a warranty was also a
representation).

See Open-source software for the implications for warranties in respect of packaged software incorporating OSS.

Limitation of liability

As mentioned earlier, this note is primarily concerned with business-to-business transactions. Business-to-
consumer transactions are subject to a different regime as regards the limitation and exclusion of liability, and the
question of whether software (and digital content) is to be treated as goods or services has been answered by statute
in the case of consumer contracts. This section should therefore be treated as applying only to business-to-business
contracts. For information on consumer contracts, see Practice notes:

• Consumer contracts: which rules apply?.

• Consumer contracts: supplying digital content.

• Consumer contracts: common terms and conditions: Limitations of liability.

As the value of the software in the customer's business, and hence the potential damage which the customer may
suffer if the software fails, may far exceed the cost of the software, the supplier should always endeavour to
restrict its liability to the customer under the licence. However, the law protects the customer in a number of ways
discussed below and the customer will want to ensure that it has effective remedies for any damage that it may
suffer. Therefore, the liability provisions are often the most contentious and heavily negotiated terms in a software
licence.

© 2021 Thomson Reuters. All rights reserved. 13

Main issues in software licensing and maintenance contracts, Practical Law UK Practice...

Before considering the drafting of clauses excluding or limiting liability, it is necessary to consider two preliminary
points:

• The Unfair Contract Terms Act 1977 (UCTA) which forms the background to the discussion.

• The question of whether a supply of software is a sale of goods or a supply of services.

Unfair contract terms legislation

For the rules that need to be considered when drafting and negotiating exclusions and limits of liability in software
licences entered into between two commercial entities, see:

• Practice note, Drafting standard terms and conditions for the supply of goods.

• Practice note, Limiting liability: statutory and common law controls on limitation clauses.

• Practice note, Limiting liability: interpretation.

• Practice note, Drafting standard terms and conditions for the supply of services.

• Practice note, Supply contracts: overview.

• Checklist, Drafting terms and conditions for the supply of goods.

• Checklist, reviewing terms and conditions of sale when purchasing goods and/or services.

(The legal considerations for licences entered into with consumers are different and, as noted above, are not covered
in this note.)

Points to highlight in the business-to-business context include the following:

• Death or personal injury caused by negligence. Liability for death or personal injury resulting from
negligence cannot be excluded or restricted under a contract (section 2(1), UCTA). Negligence is defined to
include breach of any express or implied term of a contract requiring the exercise of reasonable skill and care
in the performance of the contract or any common law duty to take reasonable care or exercise reasonable
skill (section 1(1), UCTA).

• Other loss caused by negligence. Liability for other forms of loss resulting from negligence cannot
be excluded or restricted by a contract unless the contract term satisfies the reasonableness test (section
2(2), UCTA). The sort of loss which might be caught by section 2(2) of UCTA would be that arising from
the negligent production of a product which causes physical damage to other property or financial loss (for
example, accounting software which produces inaccurate data which is relied on).

• Liability for breach of implied terms. Different rules apply to two categories of implied terms:

• liability for breach of the terms implied into contracts by law as to title, non-encumbrance and quiet
possession (under section 12 of the Sale of Goods Act 1979 (SGA) or section 2 of the Supply of Goods
and Services Act 1982 (SGSA)) cannot be excluded or restricted by contract (sections 6(1) and 7(3A),
UCTA); and

• liability for breach of the terms implied by law as to conformity of goods with description or sample
or as to their quality or fitness for a particular purpose (under sections 13, 14 and 15 of the SGA and

© 2021 Thomson Reuters. All rights reserved. 14

Main issues in software licensing and maintenance contracts, Practical Law UK Practice...

sections 3 and 4 of the SGSA) cannot be excluded or restricted by contract against a commercial entity
(as opposed to a consumer) except insofar as the term satisfies the reasonableness test (sections 6(1A)
and 7(1A), UCTA).

• Liability for breach of express terms. Where the parties to a contract deal on one party's written
standard terms of business, that party cannot (broadly) exclude or restrict any liability for breach of contract
unless the term satisfies the reasonableness test (section 3, UCTA). The sort of loss which might be caught
by section 3 of UCTA would be that caused by software which does not conform to the specification set out
in the contract or which is delivered late or not at all. Not all terms need to be fixed by the supplier in order
for the supplier to be considered to be dealing on its standard terms of business (Pegler Ltd v Wang (UK)
Ltd [2000] BLR 218).

• Liability for misrepresentation. Liability or remedies for a misrepresentation made before a contract is
made cannot be excluded or restricted by contract unless the clause satisfies the reasonableness test under
UCTA (section 3, Misrepresentation Act 1967).

• Reasonableness. In relation to a contract term, the requirement of reasonableness is that the term shall
have been a fair and reasonable one to have been included having regard to the circumstances which were, or
ought reasonably to have been, known to or in the contemplation of the parties when the contract was made
(section 11(1), UCTA). For sections 6 and 7 of UCTA, regard must be given to the matters set out in Schedule
2 of UCTA (this includes matters such as the bargaining strength of the parties and whether the customer
received an inducement to agree to the term) (section 11(2), UCTA). Where a party seeks by contract to
restrict its liability to a specified sum of money, regard is to be had in particular to the resources available to
that party to meet the liability should it arise and the availability of insurance cover (section 11(4), UCTA).

• International supply contracts. Certain controls under UCTA may not apply to contracts where the
parties' places of business are in different countries (section 26, UCTA). It is important for both parties to
keep this provision in mind when negotiating the exclusion clauses.

Does software constitute "goods"?

St Albans City and DC v International Computers Ltd [1997] FSR 251 makes it clear that:

• When software is sold with the medium on which it is stored (for example, where a program is delivered on
a disk), the transaction is a sale of goods.

• When the medium is not included in the sale of software (for example, where the supplier loads the
program onto the customer's computer from a medium retained by the supplier), the transaction is a
supply of services.

While the St Albans case considered whether software can be "goods" for the purposes of the SGA and the SGSA,
the more recent case of Computer Associates UK Ltd v Software Incubator Ltd [2018] EWCA Civ 518 considered
the St Albans approach in deciding whether electronically supplied software (where the goods are not on any form
of tangible medium, such as a disk) amounts to "goods" under regulation 2(1) of the Commercial Agents (Council
Directive) Regulations 1993 (SI 1993/3053) (CAR 1993). Considering case law to date, the Court of Appeal found
that intangible software does not constitute "goods" under CAR 1993 but the judge recognised that, in the light
of technological developments, this decision seemed somewhat outdated. On Software Incubator's appeal to the
Supreme Court, the question was referred to the CJEU (a decision is pending), see Continuing relevance of EU case
law.

© 2021 Thomson Reuters. All rights reserved. 15

Main issues in software licensing and maintenance contracts, Practical Law UK Practice...

An interesting case to also consider here around the application of CAR 1993 and what constitutes "goods" is Green
Deal Marketing Southern Ltd v Economy Energy Trading Ltd [2019] EWHC 507 (Ch). The case followed other
decisions to confirm gas and electricity would constitute "goods" under CAR 1993. This is interesting when compared
to the decision in Computer Associates and the difficulties with aligning the current legal position that identifies gas
and electricity as "goods" but not software.

Where package software is purchased over the internet and downloaded straight into the recipient computer's
memory, instead of being sent to the customer on a disk, it would seem to follow from the St Albans case that
the transaction is a supply of services. However, it remains an open question, in the case of business-to-business
transactions, whether it would make a difference if (as is often the case) the customer can, on payment of a small
additional fee, ask for a copy on disk to be sent through the post.

Where software is delivered in the form of goods, it attracts the protections set out in the sale of goods legislation,
such as the implied warranties as to satisfactory quality in section 14(2) of the SGA and section 4(2) of the SGSA
(section 4 of the SGSA will apply where software is transferred, in the form of goods, in the course of the provision
of services). The courts have also found a common law duty for services to be of satisfactory quality and reasonably
fit for their purpose.

Where software is delivered in the form of services:

• The implied terms relating to goods under the SGA and the SGSA do not apply, so section 6 and section 7 of
UCTA do not need to be considered.

• There will, however, be a common law duty to ensure that the software is reasonably capable of achieving
its intended purpose (St Albans). There are also implied terms under the SGSA in respect of services, such
as that under section 13 which implies a term in a contract for the supply of services that the supplier will
carry out the services with reasonable care and skill.

• The provisions under section 2 and section 3 of UCTA and section 3 of the Misrepresentation Act 1967 will
still apply.

As mentioned above, the goods/services tension has largely been removed in the case of business-to-consumer
contracts by the Consumer Rights Act 2015.

St Albans v ICL case

ICL provided a computer system to the St Albans local authority for use by the authority in collecting
the Community Charge. As a result of a fault in the software, the authority set the charge at too low a
level. The authority sued ICL for over £1 million in damages for breach of contract. ICL sought to rely on
a clause in its standard terms of business limiting its liability to £100,000.

Both the High Court and the Court of Appeal held that the limit of £100,000 was unreasonable under
UCTA. The key points to emerge from the decision were:

• ICL was a large company with substantial assets and insurance cover of up to £50 million and so
was in a better position to bear losses than St Albans, which would have to meet losses out of an
increased Community Charge or reduced services (or both).

© 2021 Thomson Reuters. All rights reserved. 16

Main issues in software licensing and maintenance contracts, Practical Law UK Practice...

• The limitation of £100,000 bore no relation to ICL's insurance cover of £50 million and ICL had
not attempted to justify the difference. The judge at first instance considered it reasonable that
the person making the profit should also carry the risk.

• ICL was in a strong bargaining position. Although St Albans had objected to the limitation clause
during negotiations, they were persuaded to accept it when ICL indicated that any amendment
would have to be referred back to its legal department. The resulting delay would mean that St
Albans could not keep up with its Community Charge timetable and it therefore had no realistic
option other than to accept ICL's terms.

St Albans had not been offered any inducement, such as a reduction in price, to accept the limitation
and they had no opportunity of getting better terms elsewhere because other suppliers were offering
similar terms (with the same cap on liability).

(St Albans City and DC v International Computers Ltd [1997] FSR 251.)

Drafting and negotiating exclusion clauses

As mentioned above, there is no necessary correlation between the price of a software licence and the value the
licensed software can bring, or damage it can cause, to the customer's business. This gives rise to a conflict between
the interests of the customer and the supplier. The customer wants to achieve the maximum protection possible
against loss, while the supplier will only want to accept a level of liability which is commensurate with the value
of the transaction to it.

Added to this commercial conflict is the uncertain application of the unfair contract terms provisions (see Unfair
contract terms legislation). While the supplier may wish to include a broad exclusion or limitation clause, the
supplier is faced with the dilemma that the wider the protection it seeks, the more likely the supplier is to infringe
one of the unfair contract provisions outlined above. Conversely, while it may appear superficially attractive for the
customer to accept the supplier's very broad exclusion clause on the basis it will be struck down by a court as
unreasonable, few customers want their rights of recovery to depend on the fortunes of litigation.

It is therefore in both parties' interest to reach a fair compromise on liability.

For information on the approach to take when drafting and negotiating limitations or exclusions of liability, see
Practice notes:

• Drafting standard terms and conditions for the supply of goods: Limiting or excluding liability in standard
terms.

• Drafting standard terms and conditions for the supply of services: Limiting or excluding liability in
standard terms and conditions.

• Supply contracts: overview: Limitation of liability.

Specific issues to be considered include:

• Liability which cannot be excluded.

© 2021 Thomson Reuters. All rights reserved. 17

Main issues in software licensing and maintenance contracts, Practical Law UK Practice...

• Liability which can be excluded.

• How explicit does an effective exclusion clause have to be?

• What is the effect of an exclusion of "consequential loss" or "indirect loss" (or both)?

• Losses which can be recovered. With the advent of the GDPR, UK GDPR, DPA 2018 and NIS Regulations
and customers' potentially significant exposure under them, customers are increasingly seeking rights to
recover certain losses for data protection and cybersecurity issues (see Data protection and cybersecurity).

• Loss of "anticipated savings". It is often the case that customers enter into software licences for new
software specifically because it represents better value for money to them than older systems. This is
particularly true when one looks at the commercial advantages of "cloud" deals as opposed to traditional
methods of loading software onto customer owned and maintained IT. It is, therefore, not unreasonable
to expect a customer to wish to maintain its right to claim for such losses in the event of a dispute with the
supplier.

Further points to highlight in the context of software licences include the following:

• It is tempting to deal with all the standard non-exclusions in a general clause stating that the contract does
not seek to exclude liability which cannot be excluded at law. This course has its risks: the general principle
is that exclusion clauses must make it clear what they are excluding and there is therefore no guarantee that
a general "non-exclusion" clause will be enforceable. General wording is better used, if at all, as a "sweep up"
following a list of the specific non-exclusions referred to above, but should be carefully drafted.

• The prudent advice to a supplier will always be to be as explicit as possible in describing the exclusions and
limitations being placed on the customer. This is necessary for all types of liability exclusion (or limitation)
clause not just those relating to misrepresentation. For example, a limitation clause relating to "damages"
may not be held to apply to the price paid under the contract. If so, the innocent party might be entitled to
recover that sum, in addition to "damages" (at the limit set out in the contract), in the event of a repudiatory
breach by the other party. Similarly, the Court of Appeal has held that, based on the wording of certain
exclusion and limitation clauses, the supplier had failed to exclude loss for all "anticipated savings" but
rather such losses were only subject to the financial cap on the supplier's liability as set out in the contract
(University of Keele v Price Waterhouse [2004] EWCA Civ 583; see Legal update, Engagement letters:
Exclusion of liability).

• The High Court decision of British Sugar plc v NEI Power Projects Ltd [1997] CLC 622 is significant for
software suppliers since, in the context of the supply of defective software, it is possible that certain
types of financial loss (in this case, loss of profits) can be just as direct and a natural result of the breach from
the customer's perspective as having to repair or replace the software.

• While the High Court decision in Regus (UK) Ltd v Epcot Solutions Ltd [2007] EWHC 938 (Comm) has
been overruled, it emphasised what is still the case that the greater the scope of the apparent exclusion,
the more difficult it will be to demonstrate that it is reasonable. It may therefore still be prudent, in certain
circumstances, to clarify the types of liability other than loss of profit and so on, for which the supplier
will remain liable. For example, had Regus offered service credits against its monthly charges for failure to
comply with certain standards, or if a similar clause in a software licence made it clear that the exclusion
did not cover, for example, wasted staff time or the cost of procuring a replacement system, the exclusion of
loss of profits would have been more likely to have been considered reasonable at the outset.

© 2021 Thomson Reuters. All rights reserved. 18

Main issues in software licensing and maintenance contracts, Practical Law UK Practice...

In considering the reasonableness of an exclusion of direct loss, such as loss of profit, it is always necessary to
bear in mind that there are two different ways in which claims can be excluded or limited: by reference to type (or
category) and by reference to amount. The distinction can be important. For example, where software is purchased
by a customer for the specific purpose of saving costs, and the supplier is quite clearly aware that that is the
customer's purpose, a contractual exclusion of any right to claim for loss of anticipated savings appears prima
facie unreasonable. However, where the software costs £10,000, a clause which limits the supplier's liability for
claims under the contract (including claims for loss of anticipated savings) to £20,000 (that is, twice the supplier's
anticipated revenue), is not prima facie unreasonable (even though the savings in question might have amounted
to hundreds of thousands of pounds). As always reasonableness must be judged by reference to the circumstances
of the case.

What is "reasonable" in the context of the exclusions commonly found in software development
agreements and licences?
The "reasonableness" test has already been described above. It has been applied in cases to:

• Limitations and exclusions of statutory warranties (that is, those which are capable of being excluded).

• Misrepresentation (other than fraudulent misrepresentation).

• General negligence and breach of contract.

Reasonableness is determined by reference to the circumstances of each transaction so no definitive guidance can
be given. All one can do is try to analyse the judicial trends which emerge over time. From 1995 to 2000, the trend
(in judgments of the Business and Property Courts of England and Wales in particular) was to strike down limitation
or exclusion clauses as unreasonable. St Albans City and DC v International Computers Ltd [1997] FSR 251, South
West Water Services Ltd v International Computers Ltd [1999] BLR 420 and Pegler Ltd v Wang (UK) Ltd [2000]
BLR 218 are all examples of cases in which such clauses in software contracts were found to be unreasonable.
By comparison, both EA Grimstead & Son Ltd v McGarrigan (unreported), 27 October 1999, (Court of Appeal)
and Watford Electronics Ltd v Sanderson CFL Ltd [2001] EWCA Civ 317 laid greater emphasis on the practical
circumstances of negotiation.

The Watford Electronics case concerned a supply of hardware and software on the supplier's standard terms.
The supplier's standard terms contained a clause under which the supplier excluded liability for indirect or
consequential losses, and limited its liability for direct losses to the price paid by the customer. The supplier also
agreed to use its best endeavours to allocate appropriate resources to the project in order to minimise any losses
that might arise from its performance. The court held that the limitation clause was not unreasonable under UCTA.
This was based on a number of considerations, including the fact that the supplier could only rely on the limitation
clause if it had first complied with the best endeavours obligation referred to above, and the following factors which
were relevant in the context of the guidelines in Schedule 2 to UCTA:

• The contract was negotiated by commercially experienced parties of equal bargaining power.

• Both parties' standard terms contained similar exclusion clauses.

• Both parties were aware, or should have been aware, that there was a significant risk that software
customised to the customer's specific needs might not perform to the customer's satisfaction. Losses arising
from this ought to have been in the contemplation of the parties at the time of contracting.

• Risk allocation and the quantification of damages was a factor that the parties ought to have known or would
have taken into account when determining the contract price.

© 2021 Thomson Reuters. All rights reserved. 19

Main issues in software licensing and maintenance contracts, Practical Law UK Practice...

• The software market was a buyer's market.

Another example of a case in which a supplier's limitation clause was upheld is provided by SAM Business Systems
Ltd v Hedley and Company [2002] EWHC 2733 (TCC). In this case, the software licence contained a broad
exclusion of liability subject to an upper limit on any unexcluded liability of an amount equal to the licence fees
paid. The licence did, however, give the customer the right to reject the software if it did not meet certain
acceptance criteria and to recover the fees paid to the supplier. It was held that the presence of this "money-back
guarantee" (which the customer had not exercised), the equal bargaining power between the parties and the fact that
other suppliers applied similar provisions but the customer did not try to negotiate the liability position, rendered
the terms of liability reasonable.

What is clear from these cases is that suppliers must set their limitations or exclusions by reference to the particular
circumstances of each transaction. In particular, limitations and exclusions in a supplier's standard terms may
not be reasonable in the case of the supply of a complex or customised product, and a clause which limits rather
than excludes liability is more likely to be upheld, but all of this will depend on various factors such as the parties'
bargaining strength, the presence or lack of legal representation and the sophistication of the buyer. The factors set
out in section 11 of UCTA for determining reasonableness should be considered.

Further, in formulating these clauses, the level of the supplier's insurance cover should be checked and records
of the negotiations relating to the clauses should be kept in case the supplier is ever called on to explain why a
particular limit was chosen. Records of negotiations can also help to establish that the parties did not contract under
the supplier's written standard terms. Where the parties are not dealing on the supplier's written standard terms,
a limitation of liability for breach of contract does not have to be reasonable as section 3 of UCTA will not apply.
However, a limitation clause will still have to be reasonable insofar as it operates to exclude or limit liability for
certain liabilities (for example, for negligence (section 2(2), UCTA), for breach of terms implied by the SGA (section
6(1), UCTA) and for misrepresentation (section 3, Misrepresentation Act 1967)).

Some suppliers attempt to impose time limits for bringing claims under a software licence. Such terms would
also be subject to UCTA as exclusions or limitations of liability.

Always bear in mind that the treatment of limitation of liability in consumer contracts is significantly different (see
Practice notes, Consumer contracts and Supply of digital content to consumers: changes made by the Consumer
Rights Act 2015).

Intellectual property and indemnities

A software supplier will normally warrant that it has authority to grant the licence in question (see Warranties).
However, the customer should, in addition, require protection against third-party claims that might hinder or
prevent its use of the software. The most likely type of claim is that the software infringes a third party's
intellectual property rights. This may arise where, for example, some part of the program was written for the
supplier by a contractor, allegedly using code or design principles belonging to the contractor. The customer should
seek protection in the form of an indemnity. For details of the benefits of indemnity over warranty protection, see
Practice notes:

• Warranties and indemnities: acquisitions.

• Seller warranties and limitations on liability: commonly negotiated issues: business purchases.

• Contracts: indemnities.

© 2021 Thomson Reuters. All rights reserved. 20

Main issues in software licensing and maintenance contracts, Practical Law UK Practice...

• Contracts: indemnities.

A reputable software supplier will always be prepared to protect the customer against such claims, although the
extent of the protection may be the subject of negotiation. For example, the supplier may offer protection, but not
necessarily in the form of an indemnity (although this would be usual in the vast majority of software licences).
The supplier might, for example, commit to substitute or alter the software, or obtain a licence from the third
party, so that it is no longer infringing. Further, where the customer proposes to use the software in a number
of countries, the supplier should consider whether the protection should extend to countries outside its home
jurisdiction (since it cannot be expected to know whether its software infringes intellectual property rights in any
part of the world).

The supplier may also reserve the right to substitute or alter the infringing software. For the customer, this may
be unobjectionable as long as it is subject to the stipulation that the new or altered software provides the same
or improved functionality. The supplier may also reserve the right to refund the price if the infringement cannot
be cured. Such provisions will normally be described as the customer's exclusive remedy and the customer should
resist this linkage as it may well have incurred costs and those costs may significantly exceed any refunded licence
fee. It is also arguable that a refund provision may in any event be ineffective as an attempt to exclude the statutory
warranties as to title and quiet enjoyment.

A supplier should ensure that the scope of its liability under any indemnity that it proposes to give is clearly defined
(see Rust Consulting Ltd (In Liquidation) v PB Ltd [2012] EWCA Civ 1070 and Legal update, Court of Appeal
overturns decision on interpretation of indemnity and estoppel).

See Open-source software for the implications for indemnities in respect of packaged software incorporating
OSS.

Again, the issues are dealt with more clearly in a consumer context; see Practice notes, Consumer contracts and
Supply of digital content to consumers: changes made by the Consumer Rights Act 2015.

Source code

The customer may in certain circumstances require access to the inner workings of the software (see Acts
specifically permitted). These are the lines of code in which the software is written, which constitute the
instructions that the software gives to the system in order to produce the desired result. These instructions exist
in two versions. In the form in which they run on a computer, the instructions are written in object code; a form in
which they can be understood by a machine, but not by a human. If the object code has to be changed, the customer
will need access to the source code from which the object code was derived. Unlike the object code, the source code
version of a program is capable of being read by a human programmer, although it may not make much sense to
them unless they also know the design methodologies and tools that were used in its preparation. The source code
is compiled (or converted) into the object code by a program called a compiler, the purpose of the compilation being
that the object code version will run much faster on the computer than the source code version, which would need
to be interpreted line by line. The reverse process is known as "decompiling".

If it is agreed that a customer will acquire ownership of bespoke software, the customer must also acquire
ownership of the source code (as well as object code) if it is to be able to amend the software in the future. The
contract for the bespoke software should therefore require the software developer to deliver to the customer
the source code, the design documents and technical information and a licence to use any proprietary tools
and methodologies, without which it would be difficult, or impossible, to amend the software or use the design
documents or technical information. Where the customer is only granted a licence of bespoke software, they may

© 2021 Thomson Reuters. All rights reserved. 21

Main issues in software licensing and maintenance contracts, Practical Law UK Practice...

not, even if it is a royalty-free and perpetual licence, automatically be supplied with a copy of the source code, but
similar considerations apply. Further, very rarely is a buyer of package software offered access to the source code.

A software developer will want to retain control of the source code because it gives the developer a practical means
of preserving their rights in the software. The source code reveals precisely how a program functions and therefore
it is in the interests of the developer to keep it secret.

In addition, there are less commercially contentious reasons for developers to retain control of the source code:

• Most large programs are subject to a continuous cycle of development and improvement, requiring frequent
changes to the source code. Possession of an out-of-date copy of the source code is of limited practical use
and, were the source code to be widely distributed, the task of keeping the numerous copies updated would
be cumbersome and likely to lead to an increase in licence fees.

• As long as the customer is obtaining maintenance services from the developer or a developer-approved
third party (and most large programs are accompanied by maintenance and support agreements), it will
not need access to the source code (although the developer-approved third-party maintenance company
might). What is essential for the customer's protection is that they should have access to an up-to-date copy
of the source code if the developer is unwilling or unable to maintain the software any longer (for example,
because of insolvency), but not necessarily otherwise. This is normally achieved by means of an escrow
agreement (see below).

• See Open-source software for the implications for access to source code in respect of packaged software
incorporating OSS.

Escrow agreement

This is a tripartite agreement under which the supplier agrees to deposit a copy of the source code with an escrow
agent, and the escrow agent undertakes to the supplier and the customer that they will deliver a copy of the source
code to the customer in certain events, normally limited to the supplier's insolvency or its refusal or inability to
provide maintenance.

Customers will normally find suppliers reluctant to enter into escrow agreements. There are circumstances in
which a court might order a supplier to provide source code to a customer, such as where, in the case of a software
development contract, the supplier's inability to complete the development would have a serious adverse impact
on the customer's business (see Psychometric Services Ltd v Merant International Ltd [2002] FSR 8). However,
this would happen only in extreme circumstances and the customer does not want to have to face the expense and
inconvenience of going to court to get access to the source code. Having said that, an escrow arrangement is not
without its problems and whether the customer should insist on an escrow agreement is a matter of commercial
risk assessment. An escrow agreement is a rather unsatisfactory form of insurance cover because:

• It costs money (represented either by a fee payable to the escrow agent or an increased licence fee).

• It can be difficult and take time to invoke (because there may be a dispute as to whether the release
conditions have occurred or a lengthy or involved release process).

• It needs to be policed carefully if it is to be of any use (because out-of-date source code or source code
without the associated design documents and technical information can have little value).

© 2021 Thomson Reuters. All rights reserved. 22

Main issues in software licensing and maintenance contracts, Practical Law UK Practice...

Before deciding to insist on escrow, the customer should consider the following questions:

• What would the customer do if the software could no longer be maintained by the supplier?

• Could the customer obtain maintenance from a third party at a similar cost?

• Could the customer replace the software with, and migrate to, similar software and at a reasonable cost?

• What would be the cost of migrating to new software?

If the answer is that all alternatives are unavailable or too costly, an escrow agreement, whatever its disadvantages,
is a desirable form of protection.

The supplier for their part will rarely be keen to enter into an escrow agreement unless either of the following
applies:

• The supplier treats it as a sales aid of last resort and allows insistent customers to be listed as beneficiaries
on the standard form escrow arrangement that the supplier maintains with an escrow agent.

• The customer's bargaining position is such (because of the cost of the software or the supplier's financial
condition) that it is commercially prudent for the supplier to offer escrow on the basis set out above, or
otherwise.

Where the supplier does agree to enter into an escrow agreement, it is essential for the customer that:

• The escrow agent is reliable and stable, given that their primary function is to be there when the supplier is
gone. The NCC Group is often used for this reason.

• The source code which is deposited is kept up to date and tested at regular intervals, preferably by the escrow
agent rather than the supplier, so that the process involves a degree of independence.

• The source code is accompanied by whatever design documents and technical information are necessary to
enable a reasonably skilled programmer to understand it.

• Any tools or methodologies that are proprietary to the supplier, and without which amendment of the
software or use of the design documents or technical information would be difficult or impossible, are also
deposited.

• The customer has a means of verifying from time to time that the terms of the escrow agreement are being
observed (for example, by requiring a certificate from the escrow agent, at a cost).

• The conditions for release of the software from the escrow are clear, unambiguous (these terms also
benefit the supplier) and capable of exercise by the customer without the consent of the supplier. It is
also preferable for the customer to extend the conditions for the release of the escrow beyond insolvency
and refusal to maintain so as to include, for example, the imposition of oppressive maintenance terms by the
developer or certain breaches of the maintenance terms.

• Finally, many developers use third-party distributors to sell and distribute their software. As such,
depending on whether the supplier is the developer of the software and the terms on which the supplier
is permitted to distribute a developer's software, it may be the developer (rather than the supplier) that
should enter into the escrow agreement. From the customer's perspective, this would ensure that the party
with access to the source code and all relevant documents, information, tools and methodologies is required

© 2021 Thomson Reuters. All rights reserved. 23

Main issues in software licensing and maintenance contracts, Practical Law UK Practice...

to make the deposit with the escrow agent. From the supplier's perspective, it would not be required to
comply with obligations that it may be unable to comply with.

• For further discussion on the topic of escrow arrangements, see Practice note, Software escrow
arrangements.

Confidentiality and know-how

In a licence of package software, specific clauses dealing with confidentiality are unusual, although confidentiality
provisions are often contained in the clauses dealing with intellectual property. However, a contract where there is an
element of bespoke design, particularly where the software is adapted to match the customer's business processes,
will normally contain mutual confidentiality provisions and an express reservation of the supplier's know-how,
since:

• The customer will be concerned to ensure that the supplier keeps all information about the customer's
business confidential. Where the supplier is customising the software for the customer, it is likely that it
is customising software for its other customers, and there is a risk that the customer's valuable business
information may be disclosed to other companies.

• Where, as is often the case, the development process involves a degree of co-operation between the
supplier and the customer, the supplier will be equally concerned that the customer does not exploit any
information about the supplier's methodologies or other know-how in an unauthorised manner.

Data protection and cybersecurity

Data protection regime in the UK following Brexit

The GDPR has been directly applicable in all EU member states since 25 May 2018. It repeals the Data Protection
Directive (95/46/EC) (DPD) which was implemented in the UK by the Data Protection Act 1998 (DPA 1998). The
DPA 1998 was, in turn, replaced by the DPA 2018 which received Royal Assent on 23 May 2018.

At the end of the UK-EU transition period (transition period), the GDPR and parts of the DPA 2018 became part
of the new body of retained EU law. The Data Protection, Privacy and Electronic Communications (Amendments
etc) (EU Exit) Regulations 2019 (SI 2019/419) (DP Brexit Regulations) immediately amended this retained EU law
version of the GDPR (renaming it the UK GDPR), as well as the DPA 2018. See Practice note, Brexit post-transition
period: data protection (UK): UK data protection law at end of the transition period: summary.

After the end of the transition period, data protection legislation in the UK comprises the UK GDPR and the DPA
2018. The GDPR will be known as the EU GDPR in the UK, see Practice note, Brexit post-transition period: data
protection (UK): New and amended data protection legislation.

As the EU GDPR will continue to have extra-territorial effect (see Article 3, EU GDPR) it may continue to apply to UK
software suppliers who act as controllers or processors and have an establishment in the EU, or who offer goods
or services to data subjects in the EU; or monitor their behaviour as far as their behaviour takes place within the EU.
Such suppliers may, therefore, find themselves subject to parallel data protection regulatory regimes under the UK

© 2021 Thomson Reuters. All rights reserved. 24

Main issues in software licensing and maintenance contracts, Practical Law UK Practice...

GDPR and the EU GDPR. For more information, see Practice note, Brexit post-transition period: data protection
(UK): Determining which regimes apply.

For more information, including on the changes made by the DP Brexit Regulations and key considerations for
organisations, see Practice notes:

• Brexit post-transition period: data protection (UK).

• Brexit: implications for data protection.

Data protection compliance

You might not normally expect traditional on-premise software licensing to present data protection compliance
risks, vis-à-vis the software supplier and its customer, given the fact that the software is to be locally installed,
run and operated by the customer within its own architecture.

However, where the supplier is engaged to provide software maintenance and support services, it may have
access to personal data processed by the software. Personal data might also appear in test data used as part of any
software installation, configuration or development work to be completed by supplier, or it may be collected by
the supplier as part of any service desk function it runs. Accordingly, it will be important for customers to consider
what personal data may be processed by the supplier and put in place suitable mechanisms (including contractual
clauses) to ensure such personal data is processed in accordance with the UK GDPR and DPA 2018 (and where
applicable, the EU GDPR). For more information, see Practice note, Overview of GDPR: UK perspective: Controller
and processor contracts and Standard clauses, Data processing clauses (UK).

It used to be the case that software licensors who had access to the personal data of their customers for the purposes
of support, maintenance, testing and configuration had a vested interest in categorising themselves as a processor of
that data, as the stringent data processing obligations set out in the DPA 1998 would then not apply to them directly
(although a prudent customer would often flow these obligations down to them via their licence agreements).
However, as the DPA 1998 was replaced by the DPA 2018 and the GDPR, and then the UK GDPR, this vested interest
became less important. This is because:

• Certain obligations are now imposed on processors for the first time (for example, around ensuring
minimum levels of data security) meaning the software licensor is no longer able to evade statutory data
protection obligations by arguing it is merely a processor.

• Even where direct obligations are not imposed on the processor via statute, the mandatory provisions
required to be included in contracts under Article 28(3) of the UK GDPR means that many of the risks and
liabilities imposed on controllers could be flowed down to their processors in any event.

• The categorisation can be unduly limiting. For example, a processor must comply with the instructions of
its customer when processing the personal data, and is not permitted to use the personal data for any other
purpose than that stipulated by the customer. This may be incompatible with the goods or services being
provided.

In addition, as the industry continues to evolve, suppliers must think carefully about the legal risks posed by the
goods and services they provide. They may no longer be able to argue that they simply "maintain" the software as a
processor, especially where there may be less of a distinction around the supplier's collection, storage and analysis
of data, moving away from a supplier's more historical role of simply "maintaining" a system. This is particularly

© 2021 Thomson Reuters. All rights reserved. 25

Main issues in software licensing and maintenance contracts, Practical Law UK Practice...

relevant where a supplier may perform a range of services for a customer as part of its package offering and so
(arguably) may move between acting as a controller and a processor depending on the activity in question and the
"data flow". An example is where a supplier puts itself forward as having business process outsourcing expertise
or as providing an overall technology "solution".

That said, data protection compliance concerns continue to be more prevalent in "software as a service"
arrangements where personal data may be processed, and systems, applications and processes may be managed,
remotely outside of the customer's local IT infrastructure (see Practice notes, Cloud computing: overview and Data
protection aspects of cloud computing (GDPR and DPA 2018) (UK)).

For further discussion on the distinction of controllers and processors under the UK GDPR and DPA 2018, see
Checklist, Concepts of controller and processor (GDPR and DPA 2018) (UK).

Wider cybersecurity issues

If the software contains security vulnerabilities, this can make the customer's network and information systems
more vulnerable to attack from malicious actors. The customer may wish to include certain warranties from the
licensor that reasonable steps will be taken to remove known vulnerabilities from its software products, and to
provide timely patches in the event new vulnerabilities are discovered. Cybersecurity-type warranties will likely
become more prevalent in software licences and maintenance and support agreements as data breaches
and cyber-attacks continue to garner attention in the media, and as the regulatory risk environment increases,
including through the coming into force of legislation such as the NIS Regulations. For more information on the
NIS Regulations generally, see Practice note, Cybersecurity Directive: UK implementation.

Breaches of the UK and EU GDPR, DPA 2018 and NIS Regulations can expose both customers and suppliers to
significant regulatory fines (as well as other liabilities), and so where the licensing of software presents particular
data protection and cybersecurity concerns, customers may wish to add indemnities and other provisions into their
software licences to pass this exposure down to the supplier, and to carve such indemnities and other provisions
out of certain exclusions or limitations of liability (such as any liability cap which is otherwise agreed). However,
this will likely be resisted in practice by the supplier (particularly in the case of standard software licensing).
For further discussion on this topic in general, see Practice note, Main issues in systems integration contracts:
Indemnities.

Termination and remedies

Termination provisions vary according to the nature of the software that is licensed.

Package software for consumer use

A supplier of package software often reserves the right to terminate for breach or material breach, although the
right is only likely to be exercised in practice if the customer is found in possession of unauthorised copies of the
program. In the case of shrink-wrap software, the customer is normally entitled to return the software if they are
unwilling to accept the licence terms on offer. (The wording on a Microsoft licence is "If you do not agree to the
terms of this [End User License Agreement], we are unwilling to license the software product to you", followed
by instructions for the return of the software.) For click-wrap and web-wrap software, the user is usually told not
to download or install, and may be prevented from downloading and installing, the software if it is unwilling to
accept the applicable licence terms.

© 2021 Thomson Reuters. All rights reserved. 26

Main issues in software licensing and maintenance contracts, Practical Law UK Practice...

For a more detailed discussion of termination in a consumer context, see Practice notes, Consumer contracts and
Supply of digital content to consumers: changes made by the Consumer Rights Act 2015.

Package software for business use

Licences of more expensive business software normally contain provisions allowing either party to terminate
for material breach or insolvency, however the effectiveness of the supplier's termination right for the customer's
insolvency may now be compromised (see Termination for insolvency). In addition, the supplier may have express
rights to terminate for non-payment of licence fees and breach of the licence itself.

Where payment for the software is made on a recurring basis, the customer may also want a right to terminate at
will, on notice to the supplier. The supplier in turn will want the customer to be committed for as long as possible.

With the advent of the GDPR, UK GDPR, DPA 2018 and NIS Regulations, the customer may also want rights
to terminate for significant data protection and cybersecurity issues, but this will depend on the particular
circumstances and bargaining strengths of the parties.

Bespoke software
In contracts for the development of software (or licences which contain a bespoke element) the right of
termination is critical (see Practice note, Main issues in systems integration contracts).

Termination for insolvency

With effect from 26 June 2020, it has become difficult or impossible for a supplier to terminate many contracts
for goods and services on grounds that the customer has entered a formal corporate insolvency procedure (or even
on other, pre-existing grounds), under the Corporate Insolvency and Governance Act 2020 (CIGA 2020). For full
information on these changes, see Practice note, Contracts: termination, in particular the following sections:

• Restricting termination of supply contracts on corporate customer's insolvency.

• Restrictions on terminating supply contracts in insolvency proceedings.

CIGA 2020 introduces a new section 233B into the Insolvency Act 1986 (IA 1986), which broadens the existing
protection, contained in sections 233 and 233A of the IA 1986, aimed at protecting an entity's contracts (as customer)
for the supply of goods and...
*** Start Section
... to all contracts for the supply of goods and services (subject only to certain regulated exceptions) and is triggered
if a company enters into any of the collective corporate insolvency procedures under the IA 1986 (including the Part
A1 moratorium) or into a Part 26A restructuring plan under the Companies Act 2006.

While neither CIGA 2020 nor the IA 1986 go on to define what is meant by a contract for the supply of goods and
services, the explanatory notes (at paragraph 99) state, in relation to the debts that the company must continue to
pay during a Part A1 moratorium (which include goods or services supplied during the moratorium), that "services
supplied during the moratorium" include the continued provision and usage of property owned by another, such as a
software licence. Based on this, it seems likely that software licences will be covered by section 233B. For more
information, see Practice note, Restrictions on terminating supply contracts in insolvency proceedings: What is a
contract for the supply of goods and services?.

Accordingly, it has become difficult or impossible for a supplier to terminate many contracts for the supply of goods
or (non-financial) services on the grounds that the customer has entered a formal corporate insolvency procedure.

© 2021 Thomson Reuters. All rights reserved. 27

Main issues in software licensing and maintenance contracts, Practical Law UK Practice...

Even where a supplier is contractually entitled to terminate the contract or supply for a completely different reason,
if that right arose because of an event occurring before the insolvency process, the supplier cannot exercise that
termination right while the customer is in the insolvency process.

As a result, licensors of software may start changing the way they approach termination rights in software
licences in future. Options include:

• Broadening the scope of their termination provisions by granting the licensor a termination right on grounds
of the customer's financial difficulties, before any step is taken towards an insolvency procedure.

• For high-value software:

• undertaking thorough credit risk due diligence on customers before entering into licence
commitments with them, and (where necessary) seeking parent company guarantees or other forms of
security from the customer;

• asking the customer to provide financial information, on a rolling, periodic basis (for example,
management accounts) so the supplier can assess any deterioration in the solvency of the company in
good time before any formal insolvency procedure is triggered; and

• asking for payments in advance under the contract, or, alternatively, minimising any periods where the
supplier is providing services in advance of payment (for example, when developing software).

Dispute resolution

As in the case of termination provisions, the treatment of dispute resolution will vary according to the type of
licence. Licences of package software, whether consumer or business, rarely contain detailed dispute resolution
clauses. Provisions will normally be limited to a reference to the national or state courts that are to have jurisdiction.
However, the ECJ has held a clause in a consumer contract to be unfair which obliged the consumer to submit to
the exclusive jurisdiction of a national court other than that of the consumer's country of domicile (Oceano Grupo
Editorial SA v Quintero (Case C-240/98) EU:C:2000:346), see Continuing relevance of EU case law.

The customer should check whether the supplier has signed up to the Code of Practice of the Business Application
Software Developers Association (see BASDA: Business Application Software Developers Association) which
provides that suppliers should offer a clearly defined escalation procedure for dispute resolution.

For a detailed discussion of dispute resolution provisions, see Practice note, Main issues in systems integration
contracts.

For a more detailed discussion of dispute resolution in a consumer context, see Practice note, Consumer contracts:
common terms and conditions.

Maintenance and support

Software requires maintenance and support for various reasons. First, as is often stated, no software is without
errors: fixes are often necessary. Second, much commercial software is subject to continuous development in
order to introduce new features or to adapt to changes in the software or hardware environment. Third, operators
and users who are unfamiliar with the operation of the software may need technical or practical assistance. For

© 2021 Thomson Reuters. All rights reserved. 28

Main issues in software licensing and maintenance contracts, Practical Law UK Practice...

this reason, suppliers often offer maintenance and support agreements, usually in return for an annual fee.
Maintenance and support agreements are often bundled with other agreements. The scope of maintenance and
support agreements varies widely.

Definition and scope of maintenance services

Software maintenance and support agreements can cover a wide range of different maintenance and support
services. It is necessary for the customer to give careful consideration to the type of services that it requires and
ensure that these are adequately documented. Light touch supplier standard form service descriptions are often
put forward by suppliers, which benefit the supplier by giving it wriggle room in respect of its obligations but
do not provide the customer with a great deal of certainty. A detailed definition of the services is to the benefit of
both parties. It will provide the customer with comfort that it will receive the services it is expecting and enable the
supplier to charge an appropriate fee and to ensure, at the outset, that it has the resources to provide the services
that the customer is expecting. In particular, the parties should consider the following:

• Is it clear what constitutes a "fault" or "defect" in the software so as to give rise to the supplier's obligation
to fix it, and what happens if there is a disagreement as to whether a particular item is a fault or defect?
Faults or defects may be defined by a failure of the software to conform (substantially) to its published
specification or other documents.

• Are faults or defects categorised in a reasonable manner and are the supplier's obligations appropriate
to each of the categories? Thus, while it might be acceptable for the supplier to leave minor interface
irritations to be fixed (if at all) in a regular annual update, the customer will expect the supplier to fix
major faults or defects, such as a failure in important functionality, within a matter of hours. The supplier
for their part will wish to agree achievable obligations (such as response times) and to avoid accepting
an absolute obligation to fix all faults or defects as there may be faults or defects that are incapable of
remedy (or which do not justify the time and expense required). As noted earlier, faults or defects are
usually also subject to a warranty given in the software licence (or which may be given in a software
development agreement) under which the supplier may be required to fix them (see Warranties), and
any maintenance and support agreement should reflect this (for example, it may only start at the end of the
warranty period; see also Fees).

• How are the services to be delivered? Nowadays, the majority of support is provided by supplier staff
remotely from supplier locations (often overseas). The customer should consider whether it is comfortable
with this, both in terms of the adequacy of services provided in this way and the risks that it may present,
as well as any dependencies on the customer. For example, the customer may prefer for certain issues to be
dealt with on site and should ensure that the supplier is only given access to the customer IT systems and
data that it requires. The customer may also be required to facilitate remote access to its IT systems in order
to receive the services.

• Does the customer require any support to be provided on site and, if so, will it be required at all of the
customer's sites? If so, the supplier should consider whether it has the resources to provide the services
to all such sites (particularly if they are overseas) and the customer should consider the requirements that
it will apply to the supplier's staff when on site (such as policies in respect of health and safety, use of
customer IT systems and access to customer data).

• Is the support service for technical queries only, or does it include an element of customer assistance (for
example, by means of a service desk)? Support is often categorised in different levels, with level 1 (customer

© 2021 Thomson Reuters. All rights reserved. 29

Main issues in software licensing and maintenance contracts, Practical Law UK Practice...

assistance) being essentially non-technical in nature ("Is the machine turned on?"; "Is there a reported
network fault?"), while higher levels require detailed technical knowledge.

• During what hours is the service available? If support is to be provided to different customer teams or
locations, do these vary by team or location?

• If not all users are English speakers, in what languages is the service available?

• What level of upgrade (if any) is included in the service? Is it restricted to fixing faults or defects only, or are
increases in functionality or new versions also included (see Scope of the software)?

• Are other customer group companies or external service providers to benefit from the services? The
customer should ensure that it is clear that services will be provided to all other companies in its group and
any external service providers (such as outsourced service providers) who may need them, and consider the
contractual implications of this. For example, should those parties be able to enforce the maintenance and
support agreement directly against the supplier? (See Practice notes, Contracts: structure and terms of
commercial contracts: Privity and Contracts: privity and third party rights and obligations.)

Fees

There are a number of payment issues to consider:

• Is there a fixed charge or do the charges fluctuate (for example, according to the number of hours or days of
support the customer requires the supplier to provide in any particular week, month or quarter)? If fixed,
are the charges subject to any assumptions or limits (for example, number of help desk calls received or
tickets raised)?

• Are the charges subject to indexation or other variation?

• Will the customer be charged separately for any expenses incurred by the supplier in providing the services
or are they covered by the fees?

• Does the maintenance or support agreement require the customer to pay for fixes to which they are already
entitled under a software licence or development agreement (for example, under any warranty given in
that licence or agreement)? Where the customer is already entitled to such fixes, see Practice note, Main
issues in systems integration contracts and, in particular, Maintenance and support.

Software versions supported

The customer should establish how many concurrent versions of the software will be supported by the supplier.
If the supplier is not obliged to continue to support old versions, the customer will have to buy any new version
that is issued if they want to continue to enjoy support. With complex programs, this could involve the customer
in expenditure on training, new interfaces, installation and configuration, and other items, as well as the extra
licence fees. For its part, the supplier does not usually want to invest the time and expense in supporting out-of-
date versions of the software (at least on its normal maintenance or support terms) other than for a reasonable
transitional period.

Service levels

© 2021 Thomson Reuters. All rights reserved. 30

Main issues in software licensing and maintenance contracts, Practical Law UK Practice...

The customer should try to ensure that the supplier commits to service levels for the support service, for example,
minimum response times (on the phone, electronically and on site) and minimum "times to fix". Failure to adhere
to agreed service levels should result in the supplier having to compensate the customer normally in the form
of "service credits" which may be stated to be the customer's exclusive remedy for such failure. There may be
circumstances (such as where the software is used in operations of the customer's business which are time-critical)
where the supplier will find it hard to resist the imposition of service levels. In those cases, the supplier should
ensure that the levels imposed are clear and reasonable. The customer should ensure that the service levels are
specific and measurable and any qualifications are appropriate (it is not unusual for service levels to be subject
to certain carve outs so that they, for example, do not run during pre-agreed IT system maintenance windows).
Otherwise, it may not be clear when the supplier has failed to meet the service levels and the customer is entitled
to a price adjustment.

It is important that the parties understand what a "service credit" is being used for. This is not a liquidated damage
or a financial penalty. A "service credit" is a price adjustment representing the lower level of service that a supplier
has provided and so it should not represent any form of "loss" or "damage" at all. This means that it should not
be included in any sort of financial loss cap and it also means that customers should not expect a service credit to
represent any form of exclusive remedy. If the customer has suffered loss or damage as a result of the lesser level of
service provided, then it should remain free to seek its normal contractual remedies for breach of contract.

For further issues to consider, see Practice note, Main issues in systems integration contracts and, in particular,
Maintenance and support.

Term and termination

The agreement should set out the length of the term and the parties' rights to terminate (including for breach and
insolvency, though note what is said in Termination for insolvency). Suppliers usually want to commit customers
to contracts for a long initial fixed term. In some cases, the customer may also want a long fixed term (where, for
example, support for business-critical software is not easily obtained elsewhere). In other cases, the customer may
want the freedom to extricate itself from the agreement as quickly as possible (the supplier's right to increase
the fees should be considered in this context). The supplier is unlikely to want to give up a right to terminate at will
(that is, other than for breach or insolvency) in longer term agreements as a time may come when it is no longer
viable to support the software. This is linked to the question of source code and escrow, in that a customer whose
maintenance or support agreement can be terminated unilaterally by the supplier will have a reduced chance of
obtaining maintenance elsewhere if the source code is not available (see Source code and Escrow agreement).

See also, Termination and remedies.

Warranties

The customer should ensure that the supplier provides warranties as to the quality of the services. Commonly,
suppliers warrant that the services will be provided with reasonable skill and care, but customers should consider
whether further warranties are appropriate (such as to the security of remote access solutions where support is
provided remotely or training given to supplier staff that access customer IT systems and data to provide comfort
on cybersecurity and data protection concerns, see Confidentiality and data protection).

Limitation of liability

© 2021 Thomson Reuters. All rights reserved. 31

Main issues in software licensing and maintenance contracts, Practical Law UK Practice...

The supplier should consider terms which limit its liability to the customer. Where software is critical to the
operation of the business of the customer, the losses which the customer might suffer if the supplier fails to provide
an adequate maintenance or support service may be significant and may far exceed the fees paid for the service.
For that reason, the supplier should seek to limit its liability to the customer. However, such terms need to be
carefully drafted so as to ensure they comply with the relevant legislation. It will usually be hard for the customer
to argue against the supplier imposing some form of liability limitation, but it is worth considering what type of
losses the customer might wish to recover in the event of the supplier's breach and to specify that those losses will
be recoverable (for example, paid under the agreement, the cost of obtaining maintenance or support elsewhere,
and lost management time). In appropriate cases, the customer should impose an obligation on the supplier to
maintain an insurance policy to cover the supplier's liabilities under the agreement. All the issues discussed in
relation to software licences which apply to the provision of services will apply equally to a software maintenance
or support agreement (see Limitation of liability). However, the following points, in particular, should be noted:

• Issues relating to liability are often not considered as carefully in the context of maintenance and support as
they are in the context of the supply of software. However, where the software is critical to the customer's
business, liability for failure to supply the services, or for the supply of defective services, can be significant,
and consequently careful consideration should be given by the parties to the relevant contractual terms.

• The implied terms relating to goods under the SGA and the SGSA do not apply and so sections 6 and 7 of
UCTA do not need to be considered. However, there are implied terms under the SGSA in respect of services,
for example, section 13 implies a term in a contract for the supply of services that the supplier will carry
out the services with reasonable care and skill. Typically, suppliers provide an express warranty that the
services will be provided with "reasonable skill and care" and exclude all other terms that may be implied by
law.

• The limitation of liability for damage to property caused by negligence, which is typically limited to a level
that reflects the supplier's insurance cover for this type of damage, may take on greater significance in a
software maintenance and support agreement than in a software licence if, in providing the services,
the risk of causing damage to the customer's property increases (for example, because the supplier's staff
will spend time on the customer's premises).

Intellectual property licence and infringement of third-party rights

Although the issue is not as significant as in a software licence, the customer should seek a suitable licence to
use materials provided by the supplier in the course of the services and protection for any losses it suffers if any
materials provided by the supplier turn out to infringe the intellectual property rights of third parties. This might
include new releases or new versions of the software (to the extent not covered by the software licence) or any
other software, documents, tools or other materials provided by the supplier during the course of the maintenance
and support agreement.

Confidentiality and data protection

Mutual confidentiality provisions are common in maintenance and support agreements. The supplier will usually
have some access to customer IT systems and data and so, potentially, information about its business (for example,
its products, processes, customers or staff) when providing support to the customer that the customer will want to
protect. The supplier will generally make available less of its own business information, but mutual provisions will
protect any such information that is made available (such as in respect of its methodologies or other know-how).

© 2021 Thomson Reuters. All rights reserved. 32

Main issues in software licensing and maintenance contracts, Practical Law UK Practice...

Data protection and cybersecurity provisions are also increasingly common with the advent of the GDPR, UK GDPR,
DPA 2018 and NIS Regulations and customers' potentially significant exposure under them. For examples and
discussion of data protection and cybersecurity issues in a support context, see Data protection and cybersecurity.

Dispute resolution

In a software maintenance and support arrangement, there are a number of areas in which disagreements may
arise, for example:

• Does a particular defect constitute a "fault" as defined in the agreement?

• Have the service levels been met?

• Have the service credits been properly calculated?

It can save both parties time and money if they have an obligation to attempt to resolve disputes internally before
being permitted to resort to litigation. It is important to ensure that the representatives of both parties have the
authority and expertise necessary to agree a resolution, and that the resolution periods are not too long, for any
internal dispute resolution process to be effective. In the case of technical disputes, the use of expert determination
should also be considered before permitting the parties to resort to litigation. Finally, an expedited dispute resolution
process for major "faults" may be appropriate to protect the customer from lengthy periods without business critical
functionality.

Assignment

From the customer's perspective, it would be prudent to ensure that any rights to assign contained within a
maintenance and support agreement at least mirror any such rights contained within the relevant software
licence or development agreement. This should enable the customer to assign the agreements together, for
example as part of a business sale or corporate re-organisation.

Third-party maintenance providers

The considerations that apply to software licence agreements also broadly apply to maintenance and support
agreements provided by the software owner. However, it is increasingly common for software maintenance
and support to be provided by third parties who may be in a position to provide better resources or better rates
for services than the software owner. In those cases, the parties will be concerned to ensure that the third-party
maintenance provider does in fact have the rights to maintain the software, since modification or even storage or
transmission of software without consent will infringe the copyright in the software and it is unlikely that there
are any fair dealing or "right of repair" exceptions that would apply in this situation (Mars UK Ltd v Teknowledge
Ltd [2000] ECDR 99 (For a discussion of the intellectual property rights affecting software, see Practice note,
Legal protection of software.)

The third-party maintenance provider's rights can derive either:

• From an agreement between the software owner and the third-party maintenance provider (for example,
an agreement under which the software owner appoints the third-party maintenance provider as an
"approved maintenance provider").

• Via the customer, from the licence between the software owner and the customer.

© 2021 Thomson Reuters. All rights reserved. 33

Main issues in software licensing and maintenance contracts, Practical Law UK Practice...

Reliance on the first route is often preferable as it is unlikely that the customer's licence of the software will
grant all of the permissions needed by a third-party maintenance provider. Most licences of package software
prohibit modification of the software and access to source code (see Permitted use) and usually exclude the right
to correct errors (see Acts specifically permitted). Even if the licence does permit these acts, the parties would need
to ensure that those rights could be sub-licensed to the third-party maintenance provider and that access to source
code and documents was available (see Source code). Where the supplier is a third-party maintenance provider, the
maintenance or support agreement will need to reflect the fact that the supplier of the maintenance and support
services is not the owner of the software. For example, the supplier of the maintenance and support services will
want to make it clear that any intellectual property warranty or indemnity covers acts done by itself only; it will
not be willing to indemnify the customer against infringements inherent in the original software. Also, where the
customer is relying on the third-party maintenance provider for the licence to repair, the customer will want the
third-party maintenance provider to warrant that it has the rights to support the software.

Other IT contracts

Software licences and maintenance and support agreements may be entered into in association with other types
of IT contracts, or as part of a larger transaction.

Hardware supply contracts

A contract which is solely for the purchase of hardware will normally fall within the terms of the sale of goods
legislation and be concluded on the supplier's standard terms, subject to such amendments as the customer may
be able achieve through the exercise of its negotiating power. Some aspects of that legislation are considered above
in the context of software (see Limitation of liability), but the issues relating to the purchase of computer hardware
are generally the same as those that arise in relation to the purchase of other goods or equipment. They concern the
extent of the manufacturer's warranties, responsibility for delivery and installation, conformance with description
and so on (see Practice note, Supply contracts: overview).

A customer should, however, remember that contracts which are apparently for the purchase of hardware normally
include some software (such as operating software or utility software). Indeed, PCs purchased under a corporate
contract are often bundled not only with operating software but also with suites of applications, such as Microsoft
Office. Although this software is included in the hardware price, it is not sold outright to the customer. Instead its
use is licensed subject to the terms of a standard software licence, a document that is usually to be found within
the collection of manuals and leaflets delivered with the PC or which appear when the applications are first loaded.
A review of the terms of the hardware purchase is incomplete unless it also includes a review of the terms on which
associated software is licensed to the customer, and any audit of the software used by the customer should include
this bundled software as well as software that has been bought separately.

Systems integration agreements

Similarly, all of the issues raised above concerning software licences and maintenance and support agreements
apply equally to software bought as part of a systems integration arrangement.

The term "systems integration agreement" is used to describe a contract for the acquisition, development and
integration of hardware or software which is necessary to produce (in conjunction with the customer's business
data and existing hardware and software) an entire computer system that will produce the results which the
customer wants.

© 2021 Thomson Reuters. All rights reserved. 34

Main issues in software licensing and maintenance contracts, Practical Law UK Practice...

A systems integration agreement may be turnkey in its nature or may involve the integration of components which
have been purchased separately by the customer. It often includes an element of software development, but could
involve the provision of a number of software packages without any software development at all.

For further information on systems integration agreements, see Practice note, Main issues in systems integration
contracts.

Brexit

On 31 January 2020 (exit day), the UK left the EU and the UK-EU withdrawal agreement entered into force.
Following the end of the transition period at 11.00 pm UK time on 31 December 2020, retained EU law was created,
the remaining withdrawal agreement provisions came into operation, and the future relationship agreements
(including the UK-EU trade and co-operation agreement) started to apply on a provisional basis. This resource
has been reviewed and reflects the position from the end of the transition period.

For general information on the withdrawal agreement, future relationship agreements, and the operation of UK
law following the end of the transition period, see UK legal change post-transition and UK-EU agreements toolkit
and Practical Law’s Brexit page.

For more information on the impact of Brexit on the specific practice areas covered by this resource, see Practice
notes:

• Brexit: implications for intellectual property rights.

• Brexit: effect on commercial contracts.

• Brexit: implications for cybersecurity in the UK.

• Brexit: implications for data protection.

Continuing relevance of EU case law

All EU case law that was current at the end of the transition period was retained as part of UK law (see Practice note,
European Union (Withdrawal) Act 2018: legislating for Brexit: Retained case law). However, the UK courts may
depart from that case law, subject to certain limitations set out in the UK-EU withdrawal agreement (see Practice
note, Interpretation of retained EU law and UK-EU withdrawal agreement).

The CJEU continues to have some relevance in UK law on an ongoing basis, although CJEU principles and decisions
made after the end of the transition period are not binding on UK courts or tribunals; see Practice note, UK law
after end of post-Brexit transition period: overview: CJEU jurisdiction and case law after end of transition period.

END OF DOCUMENT

© 2021 Thomson Reuters. All rights reserved. 35