Almost every modern software product contains open-source code. Frameworks, libraries, databases and development tools are often free to download and use, and they allow small teams to build products quickly. But “free” does not mean “without conditions”. Each open-source component comes with a licence, and some of those licences impose obligations that can affect how you sell, distribute or protect your own product.
Open-source risk usually surfaces at the worst moment: during an investor’s due diligence, a sale of the business, or a dispute with a customer. A buyer that discovers a key product depends on code under a licence that requires source code to be shared may reduce the price, demand an indemnity or walk away.
This article explains how open-source licences work under South African law, the main licence types, and the practical steps businesses can take to manage the risk.
Open-source licences are copyright licences
Computer programs are protected as a category of work under the Copyright Act 98 of 1978. The author, or the author’s employer where the program is made in the course of employment, generally owns the copyright. Nobody else may reproduce or adapt the program without permission.
An open-source licence is that permission. It allows anyone to use, copy, modify and distribute the code, but only on the licence’s terms. If you do not comply, you may lose the benefit of the licence and be using the code without permission, which can amount to copyright infringement. Many licences also operate as contracts, so a breach may give rise to contractual claims.
There is limited South African case law on open-source licences, but the underlying principles of copyright and contract are well established. Many open-source projects are based abroad, and their licences are applied internationally, so disputes may also involve foreign law and courts.
The main licence types
Permissive licences
Licences such as the MIT, BSD and Apache 2.0 licences allow the code to be used in proprietary products with few conditions. The main obligations are usually to keep copyright and licence notices, and to include a copy of the licence when you distribute the software. The Apache 2.0 licence also contains an express patent licence and provisions that terminate that patent licence if the user starts patent litigation over the software.
Copyleft licences
“Copyleft” licences, such as the GNU General Public License (GPL), require that if you distribute software that includes or is derived from the licensed code, you must make the source code of that software available under the same licence. This is the “viral” effect that concerns commercial software developers. If GPL code is combined with your proprietary code in a way that creates a derivative work, and you distribute the result, you may be required to release your own source code.
Weak copyleft and network licences
Some licences sit in between. The GNU Lesser General Public License (LGPL) and Mozilla Public License, for example, generally limit the sharing obligation to the licensed component itself or to modified files. At the other end, the GNU Affero General Public License (AGPL) extends the obligation to software made available to users over a network. This matters for software-as-a-service businesses, which might otherwise assume that because they never distribute software to customers, copyleft obligations never apply.
Where the risks arise
- Loss of proprietary value: copyleft obligations may require you to publish source code you intended to keep confidential.
- Infringement claims: non-compliance can lead to claims, demands to stop distribution, or reputational harm.
- Contract breaches: customer contracts often contain warranties that your software does not infringe third-party rights and is not subject to open-source terms that would affect the customer. A breach can trigger indemnity claims.
- Security: open-source components need to be monitored and updated. Outdated libraries are a common source of vulnerabilities.
- Transactions: investors and buyers routinely ask for a list of open-source components and their licences, and expect warranties about compliance.
A new reason to keep track: exporting to Europe
South African software companies that sell into the European Union should be aware of the EU Cyber Resilience Act (Regulation (EU) 2024/2847). It applies to products with digital elements made available on the EU market, regardless of where the manufacturer is based. Its vulnerability reporting obligations began to apply on 11 September 2026, and its main security requirements, including documenting software components, apply from 11 December 2027. A reliable inventory of the open-source components in your product will be central to compliance.
Who owns the code your team writes?
Open-source compliance goes hand in hand with ownership of your own code. Under the Copyright Act, copyright in work made by employees in the course of their employment generally belongs to the employer. Code written by independent contractors or freelancers generally belongs to them unless it is assigned in writing. Make sure your employment and contractor agreements deal with intellectual property, confidentiality and the use of open-source code.
Practical steps to manage open-source risk
- Adopt an open-source policy. Set out which licences developers may use freely, which need approval, and which are not permitted in your products.
- Keep an inventory. Maintain a list of open-source components and their licences, often called a software bill of materials. Automated scanning tools can help.
- Understand how you distribute. Whether you ship software, provide it on devices or offer it as a service affects which obligations are triggered.
- Comply with notice requirements. Keep copyright notices and licence texts, and include them with your product where required.
- Separate components carefully. Where copyleft code is used, design and document the architecture so that obligations are confined to that component where possible.
- Review your contracts. Check the open-source warranties and indemnities you give to customers and receive from suppliers and contractors.
- Prepare for due diligence. Before a funding round or sale, review your inventory and fix any compliance gaps.
How O’Reilly Law can help
We advise technology companies and startups on open-source policies, software licensing, intellectual property ownership and customer contracts. We review software licence agreements, prepare IP assignment and contractor agreements, and assist with intellectual property due diligence for investments and acquisitions.
Contact us to review your software licensing and open-source position.
Related reading: Who really owns your brand, code and ideas? · Preparing your business for sale: vendor due diligence
This article is general information and not legal advice. Correct as at November 2026.