Open Source Software A Core Competency For Effective Tech M&A

By Mark Kesslen, Esq. and John Wintermute, Esq.

Imagine your company just acquired its competitor for $100 million.  Now imagine the company’s most important asset – its proprietary software – is subject to third-party license conditions that require the proprietary software to be distributed free of charge or in source code form. Or, imagine these license conditions are discovered late in the diligence process, and the cost to replace the offending third-party software will costs tens of thousands of dollars and take months to remediate. Both scenarios exemplify the acute, distinct and often overlooked risks inherent to the commercial use of open source software. An effective tech M&A attorney must appreciate these risks and be prepared to take the steps necessary to mitigate or eliminate them.

Over the past decade, open source software has become a mainstay in the technology community.  Since its beginnings, open source software has always been viewed as a way to save money and jumpstart development projects, but it is increasingly being looked to for its quality solutions and operational advantages.  Today, only a fraction of technology companies do not use open source software in any way. For most of the rest, it is mission critical.

While the tech community has rapidly warmed to the idea of open source as a core strategy, technology lawyers have struggled to implement streamlined practices for addressing and solving the unique legal questions presented by open source software, particularly in the M&A arena. Failure to properly prepare for open source diligence or to identify and remediate potential red flags in an efficient manner can cause a deal to grind to a halt. Avoiding this fate requires an understanding of best practices for the disclosure and review of open source software, as well as the variety of solutions and compromises available to attorneys on each side seeking to close a deal. To that end, an effective M&A tech attorney must be able to:

• counsel a client’s technology staff on the disclosures that should or will be required;
• identify when a third-party open source audit may be necessary; and
• raise or rule out red flags based on a company’s use of open source within its larger business model.

The first step of open source diligence review is, unsurprisingly, compiling a list of the open source components being used by the target company. If the company has already implemented an effective open source management policy, this list should already be assembled. However, it is not atypical for companies to be unaware of the extent of open source in their products and systems. One potential reason is that the developers who originally wrote the applicable code may no longer be with the company. If those developers did not track or record their implementation of open source, the company’s current personnel will be tasked with diagnosing the company’s code base and determining the origins of any third-party code located therein.

In order to conduct a meaningful open source review, a company must also provide some additional pieces of information with respect to each open source component in use, including (1) the license governing each component, (2) how the component is being used by the company, including whether the component has been modified or integrated into any proprietary code, and (3) whether the component has been distributed, or is otherwise made available, to third parties. If the company heavily utilizes open source software, compiling this information can be a burdensome and time-consuming task. For this reason, an attorney must communicate with a client’s technology staff as early as possible, making clear, as buyer’s counsel, what information should be requested from the seller, and, as seller’s counsel, what information needs to be gathered and why.

As discussed above, many companies will have an incomplete understanding of their own use of open source software. In fact, a recent survey by open source security and management company Black Duck Software revealed that less than half of all code owners can produce a list of known open source in their code. What’s more, those that can tend to produce a list comprising, on average, only half of the open source actually being used. For obvious reasons, this lack of understanding presents a significant risk for buyers and investors. Aside from the risk that companies are not in compliance with the applicable open source licenses, an incomplete grasp of open source usage can lead to security vulnerabilities or a miscalculation of the proprietary value of the code base being acquired.

There is a reasonable argument that open source audits should be performed in connection with every transaction, especially when considering the vast number of companies that cannot properly document their use of open source. Both buyers and sellers will often be hesitant to absorb the expense of an often costly audit.  Therefore, it is important for attorneys to understand when a third-party audit is especially crucial.

Certainly, a company’s inability to put together a list of the open source software it uses should strongly incentivize both parties to employ a third-party auditor. However, open source audits are also strongly advised whenever license non-compliance presents heightened risks or when remediation would be difficult or infeasible. For instance, when open source software has been integrated into the company’s product and distributed to customers or other third parties, it may be difficult or costly to fix and replace any misuses of the open source, especially if the software is embedded within hardware or other physical devices. Additionally, if a significant portion of a company’s value resides in the proprietary nature of its software, it is especially important to understand the scope of open source incorporated into that software.[1]

If any of these risk factors are present, a third-party audit might be desirable from both a buyer’s and a seller’s perspective. From a buyer’s standpoint, a third-party audit provides peace of mind and fuller confidence that it understands and appreciates the composition of the code base it is buying. From a seller’s standpoint, a third-party audit can reduce the risk of providing representations and warranties regarding its use of open source.

Once any potential risks stemming from a seller’s use of open source have been identified, it is important for the attorneys involved to communicate the scope of each risk to their clients, in order to determine in each instance the appropriate reaction and/or remedy. It is standard practice for sellers, in addition to compiling a full list of open source, to provide a representation that all uses of open source comply with any applicable licenses in all material respects. However, when internal diligence or a third-party audit reveals a misuse of open source software, the parties may decide among a few different solutions.

First, to the extent a piece of misused open source software is easily replaceable, a seller should be required to fix and replace the applicable component as a condition to closing. Second, if the disclosure of open source has revealed a discrepancy between the presumed and the actual portion of proprietary coding in the seller’s code base, the parties should discuss whether an adjustment in purchase price is warranted. Lastly, if the ongoing use of open source presents a risk that cannot easily be remediated, the parties should consider whether representation and warranty insurance might be appropriate.

As open source continues to devour the world of software, M&A attorneys involved in tech transactions of any kind must be prepared for the unique hurdles and pitfalls presented by open source diligence and review. By committing to a set of standard practices, such as those set forth above, this diligence and review can be streamlined to avoid unnecessary bottlenecks. The first step is appreciating that open source software is now a core competency for all tech M&A attorneys.

Kesslen

Mark Kesslen, Partner at Lowenstein Sandler, where he is Chair of their Intellectual Property Section of Tech Group and Co-chair of the firm’s Intellectual Property Litigation Practice.

Wintermute

John Wintermute, Associate at Lowenstein Sandler, where he focuses on all aspects of intellectual property and commercial transactions

[1] Open source audits are also useful as an internal compliance tool or in preparation for a public offering.

Image Credits: Lowenstein, Steve Hockstein/HarvardStudio.com