Copyright, who's your mama?

By Nicole Neethling on 8 January 2021

It was no small thing when the wise King Solomon had two women enter his courts with a baby, both crying out that the baby was theirs, and wanting him to wield his sword of justice.  Our courts today have had to hear the not dissimilar cries from contending parties, both bringing a computer program forward and asking the court to declare… "Who's the mama?"

With all the texts, photos, databases, source codes and other elements that come into play when developing a program, and with copyright vesting in each element differently, finding the owner of the copyright requires divine wisdom of its own.  This is most relevant when an independent computer programmer is used to develop a program.  Although our Copyright Act defines the author and owner of the various elements, a string of cases that have moved through our courts show common misconceptions that parties have in claiming copyright ownership.  We would like to bring some of our own wisdom to simplify this ownership conundrum to let you know what to expect, when you are – dare I say it – expecting … a computer program.

Misconception 1: Commissioning is owning

When a client hires a programmer to develop a computer program, a misconception is that the client will own the copyright in the program.  However, our Copyright Act says that the first author, and thereby owner of copyright in a computer program, is the person who exercised "control" over the making of the program.  The 2006 Haupt v Brewers Marketing Intelligence (Pty) Ltd [2006] SCA 39 RSA case, suggests that to determine this control, we need to establish whether a developer used his own skill and judgement to create the program and whether he directed the development process himself.  However, if the programmer followed detailed instructions from the client, did the technical work required to achieve those results and required approval of each step in the process, then the client would be in control.  It was interesting to see that courts do not expect the person in control to be a programmer or have the technical skill.  Haupt, the client, was not a programmer, and yet was still found to have control as he had authority over the development process, and therefore was the author and owner.

Misconception 2: Providing customised elements makes you the owner

A client may have the misconception that because he provides the data, tables and customised texts, that he will own the program and the copyright.  In the 2019 Bergh and Others v The Agricultural Research Council [2020] ZASCA 30, the ARC emphatically tried to convince the court that it was the owner of the copyright in a program that Bergh developed for the ARC.  However, the court sliced through the middle of the ARC's argument and said that providing the functional requirements (reviewing the process and testing the program) did not establish control on the part of the ARC.  Bergh developed the program using his own skills and did not need any instructions, supervision or approval from the ARC.  He was therefore in control of the making of the program, and accordingly the author and owner of the copyright.

Misconception 3: Paying means owning

Once a client has paid the programmer, there is a misconception that he now owns the copyright that vests in the program as well.  This is not true.  If we assume that the programmer was in control of the process and that he is the first owner of the copyright in the program, then according to our copyright law, the ownership can only be transferred to another by means of a written agreement.  Not even an oral agreement will do.   Without anything in writing, the programmer remains the owner, regardless of having received payment.  Legally, what the client usually receives is a non-exclusive, tacit license to use the copyright in the program.  This is like paying for a Microsoft program.  Clients pay to use the program - not to own it.  For the client, this means that he is unable to create adaptions, copy, sell copies or any other acts reserved for copyright owners, without the consent of the programmer.  In the Bergh case above, the parties trolled through years of correspondence to prove what the actual intention of the parties was.  The court strongly recommended parties to conclude written agreements to prevent any ambiguity about the ownership of copyright.  Basically, if the client wants to own the copyright, he needs to get it assigned to him in writing!

Misconception 4: Adapting is allowed

Sometimes clients are well aware that they do not own the copyright in a program developed for them, so they try and adapt the program to create a new feature hoping to be the owner of the copyright in the new parts.  The Haupt case taught us that adaptions like this that are new and original, will in fact be covered by its own copyright.  However, with a capital "H", this does not mean that the adapted program will not infringe the copyright in the initial program.  The Copyright Act enables only the owner of the copyright in the computer program to make adaptions (and even translations) to his program.  So, anyone who does this without his permission, will be infringing his copyright rights.

How does this help you?

Our Mamas have often told us that prevention is better than cure, and that is definitely true when it comes to the ambiguity of copyright ownership.  There are many instances (and empty pockets) that show that people are not properly briefed with regards to copyright and computer programming ownership.  This extends to programs for Software-as-a-Service websites, mobile apps, month-end systems and the like.  Preventing ownership ambiguity is ultimately better and cheaper than trying to cure it after the fact.  So, if you are contemplating the development of a computer program either as a client or a programmer, and don’t want the sword of justice to slice your copyright baby in half, let us guide and assist you through the process to help you protect your rights (and your expectations). 

Back to top

Please note that our blog posts are informal commentaries on developments in the law as at the time of publication and not legal advice. You should place no reliance on our blog posts; we look forward to discussing your particular matter with you.