It is almost certain that most proprietary or in-house developed software nowadays would contain elements or modules that are open source. Open-source software, or commonly known as “OSS”, refers to software with source code that anyone can inspect, modify, enhance and use. It is very similar to software that has been licensed to end users for usage, save that the software licence comes with access to the source code of the software for modification, more often than not without charge.
The incorporation of OSS during a software development lifecycle has become something of a commonplace, primarily because of the cost saving that it brings to an organisation, and not forgetting that it is just that much quicker and easier to incorporate a set of ready source code as compared to writing everything from scratch.
If you are thinking that OSS sounds a little too good to be true, well, you are not entirely wrong. Just like any other software, OSSs are made available under their respective licensing terms and conditions. Some of these OSSs are made available free for use entirely, but would actually require the deployer of the OSS to disclose the source code of the end product incorporating the OSS to the open-source community – also known as a “copyleft licence”.
Due to the nature of copyleft licences, companies trying to commercialise their own software that contains OSS(s) under copyleft licences might have difficulty in doing so, especially when their software is meant to be distributed to others without charge. Failure to comply with the copyleft licence would often give rise to a right for the relevant open-source community to claim monetary compensation as royalty or licence fee for the use of the OSS.
To avoid the pitfall of copyleft licences, it is important for general counsels to work closely with the internal software development team to conduct due diligence on the OSSs used by the developers to verify if any of them are under a copyleft licence. Likewise, in a software acquisition exercise or when contemplating the acquisition or investment in a software company, it is important for the legal team to conduct thorough due diligence on the provenance of the target software or the software owned by the target company. We have put forth below a quick guide on how to conduct due diligence on the OSSs incorporated in a software.
- 1. Exhaustive Listing of OSSs Used in the Software Development
- The first step is naturally to request for an exhaustive listing of the OSSs used by the developers or the company in developing its in-house software. Chances are, the listing may actually contain not just the OSSs incorporated, but also the “OSS development tool” used by the developers. Typically, an OSS development tool should not have any copyleft element that could affect the rights to distribute the software end products. The legal team reviewing the listing will have to take note of the distinction and filter off the non-OSS entries in the listing.
- .
- 2. Reviewing the Applicable Open-Source Licence
- Having just the listing of the OSSs itself is meaningless if the legal team does not have visibility to the licensing terms and conditions of the OSSs. The good news is, most, if not all of the licensing terms of OSSs are published online, simply because the OSS packages are commonly distributed online by the community. The legal team should then conduct its own independent online verification to locate the licensing terms applicable to the relevant OSS and to review the same to assess whether the terms would require the deployers or users incorporating the OSS to similarly distribute the software end products via the same open-source terms or copyleft licence. A strict copyleft licence will demand the disclosure of the source code of the entirety of the software end product. Some copyleft licence may take a more laxed approach in demanding only the component or portion of the software integrated with the OSS to be disclosed.
- .
- 3. Determining the Next Step
- While finding a copyleft licence in a software is usually a red flag, there are ways that a company can mitigate the impact. Assuming that the copyleft licence only requires a limited portion or component of the software end product that is actually integrated with the OSS to be disclosed, companies may opt to do so if the ability to commercialise the software as a whole can still be preserved. Otherwise, the terms of a copyleft licence would normally allow the deployer or developer a way out of strict compliance with the copyleft requirement – to pay a licence fee or royalty for the use of the OSS. If none of the above is commercially viable, then the next available step for the company to take is naturally to source for an alternative OSS with less stringent licensing terms.
- .
Navigating the usage of OSS can be daunting, especially for legal team that is less familiar with software or technology parlance. It would be crucial for companies to work with legal advisers who are well versed in the industry to avoid any potential pitfalls that can be costly to the operation of the company. A competent legal team should even be able to help the company to manoeuvre the complex restrictions and requirements of OSS to maximise the commercial objectives of the company.
The Technology Practice Group at Halim Hong & Quek frequently assists clients with due diligence on software products incorporated with OSS, as well as advising clients on the impact of incorporating certain OSS under certain licensing terms. Please feel free to reach out to the team should you have any enquiry in this regard.
About the authors
Lo Khai Yi
Partner
Co-Head of Technology Practice Group
Technology, Media & Telecommunications (“TMT”), Technology
Acquisition and Outsourcing, Telecommunication Licensing and
Acquisition, Cybersecurity
ky.lo@hhq.com.my.
.
Ong Johnson
Partner
Head of Technology Practice Group
Technology, Media & Telecommunications (“TMT”),
Fintech, TMT Disputes, TMT Competition, Regulatory
and Compliance
johnson.ong@hhq.com.my
More of our Tech articles that you should read:
