A EULA is a type of legally binding contract between a software provider and an end-user setting out the terms of access to the software. The end-user can be an individual, a organisation, or individuals within organisations – depending on the software provider’s requirements. By clearly defining the scope of use, restrictions, and obligations, a EULA helps ensure that the software is used in a manner that aligns with the software provider’s intentions and legal requirements.
EULAs can form part of a suite of legal documentation put in place by a software provider to protect its intellectual property, limit its liability and ensure that all access to its software is tightly controlled. Alternatively, EULAs can be stand-alone and become the key agreement used by software providers. It all depends on the use case and how the software is sold, deployed and utilised.
For that reason, the different ways in which businesses use EULAs can get confused. It is not always necessary to have one and, in some circumstances, solely relying on a EULA could be the wrong legal approach to the deployment of software. In this blog, we will explore why EULAs (and any other type of software agreement) matter, what the different types of EULA are, how they can be best used and some of the related pitfalls.
Protecting computer software
Computer programs are a type of “work” that is usually protected by intellectual property rights (in particular, copyright) under the Copyright, Designs and Patents Act 1988. A computer program will form an intrinsic part of licensed computer software.
Both downloading software onto another device permanently (e.g. by buying a physical copy of a computer game and installing it) and/or accessing it online temporarily is a form of “copying”. This is because, in both scenarios copies of all or part of the software’s code will be stored on the hard drive or RAM of the user’s device.
Copying and therefore using software without a “licence” is copyright infringement. Copyright infringement, unless you have a defence (not very likely in the context of using computer software without permission), is unlawful.
Therefore, users of a software require a licence to lawfully access it.
A software licence does not have to be, but usually is, contained in a legally binding contract. This is where a EULA comes in. A EULA will contain the licence alongside the other terms and conditions attached to the grant of the licence. For these terms to be enforceable by the software provider against the user, a contract is required which is again why EULAs and other types of software agreements are used in practice.
Importance of EULA
When a EULA is required by the software provider’s circumstances, it is important. A EULA can be the source of, or a key addition to, the legal protection of the relevant software. It can also contain clear limitations of liability. For example, most EULAs also include a warranty disclaimer, which can limit the software provider’s liability for any losses incurred by the end user. More commercially, a well-drafted EULA establishes clear expectations for end users, detailing what they can and cannot do with the software. This includes restrictions on usage, such as prohibiting the use of the software for commercial purposes or on multiple devices.
By setting these boundaries, a EULA not only protects the interests of the software vendor but also provides clarity and security for the end users.
What are the typical terms found in a EULA?
The typical terms found in a EULA largely depend on two factors: (1) whether the EULA is used in conjunction with other software agreements (discussed below) or (2) whether the EULA is ‘stand-alone’.
Standalone EULAs
Stand-alone EULAs are more comprehensive because they should mirror all the terms a software provider would want to impose on its customers, such as:
Term and termination
How long the licence will go on for, and the right of either party to terminate it. For example, if an individual has taken out a subscription a SaaS product, that may be renewable every month.
Grant of the licence/restrictions
It would be best practice to ensure that the grant of the licence is expressly set out in the EULA, to ensure that there is no ambiguity.
A EULA would also contain certain restrictions or positive obligations that end-users must follow. For example, A EULA may contain reference to an Acceptable Use Policy or set out within it how it can be used. A common restriction is over the user’s right to use the software on multiple devices.
By adhering to the terms of the EULA, end users help protect the software vendor’s intellectual property rights and ensure that they can continue to use the software without interruption. Compliance with the EULA is crucial for maintaining the integrity and security of the software.
Warranties/indemnities
An appropriately drafted EULA would likely state that the software is provided “as is” so as to disclaim liability for any of the end-user’s assumptions outside the contractual terms.
A standalone EULA may also contain wide indemnities to protect the software provider. Indemnities can often be heavily negotiated or, in the consumer context, limited by consumer law. Careful use of indemnities is key.
Ownership of content generated by the end user
It is becoming more common for EULAs to expressly state who owns the content that the software generates. For example, where users want to use an image generating software or AI tool, that can become quite important.
Limitation of liability
The limitation of liability is a critical component of a EULA. It outlines the maximum extent of the software vendor’s liability in the event of a dispute or legal action. The limitation of liability can vary depending on the context, but it is typically limited to the amount paid by the end user for the software. Additionally, a EULA may include provisions that limit the liability of the software vendor for incidental or consequential damages, such as loss of business or revenue.
For example, if an end user pays £1000 for a software license, the software vendor’s liability may be limited to £1000. However, it is also important to note that limitations of liability may not always be enforceable, or they may have unintended consequences. In a B2C context, it may not be lawful for a business to cap its liability in a certain way.
Boilerplate
A standalone EULA should also incorporate legal boilerplate to ensure that the use of the EULA is more certain.
For example, at a minimum we would expect to see a governing law and jurisdiction clause within a EULA – but there are quite a few more types of boilerplate clauses that can become extremely important, especially if there is a dispute in the future.
Integrated EULAs
When EULAs are used in conjunction with a separate commercial agreement (i.e. between the software provider and its customer), the EULA will normally be a lot lighter because the primary obligations are between the software provider and the customer. In using a EULA in this context, the software provider will mostly be looking to bind individual users to the EULA to achieve greater control over their intellectual property rights.
Another common scenario is where a software ‘reseller’ is involved. A reseller of a software product will normally have the right to integrate a software product owned by a third party in its own products. The third-party software provider will not have any direct relationship with the end customer (which could be a consumer or a business) and therefore using a EULA is again useful to control intellectual property rights.
In a B2B context, the reseller scenario is usually where we would encounter a EULA – binding individual users of a single company is not practical for a number of reasons and both the software provider and the customer will want to avoid employees being bound to contractual terms. A more common way to control the use of the intellectual property within software is to place an obligation on the customer to control its employees and, if possible, remain liable for their conduct. This addresses many of the issues surrounding employees in such a context.
Standalone EULAs can be more common in B2C contexts, for example, where consumers download computer games online. The software provider will want to ensure that it has an easy to access contract that users must accept before download, where formal “signed off” terms would not be appropriate.
Finally, where relevant, It is also important to ensure that browse-wrap EULAs comply with specific platform rules, especially when distributing software through platforms like the Apple App Store or Google Play.
Different kinds of EULA
There are three main kinds of EULA: click-wrap EULA, browse-wrap EULA and shrink-wrap EULA.
Shrink-wrap EULAs refer to a scenario where license terms are printed out and attached to a box (which the user will have the opportunity to read before unwrapping the plastic – hence shrink-wrap) or in the modern world visible when the user runs the install executable for the software.
The different kinds reflect how EULAs are used in practice – they do not in themselves hold a different status or legal significance. The way in which EULAs are deployed has bearing on the basic law of contract.
A quick reminder – contract law in England requires that for a contract to be binding there must be (a) offer, (b) acceptance, (c) consideration, (d) capacity and (e) intention to create legal relations.
EULAs will not automatically be binding legal documents and below we explore the potential reasons why.
1. Click-wrap EULA
The first kind of EULA is a click-wrap EULA. This denotes a scenario where the text of the EULA appears in some form (e.g. on a website) prior to purchase or access and the user ‘clicks to accept’ by clicking a box with wording along the lines of ‘I agree’.
The individual user may do so on their own behalf or on behalf of the organisation they are involved with, thereby accepting the terms of the licensed application.
Assuming that the terms of the contract are made available prior to it becoming binding (i.e. when the software is accessed or when the software is purchased) and the user can read all the terms (and save them for future use) a click-wrap EULA should be an enforceable legal contract. This is because there is evidence to demonstrate acceptance.
2. Browse-wrap EULA
Browse-wrap EULAs are terms that are merely displayed to the user in some form – there is no ‘click to accept’ or other means to clearly demonstrate acceptance by the user (unlike with click-wrap EULAs).
‘Website terms and conditions’ (terms displayed via a link at the footer of a website) are a good example of a browse-wrap EULA. The content on the website (which may be subject to copyright protection) is being displayed and the website owner is free to determine the rights surrounding that access.
It is unlikely that a browse-wrap EULA will be enforceable because there is no method to provide evidence that a user accepted the terms. Conduct (such as continuing to use the software) can denote acceptance and software providers could implement protections to try and enhance their arguments that the user was aware of the terms and that by using the software that counted as acceptance. But it will remain difficult to prove in court and a click-wrap EULA is to be preferred.
Browse-wrap EULAs can maintain a function, however, for example notices posted on a website can be enough to demonstrate that the website owner did not owe a duty of care to its users (by warning them, for example, that the content of the website does not constitute professional advice).
3. Shrink-wrap EULAs
Shrink-wrap EULAs refer to a scenario where licenses are printed out and attached to a box (which the user will have the opportunity to read before unwrapping the plastic – hence shrink-wrap) or in the modern world visible when the user runs the install executable for the software.
Both approaches would solve the issue of ‘acceptance’ (unwrapping or proceeding with the installation) but in most scenarios shrink-wrap terms would not be accessible prior to purchase.If the contract arises at purchase (e.g. between the user and the retailer, if sold at a bricks and mortar shop) the shrink-wrap terms will not be binding because a user would only unwrap or install the software after purchase. If the software is free (such as with open-source licences), then the contract is more likely to be made upon installation/access (by which time the terms are more likely to have been read), but it is by no means a clear-cut situation.
Pitfalls
Aside from the different types of EULAs, there are some issues common to all contracts that frequently crop up when software is licenced under a EULA:
- Consumer law: software can sometimes blend both professional and consumer uses (by design or inadvertently), making it essential to consider consumer rights when drafting a EULA. If your EULA is being entered into with an individual consumer, it may not be enforceable unless the EULA is drafted (at least in part) with a consumer in mind.
- Authority to contract: where the software provider is seeking to enter into a contract with a business, lawyers have to bear in mind that an individual will be accepting the EULA on behalf of the organisation. If that individual does not have the authority to enter into agreements on behalf of the organisation, the EULA may not be enforceable against it.
- Enforcement: where EULAs are deployed on a large scale, the logistics still matter. If a software provider has no way of recording who is using the software and who has accepted what, enforcing rights will be difficult.
At EM Law, we are experts in software licencing and tech law. If you have any questions about EULAs or protecting (or using) software, please do not hesitate to contact Neil Williamson or Colin Lambertus or the firm.
