End user licence agreements and the clauses your software contract needs

You have just finished building an app, or a supplier has handed you a licence agreement to sign before you can install their software. Either way, the same screen appears at first launch: "By clicking Agree, you accept the terms of the End User Licence Agreement." Few documents are agreed to as quickly, and understood as little, as this one.

The End User Licence Agreement, or EULA, is the contract between you as the software developer or supplier (the licensor) and the person or business that uses the software (the end user). It sets out what the user may do with the software and what they cannot do, who owns it, who is liable if it fails, and which law governs the arrangement. It is a separate document from any agreement you strike with an app store, reseller or hosting provider, and it binds each end user directly, including an employee who only got access through their employer's account. Critically, it does not transfer ownership of the software. It grants permission to use it, on terms.

Essential clauses in an end user licence agreement

What the licence actually permits

The licence grant is the heart of the EULA. It is the clause that says the user may use the software, and it defines the boundaries of that permission. Anything the grant does not cover is, by default, something the user has no right to do. The drafting choice that matters most is how precisely the scope of use is described, because every later clause in the agreement builds on it. The grant typically addresses the following:

• Scope of use: the number of users, seats, devices or installations the licence covers, and whether use is limited to internal business purposes.
• Region: where the software may be used, whether within Australia, a defined territory, or worldwide.
• Exclusivity: whether the licence is exclusive to one user or non-exclusive, so the supplier remains free to licence the same software to competitors.
• Transferability: whether the user may pass the licence on to someone else, and on what conditions.
• Duration and revocability: whether the licence is perpetual or runs for a defined term, and whether the supplier can revoke it, and on what grounds.

The trap that causes downstream problems is an undefined grant. A clause that simply says "we grant you a non-exclusive licence to use the software" leaves open whether use includes accessing it through an application programming interface, allowing a contractor to log in, or running it to provide services to the user's own customers. Disputes over what "use" means are common, and they are decided against the drafter. Spell out what the user may do, not just what they may not do.

What the user is barred from doing

The restrictions clause lists the things a user cannot do with the software, even though they hold a licence. It protects the commercial value of the software and sits alongside the copyright that already protects it. In Australia, a computer program is protected as a literary work under s 10 of the Copyright Act 1968 (Cth), which defines a computer program as a set of statements or instructions to be used directly or indirectly in a computer to bring about a certain result. Because the program is a literary work, copying it without permission is already an infringement. The restrictions clause adds contractual remedies on top of that. Typical prohibitions cover the following:

• reproducing or copying the software, except as expressly allowed, such as a single backup copy;
• modifying, adapting or creating derivative works from the software;
• reverse engineering, decompiling or disassembling the software;
• circumventing or disabling any licence, security or copy-protection measures embedded in the software;
• renting, leasing, sub-licensing, reselling or otherwise transferring the software to a third party.

The drafting choice that matters here is proportionality. A restriction drafted for one business model can sink another. A clause that forbids all copying will prevent the user from loading the software onto a second machine or making a backup, which the user will reasonably expect. A clause that bans reverse engineering outright may be unenforceable as an unfair term when the user is a consumer or small business, and it will not stop a user from arguing that the restriction goes further than is needed to protect the supplier's legitimate interests.

Who owns the software, and who owns the data

The intellectual property clause makes clear that the licence does not assign ownership. The developer keeps the copyright in the software and any associated trade marks, patents and know-how, and the user obtains only the rights stated in the grant. The standard drafting move is to state that all rights not expressly granted are reserved, and to record the user's acknowledgement that the licence transfers no ownership interest.

For software that accepts user content, this clause does a second job. It should confirm that users keep ownership of the data, documents or content they upload, and that they grant the supplier a licence to use that content to operate and improve the service. It should also say what happens to user content when the agreement ends, such as whether the supplier must return or delete it after a defined period. This is the clause that is most often missing entirely from templates, and its absence leaves both sides guessing about who owns what when a relationship ends badly.

What each side promises

The warranties and acknowledgements clause records what each party represents to the other at the time the agreement is made. From the developer's side, the important warranties are that the developer owns or has the right to licence the software, that the software does not infringe any third party's intellectual property, and that the software will substantially perform as described in any documentation. These give the user confidence that they are not paying to run software that will later be pulled from the market by an infringement claim.

From the user's side, the clause typically records acknowledgements that they have received the software on the stated terms, that they will use it lawfully and in accordance with the EULA, and that they understand the scope of what they are getting. The trap is the "as is" disclaimer that many templates bolt onto this clause, stating that the software is provided without any warranties at all. In Australia that wording collides directly with the consumer guarantees, which cannot be excluded by contract, as explained next.

Who pays if something goes wrong

The limitation of liability clause is where an Australian EULA most often goes wrong. Its job is to state each party's maximum exposure if the software fails, and it typically caps total liability at the amount paid for the licence and excludes indirect or consequential loss, such as lost profits or lost data. Drafted carefully, it allocates risk between the parties. Drafted carelessly, it is void in part and gives the user stronger rights than the developer intended.

The constraint is the consumer guarantees in the Australian Consumer Law, which is Schedule 2 of the Competition and Consumer Act 2010 (Cth). Under s 64 of the ACL, a term of a contract is void to the extent that it purports to exclude, restrict or modify the application of the consumer guarantees, or any liability for failing to comply with them. The guarantees apply to supplies to consumers, and s 3 of the ACL defines a consumer broadly: someone who pays $100,000 or less for the goods or services, or who acquires goods or services of a kind ordinarily acquired for personal, domestic or household use. Anyone supplying software to consumers is presumed to be dealing with consumers unless proven otherwise. An "as is, no liability whatsoever" EULA for a consumer app is therefore largely ineffective, and telling a consumer they have no rights when the law gives them rights can also amount to a false or misleading representation.

For business users the position is different but still constrained. Under s 64A of the ACL, where goods or services are not of a kind ordinarily acquired for personal, domestic or household use, liability for failure to comply with most guarantees can be limited to the replacement or repair of the goods, or the re-supply of the services, but only if the term is fair and reasonable. Section 64A(4) sets out what a court considers: the relative bargaining strength of the parties, whether the buyer had an inducement to agree, whether they knew of the term, and whether the goods were made to their special order. A blanket cap on all liability will not survive, but a cap that is expressed to operate subject to the consumer guarantees, and that limits liability to repair, replacement or re-supply for business supplies, generally will.

How long the licence lasts and what ends it

The term and termination clause sets out the duration of the licence and the events that bring it to an end. It should cover termination for breach, whether the user gets a chance to fix the breach first, suspension for non-payment, and what happens on termination: the user must stop using the software, delete all copies, and return or destroy any materials supplied. It should also state which clauses survive termination, commonly the intellectual property, confidentiality, limitation of liability and governing law clauses, because those need to keep working after the licence has ended.

The drafting choice that matters is how much discretion the supplier keeps. A clause allowing the supplier to terminate at any time, for convenience, or on notice shorter than the user can reasonably act on will be scrutinised under the unfair contract terms regime in the ACL, which applies to standard form consumer contracts and small business contracts. Under s 23 of the ACL an unfair term in such a contract is void, and since the reforms that took effect in late 2023, proposing or relying on an unfair term is itself a contravention that can attract a pecuniary penalty. A EULA is a classic standard form contract: one party prepares it before any discussion, and the other is effectively required to accept or reject it as presented. Section 27 of the ACL presumes it is standard form unless proven otherwise. Termination rights should therefore be tied to defined events, such as material breach or non-payment, rather than left to the supplier's discretion.

Updates, support and maintenance

Support and maintenance do not come automatically with a software licence. The EULA should state plainly whether updates, security patches, bug fixes and new versions are included in the licence fee or sold separately, because users will assume they are covered. Where updates are included, the clause should address whether installing an update changes the licence terms, and whether older versions continue to be supported, or are retired at end of life. Where support is separate, the agreement should cross-refer to the support terms rather than leaving the level of service implied. The trap is silence: an EULA that says nothing about updates leaves the user arguing that fixes are included and the developer arguing they are not, a dispute that usually ends the relationship either way.

The data the app collects

If the software collects personal information, the EULA needs a data clause that says what is collected, why, and where it is stored. It should also say whether the data is disclosed to third parties, such as analytics or hosting providers, and what happens to it when the agreement ends. The clause must reflect the supplier's actual obligations under the Privacy Act 1988 (Cth) (the Act). The Act applies to organisations, and s 6D of the Act defines a small business as one with annual turnover of $3 million or less in the previous financial year, which is generally exempt from the Act. The exemption does not apply to small businesses that provide health services and hold health information, that disclose personal information for a benefit, service or advantage, or that are contracted service providers for a Commonwealth contract, among other exceptions. Businesses covered by the Act must comply with the Australian Privacy Principles, which govern how personal information is collected, used, disclosed, secured, and made accessible and correctable. A data clause that promises more than the supplier does in practice is itself a liability, because the Australian Consumer Law prohibits misleading conduct about the handling of customer data.

Which laws govern the agreement

The governing law and jurisdiction clause nominates the law that applies to the agreement and the courts that will hear disputes. For software sold into Australia, the clause should pick an Australian state or territory and its courts, so that disputes are resolved where the users and the business are. Choosing the law of another country does not remove Australian consumer protections. The consumer guarantees and the unfair contract terms rules apply to supplies made to Australian consumers and small businesses, and a governing law clause cannot be used to contract out of them. If the business sells internationally, the clause needs to work with the laws of each market the software reaches, which is a reason to get the clause reviewed rather than copied from a template.

Clauses worth adding depending on your situation

Not every EULA needs every clause, but these come up often enough that they are worth considering:

• Beta or trial terms: if you release pre-release versions, spell out that they are provided as-is, unsupported, and may change or be withdrawn without notice.
• Automatic renewal and price changes: for subscription software, set out how and when subscriptions renew, the notice period before renewal, and how price changes are communicated, since unilateral variation clauses attract unfair contract terms scrutiny.
• User indemnities: an indemnity from the user for loss caused by their misuse of the software, such as using it to breach the law, can shift risk back, but keep it proportionate to what the user actually controls.
• Open-source components: if the software incorporates open-source libraries, their licences may impose attribution or copyleft obligations that need to be carried through into the EULA.
• Reseller arrangements: if you distribute through resellers, decide who grants the end user licence and who answers to users for consumer guarantee obligations.

How an Artificer Legal lawyer reviews an EULA

A practitioner from Artificer Legal would review an EULA the way an insurer reviews a risk, clause by clause, checking what each one actually achieves under Australian law. We would push back on "as is" disclaimers that do not carve out the consumer guarantees, on liability caps drafted as if the Australian Consumer Law did not exist, and on termination and variation clauses that give the supplier unconstrained discretion. We would insist that the limitation of liability clause be redrafted against s 64A of the ACL, that the grant clause define the scope of use precisely, and that the acceptance flow be checked: the terms should be presented before the software can be used, in a way the user has a real opportunity to read, with an unambiguous act of consent. We would also check whether the EULA is a standard form contract caught by the unfair contract terms regime, and align the data clause with the supplier's actual privacy obligations. The order matters too: the grant first, then the restrictions, then the warranties, and only then the liability cap, because a cap built on an unenforceable grant protects nothing.

Why your liability cap cannot ignore the Australian Consumer Law

If one clause decides whether an Australian EULA works, it is the limitation of liability clause, because it is the one most often drafted for another country's law. A cap that says "no liability whatsoever" is void under s 64 of the ACL to the extent it covers the consumer guarantees, which means the developer ends up owing the very remedies the clause was meant to exclude: repair, replacement or a refund. The drafting choice that makes the difference is expressing the cap by reference to what the law actually allows, stating that nothing in the agreement excludes rights the user cannot validly give up, and limiting business supplies to repair, replacement or re-supply on fair and reasonable terms. That is the difference between a clause that decides who wins a dispute and a clause that hands the other side the argument on a plate.

The key points to take away are these. A EULA is a licence, not a transfer of ownership, and its grant clause defines everything that follows. The restrictions clause protects the software commercially and should be proportionate to that purpose. The intellectual property and data clauses should say who owns the software and who owns the content users put into it. The limitation of liability clause must be drafted around the consumer guarantees, which cannot be excluded, and the unfair contract terms regime, which since late 2023 carries penalties for proposing or relying on an unfair term in a standard form contract. Support, updates, privacy and governing law all need to be addressed expressly, because silence creates the disputes the EULA was meant to prevent. If you are drafting an EULA for your own software or reviewing one handed to you, these are the clauses to work through, and a lawyer can help you get each of them right.