The developer who kept one program and lost another
A software developer walked into a new job carrying a toolkit he had been building since his school days: a library of reusable code that could be dropped into almost any new program his employer produced. His employer knew about the library and wanted him to use it. Years later, after the relationship soured, a court had to decide who owned the software. It gave the developer one program and the employer another, splitting ownership of code written by the same person, at the same desk, in the same period.
Redrock Holdings Pty Ltd was a Melbourne company developing internet software. In the late 1990s it employed Adam Hinkley as a software programmer on the understanding that he would use his personal class library (a software tool used to build other software) to write programs for the company. Hinkley had conceived the library years earlier and had been refining it since high school. Around the same time, he and a group of Canadian investors established Hotline Communications Ltd to develop and market his "Hotline" software. The code was the core asset of both ventures: Redrock was commercialising products built on the library, and Hotline Communications was taking Hinkley's programs to market. Whoever owned the copyright controlled whether the software could be sold, licensed or developed further.
When the arrangements unravelled, everyone claimed the code. Redrock said it owned the copyright in the programs because Hinkley was its employee and had written them in the course of that employment. Hinkley said he was never truly an employee because he was not subject to the company's direction and control, and that the class library remained his own. Hotline Communications said Hinkley had assigned it ownership of his programs. The dispute went to the Supreme Court of Victoria, which decided the ownership questions in Redrock Holdings Pty Ltd v Hinkley [2001] VSC 91.
The two questions the court had to answer
Under the Copyright Act 1968 (Cth), computer programs are protected as literary works. Section 10(1) of the Act defines a literary work to include "a computer program or compilation of computer programs", and defines a computer program as "a set of statements or instructions to be used directly or indirectly in a computer in order to bring about a certain result". Copyright comes into existence automatically when the work is made, with no registration system in Australia, provided the work is original (s 32(1)). The default owner is the author: s 35(2) provides that the author of a literary work is the owner of the copyright in it.
Section 35(6) creates the exception that decided Redrock. Where a literary work "is made by the author in pursuance of the terms of his or her employment by another person under a contract of service", that other person, the employer, owns the copyright. The subsection raises two questions, and the case turned on both: was Hinkley an employee, and if so, was each program made in pursuance of the terms of his employment?
Was Hinkley an employee?
The court applied the modern multi-factor test for employment. The right to control is no longer the sole indicator, particularly where the worker exercises a high degree of professional skill. Hinkley argued that Redrock did not direct and control the way he worked. The court accepted that he exercised real professional skill as a programmer, but found the surrounding indicators pointed to a contract of service: a fixed salary, deduction of group tax, an ATO employee declaration form, entitlements to annual, sick and long service leave, superannuation contributions, and the provision of tools and equipment. Hinkley was an employee.
Was each program made in pursuance of his employment?
This is where the judgment gets interesting, because the question was answered differently for different programs.
For the Hotline program, the court found Hinkley was the owner of the copyright. Hotline was his own project: he developed it without Redrock's direction or knowledge, and although he worked on it while at Redrock's premises, he did so only when he had no specific tasks. Redrock could not prove the code was written during working hours. The program was not made in pursuance of the terms of his employment, so s 35(6) did not operate and the default rule in s 35(2) applied. Hinkley kept the copyright.
The class library went the other way. The library was known as App Warrior, or "Adam's App Builder". Hinkley had started it before he joined Redrock, but the court found the library as it stood after his employment was a new literary work. It had been extensively developed during the engagement, transformed from the embryonic code he had brought with him, and had become a necessary component of the software written for Redrock. Expert evidence showed most of the further development took place during weekday working hours. Because the redeveloped library was made in pursuance of the terms of his employment, s 35(6) vested the copyright in Redrock.
The Federal Court has since treated Redrock as the leading authority on this question. In EdSonic Pty Ltd v Cassidy [2010] FCA 1008, Moore J summarised the decision and observed that no authority directly addresses the scope of the phrase "in pursuance of the terms of his or her employment". The question, his Honour said, is not simply whether the author happened to be employed under a contract of service when the work was made. The inquiry is directed to the scope of the duties the employee was engaged to perform. In EdSonic itself, an author who wrote educational materials largely outside the scope of what she was engaged to do kept her copyright, even though she may have been an employee. The reasoning draws on the classic English authority Stephenson Jordan & Harrison Ltd v MacDonald & Evans (1952) 69 RPC 10, which distinguished work made in pursuance of employment duties from work made outside them.
What the case means for your software business
Redrock is not a remote curiosity. The same ownership questions play out in Australian businesses every time a developer builds a side project, reuses a personal library, or works on a start-up idea after hours. A few points are worth sitting with:
- Your employee can own code written on your time: if a developer builds a personal project during quiet periods at work, the copyright can stay with them unless the work falls within their duties.
- Your business can own code the developer thinks is theirs: a side project that grows out of, or becomes integral to, the work the developer was hired to do can end up owned by the company, as the class library did.
- Time and place are not the test: work done at home during employment can belong to the employer, and work done at the office can belong to the employee. What matters is whether the code was made in pursuance of the employment.
- One developer can be split in two: Redrock put the same developer's programs in two different hands, so neither side should assume ownership is uniform across a codebase.
- A few sentences in a contract can fix all of this: s 35(3) of the Copyright Act allows the default ownership rules to be excluded or modified by agreement, so the ambiguity Redrock had to litigate can be resolved in writing before work starts.
The deeper point is that the statutory default rules are a blunt instrument for a modern software business. They were not designed for code libraries that evolve continuously, for developers who move between projects and personal tools, or for contractors who reuse their own code across multiple clients. They also create uncomfortable surprises on both sides: the developer who assumed their side project was private can find the company owns it, and the employer who assumed all code produced by staff belonged to it can find a critical component is owned by a former employee, or by the contractor who wrote it. Redrock shows the consequences of leaving those questions to be answered after the relationship has broken down: a court sifting through salary records, leave entitlements and version histories to reconstruct who wrote what, when, and why.
What you can change this week
None of this needs to wait for a dispute to start. Five steps, each achievable this week, close the gaps Redrock exposed:
- Put an IP clause in every employment contract: s 35(3) of the Copyright Act lets the default ownership rules be modified by agreement, so a clause assigning to the company the copyright in all work made in the course of employment removes the ambiguity Redrock had to litigate.
- Assign IP in contractor agreements too: contractors are not employees, so s 35(6) does not apply to them at all. Without an express assignment of copyright, the contractor owns the code they write for you, including code that ends up embedded in your product.
- Keep development records: time logs, project briefs and version histories are what proved, and failed to prove, when the code in Redrock was written. If a dispute ever arises, the records decide it.
- Segregate personal projects: separate repositories and devices, and a written understanding about what a developer builds in their own time, protect both the developer's personal work and the company's.
- Audit any library or code your developers bring with them: if a new hire arrives with a personal toolkit, document who owns what before the first line of client code is written.
How a lawyer keeps the ownership question settled
The most expensive way to answer "who owns this code?" is in litigation, where the answer turns on evidence gathered years after the fact. A legal practitioner can resolve the question much earlier, which is the real value of professional help in this area.
A lawyer reviewing your software business would start with the contracts: employment agreements, contractor agreements and any open source or third party licences that govern code coming into the business. They would draft IP ownership and assignment clauses that deal with work made during the engagement, code libraries the developer brings with them, and inventions that straddle work and personal time. For a business that has already built a codebase on informal arrangements, a lawyer can conduct an ownership audit, tracing who wrote what and identifying the gaps that a future Redrock-style dispute would exploit. If a dispute has already started, legal advice on the evidence required, the two limbs of s 35(6), and the prospects of each ownership claim is essential before positions harden.
The line that decides who owns the code
The dividing line in Redrock is not the office door or the clock. It is whether the code was written in pursuit of the duties the developer was employed to perform, and that line can put the same developer's two programs in two different hands.
The key points from this case: copyright in computer programs arises automatically under the Copyright Act 1968 (Cth) and belongs to the author by default, the employer takes ownership only of work made in pursuance of the terms of employment under a contract of service, and that test is applied program by program, not developer by developer. Employment is judged on the whole relationship, not just control, and ownership on the scope of the developer's duties, not just time and place. Written IP clauses, contractor assignments and development records are the practical tools that stop these questions from ever reaching a courtroom.