Software IP Assignment Deeds in New Zealand: Who Owns the Code?

If your business is paying someone to build software, it is easy to assume you automatically own the code. That assumption causes real problems. Founders often rely on a quote or statement of work without checking who owns the intellectual property, accept a developer’s standard terms that quietly leave ownership with the developer, or forget that contractors and agencies are treated differently from employees.

The result can be expensive: delays in fundraising, trouble selling the business, disputes over who can modify the platform, or a developer reusing key parts of your product elsewhere.

A software IP assignment deed is the document usually used to transfer legal ownership of software-related intellectual property from the creator to the business. It can cover source code, documentation, designs, databases, inventions, and other project materials. If you are commissioning an app, SaaS platform, internal tool, website functionality, or custom integrations in New Zealand, this guide explains what the deed does, what to check before you sign, and where businesses commonly get caught out.

Overview

A software IP assignment deed is meant to do one thing clearly: move ownership of software IP from the person or business creating it to the business that needs to control it. In New Zealand, that clarity matters most when work is done by contractors, freelancers, consultants, development agencies, or founders before formal company arrangements are in place.

• Confirm exactly what intellectual property is being assigned, including code, documentation, designs, databases, APIs, schemas, and related materials.
• Check whether the transfer covers existing IP, newly created IP, or both, and whether any pre-existing tools or libraries are carved out.
• Make sure the deed deals with future rights, further assurance obligations, confidentiality, and moral rights where relevant.
• Review whether third party code, open source components, or subcontractor contributions affect the ownership position.
• Match the deed with your wider contract terms on payment, warranties, defects, support, termination, and ongoing licence rights if the developer keeps any background IP.

What Software IP Assignment Deed Means For New Zealand Businesses

A software IP assignment deed gives your business a much stronger ownership position than a vague clause in a proposal or invoice. Before you sign a development contract, the key question is simple: who will own the software and all related IP when the work is done?

For many New Zealand businesses, this issue appears at a practical founder moment. You have engaged a freelance developer to build your MVP, hired an agency to create a customer portal, or asked a technical founder to write code before the company paperwork is fully sorted. Everyone is focused on product deadlines, and ownership gets pushed aside. This is where founders often get caught.

Why ownership is not always automatic

New Zealand businesses often assume that paying for development means owning the result. That is not always right. A contract needs to state whether IP is assigned, licensed, or retained by the developer.

Employees and contractors are not treated the same way in practice. IP created by employees in the course of employment may be more likely to sit with the employer, but contractor-created IP often needs an express assignment. If the person building the software is an external consultant or agency, relying on assumptions is risky.

Founders also run into trouble when software is created before the company exists, or before all founders have signed proper documents. If one founder writes the code personally and there is no later assignment to the company, investors or buyers may ask who actually owns the product. That can become a due diligence issue very quickly.

What the deed usually covers

A properly drafted software IP assignment deed can cover far more than just the source code. Businesses usually need ownership of the wider project assets too, especially if they plan to scale, raise capital, or switch providers later.

That can include:

• source code and object code
• technical documentation and architecture diagrams
• UI and UX designs, wireframes, and prototypes
• databases, schemas, and data structures
• custom scripts, integrations, APIs, and plug-ins
• test environments, deployment instructions, and build processes
• inventions, methods, and improvements created during the project
• domain-related project materials, brand assets, and product names if they are part of the development scope

The wording matters because software projects rarely involve only one asset. If the deed only assigns code but not related documentation or design files, your business may own a technically incomplete package.

Assignment versus licence

An assignment transfers ownership. A licence gives permission to use IP without transferring ownership. Before you accept the provider’s standard terms, you need to know which one you are being offered.

Some developers retain ownership of their work and give the client a licence to use it. That can be workable in some projects, especially where the developer is using a reusable platform or proprietary framework across multiple clients. But if your business needs full control, exclusivity, freedom to modify the product, or the ability to sell the platform later, a licence may not be enough.

In other cases, the developer may assign the custom-built parts but keep ownership of background IP, such as pre-existing tools, libraries, templates, deployment scripts, or frameworks. That split can be sensible, provided the deed clearly identifies what is retained and gives your business a lasting IP licence to use whatever background IP is needed for the software to function.

Why deeds are often used

A deed is commonly used because it can help formalise the transfer clearly and reduce argument about whether enough value was provided for the assignment. In commercial practice, a deed can be useful where a business is cleaning up ownership after work has already started, or where an earlier contract was unclear.

That said, the deed should not be looked at in isolation. It should line up with the development agreement, consulting agreement, founder arrangements, employment terms, confidentiality obligations, and any subcontracting arrangements. If the documents do not match, you may still end up with uncertainty.

Legal Issues To Check Before You Sign

The main legal issue is not whether the document mentions IP, it is whether the wording actually gives your business the rights it needs. Before you rely on a verbal promise that “you’ll own everything”, check the detail carefully.

Define the assigned IP clearly

The assignment should identify the IP with enough detail to avoid later debate. Generic wording can leave room for arguments about what was included, especially in long projects with changing scope.

If multiple categories of material are involved, spell them out in the deed or attach a schedule. A business commissioning software should usually check:

• what deliverables are covered
• whether updates, upgrades, patches, and later versions are included
• whether working files and editable files are part of the transfer
• whether unfinished work or partially completed code is included if the relationship ends early
• whether related know-how, inventions, and improvements are captured

Check timing of the assignment

Ownership disputes often turn on timing. Does the IP transfer on creation, on payment, on completion, or only when a separate deed is signed?

If ownership only passes after full payment, your business may have limited rights while the project is underway. That may matter if you need to engage another developer part way through. If the assignment only covers existing IP at the date of signing, later work may fall outside the transfer unless the wording also captures future creations.

For staged projects, it can help to state clearly when each stage of IP vests in the client and what happens if the project is paused or terminated.

Background IP and third party materials

Most software projects use pre-existing materials. The legal question is whether those materials are being assigned, excluded, or licensed.

Developers often want to retain ownership of their background IP, which may be reasonable. Your business should then make sure the contract gives a broad enough licence to use, modify, host, maintain, and commercialise the finished product without needing fresh permission each time.

Third party inputs also need attention. Check whether the software includes:

• open source software subject to licence conditions
• stock code or templates
• third party APIs or SDKs
• subcontractor contributions
• cloud platform dependencies
• licensed assets such as fonts, images, or libraries

If those elements are present, the deed should not promise ownership your developer cannot legally transfer. Instead, the wider contract should explain what third party components are used and what rights your business receives.

Moral rights and further assurances

Software projects can involve materials that attract copyright-related creator rights beyond simple ownership language. A deed may include moral rights consents, where appropriate, so the business can edit, adapt, or use the materials without later objections from the creator.

Further assurance clauses are also useful. These require the assignor to sign additional documents later if needed, for example during an investment round, sale process, or trade mark and IP due diligence review. Without that obligation, a missing signature years later can become a real operational problem.

Confidentiality and access

Owning IP is not enough if the practical handover is poor. Before you sign, check how your business will receive and control the software assets.

The supporting contract or deed should address:

• handover of source code repositories and administrator credentials
• delivery of technical documentation and deployment instructions
• transfer of project management records and design files
• confidentiality obligations for business information and product plans
• return or deletion of sensitive materials at the end of the engagement

If customer or user data is involved, privacy obligations also matter. In New Zealand, businesses should think about their responsibilities under the Privacy Act 2020, particularly where a developer can access personal information during testing, support, or deployment, and whether a privacy notice needs updating.

Warranties and infringement risk

An assignment deed often sits alongside warranties from the developer. Those warranties can be just as important as the transfer itself.

Your business may want the developer to confirm that the work is original to the extent promised, that they have authority to assign it, and that using the deliverables as intended will not knowingly infringe another party’s rights. No warranty can remove all risk, but it can improve your position if a dispute arises later.

If software services are being supplied to your business, other contract and service quality issues may also sit in the background. Depending on the circumstances, New Zealand consumer and fair trading rules can affect service representations and business conduct, although business-to-business contracts often deal with these points expressly. The key point is that ownership wording should not be separated from the rest of the commercial deal.

Common Mistakes With Software IP Assignment Deed

The most common mistake is assuming a single sentence about ownership fixes everything. In practice, software ownership problems usually come from gaps between the legal document and the way the project was actually delivered.

Using a generic template with no software detail

Many businesses use a broad IP assignment form that was never written for software. It may work badly if the project involves source code repositories, third party libraries, staged releases, or ongoing maintenance.

A deed drafted for software should reflect how development happens in real life. It should deal with custom code, pre-existing code, open source use, future improvements, and handover rights.

Forgetting subcontractors and agencies

If you hire an agency, the person signing your contract may not be the person writing the code. That matters because the agency needs to have the right to pass ownership to you.

Businesses often fail to check whether the agency has proper assignments from its own staff and contractors. If that chain of title is weak, your deed may not deliver the ownership you thought you were getting.

Leaving founder-created IP outside the company

Early stage businesses regularly build their first version before formal company documents are complete. One founder may register domains, buy software tools, design the product, and write the code in a personal capacity.

If that IP is never assigned into the company, problems can appear when a new investor asks for proof of ownership. This is also relevant where a founder leaves on bad terms. Cleaning up founder IP early is usually much easier than trying to reconstruct ownership later.

Ignoring open source obligations

Open source software is common and often entirely legitimate to use. The mistake is not open source itself, it is failing to understand the licence conditions attached to it.

Some open source licences are low risk for commercial use, while others impose conditions that may affect distribution, disclosure, or modification practices. If your product depends heavily on open source components, the deed and development contract should acknowledge that fact rather than pretending the whole software stack is fully assignable.

Not matching the deed to the commercial contract

An IP assignment deed does not replace your development agreement. If one document says the client owns all project IP and another says the developer keeps all materials until full payment and grants only a limited licence, conflict can arise.

Before you sign, compare the documents side by side. Check whether they align on ownership, payment milestones, acceptance testing, support, termination rights, and what happens if either party walks away before completion.

Failing to secure practical control

Founders sometimes celebrate getting an assignment signed, then discover they still do not have repository access, passwords, build instructions, or hosting control. Legal ownership without operational access can stall your business.

This issue becomes acute if the relationship breaks down. If another developer cannot step in quickly, your business may own the code on paper but still be unable to maintain the product.

Relying on verbal promises

“Don’t worry, it’s yours” is not enough. If ownership matters to your business model, the document should say so clearly and completely.

This is especially true before you spend money on setup, before you invest in branding around the software product, and before you sign customer contracts that assume your business controls the platform. A vague promise can create a chain of later problems with customers, investors, and acquirers.

FAQs

Do I automatically own software if I paid a developer to build it?

Not necessarily. Payment alone does not always transfer IP ownership, especially where the developer is an independent contractor, consultant, or agency. The contract and any assignment deed need to state clearly who owns the software and related materials.

What is the difference between a software IP assignment deed and a software licence?

An assignment transfers ownership to your business. A licence lets your business use the software under stated conditions while ownership stays with the developer or another rights holder. Which one is suitable depends on how much control and exclusivity your business needs.

Can a deed assign future software that has not been written yet?

It can be drafted to deal with future IP, but the wording needs to be clear. This is particularly important for staged development, ongoing upgrades, and work created after the initial contract date.

What if the software includes open source or third party components?

Your business may not be able to receive full ownership of those components. Instead, the agreement should identify them, explain the relevant licence position, and make sure your business has the rights needed to use and maintain the finished product.

Do founders need an IP assignment if they built the software before the company was formed?

Usually, yes. If a founder created key software personally before the company was incorporated or before formal documentation was signed, an assignment to the company is often needed to tidy up ownership and avoid issues in due diligence.

Key Takeaways

• A software IP assignment deed is used to transfer ownership of software-related IP from the creator to the business that needs to control it.
• New Zealand businesses should not assume that paying for software development means they automatically own the code, designs, documentation, and related assets.
• The deed should clearly identify what is being assigned, when ownership transfers, what background IP is excluded, and what ongoing licence rights are needed.
• Open source software, third party tools, subcontractors, and founder-created IP can all complicate ownership if not addressed properly.
• The assignment should match the wider commercial contract on payment, warranties, confidentiality, support, termination, and handover of practical access.
• Before you sign, make sure your business can prove ownership and actually control the repositories, credentials, documentation, and project materials it needs.

If you want help with IP ownership clauses, contractor and developer agreements, founder IP transfers, you can reach us on 0800 002 184 or team@sprintlaw.co.nz for a free, no-obligations chat.