Who Owns Software Improvements in Australia?

A software build rarely stays within the first scope. A client asks for a dashboard tweak, the developer reuses a library from an earlier project, a paid customisation becomes useful for every future customer, and nobody is sure who owns the improvement.

The biggest mistakes are assuming payment equals ownership, treating all code changes as one bucket, or forgetting that reusable tools and client-specific deliverables need different wording. A vague software services agreement IP clause can leave both sides exposed when the client wants to modify the product later or the developer wants to use similar code elsewhere.

A clear position on software development IP ownership lets you decide what can be assigned, what should be licensed, what remains background IP, and what happens when enhancements are created during support, maintenance or change requests.

Software Improvements Ownership Checklist

The owner of a software improvement is usually the person or business identified in the contract, and without clear wording the default copyright rules may not match either party's expectations.

For startups, agencies and SME clients, the practical question is rarely just who owns software improvements. The harder question is which improvements should be owned by the client, which should stay with the developer, and which should be shared through a licence.

Before a project starts, or before a change request is approved, separate the work into clear categories:

• Client materials: brand assets, content, datasets, business rules, confidential information, workflow descriptions and existing software supplied by the client.
• Developer background IP: pre-existing frameworks, libraries, templates, deployment scripts, coding patterns, internal tools and know-how the developer brings to the project.
• Bespoke deliverables: code, documentation, designs or integrations created specifically for the client's project and paid for under the scope.
• Improvements to existing client software: bug fixes, new modules, feature enhancements, refactoring, API updates and performance changes made to the client's codebase.
• Reusable components: generic modules, connectors, configuration tools, admin panels, analytics functions or design systems that the developer may want to use for other customers.
• Third party materials: open source packages, commercial SDKs, cloud platform components, stock assets and marketplace plugins.

Once those buckets are clear, the ownership position can be drafted with much less friction. For example, a client may own the bespoke booking workflow developed for its platform, while the developer keeps ownership of its reusable authentication module and grants the client a licence to use it as part of the platform.

A useful software improvement clause should answer these points:

1. Who owns the pre-existing IP each party brings to the project?
2. Who owns new code written specifically for the client?
3. Who owns modifications to the client's existing software?
4. Can the developer reuse generic ideas, know-how and non-client-specific code?
5. Does the client receive source code, object code, documentation or only hosted access?
6. Can the client modify, maintain, sublicense, transfer or commercialise the software?
7. What happens if invoices are unpaid or the project is terminated early?
8. How are open source and third party licence restrictions handled?

Many disputes start because a proposal says the client receives the deliverables, but does not define whether that means ownership, a licence, hosted access, or practical control over source code. For a client, that can become a problem when switching developers or seeking investment. For a developer, it can block reuse of ordinary building blocks across future projects.

How Australian IP Law Treats Code Changes

Australian copyright law protects software code automatically, but payment for development work does not automatically transfer ownership to the paying client.

Computer programs are generally protected as literary works under the Copyright Act 1968 (Cth). Copyright can protect source code and object code, as well as some related written materials such as technical documentation. It does not protect a broad idea for an app, a business concept, or a desired feature in isolation.

The default ownership position depends on who creates the code and in what capacity. If an employee writes code as part of their employment duties, the employer will usually own the copyright in that work unless the employment contract says otherwise. This is one reason software businesses should ensure their employment contracts deal properly with IP created by developers, designers and product staff.

Contractors are different. If an independent contractor writes code for a client, the contractor will usually own the copyright unless there is a written assignment or another arrangement that transfers ownership. A statement in an invoice saying paid in full will not necessarily do the job. Copyright assignments should be in writing and signed by or on behalf of the owner assigning the rights.

This distinction matters in common project scenarios:

• A freelance developer builds a new feature for a client's existing platform: unless the contract assigns ownership, the developer may still own copyright in the new code, while the client owns or controls the original platform code.
• An agency uses its own boilerplate to deliver a custom website application: the agency may want to keep the boilerplate and assign only the bespoke client-specific elements.
• A SaaS company pays a contractor to improve its core product: the SaaS company will usually want an assignment of the improvements so its product can be funded, sold or licensed without gaps.
• A client pays for configuration of a third party platform: ownership may be limited because the platform provider's terms control the underlying system.

Trade marks, business names and domain names are separate from software copyright. A client's product name may need trade mark protection through IP Australia, but that does not decide ownership of code improvements. Patents can be relevant for some computer-implemented inventions, but many software improvement questions are primarily about copyright, confidential information and contract rights.

Confidential information is also part of the picture. A developer may learn how the client's pricing engine works, how its matching algorithm is structured, or how its internal workflow is designed. Even where copyright ownership is clear, the contract should prevent misuse of confidential information and data after the project ends.

Privacy and data protection issues can arise if improvements involve customer data, analytics, integrations or testing environments. The Privacy Act 1988 (Cth) may apply depending on the business and the type of personal information handled. Even where the Act does not apply, commercial clients often expect secure handling of production data, access controls and deletion processes.

Splitting Background IP, Project IP and Reusable Components

A fair software services agreement usually does not give one party everything. It separates background IP, project IP and reusable components so each side gets what it reasonably needs.

For many projects, the cleanest structure is not all IP belongs to the client or all IP belongs to the developer. A more commercial approach is to define different layers.

Background IP

Background IP is what a party already owned before the project, or what it develops independently outside the project. For developers, this often includes standard code libraries, starter templates, API wrappers, testing scripts, deployment tools, UI components, documentation templates and accumulated know-how.

For clients, background IP may include their existing source code, databases, brand assets, product requirements, proprietary processes, customer content and internal documentation.

A strong developer IP clause in Australia will usually say each party retains ownership of its background IP. If background IP is needed to use the final deliverables, the other party receives a licence for that limited purpose. This stops accidental transfer of valuable assets that were never meant to be sold as part of one project.

Bespoke Project IP

Bespoke project IP is the work created specifically for the client's project. This may include custom code, a unique integration, a tailored admin panel, a new reporting module or documentation prepared for the client's internal team.

Clients often expect to own bespoke deliverables because they paid for them. That expectation is reasonable in many custom development projects, especially where the software is core to the client's business. However, the contract still needs to say this clearly.

From the developer's side, assigning all project IP without carve-outs can be risky. If the wording says the client owns every idea, tool, method, improvement and derivative work created during the engagement, the developer may be unable to reuse ordinary techniques or generic components. That can be commercially unrealistic for agencies and productised service providers.

Reusable Code and Common Tools

Reusable components should be carved out expressly, because they are the main grey area between paid customisations and developer-owned IP.

Consider a developer who builds a payment reconciliation module for a retail client. If the module contains the client's unique accounting rules, reporting categories and data mapping, the client may expect ownership of those client-specific parts. If the module also includes a generic connector to a payment gateway, the developer may want to reuse that connector for future clients.

The contract can deal with this by stating that:

• client-specific business logic, content and configuration belong to the client;
• generic tools, libraries and methods remain owned by the developer;
• the client receives a licence to use any developer-owned components embedded in the deliverables;
• the developer cannot reuse the client's confidential information, data or distinctive product design; and
• similar features can be built for other clients as long as confidential information and assigned client IP are not copied.

This balance is especially useful for software agencies, SaaS implementers and technical consultants. They can deliver a working product while protecting the reusable foundations of their business.

Open Source and Third Party Code

Open source code and third party software are not owned by either party simply because they appear in the project. They are used under their own licence terms.

Some open source licences are permissive and allow broad commercial use. Others impose conditions around notices, distribution, source code availability or derivative works. The contract should require the developer to identify material third party components, follow licence obligations and avoid introducing code that conflicts with the client's commercial use case.

Clients should also be realistic. A custom application will often depend on open source packages, cloud services or external APIs with separate API terms. The key is not to ban all third party components, but to know what is being used, what restrictions apply and who is responsible for maintaining or replacing them if needed.

Modification Rights, Licences and Payment Triggers

Ownership is only one part of the deal. The client also needs practical rights to use, modify and maintain the software, and the developer needs clear limits on when those rights apply.

A client may not need full copyright ownership if it has a broad enough licence. For example, a business using custom internal software may only need the right to use, copy, modify and maintain it for its own operations. A SaaS founder, on the other hand, may need ownership or an exclusive licence so it can commercialise the product, raise capital or sell the company.

Client software modification rights should be drafted around the client's actual plans. Useful questions include:

• Will the client operate the software internally, or sell access to customers?
• Will the client need to appoint another developer later?
• Will the client receive source code and documentation?
• Can the client create derivative works or new versions?
• Can the software be transferred to a related company, purchaser or investor-backed entity?
• Can the client sublicense the software to franchisees, customers, contractors or channel partners?

If the client needs to modify the software after handover, the licence should say so directly. A narrow licence to use the deliverables may not be enough. The contract should also deal with access to repositories, build instructions, dependencies, credentials, technical documentation and any source code escrow arrangements. Legal rights are less useful if the client cannot practically run or maintain the code.

Assignment vs Licence

An assignment transfers ownership. A licence gives permission to use IP on agreed terms.

Assignments are common where a client is paying for custom software that becomes a business asset. Licences are common where the developer is supplying access to its own platform under a software licence, using reusable components, or providing a productised service.

A licence can be narrow or broad. It can be perpetual, time limited, exclusive, non-exclusive, revocable, irrevocable, worldwide, internal-use only, transferable or non-transferable. These words matter. A startup that plans to commercialise software should avoid a licence that only permits internal business use. A developer that wants to reuse its code should avoid an assignment that captures all related improvements without carve-outs.

Payment and Milestones

Many agreements link IP transfer to payment. This protects developers from handing over ownership before they are paid, while giving clients certainty once they have met their payment obligations.

A common structure is that ownership of agreed project IP transfers only after full payment of the relevant fees. Before payment, the client may receive a limited licence to review or test the work. If the project is cancelled halfway through, the contract should say whether the client can use partially completed work and what fees must be paid first.

For ongoing support, managed services or maintenance, each change request should identify whether the resulting work is a bug fix, client-owned enhancement, developer-owned reusable improvement, or third party configuration. This avoids the common problem where the main contract is clear, but later tickets and sprint tasks quietly create new uncertainty.

Examples of Common Ownership Models

Different commercial models call for different IP positions. These examples show how the same improvement can be treated differently depending on the deal.

• Custom build for a funded startup: the startup owns bespoke code and improvements after payment, while the developer retains background tools and grants a licence to embedded components.
• Agency builds similar portals for multiple SMEs: the agency owns its reusable platform and grants each client a licence, while each client owns its content, branding and custom configuration.
• Developer improves a client's legacy system: the client owns modifications to its existing codebase, but the developer retains ownership of diagnostic tools and general code snippets used across projects.
• SaaS vendor performs a paid customisation: the vendor keeps ownership of the SaaS platform and any general product improvements, while the customer may receive a contractual right to use the custom feature during its subscription.
• Joint product experiment: both parties may need a special collaboration agreement covering ownership, revenue sharing, confidentiality, roadmap control and exit rights.

Australian Consumer Law obligations may also be relevant where software services are supplied to customers. Statements about what the software will do should match the contract, proposal and marketing materials. Overpromising exclusive ownership or unlimited modification rights can create commercial and compliance issues if the written terms say something narrower.

For developers, clear scope control is just as important as IP wording. A client who owns an improvement may still need to pay for additional development, support, hosting, security updates or compatibility work. For clients, clear acceptance criteria and handover obligations help ensure the paid customisation can actually be used.

FAQs

Who owns software improvements if the contract is silent?

The answer depends on who created the improvement and their relationship with the business. Employees usually create copyright for their employer when acting within their duties, while contractors usually retain copyright unless it is assigned in writing. A silent contract is risky because the default position may not reflect the commercial deal.

Does paying a developer mean the client owns the code?

No. Payment alone does not automatically transfer copyright in software. The client may have some implied rights to use what was delivered, but that may not include ownership, source code access, modification rights or the right to commercialise the software.

Can a developer reuse code from a client project?

A developer can reuse code only if the contract and the nature of the code allow it. Generic tools, know-how and background IP can often be reused if properly carved out. Client confidential information, client-owned code, unique business logic and assigned deliverables should not be reused without permission.

Should a SaaS customer own paid customisations?

Usually not the whole SaaS platform. A SaaS provider will normally retain ownership of its platform and product improvements. The customer may receive access to the customisation under the subscription, or ownership of narrow customer-specific materials if the contract says so.

What should a software services agreement IP clause include?

It should define background IP, project IP, improvements, reusable components, third party materials, licences, assignment timing, payment conditions, source code access, modification rights, confidentiality and what happens after termination.

Key Takeaways

• Software improvement ownership should be split into background IP, bespoke deliverables, reusable components and third party materials.
• Under Australian copyright law, paying a contractor does not automatically give the client ownership of new code or enhancements.
• Clients should secure the rights they need to use, modify, maintain, commercialise or transfer the software.
• Developers should protect their reusable tools, libraries, know-how and generic product improvements with clear carve-outs.
• Change requests, support tickets and paid customisations should state whether new work is assigned, licensed or retained by the developer.
• Open source packages, cloud services and third party SDKs need separate licence checks because neither party may own them.

If you need help settling ownership of software improvements, Sprintlaw can assist with your software services agreement, IP assignment wording, developer licence terms and confidentiality protections. Contact us on 1800 730 617 or team@sprintlaw.com.au for a free, no-obligations chat.