Open Source Software Licensing

Open source software (OSS) is software whose source code is made available under a licence that grants users the right to use, study, modify, and distribute the software. The term "open source" is defined by the Open Source Initiative (OSI) through the Open Source Definition, which establishes ten criteria that a licence must meet to be considered "open source." These include free redistribution, access to source code, the ability to create derived works, and non-discrimination against persons, groups, or fields of endeavour.

It is a common misconception that open source software is in the public domain or that it is not protected by copyright. Open source software is copyrighted software. The copyright holder chooses to license the software under terms that permit broad use and modification, but those permissions come with conditions. The licence is a legally enforceable contract (or, in some jurisdictions, a bare licence subject to copyright law), and breach of the licence terms exposes the user to the same legal consequences as any other copyright infringement.

The scale of open source adoption is staggering. Industry surveys consistently show that over 90% of commercial software products contain open source components. The average commercial application may incorporate hundreds of distinct open source packages, each with its own licence terms. This creates a complex web of legal obligations that businesses ignore at their peril.

Open source licences fall into two broad categories: copyleft licences and permissive licences. The distinction between them is fundamental to understanding your legal obligations.

Copyleft Licences

Copyleft licences require that any derivative work of the licensed software be distributed under the same licence terms. The most prominent copyleft licence is the GNU General Public License (GPL), particularly GPL version 2 and GPL version 3. The copyleft obligation — sometimes referred to as the "viral" effect — means that if you incorporate GPL-licensed code into your software and distribute the resulting product, you must make the source code of your entire product available under the GPL. This can be commercially devastating for businesses that rely on proprietary software as a competitive advantage.

The GNU Lesser General Public License (LGPL) is a "weak" copyleft licence that modifies the GPL's requirements. Under the LGPL, you may link your proprietary software to an LGPL-licensed library without the copyleft obligation extending to your proprietary code, provided certain conditions are met — including allowing the user to substitute the LGPL library with a modified version. However, if you modify the LGPL library itself, the copyleft obligation applies to those modifications.

The GNU Affero General Public License (AGPL) extends the GPL's copyleft obligation to software deployed as a service. Under the standard GPL, the copyleft obligation is triggered only by "distribution" of the software. Running GPL software on a server and providing access over a network is generally not considered distribution. The AGPL closes this "SaaS loophole" by requiring that if you modify AGPL-licensed software and deploy it as a network service, you must make the modified source code available to users of the service.

Permissive Licences

Permissive licences impose minimal restrictions on how the software can be used, modified, and distributed. The most common permissive licences are the MIT License, the Apache License 2.0, and the BSD licences (2-clause and 3-clause). These licences typically require only that the original copyright notice and licence text be retained in copies and derivative works. They do not require derivative works to be released under the same licence, meaning you can incorporate permissive-licensed code into proprietary software without triggering a copyleft obligation.

Each open source licence imposes specific legal obligations that the licensee must comply with as a condition of using the software. Failure to meet these conditions means that the licence grant terminates, and continued use of the software constitutes copyright infringement.

GPL Obligations

If you distribute software that contains GPL-licensed code — whether you have modified the code or incorporated it into a larger work — you must make the complete source code of the entire work available to recipients under the GPL. You must include a copy of the GPL licence text. You must not impose any additional restrictions beyond those in the GPL. And you must provide the source code in a form that is readily accessible and complete, including all build scripts and installation instructions necessary to compile and install the software.

MIT and BSD Obligations

The obligations under the MIT and BSD licences are comparatively minimal. You must include the original copyright notice and the licence text in all copies and substantial portions of the software. The 3-clause BSD licence adds a requirement that the name of the copyright holder not be used to endorse or promote derivative products without prior written permission. There is no obligation to disclose source code or to license derivative works under the same terms.

Apache 2.0 Obligations

The Apache License 2.0 requires attribution through the inclusion of the copyright notice, licence text, and a NOTICE file (if one is provided). It also includes an express grant of patent rights from contributors to licensees, which provides protection against patent infringement claims related to the licensed software. If you modify the software, you must include a prominent notice stating that you have changed the files. The Apache 2.0 licence is not copyleft — derivative works need not be licensed under the Apache 2.0.

The consequences of failing to comply with open source licence terms can be severe. While enforcement actions in South Africa have been limited compared to the United States and Europe, the legal risk is real and growing as open source governance becomes a standard part of corporate due diligence.

Copyright infringement: Breach of an open source licence terminates the licensee's right to use the software. Continued use after termination constitutes copyright infringement, exposing the infringer to the full range of remedies available under the Copyright Act 98 of 1978 — including interdict (injunction), delivery-up of infringing copies, and damages. In practical terms, this could mean being forced to remove the infringing component from your product, which may require a complete re-engineering effort.

Forced source code disclosure: The most feared consequence of GPL non-compliance is being compelled to release the source code of proprietary software. If a court determines that your proprietary code has been combined with GPL code in a way that creates a "derivative work," the entire combined work must be distributed under the GPL. While courts in different jurisdictions have reached varying conclusions on what constitutes a "derivative work" in the context of software, the uncertainty itself creates significant risk.

Reputational damage: Open source licence violations are frequently publicised by the open source community. Organisations such as the Software Freedom Conservancy and the Free Software Foundation actively monitor and enforce GPL compliance. Being publicly identified as a GPL violator can damage a company's reputation with developers, customers, and partners.

Transaction risk: Open source compliance issues discovered during the due diligence process for mergers, acquisitions, or investment rounds can delay or derail transactions. Buyers and investors routinely conduct open source audits, and undisclosed copyleft exposure can significantly reduce a company's valuation or make a deal untenable.

Open source due diligence has become a standard component of technology M&A transactions. Acquirers and investors recognise that undisclosed open source dependencies — particularly those under copyleft licences — can fundamentally affect the value and commercial viability of a software asset.

A thorough open source audit typically involves running the target company's codebase through software composition analysis (SCA) tools that identify all open source components and their associated licences. The audit report identifies any copyleft-licensed components, assesses whether the copyleft obligations have been triggered by the manner in which the components are integrated, and flags any compliance gaps — such as missing attribution notices or failure to provide source code.

Common due diligence findings include the use of GPL-licensed code in proprietary products without compliance, missing NOTICE files for Apache-licensed components, and the use of components under licences that conflict with the company's commercial model. These findings can lead to indemnification obligations, escrow arrangements, or purchase price adjustments. In extreme cases, they can cause a transaction to fail entirely.

For South African technology companies contemplating a sale, investment round, or listing, proactively managing open source compliance is not merely good practice — it directly affects the company's ability to transact and the valuation it achieves.

Every business that develops or uses software should have a documented open source policy. The policy should be proportionate to the business's use of open source software, but at a minimum should address the following areas.

Open source licensing operates within the framework of copyright law. In South Africa, software is protected as a "computer program" under section 1(1) of the Copyright Act 98 of 1978, which 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." Computer programs are a distinct category of copyright work under section 2(1) of the Act.

The owner of copyright in a computer program has the exclusive right to reproduce the program, publish it, make an adaptation of it, and distribute it. These exclusive rights form the basis for open source licensing — the copyright holder grants a licence permitting others to exercise these rights, subject to the conditions specified in the licence.

An important consideration under South African law is the ownership of copyright in software created by employees. Section 21(1)(d) of the Copyright Act provides that where a computer program 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 default position means that code written by an employee belongs to the employer, which in turn means the employer has the legal standing to license that code — including under an open source licence.

However, where code is written by independent contractors, the default position is different. The contractor typically owns the copyright in the code they create, unless the contract expressly assigns the copyright to the commissioning party. This has significant implications for businesses that commission software development — if the contractor incorporates open source code into the commissioned work, the business must understand what open source components are included and what licence obligations they trigger.