Software License Agreement

Some notes from Practical Law UK.

Computer Software

“[a] set of instructions capable, when incorporated in a machine readable medium, of causing a machine having information processing capabilities to indicate, perform or achieve a particular function, task or result.”

Word Intellectual Property Organisation

“a computer program shall be protected if it is original in the sense that it is the author’s own intellectual creation. No other criteria shall be applied to determine its eligibility for protection.”

Software Directive


  • Object Code
  • Source Code
  • Graphical User Interface (GUI)
  • Design Documents relating to the computer program, such as flow charts, graphs and functional or technical specifications
  • On-screen text

Data Protection Legislation

the UK Data Protection Legislation and any other European Union legislation relating to personal data and all other legislation and regulatory requirements in force from time to time which apply to a party relating to the use of personal data (including, without limitation, the privacy of electronic communications);

Both parties will comply with all applicable requirements of the Data Protection Legislation.

The Customer will ensure that it has all necessary appropriate consents and notices in place to enable lawful transfer or storage of any personal data.

Intellectual Property Rights

Patents, utility models, rights to inventions, copyright and related rights, trade marks and service marks, trade names and domain names, rights in get-up, goodwill and the right to sue for passing off or unfair competition, rights in designs, rights in computer software, database rights, rights to preserve the confidentiality of information (including know-how and trade secrets) and any other intellectual property rights, including all applications for (and rights to apply for and be granted), renewals or extensions of, and rights to claim priority from, such rights and all similar or equivalent rights or forms of protection which subsist or will subsist, now or in the future, in any part of the world.

Standard Support Service

Standard Support House 8.00 am to 6.00 pm Monday to Friday, except on days which are bank holidays in England.

Software Support

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 he wants to continue to enjoy support.

Service Levels

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 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”.

Maintenance Releases

The Supplier shall from time to time make Maintenance Releases available to the Customer without charge, and

if the Customers fails to [acquire and install OR make arrangements for the installation of] a Maintenance release within [one month] of the Supplier’s notifying the Customer that such Maintenance Release is available for installation, the Supplier may terminate this agreement by giving [one month’s] written notice to the Customer.

In relation to New Versions: If the Supplier releases a New Version, the Customer shall, within seven days of delivery, test whether the New Version operates without any impairment of functionality or facilities relative to the previous version (Acceptance Testing).

  • 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?
  • Is the support service for technical queries only, or does it include an element of customer assistance?
  • During what hours is the service available?
  • If not all customers are English speakers, in what languages is the service available?
  • What level of upgrade is included in the service?
  • Is the service restricted to fixing faults only, or are increases in functionality also included?


Most large software programs are subject to a continuous cycle of development and improvement, requiring frequent changes to the source code.

As long as the customer is obtaining maintenance services from the developer or a third party it will not need access to the source code. What is essential for the customer’s protection is that he should have access to an up-do-date copy of the source code if the developer is unwilling or unable to support the software any longer, but not necessarily otherwise.

Software requires support for various reasons. 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.

The Customers Responsibilities

The Customer shall maintain the minimum software requirements set by the Supplier for the software to operate.

Limits of Liability

The Supplier shall not in any circumstances have any liability for any losses or damages which may be suffered by the Customer (or any person claiming under or through the Customer), whether the same are suffered directly or indirectly or are immediate or consequential, and whether the same arise in contract, tort (including negligence) or otherwise howsoever, which fall within any of the following categories:

  1. special damage, even though the Supplier was aware of the circumstances in which such special damage could arise;
  2. loss of profits;
  3. loss of anticipated savings;
  4. loss of business opportunity;
  5. loss of or goodwill;
  6. loss of, or damage to (including corruption of), data;

Where the software costs £10,000, a clause which limits the supplier’s liability for the 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.

Exclude liability for indirect or consequential losses, and limited its liability for direct losses to the price paid by the purchaser.

Assignment and Subcontracting

The Customer shall not assign, novate, charge, subcontract or deal in any other manner with any or all of its rights and obligations under this agreement without the prior written consent of the Supplier (such consent not to be unreasonably withheld or delayed).

The Supplier may at any time assign, novate, charge, subcontract or deal in any other manner with any or all of its rights and obligations under this agreement, provided it gives written notice to the Customer.

Each party confirms it is acting on its own behalf and not for the benefit of any other person.


Supply of the Services by the Supplier to the Customer shall commence on the date of this agreement and, subject to termination in accordance with the provisions of this agreement, shall continue for a fixed term of [NUMBER] years. After expiry of the fixed term, the supply of the Services shall (subject to any such termination) continue under this agreement from year to year until terminated by either the Supplier or the Customer on [180] days’ prior written notice to the other to expire at the end of the current [calendar year OR Contract Year] of the term.

Whether the term of the license 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.


Without prejudice to any rights that have accrued under this agreement or any of its rights or remedies, either party may at any time terminate this agreement and/or the Support Services with immediate effect by giving written notice to the other party if:

  1. the other party fails to pay any amount due under this agreement on the due date for payment and remains in default not less than 14 days after being notified in writing to make such payment;
  2. the other party commits a material breach of any term of this agreement (other than failure to pay any amounts due unde this agreement)
  3. the other party repeatedly breaches any of the terms of this agreement in such a manner as to reasonably justify the opinion that its conduct is inconsistent with it having the intention or ability to give effect to the terms of this agreement;

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 practise if the customer is found in possession of unauthorised copies of the program.

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.

Microsoft “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.

Permitted Use

Suppliers will generally only be prepared to grant licenses of package software on non-exclusive terms.

The supplier should also consider whether to restrict the use of the software in certain ways, for example, by reference to:

  • The identity of the customer or a group of users within the customers.
  • The identity of the machine on which the software is loaded.
  • The geographical location of the machine 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 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 license.

The license could include an obligation on the customer to inform the supplier where there is any change in use of the software and a right for the supplier to audit the use of the software.

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.

The following rights are conferred on software licensees:

  1. The right to make a back-up copy of a program if necessary (as opposed to prudent) for its lawful use.


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.

Installation & 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 (and / or configuration services), the fees for doing so may be reflected in the licence fees or dealth with as a one-off charge.


With the sale of package business software there is usually an initial fee, but, unlike consumer software, there will often be a recurrent annual fee as well. That fee may be classified as a licence fee, or a maintenance or upgrade fee, or both.

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.

Open Source Software

The owners of copyright in source code may choose to make it available to third parties as open source software (OSS) subject to certain licence conditions.

OSS licences often impose struct conditions on developers and users who copy, distribute or modify the OSS code. For example, almost all OSS licenses require a user to reproduce the name of the author whenever he distributes the work or incorporates it in a commercial product and, in some circumstances, and OSS licence provide that the resulting software must be made freely available as OSS.

Any distribution of the original OSS be on the same OSS terms as those on which it was provided.

Restrictive OSS licences, other the other hand, go one step further than permissive OSS licenses, imposing licensing restrictions or requirements where the OSS is amended, adapted or combined with any other software (whether proprietary or OSS) to produce a derivative work. While the provisions vary, restrictive OSS licences will (to a certain extent) apply to both the original OSS and any derivative works based upon it. This can be of key concern to organisations when using restrictive OSS alongside their proprietary “closed-source” software, as proprietary software could unintentionally be made subject to the OSS licence.

The Decreasing Prevalence of the GPL

These are FSF licences with the more zealous restrictive “copyleft” terms. In 2010, GPL-licensed OSS accounted for over half the OSS world. By 2014, this figure had dropped to 47%, with GPL version 2 (GPLv2) alone accounting for just over 27%. However, in mid-2017, the five GPL licenses together account for almost 32%; 18% of which is attributable to GPL v2.

There is an emergence of an increasing trend away from restrictive “copyleft” licences towards permissive licences. This notion is also expressly supported by some of the public comments by those responsible for Android, one of the most prominent OSS projects in the commercialised context.

“We are sometimes asked why Apache License 2.0 is the preferred license for Android .. Android is about freedom and choice. The purpose of Android is to promote openness in the mobile world … while we encourage everyone to make devices that are open and modifiable … we don’t believe it is our place to force them to do so. LGPL libraries would often force them to do so … and given the difficulties with complying with LGPL … it is most prudent to simply not use LGPL libraries if we can avoid it .. We do feel strongly on this topic, even to the point where we’ve gone out of our way to make sure as much code as possible is Apache License 2.0 …”

The Android Project

Section 2(b) adds yet further complexity to issue of how the rules on copying and derivative works apply to the technology. This is largely because of the use of the word “contains”, which is open to widely varying interpretations: if A (your software) is combined to B (the GPL program), when should they be regarded as together forming a new program that “contains” B? And when should the combination be regarded as being of separate and independent works that do not “contain” B?

The FSF, Mr Torvalds and other professionals from the IT industry have all formed their own individual views of the answer. The view of the FSF is that what constitutes combining two pieces of code into one program depends both on the mechanism of communication (how intimately the two are connected) and the semantics of the communication (what kinds of information are interchanged).

Where applications make system calls on the kernel, certainly through an API and generally otherwise, there is little debate, and there is general acceptance that section 2(b) does not apply.