Who Owns Code Written By A Freelance Developer?

Priya runs a Melbourne startup building a booking platform for allied health clinics. She finds a talented freelance developer, agrees on a price by email, pays each invoice on time, and launches a working MVP three months later.

Then an investor asks a simple question during due diligence: does the company actually own the code?

Priya assumes the answer is yes because she paid for it. In Australia, that assumption can cause real problems. Payment by itself usually doesn't transfer copyright in software from a contractor to your business.

The good news is this can be fixed with the right agreement before work starts, or sometimes cleaned up afterwards. The key is knowing what your developer contract needs to say.

Who Owns Code Written By A Freelancer In Australia?

Usually, the freelance developer owns the copyright in the code they write unless there's a written assignment transferring it to your business.

In Australia, software code is generally protected as a literary work under the Copyright Act 1968. The person who creates the code is usually the first owner of copyright. If that person is your employee and they create the code as part of their job, your business will often own it. But if they're an independent contractor or freelancer, the default position is different.

For startups, this distinction matters. A freelancer might build:

• front-end code for your app or website
• back-end infrastructure and API terms
• custom plugins, integrations or automations
• databases, scripts or deployment tools
• documentation and technical specs

If your agreement doesn't clearly transfer the relevant IP, your business may only have an implied right to use the code for the purpose you hired the developer for. That might be enough to launch your MVP, but it may not be enough to raise capital, sell the business, license the platform to customers, or stop the developer reusing parts of the work elsewhere under a separate copyright licence.

This is why investors, acquirers and enterprise customers often ask for evidence of IP ownership. They want to see signed contractor agreements, not just invoices and emails.

Does Paying A Freelance Developer Mean You Own The IP?

No, payment alone usually doesn't mean you own the IP in the code.

Paying an invoice proves you paid for services. It doesn't automatically prove the developer assigned copyright to your business. Think of it like paying a photographer for a photo shoot. You may get the files and a right to use them, but that doesn't always mean you own the copyright unless the agreement says so.

For copyright to be assigned in Australia, the assignment generally needs to be in writing and signed by the owner of the copyright. For contractor-created software, that means your agreement should clearly say that the developer assigns the IP to your company.

A Worked Example

Say Priya's company pays a freelance developer $18,000 to build a prototype booking platform. The developer sends three invoices for $6,000 each. The emails say things like build MVP and final handover, but there's no signed IP assignment.

Six months later, Priya wants to raise seed funding. An investor asks whether the company owns the platform code. Priya can show payment records and GitHub access, but not a signed document transferring copyright.

The practical result is that Priya may need to go back to the developer and ask them to sign a deed of assignment. If the relationship is still friendly, that might be straightforward. If there's been a disagreement, the developer might ask for more money, delay signing, or refuse to give broad rights.

That uncertainty can slow down a raise, complicate a business sale, or make customers nervous about signing larger contracts.

What Should An IP Assignment Clause Say?

An IP assignment clause should clearly transfer ownership of the developer's project IP to your business, including future rights in work created during the project.

A strong clause doesn't need to be full of legal jargon, but it does need to be precise. At a minimum, it should deal with what IP is being assigned, when the transfer happens, and whether your business can modify, commercialise and license the code.

Your developer agreement should usually cover:

• Project IP: the code, architecture, documentation, designs, databases and other materials created for your project.
• Assignment: the developer assigns all rights, title and interest in the project IP to your company.
• Timing: the assignment applies as work is created or on payment, depending on what you negotiate.
• Future copyright: the assignment covers rights that come into existence as the developer continues working.
• Further assurance: the developer must sign extra documents if needed to confirm ownership later.
• Use and commercialisation: your business can copy, modify, maintain, sublicense, sell and otherwise commercialise the product.

Be careful with clauses that say your business owns deliverables but don't define deliverables properly. For example, if deliverables only means the final compiled app, that may leave out source code, technical documentation, deployment scripts, test suites, source code escrow materials and admin tools.

If the developer is working through their own company, make sure the contracting party is the company and that the company assigns the IP, with any subcontractor arrangements covered. You may also need warranties that the individuals doing the coding have assigned their rights to that company first.

What About Pre-Existing Code, Libraries And Developer Tools?

Pre-existing code should usually stay with the developer, but your business needs a clear licence to use anything embedded in your product.

Many developers don't start from a blank screen. They may bring their own snippets, frameworks, internal libraries, templates, build tools or reusable components. That's normal. The risk is when your agreement pretends your company owns everything, even material the developer created years before your project.

A practical contract separates IP into categories:

• Your existing IP: your brand, product ideas, customer materials, business logic and confidential information.
• Developer background IP: tools, code libraries and know-how the developer already owned before the project.
• Project IP: new code and materials created specifically for your product.
• Third party materials: open-source packages, paid libraries, APIs and other components owned by someone else.

For developer background IP, you generally want a licence that's broad enough for the product to function and grow. That licence should allow your business to use, reproduce, modify, host, maintain, sublicense and commercialise the product as part of your business.

You don't always need to own every tool the developer uses. But you do need to know whether your product depends on something you can't control. For example, if a core part of your platform relies on a private library that the developer can withdraw later, your commercial risk is much higher.

Ask the developer to list any background IP or third party materials before work starts. If they don't list anything, the agreement can say they can't later claim undisclosed components are excluded from your ownership rights.

How Should Your Agreement Deal With Open-Source Software?

Your agreement should allow sensible open-source use, but require disclosure, licence compliance and approval for higher-risk licences.

Open-source software is common in modern development. It can save time, reduce cost and improve security when used properly. The issue isn't open source itself. The issue isn't knowing which packages are in your product or what obligations come with them.

Open-source licences vary. Some are permissive and usually easier to manage, such as MIT or Apache-style licences. Others can impose stricter obligations, especially if you distribute the software or combine it with proprietary code. Depending on the licence and how the code is used, obligations might include:

• including copyright notices or licence text
• disclosing modifications to open-source code
• making certain source code available
• not using trademarks connected with the project
• passing licence terms on to your customers

For a SaaS startup, the risk profile can be different from downloadable software because customers may access the software over the internet rather than receiving a copy. But you shouldn't assume that means every licence is fine. The answer depends on the specific licence, architecture and commercial model.

Your developer agreement can help by requiring the developer to:

• get your approval before using open-source components that impose source disclosure or similar obligations
• keep a register of open-source packages, versions and licences
• avoid components that conflict with your plan to commercialise the product
• notify you about known security vulnerabilities
• follow your technical policies for package management and updates

This is also useful for due diligence. If an investor asks what open-source software is in the platform, you don't want to start piecing it together from old commits and Slack messages.

Do Moral Rights Matter For Software Developers?

Yes, moral rights can still matter, even where your business owns the copyright.

Under the Copyright Act 1968, creators have moral rights in certain works. These include the right to be attributed, the right not to have authorship falsely attributed, and the right of integrity. Moral rights are personal to the creator and can't be assigned in the same way copyright can.

For software projects, moral rights issues don't come up every day, but they can still create friction. Your business may need to:

• modify the code heavily over time
• combine the code with other products
• remove developer names from public-facing files or credits
• white-label the product for enterprise customers
• sell or license the platform to another company

Because moral rights can't simply be transferred, many developer agreements include a moral rights consent. This is where the developer consents to your business doing certain acts that might otherwise raise moral rights concerns, such as modifying the work, not attributing the developer in every context, or allowing future owners or licensees to adapt the software.

The consent should be tailored and reasonable. A broad, vague consent may not be as helpful as a clause that explains the kinds of things your business genuinely needs to do with the software.

You should also think about attribution from a commercial angle. Some developers are happy not to be credited publicly. Others may want portfolio rights. If you allow portfolio use, set limits around confidentiality, launch timing, screenshots, customer names and sensitive product information.

What Should A Contractor Software Development Agreement Include?

A contractor software development agreement should cover IP ownership, scope, payment, confidentiality, open-source use, moral rights, support and what happens if the project ends early.

A short email chain is rarely enough for a serious product build. Even a friendly freelancer relationship can get messy if the scope changes, deadlines move, or you disagree about whether the work is finished.

Here is a practical outline you can use when planning the agreement. This isn't a finished legal document, and a lawyer should tailor it before you use it.

1. Parties: name your company, including its ACN if it has one, and the developer or their company.
2. Project Scope: describe the product, milestones, deliverables, technical requirements and what is out of scope.
3. Fees And Payment: set out fixed fees, hourly rates, milestone payments, invoice timing and what happens if payment is disputed.
4. IP Assignment: transfer project IP to your business, including source code, documentation and future copyright.
5. Background IP: identify any developer-owned tools and give your business the licence it needs to use the product.
6. Open-Source Software: require disclosure, approval for higher-risk licences and a register of packages used.
7. Moral Rights Consent: allow your business to modify, commercialise and adapt the software without repeated approvals.
8. Confidentiality: protect your product plans, customer data, business model, credentials and technical information.
9. Data And Security: set rules for access, repositories, backups, credentials, privacy obligations and secure coding practices.
10. Warranties: require the developer to promise the work is original or properly licensed, and doesn't knowingly infringe third party rights.
11. Support And Maintenance: state whether bug fixes, handover, documentation and post-launch support are included.
12. Termination: explain when either party can end the agreement and what must be handed over if that happens.

If your product handles personal information, your agreement should also support your obligations under the Privacy Act 1988, especially around access controls, data handling and security. For customer-facing products, your terms with users should also line up with the Australian Consumer Law, particularly where you make promises about product functionality or subscriptions.

What If The Developer Has Already Built The Product?

You may still be able to fix the ownership position, but it's easier if you act before a dispute or funding deadline.

Start by gathering the records you already have. Keep copies of:

• signed agreements, if any
• emails or messages about ownership, handover and scope
• invoices, receipts and payment records
• repository access records and commit history
• documentation, tickets and project management notes
• lists of open-source packages and third party tools

Next, work out what you're missing. Common gaps include no signed IP assignment, no moral rights consent, no open-source register, unclear ownership of background code, or no promise that the code doesn't infringe someone else's rights.

If the relationship is positive, you can often ask the developer to sign a deed of assignment and confirm the position. A deed is often used because it can help formalise the transfer clearly, including for work already created. The wording needs to match what was actually built and what your business needs to do with it.

If the developer doesn't want to sign, don't rush into threats. You may still have contractual or implied rights, but the strength of those rights depends on the facts. Get advice before promising investors, customers or buyers that your company owns everything outright.

For future work, don't wait until the product is nearly finished. Put the contractor software development agreement in place before the developer gets access to your repositories, credentials or confidential roadmap.

Key Takeaways

• In Australia, paying a freelance developer usually doesn't transfer copyright in the code unless there's a written IP assignment.
• Your agreement should clearly say your business owns the project IP and can modify, license, sell and commercialise the product.
• Separate project IP from the developer's pre-existing tools, reusable code and third party materials.
• Open-source software is normal, but you need approval rights, licence records and rules for higher-risk components.
• Moral rights can't be assigned, so your agreement should include a practical consent for modifications and commercial use.
• If the product has already been built, a deed of assignment may help clean up the ownership position before funding, sale or launch.

If you'd like help with your developer contractor agreement, IP assignment, open-source clauses or software handover documents, you can reach us at 1800 730 617 or team@sprintlaw.com.au for a free, no-obligations chat.