Who Owns Custom Software in Australia?

When a business pays a developer to build software, ownership is not automatic. A common mistake is assuming the invoice, proposal or project brief transfers copyright. Another is only asking for source code access after the relationship has broken down. Many businesses also overlook open source libraries, developer templates and pre-existing tools that sit inside the finished product.

For founders, product managers and SMEs, the real question is not just who owns custom software. It is whether your business can use, modify, commercialise, sell, maintain and scale the product without needing the developer's permission each time.

A well drafted software development agreement should make that clear from the start. It should separate new project IP from the developer's existing IP, deal with source code and repositories, identify third party components, and include an assignment or licence that matches your commercial plans.

Software Ownership Checklist for Commissioned Projects

Your business should confirm ownership and use rights before the developer starts building, because Australian copyright law will not fill every gap in your favour.

Under the Copyright Act 1968, software code is generally protected as a literary work. The person or company that creates the code will often be the first copyright owner, unless there is a different rule or agreement in place. If you hire an employee to develop software in the course of their employment, the employer will usually own the copyright. If you engage an external developer, freelancer or agency, the default position is different. Paying for the work does not necessarily mean your business owns the copyright.

That is why a custom software agreement in Australia should answer the practical ownership questions, not just describe the build.

• What is being created? Identify the app, platform, integration, scripts, APIs, database architecture, documentation, designs and any related deliverables.
• Who owns the new code? State whether the business receives an assignment of copyright in the new project deliverables, or only a licence to use them.
• What does the developer keep? Carve out the developer's background IP, reusable libraries, frameworks, templates, know-how and general skills.
• Can the business modify the software? Confirm whether your team or another developer can edit, maintain, extend and integrate the code.
• Can the business commercialise it? If you plan to sell subscriptions, white-label the product, franchise the model or raise capital, your rights should allow those activities.
• Who has source code access? Set out repository access, admin permissions, credentials, deployment rights and handover steps.
• Are third party components allowed? Require disclosure of open source, APIs, plugins, SDKs, fonts, datasets and paid services used in the build.
• When does ownership transfer? Some agreements transfer IP on creation. Others transfer on payment, milestone acceptance or final completion.
• What happens if the project ends early? Clarify rights to partially completed work, prototypes, documentation and paid milestones.

For example, a retailer might pay an agency to build a custom inventory tool that connects Shopify, accounting software and a warehouse system. If the agreement only says the agency will deliver a working tool, the retailer may not own the underlying code. It might only receive permission to use the system for its own business, while the agency keeps the right to reuse major parts of it for other clients.

That may be perfectly acceptable if the retailer only needs a working internal tool. It is risky if the retailer later wants to sell the software to other stores, bring development in-house or make the tool part of a business sale.

Foreground IP, Background IP and Developer Tools

Most software projects contain more than one type of IP, so ownership clauses need to distinguish between foreground IP and background IP.

Foreground IP is the new material created specifically for your project. In a software development project, this might include custom source code, user interface designs, database schemas, workflow logic, technical documentation and configuration work created to meet your brief.

Background IP is material that already existed before the project, or material the developer uses across multiple projects. It can include code libraries, internal tools, frameworks, templates, generic modules, deployment scripts, design systems, testing tools, algorithms and know-how.

A fair software development IP ownership arrangement often looks like this: the client owns or has broad rights to the foreground IP, while the developer retains its background IP and grants the client a licence to use any background IP that is embedded in the final software.

The commercial problem arises when the agreement does not define the categories. If a developer uses its pre-built booking engine as the base for your new platform, you may own the custom features developed for your business, but not the booking engine itself. Without a licence to the booking engine, your custom features may be difficult or impossible to use independently.

A useful development agreement should deal with these points clearly:

• Definitions: define foreground IP, background IP, deliverables, source code, object code, documentation and project materials.
• Assignment: state whether the developer assigns copyright in the foreground IP to your business.
• Background IP licence: grant your business a licence to use any developer-owned background IP included in, required for or connected to the deliverables.
• Scope of licence: set out whether the licence is perpetual, worldwide, royalty-free, transferable, sublicensable and able to be used for commercial purposes.
• Restrictions: identify any limits on copying, modifying, reselling, sublicensing, reverse engineering or using the software for other businesses.
• Developer reuse: confirm whether the developer can reuse generic learnings, non-confidential concepts and reusable components for other clients.

From a founder's perspective, the wording matters because investors and acquirers often ask whether the company owns its core IP. If your product depends on a developer's retained IP and the licence is narrow, revocable or non-transferable, that can affect valuation, due diligence and the buyer's willingness to proceed.

From a developer's perspective, it is also reasonable not to give away every reusable tool they have built over years of work. A balanced custom software agreement can let the client operate and commercialise the product while allowing the developer to keep its general libraries and methods.

Problems often appear in phrases that sound broad but are not precise. A clause saying the client owns the final product might not clearly transfer copyright. A clause saying the developer retains all IP might leave the client with insufficient rights to use the very system it paid for. A clause saying the client has a licence for internal business use only might prevent the client from offering the software to customers.

Where the product is business-critical, ask for a written assignment of the foreground IP and a broad licence to any background IP needed to use, maintain and exploit the software. The assignment should be in writing and signed, because copyright assignments need clear written documentation. Verbal assurances are not enough for a clean ownership position.

Source Code, Repositories and Practical Control

Owning or licensing software is not very useful if your business cannot access the source code, build environment, credentials and documentation needed to operate it.

Source code is the human-readable code developers use to build and change software. Object code or compiled code is what the system may run in production. A business can have a software licence without receiving source code, especially in SaaS or managed service arrangements. That might be fine for a standard vendor product, but custom development usually needs more control.

If the developer holds all repository access, cloud admin permissions and deployment credentials, your business may be dependent on that developer even if the contract says you own the IP. This becomes a serious issue when the developer becomes unavailable, raises maintenance fees, misses deadlines or disputes payment.

A strong software development contract should describe how control will work during the project and at handover.

• Repository ownership: decide whether the code repository sits under the client's GitHub, GitLab, Bitbucket or similar organisation from day one.
• Access levels: specify admin, maintainer and read-only access for the client, developer and any other contractors.
• Commit history: require regular commits so the client can see progress and preserve the build history.
• Deployment credentials: identify who controls hosting, cloud services, domain names, API keys, databases, analytics and app store accounts.
• Documentation: require setup instructions, architecture notes, environment variables, build steps, test instructions and third party service details.
• Handover timing: set milestones for access, not just a final handover after all work is complete.
• Escrow or backup: consider source code escrow or periodic code backups for high-value systems where the developer will retain operational control.

For a startup building its first SaaS product, repository control can be just as important as copyright ownership. If the product is hosted on the developer's cloud account and all keys are in the developer's name, the startup may struggle to move quickly when hiring an internal CTO or changing agencies. Investors may also ask who controls the codebase, production environment and essential accounts.

The agreement should also deal with suspension rights. Developers sometimes want the right to suspend access if invoices are unpaid. Businesses should be careful with broad suspension rights where the software supports customer operations, payments, bookings, healthcare workflows or other critical services. A more balanced approach might require notice, limit suspension to non-critical support work, or preserve access to data and production systems.

Data access is separate from software ownership. Your business may own customer data or have Privacy Act 1988 obligations in relation to personal information, while the developer owns code or infrastructure. If the software handles personal information, payment data or commercially sensitive records, the contract should address data security, access controls, breach notification, backups and return or deletion of data at the end of the relationship.

Source code access should also line up with your maintenance plan. If the developer will maintain the software, the agreement should set out IT support hours, response times, bug fix obligations, update processes and security patch responsibilities. If another developer may maintain it later, your rights should allow third parties to access and modify the code on your behalf.

Open Source, Third Party Components and Assignment Clauses

Open source and third party components can be useful, but they can also restrict how your business uses, sells or keeps control of custom software.

Modern software is rarely written entirely from scratch. Developers commonly use open source packages, plugins, SDKs, APIs, datasets, fonts, icons, AI tools, database products, cloud services and paid libraries. These can speed up development and reduce cost. They also bring their own licence terms.

Some open source licences are permissive and relatively easy to comply with. Others have copyleft obligations that may require distribution of source code or impose conditions on derivative works. If your business plans to distribute software to customers, embed it into hardware, provide a white-label platform or offer enterprise licences, you need to know what third party terms apply.

The contract should require the developer to disclose and manage third party components. Useful clauses include:

• Approved components: the developer must only use open source or third party materials that are approved, suitable for the project and compatible with the client's intended use.
• Disclosure schedule: the developer must list key packages, licences, versions, paid tools, APIs and restrictions.
• No problematic licences: the developer must not include components that would require the client to release proprietary source code, unless the client has approved that risk.
• Compliance obligations: the developer must provide notices, attribution files and licence information needed for compliance.
• Paid subscriptions: the contract should identify who pays for ongoing third party services and whether accounts are held in the client's name.
• Replacement rights: the client should be able to require replacement of components that create security, licensing or commercial issues.

Assignment clauses are the clauses that transfer ownership of IP from the developer to your business. They should be specific and practical. A good assignment clause will usually identify the assigned materials, state when the assignment occurs, confirm it includes copyright and related rights in the deliverables, and require the developer to sign further documents if needed.

Timing can be negotiated. Some developers will only assign IP after full payment. Clients often prefer assignment as the work is created, with payment protections dealt with separately. A middle position is assignment on payment of each milestone, so the client owns what it has paid for even if the project stops.

Businesses should also check whether the developer has the right to assign the IP. If an agency uses employees, contractors or overseas freelancers, the agency should warrant that it has secured the necessary IP rights from those people. Otherwise, you may receive an assignment from the agency that does not fully cover the people who actually wrote the code.

Moral rights should not be ignored. In Australia, individual creators have moral rights in copyright works, including rights of attribution and integrity. These rights are personal and generally cannot be assigned, but creators can give consent to certain acts or omissions. Software projects often include moral rights consent wording so the client can modify, adapt and commercialise deliverables without needing individual attribution in every context.

Confidentiality also sits alongside IP ownership. A developer may see your product roadmap, customer data, pricing model, workflows and trade secrets. A confidentiality clause should restrict use and disclosure of that information, require secure handling, and continue after the project ends. If the developer is allowed to showcase the project in a portfolio, the agreement should say when and how that can happen.

For businesses using AI-assisted development, the contract should be clearer again. Developers may use code suggestions, AI tools or generated content as part of their workflow. Your agreement can require disclosure of material AI-generated code, compliance with tool terms, checks for third party infringement risks, and confirmation that no confidential information is entered into public tools without approval.

Finally, match the IP model to your commercial goal. If you are commissioning a one-off internal dashboard, a broad perpetual licence may be enough. If you are building the core product for a SaaS company, assignment of foreground IP plus source code control will usually be more appropriate. If you are licensing a developer's existing platform with custom configuration, you may not own the platform, but you should secure clear rights to use your configuration, data and custom features.

FAQs

Do I Own Custom Software If I Paid a Developer to Build It?

Not automatically. In Australia, paying a developer usually gives you contractual rights to receive the agreed work, but it does not necessarily transfer copyright. You need a written software development contract with a clear assignment or a licence broad enough for your intended use.

What Is the Difference Between Owning Code and Having a Licence?

Ownership means your business holds the copyright in the relevant code and can generally control copying, modification and commercial use. A licence gives permission to use the code on agreed terms. A licence can be broad and long-term, but it may still contain limits on resale, transfer, modification or use outside your business.

Should My Business Ask for Source Code?

Yes, if the software is custom, business-critical or likely to be maintained by someone else later. Source code access, repository control, credentials and documentation help your business avoid being locked into one developer. For some managed SaaS-style arrangements, access to source code may be less common, but the contract should still explain your rights and exit options.

Can a Developer Reuse Code From My Project for Other Clients?

That depends on the contract. Developers often want to reuse background IP, generic modules and know-how. Your business may want to restrict reuse of confidential information, unique product features or code assigned to you. The agreement should separate reusable developer materials from project-specific deliverables.

What Should I Check Before Signing a Custom Software Agreement in Australia?

Check the IP assignment or licence, source code access, background IP carve-outs, open source rules, confidentiality, data handling, milestones, payment terms, warranties and termination rights. The agreement should match your plan for using, maintaining and commercialising the software.

Key Takeaways

• Paying for custom software does not automatically mean your business owns the copyright in the code.
• A strong software development contract should separate foreground IP from the developer's background IP and tools.
• Source code access, repository control, credentials and documentation are essential for practical control of a custom build.
• Open source packages, APIs and paid third party tools should be disclosed and checked against your commercial plans.
• Assignment clauses should be written clearly, signed, and supported by rights from any employees, contractors or freelancers involved in the build.
• The right structure depends on whether you need an internal tool, a commercial SaaS product, a white-label platform or a customised version of an existing system.

If you are commissioning software, Sprintlaw can help review or prepare your development agreement, IP assignment, background IP licence and confidentiality terms so your rights match your product plans. Call 1800 730 617 or email team@sprintlaw.com.au for a free, no-obligations chat.