EULA Requirements for Software in New Zealand

End-user licence agreements, often shortened to EULAs, are easy to click past and easy to get wrong. For software founders and SMEs in New Zealand, the usual problems are surprisingly consistent: accepting a supplier’s standard terms without checking who carries the risk, using a copied template that does not match the product, or promising customers more rights than the business actually intends to give. Those mistakes can create disputes about refunds, misuse of software, data access, intellectual property ownership, and liability when something goes wrong.

A well-drafted EULA does more than say “you may use this software”. It sets the rules for access, limits misuse, explains what happens to updates and support, and allocates commercial risk in a way that makes sense for the product. If you are buying, licensing, distributing, or offering software in New Zealand, this guide explains what an end-user licence agreement covers, what legal issues to check before you sign, and where businesses most often get caught.

Overview

An end-user licence agreement is the contract that sets the terms on which a customer may use software, an app, or a digital platform. In New Zealand, the practical value of a EULA is that it helps define the licence scope, protect intellectual property, manage customer expectations, and reduce arguments about support, warranties, and liability.

• who owns the software, updates, and related intellectual property
• whether the licence is limited, transferable, exclusive, or revocable
• what users are allowed to do, and what they are prohibited from doing
• how subscription fees, renewals, and termination rights work
• what warranties are given, and what liability limits apply
• how privacy, data use, and security responsibilities are allocated
• whether New Zealand consumer law may override some contract terms
• how the EULA is accepted, especially for online sign-up and click-through flows

What a Software Licence Agreement Covers

A software licence agreement should clearly answer one core question: what exactly is the user allowed to do with the software, and on what terms?

That sounds simple, but the detail matters. A EULA is often the main contract between a software provider and the end user. If you are the provider, this document can define how your software is used and protect your business from misuse. If you are the customer, it tells you what you are really buying, and what you are not.

Licence scope and usage rights

The heart of a EULA is the licence grant. This clause should explain whether the user gets a personal, non-exclusive, non-transferable right to use the software, or something broader.

Before you accept the provider’s standard terms, check the scope carefully. Businesses often assume they can install software across a team, a group of related companies, or multiple devices, only to find the licence is restricted to one named user or one site.

A licence clause commonly deals with:

• how many users, seats, devices, or locations are covered
• whether contractors or affiliates may use the software
• whether the software may be sublicensed or shared
• whether the software is available on a subscription or perpetual basis
• whether trial or beta access has extra restrictions

This is where founders often get caught. A customer may think they bought software outright, when in reality they only received a limited permission to use it while fees are paid and terms are met.

Intellectual property ownership

A EULA should make it clear that licensing software is not the same as transferring ownership of the software or the underlying intellectual property.

If you developed the product, the agreement should state that all copyright and other intellectual property rights remain with you or your licensors. If the customer uploads content, data, or feedback into the platform, the contract should also explain who owns that material and what licence each party gives to the other.

That may include:

• customer content and business data
• user suggestions, feedback, and feature requests
• custom developments or integrations
• documentation, branding, and training materials

Ownership clauses should align with your wider intellectual property position. If contractors helped build the software, or if third-party code is involved, make sure your internal contracts support the rights you are licensing externally.

Restrictions on use

A EULA should spell out what the user must not do. Without clear restrictions, it becomes harder to act when someone copies, reverse engineers, misuses, or redistributes the software.

Common restrictions cover:

• copying or reproducing the software outside permitted use
• reverse engineering, decompiling, or attempting to access source code
• modifying the software without permission
• reselling, renting, or distributing the software to third parties
• using the software unlawfully, fraudulently, or in a way that harms the service
• circumventing security features or access controls

Restrictions should be realistic and connected to your business model. If your product depends on integrations, developer access, or customer configuration, an overly broad prohibition can create confusion and friction.

Fees, renewals, support, and updates

A software licence agreement should also deal with the commercial basics. If the software is subscription based, the customer should know exactly when fees are charged, when the term renews, and what happens if payment is missed.

Support and update clauses matter just as much. Customers often assume that buying access includes ongoing assistance, bug fixes, feature upgrades, or uptime commitments. If that is not the deal, the contract should say so plainly.

Useful clauses often address:

• pricing, billing cycles, and payment methods
• automatic renewal and notice periods for cancellation
• suspension rights for non-payment or misuse
• whether updates are included, optional, or charged separately
• what support channels and response times are offered
• whether service levels are promised under a separate agreement

Before you rely on a verbal promise, make sure support commitments are documented in the written terms. Sales conversations often create expectations that the written terms do not match.

Data, privacy, and security

If the software handles personal information, the EULA may need to work alongside a privacy policy, data processing terms, or a privacy notice with more detailed security commitments. The key point is that the contract should not be silent about data if data is central to the product.

In New Zealand, businesses handling personal information should think carefully about their obligations under privacy law and data protection requirements. The agreement should not say anything misleading about data use, access, or disclosure. It should also explain practical points such as account security, user credentials, backups, and what happens to data after termination.

Where relevant, the contract may cover:

• what data the provider collects and uses
• whether data is hosted by third parties or offshore
• security responsibilities of each party
• retention, deletion, and export of customer data
• notification processes if a security issue occurs

Termination and consequences

A EULA should say when access can end and what happens next. That matters whether termination is for convenience, breach, insolvency, or non-payment.

Customers usually want clarity about data export, transition support, and prepaid fees. Providers usually want the right to suspend or terminate where there is misuse, unpaid invoices, or legal risk.

The end of the relationship should deal with:

• whether the licence stops immediately or after notice
• whether the user must delete copies of the software
• whether the provider can retain or delete account data
• what fees remain payable
• which clauses continue after termination, such as confidentiality and liability provisions

Legal Issues To Check Before You Sign

Before you sign a contract, the main question is not whether there is a EULA, but whether its terms actually match the way the software will be used and the risks your business can live with.

That applies whether you are a software vendor presenting terms to users, or a business customer taking software on someone else’s paper. Standard form contracts are common, but standard does not mean harmless.

Is the contract enforceable in the way it is accepted?

If the agreement is accepted online, the acceptance process matters. A click-wrap flow where the user actively accepts the terms is generally much stronger than burying terms in a footer or relying on implied acceptance.

For providers, the practical issue is evidence. You should be able to show:

• what version of the EULA was presented
• when the user accepted it
• how acceptance was recorded
• whether the user had a fair chance to review the terms

If the agreement may be updated over time, the variation mechanism should also be clear. Quietly changing legal terms after sign-up can create enforceability problems and customer complaints.

Do consumer protections apply?

Some contract clauses may not work the way a provider expects if New Zealand consumer protection laws apply. The Consumer Guarantees Act 1993 and Fair Trading Act 1986 can affect how software and digital services are marketed, supplied, and described.

If end users are consumers, broad “no warranty” language may not fully exclude statutory rights. If your customers are businesses, some statutory protections may be contracted out of in the right circumstances, but that needs careful drafting and should not be assumed.

Marketing language also matters. If your website, demos, or sales material promise functionality, integrations, performance, or savings, those statements can create risk if the product does not match the description. This is especially relevant before you accept the provider’s standard terms and rely on sales assurances that are not written into the contract.

Are liability caps and exclusions commercially realistic?

Liability clauses are often the most negotiated part of a EULA because they determine who pays when something goes wrong. The provider may want a very low cap. The customer may be relying on the software for critical operations and may see that cap as meaningless.

Check the contract for:

• the overall liability cap, and whether it is tied to fees paid
• carve-outs for confidentiality breaches, privacy breaches, or intellectual property infringement
• exclusions for indirect or consequential loss
• special rules for data loss, downtime, or third-party claims
• whether refunds are the sole remedy

The right position depends on the product and the bargaining power of the parties. A low-cost self-serve app will usually be treated differently from enterprise software integrated into a core business system.

Who carries security and compliance risk?

If the software stores customer records, payment information, health information, or other sensitive material, security obligations should not be vague. A short clause saying the provider uses “reasonable efforts” may leave too much uncertainty.

Before you sign, pin down the practical responsibility split. For example:

• who manages user access and passwords
• who is responsible for backups
• what minimum security controls are promised
• what happens if a subcontractor hosts the data
• how the provider will communicate security incidents

Small businesses often focus on price and features first, then realise later that the contract says very little about the provider’s obligations if data is lost or access is interrupted.

Does the governing law and dispute process make sense?

A EULA often names the governing law and where disputes must be dealt with. If you are a New Zealand business using offshore software, you may find the agreement points to a foreign legal system and a foreign forum.

That does not automatically make the contract invalid, but it can make enforcement expensive and impractical. Before you sign, check whether the dispute process is realistic for the size of the deal and the value at risk.

Common Software Licence Agreement Mistakes

The most common EULA mistakes are not technical drafting errors. They are business assumption errors, where the contract says one thing and the parties behave as though it says another.

Using a generic template that does not fit the product

A template written for downloadable desktop software may be a poor fit for a cloud platform. A B2C app EULA may not work for a B2B SaaS product with admin controls, integrations, and recurring fees.

This matters because the agreement should reflect how the software is actually delivered. If your product is account based, data driven, and continuously updated, the terms need to address service access, suspension, support, privacy, and changing features.

Confusing ownership with access rights

Businesses often speak loosely about “selling software” when they are really licensing access. That wording can create confusion internally and externally.

If your sales team, customer support team, and legal documents use inconsistent language, customers may expect rights they never received. Clear drafting helps avoid arguments over source code access, transfer rights, or entitlement to future versions.

Overpromising in sales material

The contract does not exist in isolation. Product demos, onboarding discussions, proposal documents, and advertising claims can shape what the customer thinks they are getting.

The main risk is mismatch. If the EULA says support is limited, but the salesperson promised hands-on implementation and custom reporting, the dispute will not feel academic when the customer complains. Businesses should align their contract terms with the way the product is marketed.

Ignoring New Zealand legal overlays

Some businesses adopt offshore EULAs with little localisation. That can leave gaps around New Zealand consumer law, local terminology, and the practical expectations of New Zealand customers.

Even if the supplier is overseas, local legal exposure can still matter where software is offered to New Zealand users. Contracting practices, privacy disclosures, and representations to customers should make sense in the New Zealand market.

Leaving data issues to separate documents without consistency

It is common to have a EULA, privacy policy, service terms, and security schedule. The mistake is letting those documents say different things.

For example, the EULA may promise deletion of data on termination, while the privacy wording says information may be retained for long periods. Or the sales order may promise specific support response times that the standard terms do not mention. Inconsistency creates avoidable friction and can undermine trust.

Failing to plan for termination

Many software disputes happen at the end, not the beginning. If the agreement says little about offboarding, the parties may clash over data export, timing, unpaid invoices, and continuing access during transition.

Before you spend money on setup or migration, make sure the contract covers how the relationship can end. Exit terms are especially important where the software becomes embedded in day-to-day operations.

FAQs

Is a EULA legally binding in New Zealand?

Yes, a EULA can be legally binding if it is properly presented and accepted, and the terms are otherwise enforceable. Clear click-through acceptance usually gives stronger evidence than passive or hidden terms.

What is the difference between a EULA and terms of service?

A EULA usually focuses on the licence to use software and related restrictions. Terms of service may be broader and cover account rules, billing, platform conduct, and service delivery. In practice, some businesses combine these into one document.

Can a software provider exclude all liability in a EULA?

No, not always. Liability exclusions may be limited by statute, including consumer protection laws, and some clauses may be unreasonable or ineffective in context. The wording needs to be tailored to the product and customer base.

Does a EULA need to deal with privacy?

If the software collects or processes personal information, privacy should be addressed somewhere in the contractual and disclosure framework. The EULA may not need every privacy detail, but it should not conflict with the provider’s privacy commitments.

Should New Zealand businesses negotiate a supplier’s standard software licence?

Often, yes. Even where the supplier uses standard terms, key areas such as licence scope, renewals, data handling, liability caps, service levels, and termination rights may justify negotiation, especially for important business systems.

Key Takeaways

• An end-user licence agreement sets the rules for how software may be used and helps protect intellectual property, pricing arrangements, and risk allocation.
• The most important clauses usually cover licence scope, ownership, restrictions on use, fees, renewals, support, privacy, security, and termination.
• Before you sign, check whether the contract acceptance process is enforceable, whether New Zealand consumer law may affect the terms, and whether the liability position is commercially realistic.
• Founders often get caught by generic templates, inconsistent sales promises, weak data clauses, and unclear offboarding terms.
• A EULA should match the real product, the real customer journey, and the real commercial risk, not just act as a box-ticking document.

If you are reviewing or negotiating end-user licence agreements or need help with licence scope, liability clauses, privacy terms, and software contract negotiation, you can reach us on 0800 002 184 or team@sprintlaw.co.nz for a free, no-obligations chat.