Open source software – how to carry out the due diligence

When investing in or acquiring Fintech companies, one critical part of the due diligence process often relates to the details around software development, ownership of Ip and any use of so-called open source components. this review, which is important to any investment in tech-companies, can potentially be crucial in a Fintech setting. this is due to the fact that the necessary control of the relevant software solutions may have regulatory and security impacts, with potentially severe consequences should any issues arise. So how should a thorough review be conducted? In practice, a complete and exhaustive review may be difficult to achieve. However, there are many ways to ensure that the legal and technical risks with open source components are minimized.

Open source components constitute an essential part of software development, without which the IT community would be unable to develop high-quality software with the requisite speed and financial viability. However, the use of open source components also come with significant legal and ownership risks that need to be considered when deciding to use such components in a company’s software products or proprietary IT solutions.
Therefore, when investing in a software development company, one needs to consider several possible risks associated with the use of open source components. 
On an overarching level, some of these may include:

• Loss of revenue. If it is unclear which open source components are actually integrated or which license terms apply, a company´s current or future investments in creating new software products for commercialization may be endangered.
• Loss of advantage over competitors. If applicable licenses contain so called “copy left” provisions, the company may be forced to disclose trade secrets that are integrated in the code.
• Violation of the license. Open source licenses can be enforced by the copyright legal framework if the company doesn´t comply with the terms of the license. If it is unclear which open source components are integrated, it can be practically impossible to ensure compliance with the license terms.
• Copyright infringement. Open source codes could contain components that are nevertheless subject to third-party copyright. It can therefore be difficult to ensure that code labelled as open source is, in fact, not proprietary. Use of such code could constitute infringement, which – in a worst-case scenario – could lead to a ban on sales of the product.
• Badwill. Failure to comply with applicable license terms, or any consequence of such non-compliance (including sales ban), may cause significant reputational harm – particularly concerning FinTech solutions, where quality requirements are generally high.
• Potential regulatory risks. For many FinTech services, applicable regulations contain requirements on noninterruption and security, as well as system integrity and stability. Any issues due to non-compliance with license terms, for example, may risk affecting regulatory approvals.

How, and to what degree, these risks should be considered and reviewed will need to be based on a case-by-case assessment, depending on the specific details of each investment or acquisition. There are also several possible ways to address any open-source related risks, depending on the type and severity of the risks, some of which are outlined below:

A) At a minimum, one should ensure that there are always clear procedures and policies in place, and that they are adhered to, for any open-source usage in the development of software products or proprietary IT solutions. Such procedures should include a comprehensive license inventory of all third-party components used in the developed software. The inventory should include all open source components as well as any commercial licenses.

B) In any investment or acquisition, some degree of protection from adverse outcomes may be provided by warranties and indemnification obligations related to the identified open source risks. However, such warranties or indemnities are, by their very nature, always limited and often do not fully offset or hedge the risks of uncontrolled or unlawful use of open source components – particularly in a FinTech setting, where adverse outcomes may be more severe than the protection provided by a warranty is able to offset.

C) The most efficient way of minimizing such open-source related risks is to undertake a thorough due diligence (both legal and technical) of the company and its product. For such due diligence, the aim is to identify the components used and ensure compliance as far as possible. The focus should be to gain as much knowledge of the content of the product as possible, and take all necessary steps to reduce any uncertainties.

It may, however, not be possible to comprehensively review the actual components used in a software product without actually reviewing the relevant source code – with millions of open source projects around the world, this would be incredibly time consuming without the use of automated services conducting such a review. Potential open source components in the source code can therefore be controlled with automated tools that conduct in-depth scans and comparisons with open source code databases (which may also indicate relevant applicable license terms). There are a variety of tools (sometimes called open source management solutions, automated tools, open source scanning tools, etc.), which can perform this task. Some of these tools include Black Duck, Protecode, Palamida, WhiteSource  and OpenLogic.

However, even if such tools provide significant help in assessing the risks associated with open source software, the assessment would normally require that the software product’s source code is made available to the scanning tool provider. Although this can be done under obligations of confidentiality, such disclosure can be very sensitive during a due diligence process (since many software proprietors – often correctly – consider their source code their most valuable asset, and thus confidentiality must be assured). At the same time, the product owner will have to assess the benefits of disclosing the source code to avoid open source vulnerabilities, which can be costly. Both pathways have risks associated with them and should be evaluated on a case-by-case basis.

The correct course of action will of course depend on the value and importance of the software product in relation to the business model and the risks associated therewith. Since many of these risks are legal in nature, but technical in their origin, we recommend having a lawyer with the requisite technical expertise on hand at each step!