One of the most common -- and most costly -- misconceptions in the South African technology sector is the assumption that the party who pays for custom software development automatically owns the intellectual property in the resulting code. Payment alone transfers nothing. Under South African law, copyright vests in the “author” of the work -- and for a computer program, the Act defines the author as the person who exercised control over the making of the program (section 1(1)), not necessarily the programmer who wrote the code. Who that person is depends on the facts of each project, and the only safe way to settle it is an express written agreement. For more technology law topics, see our Software & Technology Law hub.
This fact-specific test has caught South African businesses off guard in both directions. Commissioning companies that invested hundreds of thousands -- or millions -- of Rands in bespoke development have discovered, sometimes only when the relationship sours, that the development house owns the software they commissioned and paid for. Development houses have discovered the opposite: that a hands-on customer who directed the build was the author all along. Understanding the legal framework for software IP ownership is therefore essential for any business that commissions, develops, or invests in custom software.
The control test: Haupt v Brewers Marketing Intelligence
Unlike most categories of work, the “author” of a computer program is not the person who created it but the person who exercised control over the making of the program. In Haupt t/a Soft Copy v Brewers Marketing Intelligence 2006 (4) SA 458 (SCA), the Supreme Court of Appeal applied this definition and held that a commissioning customer who instructed, directed and controlled a programmer's work owned the copyright in the resulting program -- without any written assignment.
The flip side: a customer who hands over a brief and waits for delivery exercises no such control, and the development house remains the owner even though the customer paid for everything. Because the line is drawn on the facts of each project, neither side should rely on it -- record ownership expressly, in writing.
Copyright Act 98 of 1978 -- Key Provisions for Software
Software is protected as a "computer program" -- its own, separate category of protected work -- under the Copyright Act 98 of 1978. Computer programs were inserted as a distinct category by the Copyright Amendment Act 125 of 1992; unlike the position in the United Kingdom, software in South Africa is expressly not protected as a "literary work". Section 1 of the Act defines a computer program as "a set of instructions fixed or stored in any manner and which, when used directly or indirectly in a computer, directs its operation to bring about a result." Source code and object code fall within this definition; associated documentation is typically protected separately as a literary work.
Key Provisions
- Section 2(1)(i): Computer programs are listed as a separate category of works eligible for copyright protection -- inserted by the Copyright Amendment Act 125 of 1992 -- alongside, but distinct from, literary works, artistic works, cinematograph films, sound recordings, and other categories.
- Sections 1(1) and 21(1): Copyright vests first in the author of a work. For a computer program, the "author" is defined as the person who exercised control over the making of the program -- not automatically the programmer who wrote the code (see the Haupt case discussed above).
- Section 21(1)(d): Copyright in a work made in the course of the author's employment under a contract of service vests in the employer, unless otherwise agreed.
- Section 21(2): Where a computer program is made by or under the direction or control of the State or a prescribed international organisation, that entity is the first owner of the copyright. This provision does not extend to private commissioning parties.
- Duration: Copyright in a computer program subsists for 50 years from the end of the year in which the program was first made available to the public, or from the end of the year in which it was made, whichever is later.
- Section 22(3): An assignment of copyright is not valid unless it is in writing and signed by or on behalf of the assignor. Verbal agreements to transfer copyright are unenforceable.
Critically, the Copyright Act does not contain a "work for hire" doctrine equivalent to that found in United States copyright law. In the US, works created by independent contractors can be treated as "works made for hire" if certain conditions are met, with ownership vesting automatically in the commissioning party. No such concept exists in South African law. South Africa instead reaches the commissioning question through the control test: because the author of a computer program is the person who exercised control over its making, a hands-on commissioning party may own the copyright from the outset -- but a commissioning party who simply pays and waits for delivery generally will not. Because that question is decided on the facts of each project, a written assignment remains the only reliable route to ownership.
Employee vs Contractor -- Why the Distinction Matters
The distinction between an employee and an independent contractor is one of the most consequential determinations in software IP law. Section 21(1)(d) of the Copyright Act provides that where a work is made by an author in the course of their employment under a contract of service or apprenticeship, the employer is the first owner of the copyright, unless otherwise agreed. This is the clearest automatic vesting rule in the private-sector context -- though, as discussed above, the control test in the definition of "author" can also place first ownership of a computer program in a hands-on commissioning party.
Employee Developers
When a developer is employed under a contract of service (i.e., a true employment relationship), copyright in software created in the course of that employment vests automatically in the employer. The key requirement is that the software must be created "in the course of employment" -- software developed by an employee during their personal time, using their own equipment, and outside the scope of their employment duties may not fall within this provision. Employment contracts should therefore clearly define the scope of the employee's duties and include provisions addressing IP created both during and outside working hours.
Independent Contractors
When a developer is engaged as an independent contractor (under a contract for services, as opposed to a contract of service), section 21(1)(d) does not apply -- and ownership turns on the control test. If the development house ran the build in the ordinary way (its own team, its own methods, its own decisions), it will usually be the author and first owner, even though the commissioning party paid for the development. But where the commissioning party directed and controlled the making of the program in detail, it may itself be the author -- that is precisely what the Supreme Court of Appeal held in Haupt v Brewers Marketing Intelligence, where the commissioning customer owned the copyright without any written assignment. The trap is that nobody knows which side of the line a project falls on until a court decides. Note too that the commissioned-works rule in section 21(1)(c) is no help: its closed list covers photographs, portraits, gravures, cinematograph films and sound recordings -- not computer programs. The only safe course for a commissioning party is an express, written assignment of copyright. A verbal agreement, an implied understanding, or even payment of the full development fee does not transfer copyright ownership.
Important: The determination of whether a developer is an employee or an independent contractor is a question of substance, not form. Labelling an engagement as "independent contracting" in a contract does not make it so if the reality of the relationship reflects an employment relationship. South African courts apply the "dominant impression" test, considering factors such as control, integration, economic dependence, and the provision of tools and equipment.
Assignment vs Licence -- Structuring IP Transfer Correctly
When negotiating the IP provisions of a software development agreement, the commissioning party must decide between two fundamentally different approaches: acquiring ownership of the IP through an assignment, or acquiring usage rights through a licence.
Assignment of Copyright
An assignment is a complete transfer of copyright ownership from the developer to the commissioning party. Once assigned, the commissioning party becomes the owner of the copyright and can exercise all rights associated with ownership, including the right to reproduce, adapt, modify, distribute, and sublicense the software without further reference to the developer.
Under section 22(3) of the Copyright Act, an assignment of copyright must be in writing and signed by or on behalf of the assignor (the developer). An assignment may be general (covering all rights) or partial (covering specific rights, such as the right to reproduce but not adapt). It may also be limited to a specific territory or time period. Assignments should clearly identify the works being assigned, specify whether the assignment includes all existing and future rights, and address the status of any pre-existing IP incorporated into the software.
Licence of Copyright
A licence is a permission to use the software without transferring ownership. The developer retains copyright ownership and grants the commissioning party specific usage rights. Licences can be exclusive (only the licensee may use the software, even to the exclusion of the developer), sole (only the licensee and the developer may use the software), or non-exclusive (the developer may grant licences to others as well).
From the commissioning party's perspective, an exclusive licence provides many of the practical benefits of ownership, particularly if it is perpetual, irrevocable, and transferable. However, a licence always carries the risk that the licensor may become insolvent, at which point the trustee may challenge the validity of the licence or seek to terminate it. For this reason, many commissioning parties prefer a full assignment of copyright, supplemented by a licence-back to the developer where the developer needs to retain certain usage rights (for example, to use generic components in other projects).
Moral Rights in Software
Moral rights are the rights of the author to be identified as the creator of a work (the right of attribution or paternity) and to object to derogatory treatment of the work (the right of integrity). While moral rights are well-established for literary and artistic works, their application to computer programs under South African law is more limited.
Section 20 of the Copyright Act provides for moral rights in respect of literary, musical, and artistic works, as well as cinematograph films. Computer programs have been classified separately from literary works since the Copyright Amendment Act 125 of 1992, and the extent to which section 20 applies to computer programs remains the subject of academic debate. In practice, moral rights are rarely asserted in the context of software development, particularly in commercial settings where the software is developed for a specific business purpose rather than as a creative expression.
Nevertheless, prudent drafting should address moral rights in the software development agreement. The developer should waive any moral rights they may have in the software (to the extent permitted by law) or consent to the commissioning party's use and modification of the software without attribution. This avoids any future argument that modifications to the software constitute "derogatory treatment" of the developer's work.
Escrow Arrangements -- Protecting Your Investment
A source code escrow is an arrangement in which the developer deposits the source code of the software with an independent third-party escrow agent. The source code is released to the commissioning party only upon the occurrence of specified trigger events, such as the developer's insolvency, liquidation, material breach of the development agreement, or failure to maintain the software.
When Escrow is Appropriate
- Licence-based arrangements: Where the commissioning party holds a licence rather than an assignment of copyright, escrow provides a safety net ensuring access to source code if the developer can no longer support the software.
- Business-critical software: Where the software is essential to the commissioning party's operations and cannot be easily replaced by an alternative product.
- Small or single-person developers: Where the developer is a small company or sole proprietor, and the risk of business discontinuity is higher than with a large, established software house.
An effective escrow arrangement requires a tri-party agreement between the developer, the commissioning party, and the escrow agent. The agreement should specify the deposit materials (source code, build scripts, documentation, third-party libraries), the deposit schedule (initial deposit plus regular updates), verification procedures (to confirm the deposited materials are complete and can be used to build a working version of the software), and the precise trigger events and release conditions. Escrow agents in South Africa include specialist IT escrow providers as well as attorneys holding materials in trust.
Agile and Iterative Development -- Contract Structures That Work
Traditional software development agreements are often structured around the waterfall methodology, with detailed specifications agreed upfront, a fixed price, and defined milestones. However, the majority of modern software development follows agile methodologies (Scrum, Kanban, or hybrid approaches), which are inherently iterative, adaptive, and less amenable to fixed-scope, fixed-price contracting.
The tension between agile development and traditional contract structures is a common source of disputes. Agile methodologies assume that requirements will evolve during development, that priorities will shift based on user feedback, and that the final product may differ significantly from initial expectations. This creates challenges for contractual provisions relating to scope, pricing, acceptance criteria, and delivery timelines.
Contract Structures for Agile Development
- Time and materials with a cap: The developer bills for actual time spent, subject to a maximum budget ceiling. This accommodates scope flexibility while providing cost certainty for the commissioning party. Sprint budgets can be agreed per iteration.
- Master services agreement with statements of work: A framework agreement sets out the general terms (IP, confidentiality, liability, dispute resolution), while individual statements of work define the scope, timeline, and pricing for each development sprint or phase. This allows both parties to adapt without renegotiating the entire contract.
- Incremental IP transfer: Rather than a single assignment at project completion, copyright in each sprint's deliverables is assigned upon payment for that sprint. This protects the commissioning party by ensuring it acquires IP incrementally, while protecting the developer by tying IP transfer to payment.
Warranties, Acceptance Testing, and Defect Liability
A well-drafted software development agreement must address what happens when the delivered software does not meet the commissioning party's expectations. Three interrelated concepts govern this area: warranties, acceptance testing, and defect liability.
Warranties
The developer should warrant that the software will materially conform to the agreed specifications, will be free from material defects, will not infringe any third party's intellectual property rights, and will be developed using professional skill and care. These warranties should survive delivery and acceptance for a defined period (typically 12 months). The agreement should also specify the remedies available for breach of warranty -- typically, the developer must correct the defect at no additional cost, and if the defect cannot be corrected within a reasonable period, the commissioning party may terminate the agreement and recover fees paid.
Acceptance Testing
The agreement should establish a structured acceptance testing process. This typically involves the developer delivering the software (or a sprint increment) to the commissioning party, who then has a defined testing period (e.g., 10 to 20 business days) to evaluate the deliverable against agreed acceptance criteria. If the software passes, the commissioning party issues a written acceptance notice. If the software fails, the commissioning party provides a detailed deficiency report, and the developer has a defined cure period to address the issues. The agreement should specify what happens if the software fails acceptance testing multiple times -- typically, the commissioning party may terminate the agreement and recover fees paid for the failed deliverable.
Defect Liability Period
The defect liability period (sometimes called a "warranty period" or "maintenance period") is the period following acceptance during which the developer remains obligated to fix defects in the software at no additional cost. This period typically runs for 6 to 12 months from the date of final acceptance. The agreement should classify defects by severity (critical, major, minor) and specify the required response and resolution times for each category. After the defect liability period expires, ongoing maintenance and support should be addressed in a separate maintenance agreement with agreed service levels and pricing.
Key Clauses Every Software Development Agreement Needs
Drawing together the themes discussed above, every software development agreement in South Africa should address the following critical areas:
Intellectual Property Ownership and Assignment
A clear, written assignment of all copyright and other IP rights in the deliverables to the commissioning party, complying with section 22(3) of the Copyright Act. Address pre-existing IP, third-party components, and open-source software separately.
Scope of Work and Change Control
A detailed description of the work to be performed, the deliverables to be produced, and a formal change control procedure for managing scope changes, including the process for requesting, evaluating, pricing, and approving changes.
Payment Terms and Milestones
A clear payment schedule linked to deliverables or milestones, with provisions for holdback amounts pending acceptance and the consequences of late payment (including whether the developer retains IP until payment is made in full).
Confidentiality and Non-Disclosure
Mutual confidentiality obligations protecting both parties' proprietary information, business strategies, and technical know-how, with appropriate carve-outs for information that is publicly available or independently developed.
Data Protection and POPIA Compliance
Where the development involves personal information, the agreement must address POPIA obligations, including operator agreements, data security measures, and breach notification procedures. For detailed guidance, see our article on POPIA compliance for technology companies.
Warranties and Acceptance Testing
Developer warranties regarding conformity to specifications, freedom from defects, and non-infringement, together with a structured acceptance testing process and clear remedies for breach.
Limitation of Liability
Agreed caps on each party's liability, with appropriate carve-outs for IP infringement, breach of confidentiality, and wilful misconduct. Ensure liability caps are proportionate to the contract value and the risks involved.
Termination and Consequences
Grounds for termination by each party, including material breach, insolvency, and convenience. Clearly state the consequences of termination, including IP ownership in partially completed work, payment for completed milestones, and the return or destruction of confidential information.
Dispute Resolution
A tiered dispute resolution clause providing for negotiation, mediation, and (if necessary) arbitration or litigation. Specify the governing law (South African law), the seat of arbitration, and the applicable arbitration rules.
Protecting Your Software Investment
Software development represents a significant investment for any South African business. The legal framework governing IP ownership is unforgiving -- ownership turns on who exercised control over the making of the program, not on who paid for it, and without a proper written assignment a commissioning party may discover the developer owns the software it funded (or a developer may discover the customer does). This is not a risk that any business can afford to take.
A well-drafted software development agreement, prepared with the assistance of an attorney experienced in technology law, is the single most important step a commissioning party can take to protect its investment. The cost of proper legal advice at the outset is negligible compared to the cost of litigating ownership disputes after the fact.