Sui Generis Database Rights: Are They Recognised in New Zealand?

If your business collects, organises, licences or relies on valuable data, it is easy to assume the database itself is automatically protected in New Zealand. That is where many founders get caught. A common mistake is treating raw data as if it were covered by copyright in the same way as written content. Another is copying data structures, supplier lists or compiled records from overseas sources without checking what rights apply. A third is using contracts and privacy documents that talk generally about “data ownership” without actually protecting the database in practice.

This guide answers the question at the centre of understanding sui generis database rights for New Zealand businesses: does New Zealand recognise a separate database right, and if not, what legal tools actually matter? It also explains when the issue comes up, what founders should check before they sign a contract or spend money on setup, and the practical steps that reduce risk when you build or use a data-heavy product.

Overview

New Zealand does not have a standalone sui generis database right in the same way some overseas jurisdictions do. That means businesses usually need to look at copyright, confidentiality, contract terms, privacy law, trade marks and technical controls rather than relying on a separate database-specific property right.

The legal position often depends on what exactly you are trying to protect, the source of the data, and how another party has used it.

• New Zealand generally protects original expression, selection or arrangement, not mere facts or raw data by themselves.
• Overseas database rights, especially from the UK or Europe, do not automatically give enforceable protection in New Zealand.
• Contracts, confidentiality clauses, licence terms and access restrictions often do the heavy lifting for database protection.
• Privacy obligations apply if the database contains personal information, even where intellectual property rights are unclear.
• Before you sign a contract, check who owns the database, who can extract or reuse the contents, and whether third party source data was lawfully obtained.

What Understanding Sui Generis Database Rights Means For New Zealand Businesses

The short answer is this: New Zealand businesses cannot usually rely on a separate sui generis database right under New Zealand law.

The phrase “sui generis database right” usually refers to a special legal right recognised in places such as the UK and parts of Europe, where the maker of a database may have protection based on substantial investment in obtaining, verifying or presenting the contents. New Zealand does not have an equivalent standalone regime.

That matters because founders often hear about database rights from overseas articles, software providers or platform terms and assume the same concept applies here. It usually does not. In New Zealand, the legal analysis is more piecemeal and more practical.

What can still be protected?

A database can still attract legal protection in New Zealand, but not simply because it took time or money to compile. The protection may come from several different places.

• Copyright may protect original selection, arrangement, coding, interface design or written material associated with the database.
• Confidential information law may protect non-public data that has commercial value and is handled confidentially.
• Contract law may restrict scraping, extraction, resale, reuse or unauthorised access.
• Privacy law may regulate how personal information within the database is collected, stored, used and shared.
• Trade mark law may protect branding connected with the database product or platform.
• Technology controls can support a legal position by showing access was restricted and not intended to be open for reuse.

What is not usually protected by itself?

Mere facts, data points and information that are not expressed in an original way are often the hardest thing to protect. A list of names, prices, addresses, property records, business details or product specifications may not attract copyright just because someone invested effort in collecting them.

This is where businesses often get caught. They assume that because a dataset is valuable, the law automatically treats it like owned property in every sense. In reality, the legal position depends on:

• whether the material is confidential or public,
• whether the selection or arrangement is original,
• whether contractual restrictions apply,
• whether the data contains personal information, and
• whether the use involves copying expressive material rather than merely using facts.

Why the overseas position still matters

Even though New Zealand does not have its own standalone database right, overseas rights can still matter commercially.

For example, a New Zealand business may license a UK database, acquire a business with customers in the UK, or operate a platform that is accessed overseas. In those cases, UK or EU database rights might affect what the business is allowed to do in those markets. The key point is that this does not mean the same standalone right automatically exists for purely New Zealand use.

If your startup is building a product with international users, planning to sell online overseas, or entering cross-border data supply contracts, you may need separate advice on the laws of those jurisdictions before launch.

When This Issue Comes Up

This issue usually appears when a business treats data as a key asset, or when one business accuses another of taking data, reusing it or building on it without permission.

You are more likely to run into the problem in day-to-day founder decisions than in abstract legal planning.

Building a data-driven product

If you are creating a SaaS platform, marketplace, analytics tool, AI-enabled service or lead generation system, the database may be part of the value of the business. Before you spend money on setup, work out what the legal basis is for collecting and using that data.

Typical examples include:

• a property tech business compiling listing history and suburb metrics,
• a recruitment platform building candidate and employer profiles,
• an e-commerce business maintaining product catalogues and customer segmentation data,
• a logistics platform organising supplier, route and pricing data, and
• a software company training features using structured commercial datasets.

Buying, selling or licensing data

If your business buys a dataset, licenses one from a provider, or sells database access to customers, the main risk is assuming the seller actually has the right to license what they are supplying.

Before you sign a contract, check:

• where the data came from,
• whether the source terms prohibited scraping or reuse,
• whether personal information is involved,
• whether the licence is exclusive or non-exclusive,
• whether customers can extract substantial parts of the database, and
• what happens to the data when the contract ends.

Hiring developers or contractors

Ownership issues often start internally. A founder may pay a developer, analyst or contractor to create the database structure, import records, design taxonomy or write code that powers search and extraction. If the contract is silent, ownership and usage rights can become messy.

This is especially important where the value sits not just in the software, but in the cleaned and structured dataset itself. You want the agreement to deal with:

• who owns the database schema and imported content,
• who owns any scripts used to collect or transform data,
• whether the contractor can reuse the same database design elsewhere, and
• what confidentiality obligations continue after the work ends.

Scraping and competitor data use

Some founders assume that if information is visible online, it is free to take and republish. That is risky. Even if copyright in the raw facts is weak, the conduct may still create problems under terms of use, confidentiality arrangements, fair trading issues, privacy rules or technical access restrictions.

This tends to come up when a business:

• scrapes competitor websites,
• copies product catalogues or directories,
• reuses customer reviews or user-generated content,
• mirrors a platform's database structure, or
• downloads data through an account in ways the provider did not authorise.

Due diligence, investment and exits

Investors and buyers often ask pointed questions about the legal basis for your data asset. They want to know whether the database is actually protectable, whether your business can keep using it, and whether a third party could challenge your rights.

For an acquisition or capital raise, documents may need to show:

• clear ownership or licence rights,
• privacy compliance for personal information,
• contractual restrictions on customer use,
• staff and contractor IP assignments, and
• any exposure relating to overseas database rights where international operations are involved.

Practical Steps And Common Mistakes

The practical answer for most New Zealand businesses is to protect databases through layered legal and operational controls, not through assumptions about a standalone database right.

This section is where founders can save themselves real cost later.

1. Identify what you are actually protecting

Start by separating the different elements of the asset. A database is rarely just one thing. It may include raw facts, curated records, tags, code, interfaces, reports, customer information and confidential know-how.

Write down what sits in each category:

• public source data,
• licensed third party data,
• internally generated data,
• personal information,
• copyright content such as descriptions or notes, and
• confidential internal analysis or scoring.

This helps you avoid overclaiming rights you do not actually have, while properly protecting the parts you do.

2. Use contracts that match the real risk

For many businesses, the strongest protection comes from contracts. Terms of use, supply agreements, contractor agreements, employment contracts and customer terms should say clearly what others can and cannot do with the database.

Clauses often need to deal with:

• ownership of database contents and structure,
• permitted internal use,
• restrictions on extraction, scraping, resale and republication,
• API access conditions,
• confidentiality obligations,
• termination and deletion requirements, and
• audit or enforcement rights where appropriate.

A vague statement that “all data belongs to us” is often not enough. The better approach is to define the asset and the permitted uses with some precision.

3. Check privacy compliance early

If the database contains personal information, the Privacy Act 2020 may shape the whole project. That applies whether the database is customer-facing or internal.

Before you launch online or share a dataset with a service provider, think about:

• why you are collecting the personal information,
• whether people were told how it would be used,
• whether the data is accurate and up to date,
• who can access it,
• whether it will be stored or disclosed overseas,
• whether your privacy policy reflects those uses, and
• how individuals can exercise their privacy rights.

A business can have a strong commercial dataset and still face legal trouble if its privacy position is weak.

4. Do not assume website data is free to copy

This is one of the most common mistakes. Public access is not the same as permission. A site may contain copyright material, contractual use limits, access controls or personal information issues even where the facts themselves look ordinary.

Before reusing material from another source, check:

• whether terms of use restrict automated extraction,
• whether the material includes images, descriptions or reviews that are likely copyrighted,
• whether the content is confidential or access-controlled,
• whether republication could mislead customers under fair trading rules, and
• whether the data source had the right to provide the material in the first place.

5. Lock down ownership with staff and contractors

If your team builds the database, clean ownership should be documented from the start. Founders often focus on company setup, registration, business structure and product launch, but forget the paperwork for the people doing the technical work.

Your documents may need to cover:

• intellectual property assignment,
• moral rights consents where relevant,
• confidentiality,
• return or deletion of data on exit,
• limits on reuse of scripts and models, and
• post-engagement handling of credentials and access.

6. Make your commercial terms consistent

Founders sometimes say one thing in a customer contract, another in platform terms, and something different again in a privacy policy. That inconsistency creates avoidable arguments.

For example, your customer terms might say clients keep ownership of uploaded data, while your platform terms claim broad rights to use all information for analytics, training or resale. Those provisions may not fit together. The right wording depends on the product and the deal model.

7. Protect branding and know-how as well

The database may not be your only asset. The product name, visual identity, methodology and data categorisation system may also be valuable. That is why trade mark protection and confidentiality controls are often part of the wider strategy.

If competitors can lawfully assemble similar public facts, your advantage may come from:

• brand trust,
• exclusive data sources,
• clean contracts,
• better analytics, and
• faster product execution.

Common mistakes founders make

The mistakes are usually practical rather than theoretical. Businesses often run into trouble because they move quickly and paper the issues later.

• Assuming New Zealand has the same database right as the UK or EU.
• Claiming ownership over raw facts without checking whether any legal basis supports that claim.
• Buying datasets without proper warranty, indemnity or provenance checks.
• Scraping data before reviewing source terms and privacy implications.
• Letting contractors build core data assets without written IP assignment.
• Ignoring privacy obligations because the business sees the project as an IP issue only.
• Failing to define what customers can export, copy or retain after termination.
• Using offshore templates that do not fit New Zealand law or the actual business model.

FAQs

Does New Zealand have sui generis database rights?

No. New Zealand does not generally recognise a standalone sui generis database right like the UK or parts of Europe. Businesses usually need to rely on copyright, confidentiality, contracts, privacy law and technical controls instead.

Can copyright protect a database in New Zealand?

Sometimes. Copyright may protect original selection, arrangement, software code, written descriptions or reports connected with a database. It does not usually protect raw facts or information by themselves.

Can I scrape publicly available data from another website?

Not safely without checking the position first. Publicly visible data can still be subject to copyright, terms of use, privacy restrictions, access controls or confidentiality issues.

Who owns a database built by a contractor?

Do not assume your business owns it automatically. The answer depends on the contract, the nature of the work and what was created. A written agreement should deal expressly with ownership, reuse rights and confidentiality.

What if my business operates in the UK as well as New Zealand?

You may need to consider overseas database rights for your UK activities, licences or customers. The New Zealand position and the UK position are not the same, so cross-border projects should be reviewed carefully before launch or expansion.

Key Takeaways

• New Zealand does not generally provide a standalone sui generis database right, so businesses should not assume overseas database rules apply locally.
• Protection for a database in New Zealand often depends on copyright in original elements, confidentiality, contract terms, privacy compliance and access controls.
• Raw facts and public information are usually harder to protect than original expression, curated structure or confidential commercial datasets.
• Database issues commonly arise when building data products, scraping sites, licensing datasets, hiring developers, or raising investment.
• Before you sign a contract or spend money on setup, check data source rights, customer usage rights, contractor ownership, privacy obligations and any overseas legal exposure.
• Clear agreements and consistent documents are often the strongest practical protection for a New Zealand data-driven business.

If your business is dealing with understanding sui generis database rights and wants help with data licensing terms, contractor IP clauses, privacy compliance, contract review, or commercial contracts, you can reach us on 0800 002 184 or team@sprintlaw.co.nz for a free, no-obligations chat.