Who Owns Software IP and How to Protect Your Code

If you are building software in New Zealand, one of the easiest mistakes to make is assuming the person who paid for the work automatically owns the code. Another common problem is treating a handshake, Slack thread, or invoice as enough to deal with IP ownership. Founders also get caught when a developer reuses open source code without checking the licence, or when a contractor keeps the copyright because the contract never assigned it properly.

That matters early. It can affect fundraising, a sale process, your ability to licence the product, and even whether you can stop a former developer or agency from reusing the same code elsewhere. If ownership is unclear, investors and commercial customers will often see that as a red flag.

This guide explains who usually owns software IP in New Zealand, what changes when employees, contractors, agencies, and co-founders are involved, and what practical steps help protect your code before you sign a contract, launch online, or spend money scaling the product.

Overview

Software IP ownership usually turns on who created the code, what relationship they had with the business, and what the contract says. Copyright can arise automatically, but automatic protection does not mean your company automatically owns everything made for it.

• Check whether code was created by an employee, contractor, agency, founder, or third party
• Review contracts to see if copyright and other IP have been clearly assigned to the right entity
• Confirm whether open source software, third party libraries, or pre-existing code sit inside the product
• Document who contributed what, when they contributed, and under what terms
• Protect confidential information with NDAs, access controls, and clear internal policies
• Consider trade mark protection for the software name, logo, and brand assets
• Make sure privacy policy terms, customer contracts, and developer agreements line up with your ownership position

What Who Owns Software IP and How to Protect Your Code Means For New Zealand Businesses

The key point for New Zealand businesses is simple: paying for software does not always mean you own the IP. Ownership depends on legal rules about copyright and on the wording of your agreements.

In most software businesses, the main IP right is copyright. Copyright can protect source code, object code, user interfaces, databases with original selection or arrangement, technical documentation, and some design materials. You do not register copyright in New Zealand for it to exist. It generally arises automatically when an original work is created.

That sounds straightforward, but founders often miss the ownership layer. The person or entity that creates the work is commonly the first owner, unless an exception applies or the rights have been assigned in writing.

Employees versus contractors

Code created by an employee in the course of employment will often belong to the employer. That is why properly drafted employment contracts matter. If your developer is a genuine employee and is writing software as part of their job, the business will usually be in a much better ownership position.

Contractors are different. If you hire a freelance developer, development studio, or specialist agency, they may own the copyright in what they create unless the contract clearly says the rights are assigned to your business. A statement that you are paying for delivery of the software is not the same as an IP assignment.

This is where founders often get caught. They engage a contractor quickly, agree the scope in messages, pay invoices on time, and assume the company owns the product. Later, during due diligence or a dispute, there is no signed assignment and no clean chain of title.

Co-founders and early contributors

Early stage products are often built before the business structure is settled. A co-founder may write the first version personally, an adviser may contribute code for equity, and a friend may design the interface. If the company did not exist when that work was created, the company may not own it unless those rights were later transferred.

That creates problems when you incorporate a company, issue shares, or bring in investors. Before you invest in branding, before you register a domain, and before you sign with customers, it is worth checking whether all founder-created IP has been assigned into the company that will trade and hold the assets.

What counts as software IP

Software IP is broader than just source code. A founder should think about:

• application code and scripts
• architecture and technical specifications
• APIs and integrations
• databases and data structures
• UI and UX designs
• documentation, manuals, and onboarding materials
• product names, logos, and brand assets
• confidential know-how, workflows, and internal tools

Different rights may protect different parts of the product. Copyright is central, but trade marks protect branding, confidentiality helps protect sensitive information and processes, and contracts help allocate ownership and control.

Why ownership matters commercially

Clear IP ownership affects more than legal theory. It directly affects your ability to sell, licence, raise capital, and scale.

Customers may ask you to warrant that you own or can lawfully licence the software. Investors may ask for proof that contractors assigned their rights. A buyer may discount the deal or delay settlement if code ownership is uncertain. If your team built on a previous employer's codebase or copied third party material without permission, the problem can become expensive quickly.

For software businesses selling online, ownership also sits beside privacy and contract terms. Your website terms, SaaS terms, service agreement, master services agreement, and contractor documents should all support the same story about what your business owns, what it licences, and what customers can do with the software.

When This Issue Comes Up

Software IP questions usually arise at practical business moments, not in abstract legal reviews. The best time to sort ownership out is before a deal or dispute forces the issue.

When engaging developers

The issue comes up whenever you hire someone to build or improve software. That could be a full-time employee, offshore contractor, local freelancer, or development agency. Before you sign a contract, check who will own newly created code, who keeps pre-existing tools, and whether the developer can reuse components across other client projects.

If the arrangement is silent, you are taking avoidable risk. You want the scope, deliverables, payment terms, confidentiality obligations, moral rights consents where appropriate, and IP ownership position captured in writing.

When incorporating or changing business structure

Many products start before formal company setup. You might test an idea as a sole trader, then move into a company later. Or several co-founders may contribute code before the shareholding and governance documents are finalised.

That is a key moment to transfer ownership into the operating entity. If your business structure changes, your IP records and agreements should change too. The entity taking investment or signing customers should usually be the entity that actually owns or validly licenses the code.

When taking investment or preparing for sale

Due diligence often exposes missing IP assignments. Investors and buyers commonly ask for copies of employment contracts, contractor agreements, founder assignment deeds, and details of third party software used in the product.

If a contractor from two years ago never signed an assignment, you may need to go back and fix the paperwork. That can be awkward, costly, or impossible if the relationship has broken down.

When using open source and third party tools

Most software products rely on libraries, frameworks, APIs, and hosted services. That is normal, but the licences matter. Some open source licences are permissive. Others may require source code disclosure, licence notices, or conditions that do not fit your commercial model.

The legal question is not just who wrote your core code, but also what rights and obligations attach to code you imported. Before you launch online or enter enterprise contracts, you should know what third party software sits in the stack and what licence terms apply.

When branding and marketing the product

Software businesses often focus on code first and branding later. But the product name, app name, logo, domain strategy, and marketplace presence carry their own IP risks. Before you print packaging, spend money on a rebrand, or push a product launch, check whether your intended business name is available and whether trade mark protection makes sense.

Branding disputes are not the same as code ownership disputes, but they often surface together during growth.

Practical Steps And Common Mistakes

The most effective protection comes from getting the basics right early: clear contracts, clean records, sensible access controls, and consistent IP ownership across the business. Most software IP problems trace back to messy onboarding, unclear documents, or assumptions that were never written down.

1. Put IP ownership in writing

Every person who creates software for the business should sign an agreement that deals with IP clearly. The right document depends on the relationship, but the principle is the same. Do not rely on payment, goodwill, or informal messages.

Your agreements should usually address:

• who owns newly created IP
• whether IP is assigned immediately or on payment
• what pre-existing materials each party keeps
• whether the creator grants any licence back or receives any limited rights
• confidentiality obligations
• handover of source code, credentials, and documentation
• warranties about originality and non-infringement
• what happens on termination

For employees, this often sits in the employment agreement and IP policy. For contractors and agencies, it usually sits in a services agreement or contractor agreement.

2. Make sure the right entity owns the code

Founders regularly sign development arrangements in their personal names, then later trade through a company. If the company is the business vehicle, your documents should align with that reality.

Where code was created before incorporation or before the current structure was in place, consider a formal assignment from the individual founder or old entity to the current company. Keep records of the transfer with your company documents.

3. Track pre-existing IP and reused components

Not every line of code in your product will be new or owned outright by your company. Developers may bring templates, utility scripts, libraries, or existing modules. Agencies may use their own frameworks. Contractors may incorporate code from earlier projects where they retained ownership.

That is not always a problem if the agreement spells it out. The main risk is uncertainty. Separate new deliverables from background IP and confirm what rights your business gets to use each piece.

4. Manage open source properly

Open source can save time and money, but only if your team understands the licence conditions. Keep an internal register of major open source components and review the obligations attached to them.

At a practical level, this means:

• identifying the key open source packages used in the product
• recording the applicable licence for each package
• checking whether the licence requires notices, attribution, or source code disclosure
• setting internal approval rules for introducing higher risk licences
• reviewing dependencies before major customer deals or investment rounds

If your product handles personal information, this review should also sit alongside your privacy policy work. Third party tools, analytics, hosting services, and integrations can affect both IP and Privacy Act compliance.

5. Protect confidential information around the code

Copyright protects original code, but it does not replace confidentiality measures. Trade secrets, algorithms, internal logic, pricing tools, training data arrangements, and deployment methods are often protected best through controlled access and contract terms.

Use NDAs where appropriate, but do not stop there. Limit repository access, control admin credentials, use role-based permissions, and document offboarding. A business that says its code is confidential should treat it that way operationally.

6. Think about trade marks as well as copyright

Your code and your brand are different assets. Even if your company owns all software copyright, another business may challenge your product name if your branding steps on their rights.

Before you invest in branding or app store listings, consider whether to clear and register your trade mark. That can be especially useful for SaaS products, apps, platforms, and software tools sold nationally or overseas.

7. Align customer contracts with your ownership model

Your commercial terms should match how your product is actually supplied. Most software businesses license software to customers rather than transferring ownership. If your contract language implies customers own custom developments, source code, or derivative works when that is not your intention, disputes can follow.

Customer contracts should state clearly:

• whether the customer gets a licence or ownership
• what the customer can and cannot do with the software
• who owns customisations, feedback, and improvements
• whether third party terms apply to any parts of the service
• what happens to data, access, and materials when the contract ends

This matters for software development services too. If you build custom software for clients, the contract should say whether they receive full ownership, a licence, or some split arrangement for reusable components.

Common mistakes founders make

The same errors appear again and again in software businesses. They usually seem minor at the time, then become serious when money or reputation is on the line.

• assuming invoices or payment alone transfer IP rights
• using contractors without signed agreements
• forgetting to assign founder-created IP into the company
• ignoring open source licence terms
• failing to keep records of who built what
• mixing personal and company Git repositories or accounts
• letting former team members keep admin access after departure
• launching a product name before checking branding risk
• using customer terms that contradict internal ownership arrangements

If you are trying to start a software business in New Zealand, these issues sit alongside other setup questions such as registration, business structure, privacy compliance, website terms, contractor versus employee arrangements, and trade mark planning. They should be dealt with early, before the product gains traction and the paper trail becomes harder to fix.

FAQs

Does my business own code created by a contractor in New Zealand?

Not automatically. A contractor may own the copyright unless the contract clearly assigns it to your business or grants the rights you need. Always deal with this in writing before work begins.

Do I need to register copyright for software in New Zealand?

No. Copyright generally arises automatically when original code is created. The real issue is proving ownership and having contracts that put the rights in the correct entity.

Can employees claim ownership of software they build for the company?

Software created by an employee in the course of employment will often belong to the employer, but your employment documents should still deal with IP clearly. Problems can arise if the work was created outside the employment scope or using pre-existing employee materials.

Is open source software free to use in commercial products?

Sometimes, but not without conditions. Open source licences can impose obligations such as notices, attribution, or other compliance steps. You should review the specific licence terms before relying on the code in a commercial product.

Should I protect my software name as well as the code?

Usually yes, if the name is commercially important. Copyright and trade marks protect different things. Code ownership will not stop another business from challenging your branding, and a trade mark strategy can help reduce that risk.

Key Takeaways

• Software IP ownership in New Zealand depends on who created the work, the relationship involved, and what the contract says
• Employees and contractors are treated differently, so your employment and contractor agreements need clear IP clauses
• Founder-created code should be assigned into the correct company, especially before investment, sale, or major customer deals
• Open source and third party software can create licence obligations that affect how you commercialise your product
• Protecting code also means protecting confidential information, controlling access, and keeping clean internal records
• Trade mark planning, privacy terms, and customer contracts should support your wider software IP strategy
• Fixing ownership early is usually far easier and cheaper than trying to repair gaps during due diligence or a dispute

If your business is dealing with who owns software IP and how to protect your code and wants help with contractor agreements, IP assignments, software terms, trade mark protection, you can reach us on 0800 002 184 or team@sprintlaw.co.nz for a free, no-obligations chat.