Open Source Software Policies for New Zealand Businesses

Many New Zealand businesses use open source software every day without realising how much legal risk can sit behind a simple code download.

The usual problems are predictable: teams copy code from public repositories without checking licence terms, businesses mix open source with proprietary code in customer products, and nobody keeps a record of what was used or where it came from. That can create issues with ownership, disclosure obligations, security, supplier contracts and even a future sale of the business.

An open source software policy helps you set rules before those problems become expensive. It tells your team what they can use, what approvals are needed, how to track licences, and what to do before software is released to customers or investors review your codebase. For startups and SMEs in New Zealand, that matters whether you are building a SaaS platform, custom software, an app, connected hardware, or internal business systems.

This guide explains what an open source software policy should cover, when businesses usually need one, and the practical mistakes to avoid before you sign contracts, launch online, or raise capital.

Overview

An open source software policy is an internal set of rules for how your business selects, approves, uses and distributes software governed by open source licences. The main legal issue is not that open source is risky by itself, but that each licence comes with conditions and those conditions may affect ownership, distribution, source code disclosure, notices, and supplier promises.

A sensible policy helps a business move faster because engineers, founders and procurement teams know what is allowed and what needs review.

• identify what open source software your business uses, including libraries, frameworks, plugins, containers and developer tools
• work out which open source licences apply and whether any terms conflict with your business model
• set approval rules for high risk licences, code modifications, and software shipped to customers
• keep a software inventory and licence records so you can answer due diligence questions
• align your customer contracts, supplier agreements, employment contracts and IP clauses with your actual development practices
• check related issues such as privacy, cyber security, trade mark use, and marketing claims about your product

What Open Source Software Policy Means For New Zealand Businesses

An open source software policy means your business has a clear position on how open source code can be used without creating avoidable IP and compliance problems.

In practice, it is an internal governance document. It sits alongside your development processes, procurement rules, employment obligations, contractor agreements and software contracts. For some businesses it is a short operating policy. For others, especially product companies or managed service providers, it will be backed by approval workflows, code scanning and contract wording.

What is open source software?

Open source software is software made available under a licence that permits use, modification and redistribution under stated terms. Those terms vary. Some licences are relatively permissive. Others include conditions that may require notices, making source code available in certain cases, or licensing derivative works in a particular way.

This is where founders often get caught. They assume “free to download” means “free to use however we want”. That is not the legal test. Your business still needs to comply with the applicable licence.

Why does a business policy matter?

A policy matters because software decisions are usually made quickly and by different people. Developers install packages, contractors contribute code, product teams release features, and sales teams promise customers they will own or exclusively control the product. Without a policy, those decisions can clash.

Common consequences include:

• customer contracts promising ownership or exclusivity that your business cannot fully give
• investor or buyer due diligence uncovering unmanaged open source obligations
• uncertainty about whether modified code must be disclosed when software is distributed
• security issues from unsupported or unvetted libraries
• licence notices being missed in commercial releases
• disputes with developers or contractors about who owns contributed code

How does this fit into New Zealand law?

New Zealand does not have a separate standalone statute called an open source software law. The issues usually sit across contract law, copyright and intellectual property principles, fair trading obligations, privacy compliance, and the way your business documents ownership and risk allocation.

If your business is incorporated, your directors still need to act carefully and make sensible decisions about business risk. If you are early stage and choosing your business structure, the issue can affect whether you operate as a company, partnership or sole trader, because liability and contracting arrangements are handled differently. Registration with the Companies Office does not solve software ownership questions by itself. Those issues need to be covered in your contracts and internal processes.

If you are selling online, licensing software to customers, or offering implementation services, your terms and conditions need to match your use of open source. Marketing also matters. If you claim your platform is fully proprietary, uniquely owned, or unrestricted for commercial use, those statements must be accurate. In New Zealand, misleading claims can raise Fair Trading Act concerns.

What should an open source software policy usually cover?

A practical policy should answer basic operational questions in plain English. It should not read like a generic legal memo nobody follows.

Most businesses should cover:

• who can approve new open source components
• which licences are pre-approved, restricted, or prohibited
• when legal or technical review is needed
• how the business tracks software components and versions
• rules for modifying open source code
• rules for contributing company code back to open source projects
• release steps for products distributed to customers
• security and patching expectations
• record keeping, notices and attribution requirements
• how exceptions are documented and signed off

Your policy may also need separate rules for internal tools versus customer-facing products. A library used only in-house may raise different issues from software embedded in a product you sell to the market.

When This Issue Comes Up

The need for an open source software policy usually appears when the business starts scaling, signing customer contracts, or preparing for due diligence, but the best time to sort it out is earlier.

When building a SaaS or software product

Startups often assemble products from multiple third party components. That is normal. The problem starts when nobody reviews whether those components are compatible with the product’s licensing model or with promises made to customers.

If you are launching online, releasing an app, or selling subscription software, this is the point to decide what your team can use and what needs approval before code goes live.

When engaging developers and contractors

Founders often assume anything built for the company belongs to the company. That is not always safe to assume, especially when contractors are involved. Your developer and contractor agreements should clearly assign IP, require compliance with your open source rules, and prevent unauthorised use of code that creates licensing conflicts.

This is particularly important before you spend money on setup with an outsourced development team or offshore contractor.

When signing customer or supplier contracts

Open source issues often surface during contract negotiations. A customer may ask for warranties that software is free from third party restrictions, or that the customer will receive exclusive ownership. A supplier may be providing a codebase that includes open source components without clear records.

Before you sign a contract, check whether the legal promises match the reality of the software stack. A contract review at this stage can help avoid mismatched warranties and ownership clauses.

When raising investment or selling the business

Investors and buyers commonly ask about IP ownership, software licences and compliance processes. If your business cannot show what open source it uses, what licences apply, and how risks are managed, the deal process can slow down or the valuation can be affected.

This is one of the biggest reasons established startups formalise a policy. What felt like a small engineering issue becomes a transaction issue.

When handling personal information or regulated data

If your systems use open source components in products that collect or process personal information, your policy should connect with privacy and security controls. Under the Privacy Act 2020, agencies need to take reasonable steps to protect personal information. That does not create a special open source ban, but it does mean unsupported, unpatched, or poorly understood components can become part of a wider compliance problem.

Health, financial services, education and other data-heavy sectors should be especially careful about component management, patching and vendor oversight, including whether a privacy policy and incident response processes are up to date.

When protecting your brand and commercial position

Open source software and trade marks are different legal issues, but they often overlap in practice. Your product may include software governed by an open source licence while your business name, logo and platform brand remain proprietary. A policy helps teams avoid muddled messaging about what customers can reuse and what remains protected.

If your business has not yet sorted out its brand position, consider trade mark strategy separately from software licensing. The two should support each other.

Practical Steps And Common Mistakes

The best open source software policy is one your team can actually use, backed by contracts, records and release checks.

Step 1: Map what you already use

You cannot manage licence obligations you have never identified. Start with an inventory of the software components used across your products and internal systems.

Your inventory should include:

• libraries and packages
• frameworks
• containers and images
• plugins and extensions
• SDKs and APIs where relevant
• developer tools that may affect release obligations
• any code copied from forums, repositories or community projects

One common mistake is focusing only on the main application and ignoring build tools, scripts, snippets or dependencies pulled in automatically.

Step 2: Classify licences by risk

Not every licence needs the same response. Some can be used more freely. Others require a closer look, especially if software will be distributed, embedded in hardware, or combined with proprietary code.

Your policy should create sensible categories, such as:

• pre-approved licences for ordinary use
• restricted licences needing legal or technical review
• prohibited licences for certain products or use cases

The point is not to turn every code decision into a legal bottleneck. The point is to stop high impact choices from slipping through unnoticed.

Step 3: Decide when approval is required

Your team needs clear triggers for escalation. If developers are unsure when to ask, they usually will not.

Approval is often required when:

• a new open source component is added to a customer-facing product
• the business plans to modify open source code
• software will be redistributed outside the business
• an enterprise customer asks for ownership or broad warranties
• the component is under a higher risk licence
• the product is used in a privacy-sensitive or security-sensitive setting

Step 4: Align your contracts with the policy

Your internal rules only go so far if your contracts say something different. This is where many SMEs run into trouble.

Check your key documents, including:

• developer employment agreements
• contractor agreements and statements of work
• software development agreements
• SaaS terms and conditions
• master services agreements
• supplier procurement terms
• IP assignment deeds where ownership needs to be cleaned up

These documents should deal with ownership, licence compliance, use of third party code, disclosure of open source components where needed, and limits on promises given to customers.

Step 5: Set release and record-keeping rules

A policy works better when it connects to the release process. Before software is shipped, someone should confirm that approvals were obtained, notices are included where required, and the software bill of materials or equivalent record is up to date.

Good records matter for due diligence, customer security questionnaires and internal troubleshooting. They also make it easier to update components when security issues arise.

Step 6: Train the people who actually touch the code

A policy sitting in a folder will not change behaviour. Developers, product leads, procurement teams and founders should understand the practical rules.

Training does not need to be formal or heavy. It does need to be clear about what is allowed, what is restricted, and who signs off exceptions.

Common mistakes businesses make

The same errors appear again and again, especially in fast-moving startups.

• assuming public code repositories can be used without checking the licence
• promising customers exclusive ownership of software that includes third party code
• forgetting that contractor-built code may not automatically belong to the business
• treating open source as only a technical issue and not a contract issue
• failing to keep an inventory of dependencies and versions
• ignoring notice and attribution obligations
• missing privacy and security implications where vulnerable components handle personal information
• waiting until due diligence to clean up the codebase

A practical example

A New Zealand SaaS startup uses several open source libraries to launch quickly. Early enterprise customers ask for strong IP warranties and a promise that the customer will own all custom developments. The company also uses freelance developers and has no central record of which components are included.

At this point, the business needs more than a technical audit. It needs an open source software policy, cleaner contractor terms, customer contract wording that reflects actual rights, and a process for approving future components. Fixing those issues early is usually cheaper than renegotiating customer obligations later.

FAQs

Does every New Zealand business need an open source software policy?

No, not every business needs a detailed formal policy. But if you build software, customise platforms, sell digital products, or rely on developers and contractors, some written rules are usually worthwhile.

Is open source software illegal or unsafe to use?

No. Open source software is widely used and often very reliable. The real issue is whether your business understands and complies with the relevant licence terms and manages security updates properly.

Can we still own our product if it uses open source components?

Usually, yes, but ownership and licence rights are not the same thing. Your business may own its original code while still needing to comply with third party licence conditions for included components.

Do we need to tell customers that we use open source software?

Sometimes you may need to provide notices, attribution or other licence-related information, and some customer contracts may require disclosure. The right approach depends on the licences involved and what your contract promises.

Should our privacy and security processes be connected to this policy?

Yes. If open source components are part of systems that handle personal information or critical business data, your policy should work alongside your privacy, cyber security and incident response processes.

Key Takeaways

• An open source software policy gives your business clear rules for using, approving and tracking open source code.
• The main risks usually involve licence compliance, IP ownership, customer promises, poor record keeping, and unmanaged security issues.
• New Zealand businesses should make sure their development practices match their contracts, privacy obligations, marketing claims and commercial strategy.
• The best time to set a policy is before you sign major customer contracts, engage developers at scale, launch online, or start investment due diligence.
• A useful policy should cover licence categories, approval workflows, record keeping, release checks, contractor controls and exception handling.

If your business is dealing with open source software policy and wants help with software contracts, IP ownership terms, contractor agreements, privacy compliance, you can reach us on 0800 002 184 or team@sprintlaw.co.nz for a free, no-obligations chat.