1. What a software licence agreement is for
  2. The essential clauses
    1. How customers accept the terms
    2. What the licence grant covers
    3. What users may not do
    4. Who counts as an authorised user
    5. Fees, billing and what happens on non-payment
    6. Who owns the software and the data
    7. Liability: caps, exclusions and the line the ACL draws
    8. Term, renewal and what happens at the end
  3. Optional clauses worth adding for the right deal
  4. Getting an Artificer Legal lawyer to review your software licence agreement
  5. The exclusion clause that gives false comfort

What a software licence agreement is for

You have built the product, priced the tiers and opened the doors to your first customers. The next document in front of you is the one that decides how much control you keep over the software you spent months building: the software licence agreement. It is the contract customers click through at signup, or the document an enterprise procurement team wants to review before they issue a purchase order.

A software licence agreement grants a customer permission to access and use software that you own. It does not sell the software, and it does not transfer the intellectual property in it. It binds the customer to your payment terms and use restrictions, and it is the document you rely on when a user does something you never intended. It works alongside your terms of service and any end user licence agreement (EULA), so the three need to cross-reference each other cleanly rather than contradict each other. The code behind your platform is protected as a literary work under the Copyright Act 1968 (Cth), which is why the licence matters: it is the permission that makes your customers' ordinary use of the product lawful.

The essential clauses

How customers accept the terms

Your first decision is the acceptance mechanism, because it determines which customers are bound and how easily you can update the terms later.

  • Clickwrap: the customer ticks a box on your platform before they can use the product. It keeps administrative overhead near zero, and you can roll out updated terms quickly if you have included a variation clause that lets you do so. For high-volume consumer products this is usually the only workable option.
  • Signed agreement: the document is executed by both parties, either physically or through a digital signing platform. This suits enterprise deals with bespoke pricing, service levels, data handling or integration requirements, and it is the better fit when customers host your software on their own servers rather than accessing a platform you run.

The trap in the clickwrap path is browsewrap: a terms link sitting in the footer of your site with no active acceptance step. If a dispute reaches court, you have to prove the customer actually agreed to the terms, and a footer link is a weak basis for that. Keep an audit record of which version of the terms each customer accepted and when. The trap in the signed path is the opposite: a formal negotiation process is slow and expensive for a product with thousands of customers, so reserve it for the deals where the commercial value justifies it.

One point worth remembering for business customers: the company is the party to the agreement, not the individuals who log in. If you want to enforce your rules directly against those individuals, have each user accept a clickthrough EULA before they access the platform.

What the licence grant covers

The grant clause is the heart of the agreement. It states what the customer may actually do with your software, and it is usually drafted as a non-exclusive, non-transferable, revocable right to access and use the platform for the customer's internal business purposes during the term. Non-exclusive means you remain free to licence the same product to any number of other customers.

The drafting choice that matters most is how precisely you define "use". Spell out whether the licence covers production use only or also test and development environments, how many environments the customer may run, whether API access is included and at what volume, and whether the customer may integrate your product into their own offerings. An ambiguous grant is construed against the drafter, so a vague "right to use" can end up meaning more than you intended.

  • What the customer will push for: the right to transfer the licence, sublicence it to related companies, resell access, or modify the software. Only give these away deliberately, and define the limits of any sublicence you do allow.
  • What to avoid granting: a perpetual licence, a right to copy and modify the source code, or rights that survive the end of the subscription unless you have priced for them.
  • Minimum content: the scope of permitted use, the term, whether the licence is exclusive, and whether any rights of transfer or sublicence exist.

What users may not do

Restrictions on use stop customers from undermining your business model or your product's security. Standard restrictions prohibit reverse engineering and decompiling the software, reselling or redistributing access, using the product for unlawful purposes, and interfering with the service for other users.

Many SaaS providers fold the detail into an acceptable use policy that is incorporated into the agreement by reference. The policy typically sets out prohibited conduct in plain language, such as:

  • attempting to disrupt or overload the service;
  • uploading malicious code or content;
  • using the software to infringe another person's rights; and
  • scraping or harvesting data from the platform.

The trap here is overreach. Absolute prohibitions that are wider than needed invite challenge, and some cannot be enforced anyway. The Copyright Act 1968 (Cth) provides that certain acts do not infringe copyright in a computer program, such as reproducing the program in the ordinary course of running it, so a clause that tries to ban all copying will not hold up. Draft restrictions that target misuse and abuse rather than ordinary use, and make the acceptable use policy specific enough to be useful when you need to suspend a customer for breaching it.

Who counts as an authorised user

If you sell to business customers, you can limit access to a stated number of users. Decide and state:

  • how many authorised users the customer may have under their plan;
  • whether they are named users or concurrent users who may share a pool of seats;
  • whether all users may be active at the same time; and
  • what happens when the customer exceeds the limit, whether that is automatic blocking, automatic billing for extra seats, or a request for an upgrade.

Pricing per seat is the common model, but "unlimited users" plans are attractive for the customer and easy to regret. If you do offer one, define who counts as a user so that shared logins, contractors and automated scripts do not quietly multiply your support load. Require the business customer to make their users comply with the agreement, since you cannot enforce it directly against individuals who are not parties to it.

Fees, billing and what happens on non-payment

Your pricing structure belongs in the agreement so there is no dispute about what was promised. State the price, whether it is charged monthly or annually, whether you bill in advance or in arrears, and how GST is handled. If the customer can exceed their plan limits, set out the overage charges.

Reserve an express right to suspend access if a payment fails, after a reasonable notice period. Without that right, you may be limited to suing for the debt while the customer keeps using the service.

The unfair contract terms regime constrains how far you can go here. Under s 23 of the Australian Consumer Law (ACL), which is Schedule 2 to the Competition and Consumer Act 2010 (Cth), an unfair term in a standard form consumer or small business contract is void, and since the 2022 reforms took effect in November 2023, proposing or relying on such a term can attract a penalty. A term that lets you vary the price without giving the customer a right to terminate is the kind of term the ACL flags as potentially unfair, so include adequate notice of any price change and a right for the customer to cancel. The same logic applies to automatic renewal: state the renewal terms clearly and give notice before renewing, rather than quietly rolling customers over.

Who owns the software and the data

Ownership clauses are easy to overlook because the answer seems obvious, but they prevent expensive arguments later. State that all intellectual property in the software remains with you, that the customer acquires only the licence granted, and that any feedback or suggestions the customer gives you may be used to improve the product. If you expect to restructure or sell the business, check that the agreement lets you assign it to a new entity.

The other half of this clause is data. Set out who owns the data customers and their users put into the platform, what you may do with it, and what happens when the agreement ends, such as an export window followed by deletion of your copies. If the data includes personal information, your handling of it may also be regulated by the Privacy Act 1988 (Cth) depending on your turnover and the kind of information involved, and a lawyer can confirm whether the small business exemption applies to you.

Liability: caps, exclusions and the line the ACL draws

Liability clauses manage your financial exposure when something goes wrong. Most SaaS agreements cap your total liability at the fees the customer has paid, usually over the preceding twelve months, and exclude indirect and consequential loss such as lost profits or lost data. These are sensible drafting choices, but Australian consumer law draws a line through them.

When you supply services to a consumer, the ACL implies guarantees that the services will be rendered with due care and skill and will be reasonably fit for the purpose the customer made known to you. "Consumer" is broader than a natural person buying for themselves: a business customer acquires services as a consumer if the amount paid or payable does not exceed $100,000, or if the services are of a kind ordinarily acquired for personal, domestic or household use. That means many small business customers on a standard SaaS subscription are consumers for the purposes of the guarantees.

The critical consequence is in s 64 of the ACL: a term that purports to exclude, restrict or modify the consumer guarantees is void. For services that are not of a kind ordinarily acquired for personal, domestic or household use, s 64A(2) allows you to limit liability for a failure to comply with a guarantee to supplying the services again or paying the cost of having them supplied again. That is the boundary your liability clause must respect.

  • The trap: a template clause saying "we accept no liability whatsoever" is void against consumer customers, which includes many of your business customers, and gives you no protection at all where you thought you had it.
  • The trap: excluding liability for loss of data is common, but if your platform loses a consumer customer's data through your failure to exercise due care and skill, the exclusion is unlikely to survive.
  • What works: a cap linked to fees paid, an exclusion of indirect and consequential loss, and an express carve-out stating that nothing in the agreement excludes or limits the consumer guarantees, with liability for a failure to comply limited to re-supply where s 64A(2) permits it.

The point is not theoretical. In Valve Corporation v Australian Competition and Consumer Commission [2017] FCAFC 224, the Full Federal Court upheld findings that the consumer guarantees applied to software and games supplied digitally to Australian customers and that statements suggesting refunds were unavailable misrepresented the guarantees. The same logic applies to a SaaS subscription: the guarantees sit behind your product regardless of what your template says.

Term, renewal and what happens at the end

State how long the licence runs, whether the subscription renews automatically, and what notice either party must give to cancel. Termination rights need to cover breach by the customer, with a cure period, and a right to suspend access while a serious breach or non-payment is being resolved.

Two areas deserve particular attention. First, specify what happens to the customer's data on termination: how long they have to export it and when your copies are deleted. Second, if the customer has integrated your software into their own products, state clearly which components they may continue to use and which they lose access to when the agreement ends. Ambiguity here converts an ordinary termination into a dispute about stranded functionality.

The unfair contract terms regime also reaches into this clause. A term allowing one party to terminate unilaterally without reasonable grounds or notice is one of the examples of potentially unfair terms in s 25 of the ACL, so give the customer defined termination rights rather than a bare right for you to end the agreement at will.

Optional clauses worth adding for the right deal

Some provisions are not needed for every product, but each earns its place in particular deals:

  • Service level commitments: an uptime percentage with credits when you miss it, for customers whose own operations depend on your platform being available.
  • Data handling and privacy terms: what you collect, how you use it and whether it is disclosed offshore, whenever you process personal information on behalf of customers.
  • Sublicensing rights: a controlled right for the customer to extend access to companies within a corporate group, or to white-label partners.
  • Customer indemnity: the customer indemnifies you for misuse of the platform or for content they upload that infringes third-party rights.
  • Transition and API access: a commitment to provide data export and integration access after termination so the customer can migrate, which is often the price of closing an enterprise deal.

An Artificer Legal practitioner reviewing a software licence agreement starts by classifying it: is it a standard form contract, and does it sit on the consumer or small business side of the ACL? That classification decides which of your clauses are enforceable at all. From there we would check the liability clause against ss 64 and 64A(2), look for unilateral variation, automatic renewal and price change terms that expose you to the unfair contract terms regime, and confirm that the licence grant matches the product you actually sell, including seats, tiers and API access.

When negotiating on your behalf, we would typically push back on perpetual licences, uncapped liability for data loss, and indemnities that do not carve out your own negligence. The sensible order of negotiation is grant scope first, then fees, then liability, then termination, because each earlier clause sets the commercial frame for the ones after it. If you are at the template stage, we can draft the clauses so the traps above never reach your customers.

The exclusion clause that gives false comfort

If one clause decides whether your agreement protects you, it is the liability clause, and the specific choice inside it is how you handle the consumer guarantees. A confident "we exclude all liability" line copied from a template is void against consumer customers under s 64 of the ACL, which means the clause you thought was your shield is the first thing a court ignores. The drafting that works states the cap, excludes only what the law allows, carves the guarantees out expressly and limits liability for a guarantee failure to re-supply where s 64A(2) permits. That version survives contact with the ACL and gives you the protection you actually paid a lawyer to think about.

The rest of the agreement supports that core. Define the licence grant precisely, restrict misuse without overreaching, decide who counts as an authorised user, put the payment and suspension mechanics in writing, keep ownership of the software and a workable data position, and state what happens at the end of the term. Reviewed against the unfair contract terms regime and the consumer guarantees, a software licence agreement becomes a document that protects your intellectual property instead of a formality your customers never read.