End user licence agreements and the clauses that decide how your software can be used

The draft EULA has landed in your inbox, either because a vendor wants your team to accept it before you install their platform, or because you are finally adapting that template you downloaded for your own software product. Either way, this is the moment when most software businesses skim the document, tick the box, and move on, and it is also the moment when enforceable rights are either created or lost.

An end user licence agreement (EULA) is the contract that grants a customer permission to use your software. It is not a sale. You keep ownership of the code, and the document sets the boundaries around what the customer can and cannot do with it, what you promise in return, and what happens if things go wrong. In Australia the EULA also has to sit inside a legal framework you cannot contract out of, above all the consumer guarantees and the unfair contract terms rules in the Australian Consumer Law (ACL), which is Schedule 2 to the Competition and Consumer Act 2010 (Cth). This guide walks through the clauses that do the real work in a EULA, the drafting traps that come with each, and where a lawyer's review earns its keep.

The clauses that do the work

A EULA is a short document compared with a negotiated software licence agreement, but the clauses below are where the commercial deal is actually defined. They appear in roughly the order you would read them in a well-drafted EULA, and roughly the order of their commercial weight.

What the licence actually allows

The licence grant is the heart of the document. It states that the owner grants the user a licence to install and use the software, and it defines the scope of that permission. The drafting choice that matters most is precision about scope, because every limitation you intend to rely on later has to be expressed here or it does not exist. The scope of the permission needs to be defined in four respects:

• Who is licensed: personal use only, or the named business and its employees.
• How many: a set number of seats, devices, installations, or monthly active users.
• What counts as use: installing, running, accessing via an API, embedding in the customer's own product, or merely viewing.
• Exclusivity and transfer: non-exclusive by default, and whether the licence can be transferred or sub-licensed at all.

The trap is vagueness. A grant that says the customer may "use" the software without defining what use means invites dispute the first time a customer asks whether a colleague's login, an integration, or a reseller arrangement is covered. Conversely, an over-restrictive grant creates tension with the consumer guarantees discussed below, because the software still has to be fit for the purpose it was sold for.

The restrictions, and where the law overrides them

Most EULAs prohibit reverse engineering, decompiling, and attempts to extract the source code, along with resale, sharing of login credentials, and uses that breach the law or the vendor's acceptable use rules. These restrictions are necessary, but they are also the clause where Australian copyright law pushes back.

Software is protected as a literary work under the Copyright Act 1968 (Cth), and the Act defines a computer program as a set of statements or instructions used to bring about a result. The EULA does not create that protection; it reinforces it. The Act also carves out things a user may do regardless of what the EULA says:

• Reproduce the program in the normal course of running it.
• Make a backup copy.
• Reproduce it to make an interoperable product.
• Reproduce it to correct an error.
• Reproduce it to test security in good faith or investigate a security flaw.

The drafting point is that an unqualified ban on reverse engineering can overreach the statute, which allows copying for interoperability, error correction, and security testing in defined circumstances. Restriction clauses that acknowledge these statutory exceptions, rather than pretending they do not exist, are easier to enforce and read better if a customer's lawyer reviews the document.

How long the licence runs and how it ends

A EULA should say whether the licence is perpetual or for a fixed term, and what either side can do to end it. For the vendor, termination rights for breach, non-payment, or a security risk are standard. For the user, there should be a right to terminate and a clear statement of what happens afterwards, including whether the user can export their own data before access is cut off.

This is also where auto-renewal lives, and auto-renewal is a recognised unfair contract term risk. The ACL lists as potentially unfair a term that lets one party renew or not renew the contract, or that renews silently without giving the user a real chance to opt out. In a standard form EULA with a consumer or a small business, a silent evergreen renewal with no reminder and no easy exit can be void, and proposing it can now attract a penalty.

Fees, renewals, and what happens if payment fails

If the software is paid for, the EULA sets out the fees, the billing cycle, and the consequences of non-payment, typically suspension of access after a grace period, with a data retention window before deletion. The drafting trap here is unilateral change. A term that lets the vendor vary the upfront price without giving the customer a right to terminate is expressly listed in the ACL as a type of term that may be unfair. The safer drafting is to promise notice of any price change and give the customer a right to cancel without penalty before the new price takes effect.

Updates, support, and availability promises

Software changes, and the EULA should say who decides that. Most vendors reserve the right to patch, update, and modify features, and state whether major updates are included in the licence or require a new one. If support is included, the level should be described; if it is not, the EULA should say so plainly.

The trap is over-promising. What you write here, and what your marketing says on the website, becomes the standard against which the product is judged. The ACL prohibits misleading or deceptive conduct in trade or commerce, so a support promise you cannot staff, or an availability claim that does not match the product's real behaviour, is exposure. Describe support and uptime honestly, and where you commit to a service level, say what the remedy is if it is missed.

Who owns the code

The IP clause confirms that the vendor retains all intellectual property in the software, the documentation, and any updates, and that the customer acquires only the licence granted. For products with APIs or SDKs, it should also say who owns derivative works and integrations the customer builds.

Two points to get right. First, ownership of copyright in code does not need to be stated to exist, because copyright arises automatically on creation, but stating it prevents the customer from arguing that payment for the licence amounted to a transfer. Second, if your developers used open source libraries, the IP clause cannot override the open source licences, which is why the third-party components clause below matters.

What the vendor is liable for, and the ACL limits

The liability clause is where the EULA's protection is supposed to live: a cap on direct losses, usually to the fees paid in the preceding twelve months, an exclusion of indirect and consequential loss, and a disclaimer of warranties. In Australia, three rules constrain how far that clause can go.

First, the consumer guarantees cannot be excluded. The ACL treats computer software as goods, and when you supply software to a consumer, guarantees of acceptable quality, fitness for purpose, and matching the description apply. A term that purports to exclude, restrict, or modify those guarantees is void, and a blanket "no refunds" statement sits so uncomfortably with the guarantees that it risks being misleading conduct in itself.

Second, the unfair contract terms rules apply to standard form contracts with consumers and with small businesses, defined as businesses with fewer than 100 employees or turnover under $10 million in the last income year. A term is unfair if it causes a significant imbalance in the parties' rights, is not reasonably necessary to protect the legitimate interests of the party advantaged by it, and would cause detriment if relied on. There is a statutory presumption that the advantaged party's term is not reasonably necessary, so the burden of justifying it sits with the vendor. An unfair term is void, and the rest of the contract continues to bind.

Third, since the 2022 amendments, proposing an unfair term in a standard form contract, or applying or relying on one, is itself a contravention with penalties of up to $100 million for a company (or three times the benefit obtained, or 30 per cent of adjusted turnover if the benefit cannot be determined) and up to $2.5 million for an individual. The liability cap is not a free zone; it has to be defensible, transparent, and proportionate.

The drafting choices that survive these rules: cap liability but carve out the consumer guarantees, fraud, and wilful misconduct; exclude indirect and consequential loss but acknowledge that the exclusion cannot apply to consumers' statutory rights; and keep the wording in plain language so a court can see it was transparent.

Data, privacy, and security

If the software collects personal information, the Privacy Act 1988 (Cth) may apply, and the EULA should say what data is collected, why, and who it is shared with, then link to the separate privacy policy rather than trying to reproduce it. For business customers whose own data flows through your platform, the EULA should point to the data processing arrangements that govern security, subprocessors, and international transfers. And if your EULA promises breach notification or encryption standards, your processes must match, because a promise in the contract becomes a contractual obligation.

Third-party and open source components

Few products are built entirely from scratch, and the EULA should disclose the third-party and open source components inside the software. This is not box-ticking. Open source licences impose their own conditions, sometimes including obligations that flow to users, and a EULA that purports to impose restrictions the open source licence forbids creates a conflict where the open source licence usually wins. Identify the components, link to the licence texts, and make clear which obligations attach to whom.

Governing law, disputes, and notices

Australian software sold to Australian customers should pick an Australian governing law and jurisdiction, spell out how notices are given (email is usually fine), and consider a staged dispute process: good faith discussions, then mediation, then the courts. The trap is assuming a governing law clause protects you from the ACL. The consumer guarantees and unfair contract terms rules apply to supplies to Australian consumers and small businesses regardless of the governing law you choose, so the clause governs the contract mechanics, not your ability to contract out of the statute.

Clauses you only need in some deals

The clauses above belong in most EULAs. These next ones are situational, and each earns its place only when the trigger is present:

• Acceptance testing and installation: worth including when you sell on-premise or perpetual licences, where delivery, installation, and a testing window decide when the licence actually starts.
• Audit rights: worth including for per-seat or usage-capped licences, where the vendor needs a way to verify compliance without a court application.
• Customer indemnities: worth including where users create content, resell the software, or build integrations, because their conduct can generate third-party claims against you.
• Confidentiality: worth including in enterprise deployments where the vendor sees the customer's data or systems during support.
• Source code escrow: worth including for mission-critical on-premise software, where the customer's continuity depends on the vendor remaining in business.

How an Artificer Legal lawyer would review your EULA

When we review a EULA for a software business, we read it in a particular order, because that is the order in which the clauses fail. First the liability and disclaimer clause, checking it against the consumer guarantees and the unfair contract terms rules, because that is where most templates overreach. Next the termination and renewal mechanics, because silent auto-renewal and unilateral variation are the two terms the regulator and the courts actually strike down. Then the licence scope, because that is the clause that will be argued about in any dispute over what the customer was allowed to do.

We push back on absolute disclaimer language, unqualified bans on reverse engineering, and caps that are so low they are obviously not reasonably necessary. We insist on a clean clickwrap acceptance flow, because a EULA that was never properly accepted binds nobody. Australian courts recognise clickwrap, browsewrap, and sign-in-wrap agreements, and enforceability turns on whether the user had reasonable notice of the terms and took a positive step to accept them, as the Federal Court confirmed in Dialogue Consulting Pty Ltd v Instagram, Inc [2020] FCA 1846. A buried footer link that no one reads is a much weaker basis for enforcement than a checkbox at the point of sign-up.

We also review the rollout, not just the text: whether there is a version history, whether material changes are flagged and re-accepted, and whether the privacy policy and any support promises are consistent with the EULA. That is the difference between a document that exists and a document that works.

Why the liability clause decides most EULA disputes

If you remember one thing from this walkthrough, make it the liability clause, because it is the clause that decides who pays when a dispute actually happens. Users who breach a EULA usually breach it quietly, and the fight is rarely about whether they were allowed to do something; it is about how much the vendor can recover, and how much the user can claim back. A cap that is void under the consumer guarantees, or unfair within the meaning of the ACL, is no protection at all, and since 2022 the penalty for proposing or relying on an unfair term in a standard form contract can reach eight figures. Draft the cap to survive the ACL, keep the rest of the document transparent and specific, and present it through a clickwrap flow that records genuine acceptance.

The key points in short: a EULA is a licence, not a sale, and it cannot exclude the consumer guarantees; the unfair contract terms rules now carry penalties, so unilateral variation and silent renewal need careful drafting; copyright protects your code automatically, but the statutory exceptions for interoperability, error correction, and security testing qualify any ban on reverse engineering; and the way you present the EULA at sign-up, with clear notice and an active acceptance step, determines whether it binds anyone at all.