The Allure and Misconception of Open Source
Open-Source Software (“OSS”) is nothing new within the Nigerian tech scene. From household names like Flutterwave to early-stage startups, open-source tools power key components from prototypes to full-scale platforms. They help teams ship faster, add new features easily, and build cost-efficient products. Yet one common misconception persists: “open source means no rules.”
In reality, “free to use” does not mean “free from obligations.” Every OSS comes with a licence that dictates how it can be used, shared, or modified. For example, an OSS license may prohibit commercial use, AI training, redistribution without attribution, or modification of source code. Ignoring these terms can expose your startup to serious legal and commercial risks such as huge penalties resulting from intellectual property claims capable of destabilizing your startup.
In this edition of Tech Brief by TALP, we will be examining OSS, its associated risks, and mitigation strategies.
What Exactly is Open-Source Software?
Open-Source Software is any software whose source code is publicly available for anyone to view, use, and modify. However, every OSS comes with a licence, and that licence is what dictates how you can use the OSS. These licence requirements typically kick in when you distribute the OSS; for example, when you share, integrate, or commercialise a product that integrates or contains a modified version of the open-source component. What qualifies as “distribution” can vary from one licence to another.
Types of OSS Licences
OSS licences generally fall into two main categories:
- Permissive Licenses: These licences allow you to freely use, modify, and even sell derivative software with minimal conditions — usually just a requirement for attribution or inclusion of a copyright notice. An example is the Apache License 2.0.
- Restrictive (or Copyleft) Licences: As the name suggests, these come with stricter rules. An example is the GNU General Public License (“GPL”). Copyleft licenses can be grouped into “weak” and “strong” categories. A weak copyleft license typically requires you to share the source code of only the portions of OSS you have modified or directly integrated into your own software. In contrast, a strong copyleft license goes further. It mandates that you disclose the entire source code of your derivative software under the same license terms as the original OSS.
A practical example: Some Tesla vehicles use the Linux Kernel, which is licensed under GPLv2. To comply with license requirements, Tesla began releasing the source code for certain software components built on top of the Linux Kernel.
Key Legal Risks When Using OSS
- Claims on License Violation: Failing to comply with licence terms can trigger infringement claims. In the French case of Entr’Ouvert v. Orange, the court ordered Orange S.A. to pay €900,000 in damages and costs for violating a copyleft licence.
- Exposure to Patent Claims: While most OSS licences protect you from copyright infringement claims by the developers, they do not always extend protection to patent claims. In other words, you could use open-source code perfectly within its licence terms and still get sued if its functionality, for example, infringes on someone else’s patent. Take the 2009 case of Microsoft v. TomTom. TomTom, known for its navigation systems, used the Linux Kernel (an OSS) in its devices. Microsoft claimed TomTom’s use of that open-source component infringed on its patents.
- Licence Compatibility: Different open-source components often come with different licence requirements. When a copyleft OSS licence is mixed with a third-party licence that demands exclusivity or confidentiality, conflicts can arise. The copyleft licence may require source code disclosure, while the proprietary terms prohibit it.
- Indemnity and Liability Limitation: Most OSS licences come with blanket disclaimers excluding all forms of liability in relation to your use of the OSS. They pretty much imply “use at your own risk.” So, if something breaks or exposes your system to loss, you cannot recover damages from its developers.
- Security Vulnerabilities: Because OSS source code is publicly available, its weaknesses are also visible not just to other developers, but to hackers. If you adopt OSS without addressing known vulnerabilities, your system becomes an easy target. Moreover, when certain OSS projects lose community support, users often turn to unverified sources for updates, exposing their systems to malware or malicious code injections.
How can these risks be mitigated?
- Set Clear Ground Rules for OSS Adoption
Develop internal policies for adopting open-source components. Define a clear approval process, especially when copyleft licenses are being used. Specify which licence types are acceptable and always loop in your legal team for a thorough review of the license terms.
- Maintain a Software Bill of Materials (SBOM)
Think of the SBOM as an inventory of your software components. Maintain a detailed log of every open-source component used in your products, including licence types and key requirements. This makes it easier to track compliance obligations and identify vulnerabilities before they become a problem.
- Know Your Licences Obligations (and Their Triggers)
Different licences activate obligations at different stages (use, modification, distribution). Knowing these triggers prevents accidental breaches.
- Train your Team
Your developers are your first line of defence. Make sure they understand your OSS adoption rules, and encourage them to pursue certifications and training offered by reputable institutions such as the Linux Foundation’s OSS Compliance courses.
- Stick with Supported and Scalable Software
Always verify that the OSS you are using is actively maintained and has a strong developer community. Unsupported projects often lack updates, patches, and documentation, exposing your system to security and performance risks. Also, assess the software’s scalability, whether it can handle growth in users, data, or features without breaking. Choosing OSS with long-term support and proven scalability helps ensure stability as your product evolves.
- Run Regular Code Audits
Make OSS review part of your routine audit. Tools like Black Duck, FOSSA, or Mend (formerly WhiteSource) can identify open-source components and flag potential compliance issues. Regular audits keep you secure and compliant.
Conclusion
Adopting open-source software is not a mistake; it is an opportunity. With clear internal policies, regular audits, and informed legal oversight, startups can harness OSS to innovate faster and smarter, without fear of compliance pitfalls.
The rule of thumb: free access does not mean free rein.
Disclaimer: This Newsletter is for general informational purposes only and does not constitute legal advice.
