Technology Law

Software Development Agreements & IP Ownership

Understanding who owns custom software under South African law, and how to structure development agreements that protect your investment

12 min readMJ Kotze Inc

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. This assumption is wrong. Under South African law, the default position is that the developer, not the commissioning party, owns the copyright in software they create. This default can only be altered by an express written agreement. For more technology law topics, see our Software & Technology Law hub.

This seemingly counter-intuitive principle has caught countless South African businesses off guard. Companies that have invested hundreds of thousands -- or millions -- of Rands in bespoke software development have discovered, sometimes only when the developer relationship sours, that they do not own the software they commissioned and paid for. Understanding the legal framework for software IP ownership is therefore essential for any business that commissions, develops, or invests in custom software.

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)(b) 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 only automatic transfer of copyright ownership under South African law in the private sector context.

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), the default position is that the developer retains copyright in the software they create, even though the commissioning party pays for the development. This is the rule that catches most businesses by surprise. The only way for the commissioning party to acquire ownership is through 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. The courts have consistently upheld this principle, making the written assignment requirement non-negotiable.

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 are classified separately from literary works under the Act, 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 clear but unforgiving -- without a proper written agreement, the developer retains copyright regardless of who paid for the work. 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.

Need a Software Development Agreement?

Whether you are commissioning custom software or providing development services, MJ Kotze Inc can draft and negotiate agreements that properly allocate IP rights, manage risk, and protect your interests.

Chat with us