Software Licence Agreements and EULAs in New Zealand

A software licence agreement and EULA can look routine, especially when a provider says its terms are “standard” or a customer wants your paper signed quickly. That is where New Zealand SaaS and software businesses often get caught. Common mistakes include assuming the licence terms match the sales pitch, accepting broad liability for customer losses, and treating privacy and data use as an afterthought. Another frequent issue is signing a document labelled “licence” that also contains support commitments, auto-renewal terms, audit rights and IP restrictions that were never properly discussed.

If you are buying software for your business, licensing your own software to customers, or negotiating a white-label or enterprise deal, the wording matters. A well-drafted agreement does more than grant permission to use software. It sets the commercial boundaries, allocates risk, explains what happens to data, and defines what each party can do when things go wrong. Here’s what to sort out before you sign a contract, before you accept the provider's standard terms, and before you rely on a verbal promise about features, uptime or ownership.

Overview

A software licence agreement and EULA records the legal rules for using software, and for SaaS it usually also deals with access, service levels, data handling, payment terms, IP ownership and liability. In New Zealand, these agreements need to work alongside general contract law, the Fair Trading Act 1986, the Privacy Act 2020 and, in some cases, consumer protection rules that cannot simply be written away.

• Who owns the software, updates, customisations and any customer-created content.
• Whether the customer gets a limited, revocable, non-exclusive licence or something broader.
• Usage limits, seat counts, user restrictions and rules on sharing access.
• What the supplier promises about uptime, maintenance, support and security.
• How personal information and other customer data will be collected, stored, used and returned.
• Fees, renewals, price increases, suspension rights and termination rights.
• Liability caps, excluded losses, indemnities and remedies if the software fails.
• Whether New Zealand mandatory laws may still apply, despite the contract wording.

What a Software Licence Agreement Covers

A software licence agreement should say exactly what the customer is allowed to do, what the supplier is obliged to provide, and where the risk sits if the relationship breaks down.

The term “EULA” usually refers to an end user licence agreement, often used for off-the-shelf software or app downloads. In practice, many NZ software deals use a mix of documents, such as order forms, master service agreements, SaaS terms, acceptable use policies, privacy wording, privacy notices and technical schedules. The legal effect comes from the full package, not just the title on page one.

Licence scope and permitted use

The licence clause is the core of the deal. It should explain whether the licence is exclusive or non-exclusive, transferable or non-transferable, perpetual or subscription-based, and limited by users, devices, locations, volumes or business units.

This is where founders often get caught if they assume broad internal use rights that are not actually there. A customer may think group companies can use the platform, or that contractors can log in, only to discover the agreement limits access to named employees of one entity.

A clear licence clause should deal with:

• who can use the software;
• where and how it can be used;
• whether use is limited to internal business purposes;
• whether sublicensing, resale or white-labelling is allowed;
• whether reverse engineering, copying or modification is prohibited; and
• what happens if usage exceeds the agreed limits.

Intellectual property ownership

The supplier will usually keep ownership of the software, source code, branding and underlying IP. That is standard. The harder questions involve configuration work, integrations, customer feedback, new features requested by a client, and any bespoke developments paid for as part of the deal.

If the contract says all enhancements vest in the supplier, a customer may end up funding functionality it does not control. If the agreement is silent, disputes can arise later about who owns custom code, API connectors or workflow templates.

The IP section should separate out:

• pre-existing supplier IP;
• customer data and customer content;
• customisations and bespoke deliverables;
• feedback and suggestions; and
• third-party software components or open source elements.

Service standards, support and updates

For SaaS, the real issue is often service access rather than a traditional software copy. The agreement should say what support is included, how incidents are classified, whether there is any uptime commitment, and when maintenance windows can occur.

Before you sign, check whether the provider can change features at any time. Some terms allow major functionality changes with little notice. That may be fine for low-cost tools, but it is risky if your operations depend on specific reports, integrations or compliance features.

Data use, hosting and privacy

If the software handles personal information, the agreement should line up with your Privacy Act 2020 obligations. That means looking beyond a generic statement that the provider takes privacy seriously. You need to know where data is hosted, what subcontractors are involved, how incidents are managed and whether information may be used for analytics, product improvement or AI training.

For business customers in New Zealand, practical data questions often include:

• whether data is stored in New Zealand or overseas;
• whether offshore disclosure needs to be addressed;
• who can access the data and for what purpose;
• how long the provider keeps backup copies after termination;
• what security commitments are actually contractual; and
• how the supplier will help with access requests, corrections and privacy incidents.

Payment, term and termination

Many software disputes are not about bugs. They are about pricing, renewals and exits. A contract should state the fees, billing cycle, when prices can change, whether minimum commitments apply, and what rights each side has to suspend or terminate.

Pay attention to automatic renewals and notice periods. It is common for enterprise software terms to renew unless notice is given 30, 60 or 90 days before the end of the current term. If that date is buried in the fine print, the customer may be locked in for another year.

An exit clause should also deal with:

• data export rights;
• transition assistance, if needed;
• deletion or return of confidential information;
• whether prepaid fees are refundable; and
• the supplier’s right to retain data for legal or backup reasons.

Legal Issues To Check Before You Sign

Before you sign a software licence agreement and EULA, the key legal question is not whether the product looks useful. It is whether the contract matches the commercial reality and gives you a workable remedy if something goes wrong.

Contract formation and enforceability

For online terms, a business should be able to show that the customer had notice of the terms and took a clear step to accept them. Clickwrap acceptance is generally stronger than terms hidden behind a passive browse process. If your business is licensing software online, your records of version control and acceptance matter.

If you are the customer, ask which terms apply. Founders sometimes receive a proposal, an order form and a link to online terms, all with different wording. That creates uncertainty over priority if a dispute arises.

Fair Trading Act risks

You cannot rely on a contract to excuse misleading claims made during the sales process. If software is promoted as having features, integrations, compliance readiness or performance levels that it does not actually have, the Fair Trading Act 1986 may become relevant.

This matters for both sides. A supplier should make sure marketing language, demos and sales promises match the signed terms. A customer should avoid relying on verbal assurances that are not written into the contract.

Consumer law and business contracting out

Some software deals involve business customers only, while others may involve end users or mixed-use arrangements. In certain cases, rights under the Consumer Guarantees Act 1993 may apply unless the parties are both in trade and validly agree to contract out. Whether contracting out works depends on the circumstances and the wording used.

If you sell to small businesses, sole traders or users whose status is not always clear, this point deserves attention. A clause saying “all warranties excluded” may not achieve what the supplier expects.

Privacy Act compliance

If the software collects or processes personal information, privacy obligations do not disappear because a cloud provider sits in the middle. The business collecting the information may still need to explain what is happening to that data, including overseas storage or disclosure.

Before you accept the provider's standard terms, check whether the privacy wording actually covers:

• the purposes for which personal information is used;
• offshore hosting and cross-border disclosure issues;
• sub-processors and third-party service providers;
• security measures and breach notification steps; and
• how data subjects can access or correct their information.

Liability caps and indemnities

Liability clauses are often the most negotiated part of a software agreement because they decide who bears the financial pain if things go wrong. A low monthly fee does not always mean a low legal risk. If your software stores key records, processes payments or handles sensitive data, even a short outage can create significant loss.

Look carefully at:

• the total liability cap and whether it is tied to fees paid over a set period;
• losses excluded, such as indirect loss, lost profits or loss of data;
• carve-outs for privacy breaches, IP infringement, fraud or wilful misconduct;
• indemnities for third-party claims; and
• whether the supplier’s remedies are your sole remedies.

A customer may accept a clause that limits the supplier’s liability to a small amount, only to realise later that there is no practical remedy for a prolonged outage. A supplier may do the opposite and give overly broad indemnities that create open-ended exposure.

Jurisdiction, governing law and offshore providers

If the provider is based overseas, the contract may nominate a foreign governing law and court system. That can make disputes slower, more expensive and harder to enforce. It can also create practical issues if privacy obligations, security expectations or mandatory NZ laws pull in a different direction.

Sometimes offshore terms are non-negotiable, especially with global platforms. Even then, a business should at least understand the risk before it signs and think about whether the tool is suitable for high-value or sensitive use cases.

Common Software Licence Agreement Mistakes

The most common software licence agreement mistakes happen when businesses assume the paperwork is routine and sign before the legal and technical teams have tested the real-world impact.

1. Treating all software licences like basic subscriptions

A low-cost tool used by a small team is very different from a platform embedded in your customer delivery, payroll, records management or compliance workflow. Yet many businesses use the same sign-off process for both. The more central the software is, the more carefully the agreement should deal with uptime, support, security and exit rights.

2. Relying on the sales conversation instead of the contract

Founders often remember statements such as “that feature is coming next month” or “your data stays in New Zealand”, but if those promises are not in the agreement or an attached schedule, enforcing them can be difficult. This is especially risky in enterprise SaaS negotiations where the order form is short and the main terms strongly favour the supplier.

3. Ignoring data return and deletion rights

A business may focus on implementation and forget to plan for the end of the relationship. Then the contract ends, access is switched off, and there is no usable export path. If the software contains customer records, project files or regulated information, that can become an operational problem very quickly.

Before you spend money on setup, confirm:

• what export formats are available;
• how long data remains accessible after termination;
• whether there is a fee for extraction or transition support; and
• when deletion actually occurs.

4. Accepting one-sided change rights

Some EULAs allow the supplier to update the terms, suspend accounts, change pricing or remove features with minimal notice. That may be commercially acceptable for mass-market software, but it is not always sensible for software that sits at the centre of your business.

If you are the supplier, broad unilateral change rights can also create customer trust issues and potential enforcement arguments. Clear notice processes are usually better than trying to reserve unlimited discretion.

5. Overlooking security obligations

Security wording is often surprisingly light in standard form software contracts. A provider may mention “industry standard” practices without promising much at all. A customer may assume encryption, backups, access controls and incident response are covered when they are not.

Where data sensitivity is high, the agreement should spell out the expected controls or refer to a clear security schedule. That does not mean publishing your whole security playbook. It means making the contractual baseline clear enough that both sides know what has been promised.

6. Missing IP issues in custom development

Software businesses often blend standard product licensing with implementation services, custom integrations or feature development. If the contract does not separate those elements, ownership and re-use rights can become messy. The customer may expect to own deliverables because it paid for them. The supplier may expect to retain ownership because the work builds on its core platform.

7. Using offshore templates without adapting them for New Zealand

Many software businesses start with UK, US or Australian templates. That is understandable, but the legal assumptions may not fit New Zealand law or local sales practices. Privacy wording, contracting-out language, dispute clauses and terminology often need adjustment.

A template is a starting point, not proof that the agreement works for your customer base or delivery model.

FAQs

What is the difference between a software licence agreement and a EULA?

A EULA is usually a type of software licence agreement aimed at end users. In practice, NZ software deals often combine EULA-style usage terms with broader commercial terms covering support, privacy, payments and liability.

Does a SaaS business still need a licence agreement if users only access software online?

Yes. Even where no software copy is installed locally, the business still needs terms that govern access, permitted use, IP ownership, fees, service standards, data handling and termination.

Can a software provider exclude all liability in New Zealand?

Not always. Liability clauses may be restricted by mandatory law, the parties’ status, and the way the contract is formed. A broad exclusion written into standard terms may not remove every possible claim, especially where misleading conduct or non-excludable rights are involved.

Who owns customer data under a SaaS agreement?

The contract should say this clearly. Many SaaS agreements state that the customer owns its data while the supplier has limited rights to host, process, back up and use it for agreed purposes. The real issue is often not ownership alone, but access, portability, retention and permitted secondary use.

Should software businesses use one standard agreement for every customer?

Usually, a standard form is useful, but it should match the product and customer type. Enterprise deals, reseller arrangements, white-label projects and software with sensitive data often need extra schedules or negotiated clauses.

Key Takeaways

• A software licence agreement and EULA should do more than grant access. It should define permitted use, ownership, support, privacy, payment terms, risk allocation and exit rights.
• Before you sign, make sure the contract matches what was sold, especially around features, uptime, data location, security and renewal terms.
• For New Zealand businesses, the Fair Trading Act 1986, Privacy Act 2020 and, in some cases, consumer protection rules may still matter even if the contract looks heavily one-sided.
• The biggest practical risks often sit in liability caps, indemnities, auto-renewals, unilateral change clauses and weak data return wording.
• If your software deal includes custom development, integrations or enterprise support, document IP ownership and service obligations separately and clearly.
• A standard template can save time, but it should be reviewed for your product, customer base and NZ legal context before you rely on it.

If you want help with licence terms, privacy and data clauses, IP ownership, liability and indemnity wording, you can reach us on 0800 002 184 or team@sprintlaw.co.nz for a free, no-obligations chat.