The developer has just emailed you a draft agreement for the website or software they are about to build. Most of it is about scope, timing and payment, but buried in the middle is a clause headed "Intellectual Property" that talks about assignment, licences and moral rights. This is the part that decides who owns the finished product, and it deserves more attention than the payment schedule.
The development agreement is the contract that fixes who owns the code, designs and content produced for your project, and who is allowed to use each part of it. It binds the developer, and it displaces the default ownership rules in the Copyright Act 1968 (Cth) (the Act). If the agreement says nothing about intellectual property (IP), ownership stays where the Act puts it, which is rarely what the business paying for the work expects.
The clauses that decide who owns the code
Setting out who owns what
Every development project draws on three pools of IP, and a well-drafted agreement identifies each of them:
- Your material: the logos, copy, images, data and brand assets you hand to the developer.
- The developer's material: the source code, object code, layouts, designs, databases and documentation they create for you.
- Third-party material: open source libraries, frameworks, fonts, stock images and application programming interfaces (APIs) that neither of you owns, but that the developer is licensed to use.
The agreement should define these categories and list what falls into each, usually in a schedule. The list matters because copyright in Australia is automatic. There is no registration system, and the Attorney-General's Department confirms that protection is free from the moment a work is created. Source code and website designs are protected as literary and artistic works under the Act as soon as they are written, and the default owner is the author. The schedule is the map that every other clause operates on.
Assigning the developer's rights to you
Because the developer is not your employee, the Act does not give you the copyright in what they build. The commission exception in s 35(5) of the Act applies only to photographs, portraits and engravings, not to software. For code, ownership moves only if the agreement assigns it.
The assignment clause is where that happens, and it is the most important clause in the agreement. It should contain:
- Express words of assignment: The developer should assign all of their present and future rights, title and interest in the deliverables, in a clause signed by or on behalf of the developer. Under s 196(3) of the Act, an assignment has no legal effect unless it is in writing and signed, so a handshake deal or an exchange of emails is not enough.
- A definition of the deliverables: The clause should cover source code, object code, databases, designs, documentation, test scripts and anything else the project produces. If the definition is narrow, the developer keeps everything it does not name.
- Coverage of future copyright: Under s 197 of the Act, a signed agreement can assign copyright in works that do not yet exist. When the work comes into existence, ownership vests in you automatically, so you own the code from the moment it is written rather than at some later handover point.
- Flow-down to subcontractors: If the developer brings in subcontractors, the developer does not own what those subcontractors create. The employer rule in s 35(6) of the Act covers only employees under a contract of service. A subcontractor owns their own work unless they assign it, so the agreement should require the developer to obtain the same assignment from every subcontractor.
Two drafting traps cause most of the disputes. The first is a clause that says the developer "agrees to assign" the IP on final payment, rather than assigning it now. Until the condition is met, the developer remains the owner, and if you need to modify or sell the product before then, you are acting on borrowed rights. The second is a promise to assign that is never signed. A verbal or unsigned promise can give you at best an equitable interest, which is far weaker than ownership and expensive to enforce.
Keeping your own material
Your logos, copy, images and data remain yours, but the agreement needs to say so, and it needs to control how the developer uses them. The standard approach is a clause that:
- confirms you own the material you supplied;
- grants the developer a licence to use it, but only for the purpose of building the product for you; and
- ends the developer's right to use your material when the project is complete or the agreement is terminated.
The variant to watch for is a licence that is broader than the project. Some developers will ask for a right to use your material in their portfolio, marketing or future work. If you do not want your brand assets appearing in a developer's brochure, the clause should say the licence is limited to the project and nothing else.
When the developer keeps ownership and licences to you
Not every developer will assign the IP. Some, particularly those building on their own proprietary framework, will keep ownership and grant you a licence to use the product instead. That is a legitimate structure, but the licence terms decide how much the product is actually worth to you. Check four things:
- Scope of use: Can you use the product only for internal business purposes, or can you modify it, white-label it and sell it to your customers?
- Duration: Is the licence perpetual and irrevocable, or does it expire when the agreement ends or when you stop paying maintenance fees?
- Exclusivity: Is the developer free to licence the same product to your competitors?
- Sublicensing: Can you let your customers, staff or contractors use the product as part of your service?
The trap is a licence for "internal business use" that makes it a breach to host the product for your own customers, or a licence that terminates if you end the development agreement, leaving you with software you have no lawful right to run.
Third-party software and open source components
Developers routinely build on libraries, frameworks, fonts, images and APIs that they do not own. The agreement should deal with these third-party components in three ways:
- Disclosure: The developer should list every third-party component and its licence in a schedule, completed before you sign rather than after.
- Warranties: The developer should warrant that they have the right to use each component in your project.
- Compliance: The agreement should say who is responsible for meeting the conditions of each licence.
Open source licences deserve particular attention because they vary widely. Permissive licences such as MIT, BSD and Apache generally allow the software to be used inside a proprietary product, usually with conditions such as preserving copyright notices. Copyleft licences such as the GNU General Public Licence can impose obligations on how the finished product is distributed, and in some situations can require that related source code be released under the same licence. A developer who quietly pulls in copyleft libraries can leave you with a product you cannot distribute the way you planned. If the schedule is vague or says "various open source licences", treat that as a red flag.
Clauses that protect the deal around the assignment
Moral rights
Copyright is not the only right in the code. The individual author also holds moral rights: the right to be attributed as the author, the right not to have authorship falsely attributed, and the right of integrity, which protects the work from treatment that harms the author's reputation. These rights sit with the author personally and, under s 195AN(3) of the Act, cannot be assigned, transferred by will or passed on by operation of law.
What the developer can do is give written consent to acts that would otherwise infringe those rights. Under s 195AWA of the Act, consent must be in writing, and it can cover specified acts or classes of acts and works that do not yet exist. The agreement should collect written consents from the developer and from each subcontractor covering your right to modify the software, change or remove attribution in the code, and use the product in ways that would otherwise engage the integrity right. Without those consents, an individual developer who is unhappy with how you changed their code can point to the moral rights regime, even after you own the copyright.
IP warranties and indemnities
The developer should warrant that the deliverables are original, do not infringe any third party's IP, and comply with the licences listed in the schedule. They should also indemnify you if a third party claims that the product infringes their rights, so that the developer bears the cost of defending the claim and fixing the problem.
The traps are qualifications. A warranty that is limited to "the best of the developer's knowledge" gives you little protection if the developer never checked, and an indemnity capped at the fees paid can leave you paying for a complete re-build after a successful infringement claim. If the product is central to your business, push back on both.
What survives termination
The agreement should say what happens to the assignment and the licences if the contract ends early. If the assignment is expressed to take effect on creation, as s 197 of the Act allows, ending the agreement should not strip you of ownership of what was already delivered. But the developer's licence to use your material should end, and your licence to use any components the developer retained may end or continue depending on the deal you struck. A survival clause makes these consequences explicit, so a termination does not leave either side's rights ambiguous.
Optional clauses worth asking for
A handful of additional clauses can strengthen the agreement beyond the core assignment and licence terms. Consider asking for:
- Source code escrow: worth including when the developer retains ownership or will host and maintain the software. The escrow agent holds a verified copy of the source code that is released to you if the developer stops maintaining the product, becomes insolvent or breaches the agreement.
- Reuse of generic components: developers often want to carry generic libraries, utilities and design patterns they wrote for your project into other clients' work. If you want exclusivity over what was built for you, say so; if not, limit any reuse right to generic components and keep it away from your confidential information and brand assets.
- Post-delivery modifications: decide who owns changes made after handover, whether by you, by the developer under a separate support agreement, or by a future developer. Otherwise a later rebuild can create a dispute about who owns what in the modified product.
- Trade marks and attribution: if the product gets a name and logo, deal with who owns the trade mark, who pays to register it, and whether the developer has any right to be credited in the product or to use your name in their marketing.
- Confidentiality: protect the source code, specifications and your business information as confidential information, with obligations that survive the end of the agreement.
How an Artificer Legal lawyer reviews a development agreement
An Artificer Legal practitioner would start with the assignment clause, because it is the clause that decides whether you own the product at all. We would check that it uses express present-tense words of assignment, that it is signed, that it covers future copyright under s 197 of the Act, and that it flows down to subcontractors. From there we would move to the licence definitions, because they decide what you can actually do with the product, then to the schedule of third-party components, because that is where open source exposure hides, and finally to the moral rights consents.
We would push back on assignment conditional on final payment, on IP warranties qualified to "the best of the developer's knowledge", and on licences that die with the agreement. We would insist that the schedule of third-party components be completed before signing, not after, and we would negotiate ownership before price and scope. Everything else in the agreement is built on who owns the outcome, so it is the wrong place to compromise.
The present-tense assignment clause
If there is one drafting choice that separates an agreement that works from one that fails, it is whether the assignment clause uses present-tense words of assignment in a signed agreement covering past, present and future copyright, rather than a promise to transfer ownership later. Under the Act, an assignment is ineffective unless it is in writing and signed, and future copyright vests automatically on creation only if a signed agreement says so. A promise, even a clear one, leaves the developer as owner of the code and you with at best an equitable interest and a dispute on your hands. That is the difference between owning the software and merely having permission to use it.
To summarise the key points: map the three pools of IP at the start of the agreement, assign everything in writing signed by the developer and their subcontractors, keep a project-limited licence over your own material, check the licence terms carefully if the developer retains ownership, schedule every third-party component and its licence, collect written moral rights consents, and have a lawyer review the IP clauses before you sign.