News

IP Conflicts in Technical Due Diligence

By Holly Wyld, Governance Specialist at Source Code Control Ltd

Third-Party Software in M&A

If an E-Commerce cloud solution contained 27 open source licences, two of which require the entire source code to the solution to be made available, 53 copyright statements, 29 critical risk security vulnerabilities and all licence obligations are currently not met (see Figure 1) would this change the terms of your investment?

Figure 1: Licence Composition and Security Vulnerabilities found in an E-Commerce Solution, audited by Source Code Control Ltd

In our experience, we have seen that in a Merger and Acquisition (“M&A”) or an investment scenario if software contains a large quantity of open source that is not consistently tracked, acquiring organisations have delayed decisions and in some cases changed the terms and conditions of the deal.

In the context of open source software compliance, copyleft compliance issues present the most risk to the acquiring organisation. At Source Code Control we are also increasingly seeing a focus on software security.

Technology is often a material asset of a deal. If the target company is a technology company then software could be the principal asset. In these cases, it is becoming standard practice for investors or acquiring organisations to require independent code reviews which look for IP/licensing and security issues as part of the broader due diligence process.

As part of this assessment, the target will need to demonstrate the amount of control, they have over their use of open source software.

The ‘Viral’ Effects of Copyleft Licences

Copyleft licences are often referred to as ‘viral licences’. This is because they grant the right to freely distribute and modify intellectual property with the requirement that the same rights be preserved in any derivative works created. Therefore the objectives of copyleft licences conflict with those of proprietary licence business models.

Copyleft licences obligate users who modify or incorporate copyleft components into software products to license the resulting software under the same licence terms.

Because of this requirement, if the software product contains a copyleft licence like the GPL, and the software as a whole is licensed under a proprietary licence such as an End User Licence Agreement (“EULA”), this would result in a licence conflict (see Figure 2).

Figure 2: License Conflict Example

Copyleft licences also require users who modify copyleft components or develop software products that incorporate copyleft components, to share the entire source code for that product.

Users who violate a copyleft licence, like the GPL, have the choice of releasing the entire source code to the software under the same copyleft licence, removing the copyleft components which requires reengineering of the entire product or to pull the product from the market altogether. Any of these consequences may be undesirable to a potential acquirer or investor.

If the target holds IP value in their software the obligation to share the entire source code under the copyleft licence could significantly diminish or even eliminate the products commercial viability.

To illustrate, when Cisco the multinational technology conglomerate acquired the networking company Linksys for $500 million, post-deal Cisco discovered that some of Linksys’ software products contained GPL licensed components.

The Free Software Foundation (“SFS”) a non-profit organisation with a worldwide mission to promote and defend software freedom, which created the GPL, brought a copyright infringement action against Cisco for violation of the licence.

After reviewing its options Cisco believed that it would be cost-prohibitive to reengineer the code and instead entered into a settlement agreement in which Cisco agreed to release the source code to the Linksys product under the GPL licence. This meant that individuals or organisations could use, modify and distribute the software for free.

As a result, Cisco was prevented from generating licensing revenue from the software products it acquired from Linksys.   

Although, this is an old case the risks posed by violations are still relevant because of the SFS’s numerous sustained enforcement campaigns. The SFS have multiple Copyleft Compliance Projects, including their Strategic GPL Enforcement Initiative and their Firmware Liberation Project for IoT via GPL Enforcement.

Technical Due Diligence

Technical due diligence is a subset of the broader due diligence process. The process is a comprehensive review of the technical condition of the product, code quality and architecture to assess all possible risks before the completion of the transaction.

If there’s an open source risk, pre-close is the time to ascertain it, then addressing the risks can be worked into terms and integration plans. To assess the risk all third party code in the software should be identified and disclosed to the acquirer.

The most effective method of making this disclosure is to carry out a software audit to produce a Software Bill of Materials (“SBoM”).

An SBoM is a formal record of components and their associated licences in a piece of software. It is analogous to a list of ingredients on food packaging. An SBoM identifies and lists software components and their licences and the security vulnerabilities associated with those components (see Figure 3).

Figure 3: Example Source Code Control Ltd SBoM showing each component and its governing licence

Following the audit, the acquiring company should have the data to assess to what extent the target is compliant with their open source licence obligations.

This information can then be used in negotiations and when defining a remediation plan to update the code, provide attribution and notices, if necessary, to mitigate and manage any risks before the transaction execution.

However, an audit only shows the data for that particular point in time. The nature of modern software development means that new components are pulled into software in day to day operations as modifications and updates are made.

Therefore, moving forward consistent audits should be conducted so that the use of open source software can be appropriately tracked.

At Source Code Control we are increasingly seeing that investors need insurance against licence compliance moving forward post-deal. A method we have seen to secure this insurance is to request that the target becomes OpenChain ISO/IEC 5230:2020 conformant as a condition of ongoing investment.

The OpenChain standard is a best practice for improving open source software licence compliance in the software supply chain. Conformance to the OpenChain ISO 5230 standard is a great governance mechanism to ensure that the investee is not veering off the path of open source licence compliance before the investor exits.

It also has the potential to reduce friction in transactions and makes the investor’s exit smoother as, a lot of the information required during the process, such as the SBoM and the open source software policy, is ready to hand if the specification is adhered to.

Like proprietary software, open source software is a source of vulnerabilities and security risks. Therefore, security is likely to become a bigger focus in OpenChain and the technical due diligence process.

In most cases, there is already a fix to vulnerable components before a breach materialises. However, if an organisation is not tracking security vulnerabilities in their code it is irrelevant if there is a fix or not.

One of the most high profile cyber-attacks was the 2018 British Airway’s attack. The security breach compromised the sensitive data of over 400,000 of their customers, resulting in an initial £183million GDPR fine due to the breach of Article 32(see Figure 4).

Figure 4: British Airways Fine, Source BBC

The cyber-attack was caused by a well-known security vulnerability in one single component which had not been updated since 2012. British Airways received such a large fine because they had the power to avoid this breach but due to their lack of software management, it materialised.

The rise in cyber-attacks has led to an increase in regulations issued by industry and governmental bodies to regulate the use of open source software. These standards all mandate the production of SBoM’s (see above).

On the 12th of May 2021, the White House issued an Executive Order to improve the nation’s cybersecurity. The Executive Order guides buyers of software solutions to request an SBoM for each product and, software solution providers to supply an SBoM for each product.

The Executive Order has created waves across the US as software providers adjusted their processes to accommodate. This also cascaded across global markets associated with US trade. 

Other open source regulatory examples include ENISA’s ‘Guidelines for Securing the Internet of Things (IoT) – Secure Supply chain for IoT’ and the PCI Secure Software Standards for the payment card industry.

If an organisation does not consistently produce SBoM’s this will likely hinder its ability to achieve licence compliance for the software that it shares. Additionally, with the importance of open source software security and regulations on the rise, an organisation may effectively be restricting their market if it does not produce SBoM’s.

Adding Open Source to the Due Diligence List

Open source due diligence is one task in a long list that needs to be completed in an M&A transaction. It is still an important aspect of the general due diligence process, especially if the target is a technology company. Any issues uncovered are a reflection of bad practices and poor quality assurance processes.

To be prepared a target can maintain proper open source compliance practices by tracking their open source software use within development, performing consistent software audits to produce an SBoM for new or updated code entering the software and fulfilling all licence obligations.

Adopting best practices such as OpenChain ISO 5230 will assist an organisation in the due diligence process and increase the likelihood of open source software licence compliance going forward.  If licence compliance practices are not adopted into operations, organisations will only accumulate the same risks in the future.

Ultimately the acquirer will define the level of risk they are willing to assume, but they should know what to look for. The key red flags to look out for is copyleft licence compliance and large quantities of unmanaged security vulnerabilities.

Conducting appropriate open source due diligence will help potential acquirers avoid acquiring assets that may expose them to several commercial risks (for more detail on these risks see the previous article in this series titled ‘Is Your Software IP Really Your IP?’).

Resources & Best Practices

Share This