Disputes over ownership of software often cross my desk. The story is almost invariably the same: someone has paid a software developer to write code, and there is no written agreement dealing with who owns that code. Then the developer decides that he owns the code and won’t hand over the source code.
How do you tell who owns the code? The rules around this are quite simple, at least on the face of it.
If the developer was employed by the person for whom he wrote the code, then the employer owns the code because it was written within the scope of the developer’s employment. While the developer may be the author of the code, the employer will own it. Developers often argue that writing the code falls outside the scope of their employment for whatever reason, but that is a question for another day.
If the developer was not an employee, then the author of the code will also be its owner. It is then important to work out who the author is, as the author will also be the owner.
The Copyright Act defines the author of a computer program (the legal term for code) as the person “…who exercised control over the making of the computer program;”. It is this phrase that leads to a certain amount of angst and confusion.
If the developer is working as an independent contractor (i.e. doing work for someone but not as an employee), then the courts will look at how closely the person who commissioned the work (the commissioner) was involved in the development of the code. If the commissioner merely gave the developer a set of overarching requirements and the developer had free rein in the development process, then the commissioner would not have exercised control in this sense, and the developer would be the author and hence the owner of the software. However, if the commissioner was intimately involved with the development process and the developer took daily instructions and reported back frequently, then the commissioner would be the author, and hence the owner of the code.
The Haupt Case
The classic case here is that of Haupt t/a Soft Copy v Brewers Marketing Intelligence (Pty) Ltd and Others. The commissioner in this case did not merely instruct the developer on what was required and stand back. The commissioner gave the developer detailed instructions on an ongoing basis, and the developer followed these instructions closely, being in constant contact with the commissioner. As work progressed the developer submitted it to the commissioner frequently for approval.
The court held that in these circumstances the commissioner’s involvement in the development process was intimate enough that the commissioner could be said to be the author of the software, even though the developer had actually written it, because the commissioner had exercised control over its creation. It was not necessary for the commissioner to understand what the developer was doing from a technical standpoint. Merely controlling the progress of the work was sufficient.
The Haupt judgement was handed down in 2006, and there had been little case-law on this point since. It was thus with great glee that I read the very recent case of Bergh and Others v The Agricultural Research Council, which confirms the decision in Haupt.
The Bergh Case
The case deals with a complicated relationship between the Agricultural Research Council (ARC) on the one hand and various collaborators and service providers on the other. It is not necessary to explain the twists and turns of this particular drama (and software disputes always are dramas). For our purposes it is sufficient to state that a Mr Pauw developed a program used to keep track of the pedigrees and performance of stud animals for ARC. This program was then to be used to provide a service to farmers to allow them to source the best animals for breeding.
After the program had been completed, one of the other parties to the action obtained a copy of it, and wished to commercialise it. ARC maintained that it was the owner of the program, and approached the court in an attempt to prevent infringement of its copyright in the program. The question of infringement turned on whether ARC was the author and hence the owner of the program.
Pauw was not an employee of ARC, nor was there a written agreement between Pauw and ARC (though there had been attempts to put one in place). All parties accepted that Pauw was commissioned to write the program by ARC. In the absence of an agreement the question then was to what extent ARC exercised control over his creation of the program.
On the evidence it appeared that Pauw worked independently in developing the program. He only sought information from time to time that he required to ensure that the program fulfilled its purpose. His work was not subject to the approval of anyone at ARC, nor did he follow instructions from anyone at ARC. One can see that these facts differ markedly from those of the Haupt case, where the developer was under regular and fairly close supervision.
The court in this case held that ARC did NOT exercise control over the making of the computer program, and that Pauw was thus the author of the program. As a result he, and not ARC, was the owner of the program, and ARC hence had no rights under copyright to prevent the other parties from commercialising it.
Conclusion
The upshot of all of this is that to control the development process (and thus be the author) the commissioner has to be quite intimately involved in the day-to-day development of the program. It is not enough to just define functional specifications and to test the result periodically to see that it does what is required.
If someone makes a little mistake like this and the developer ends up owning the code when he shouldn’t, we can fix it by doing an assignment of the code to the commissioner, but this requires the developer’s co-operation, and developers are often of an uncooperative bent (as I mentioned earlier, software disputes usually involve a certain amount of drama).
The wise move? The pain of working out who the author of the code is can be avoided by having a proper written agreement in place BEFORE the code is developed.