The copyright question every business using AI coding tools needs to ask
AI coding assistants like Claude are now embedded in software development workflows across almost every industry. They draft functions, refactor modules and in some cases produce entire codebases from a handful of prompts. What most boards and management teams have not yet turned their minds to is a much more fundamental question – does anyone actually own the copyright in that code?
Under Australian law, the answer is not automatic and for some AI-generated code, the answer may be no one at all.
Copyright in Australia does not require registration, but it does require a human author. Source code is protected as a literary work under the Copyright Act 1968 (Cth) and for copyright to subsist, a work must originate from an identifiable person (or persons) who exercised independent intellectual effort in bringing it into existence. This is not a technicality. It is the legal basis on which both the existence of copyright and originality itself, depend.
Copyright needs a human author
Where that human contribution cannot be identified or is insufficient in substance, Australian courts have been willing to find that a work is simply “authorless” and therefore unprotected, no matter how much time, money or commercial value went into producing it.
The courts have already grappled with this, just not for AI
There is no Australian decision yet dealing with copyright in code generated by a large language model.
But there does not need to be, as the High Court and Federal Court have already built the relevant framework in a line of cases dealing with computer-generated material, most notably IceTV v Nine Network (2009), Telstra v Phone Directories (2010) and Acohs v Ucorp (2012).
The consistent thread through this case law is this – the fact that a human being configured, supervised or initiated an automated system is not, of itself, enough to make that human the author of what the system produces.
In Acohs, safety data sheets generated by a document system were found to be authorless, even though people had built and operated the system that produced them. The parallels to AI-assisted code development are difficult to ignore and, in our view, a court asked to consider AI-generated source code would very likely apply the same reasoning.
There is also no legislation and no announced timetable for legislation, that deems an AI system, its developer or its user to be the “author” of AI-generated output. Reform in this area is being actively considered by the Federal Government’s Copyright and Artificial Intelligence Reference Group, but nothing has yet changed the legal position described above.
Where does that leave a business relying on AI-generated code?
The practical exposure sits on a spectrum.
At one end, code produced by a developer who directs the task, actively reviews the output, and makes the substantive structural and drafting decisions looks much like code produced with the help of any other software tool and would have a reasonable claim to copyright in the usual way.
At the other end, code generated from an open-ended prompt with minimal human direction over the actual expression produced and limited genuine review, carries a real risk of falling into the “authorless work” category described above. If that risk materialises, the consequences are significant. There is no ability to stop a competitor copying the code, no ability to exclusively license it and no infringement claim available, irrespective of how central that code is to the business.
Most real-world development activity sits somewhere in the middle and the honest answer is that this middle ground is largely untested.
What we do know, from cases like IceTV, is that courts are willing to draw adverse conclusions where there is no contemporaneous evidence of genuine human authorial contribution. Version control history, code review records and development documentation are likely to matter a great deal if this issue is ever tested.
It is not only a litigation question
This issue also has direct, practical relevance to:
- Employment and contractor agreements – the default ownership rules for employees and contractors operate vary and neither rule can create an ownership interest in code that has no copyright in the first place.
- M&A and investment due diligence – IP warranties and valuations that assume ‘clean’ copyright ownership over a codebase may be resting on shakier ground than the parties realise.
- Licensing and commercialisation – a business cannot grant an exclusive licence over rights that do not exist.
Where to from here?
This is a live issue and, in our view, an under-appreciated risk area for any business scaling its use of AI coding tools. It sits at the intersection of IP law, employment and contractor drafting and corporate risk management, which is exactly the combination our commercial and corporate team advises on daily.
We have developed a practical framework for assessing and mitigating this risk, covering internal AI development governance, contract drafting for employees and contractors and layered protection strategies that do not rely on copyright alone.
If your business is adopting AI coding tools or is about to go through a transaction where codebase ownership matters, it is worth having a conversation before the question is tested for you by a competitor or by a counterparty’s lawyers.
This article is general commentary only and does not constitute legal advice. If you would like to discuss how this issue applies to your business, please get in touch with Jeremy Goldman, Head of Commercial and Corporate at KCL Law.
Jeremy Goldman
Principal Lawyer | Head of Commercial and Corporate
KCL Law
jgoldman@kcllaw.com.au | 03 8600 8888