Executive management of technology companies should be mindful that a significant business partner or acquiror of the company will be highly focused on whether the use of open source software by the company’s development team is consistent with the company’s software development policies and procedures. Being fully prepared in advance to engage with a business partner on this topic is critical to reaching a successful – and timely – conclusion to a business transaction. The following are key issues about open source software that management teams and board members should consider.

Open Source Software Is Ubiquitous

Use of open source in conformance with internal controls is good business. In fact, there are very valuable open source development tools and internet infrastructure elements that are used by every company that has a desktop or data center. But not all open source projects are maintained by established groups. The key, as with any good business decision, is to balance the value of using open source software against the risks, such as possible lack of support and lack of protection against claims of copyright or patent infringement. If your development team tells you that it absolutely does not use any open source software, this should prompt further inquiry, as it is highly unlikely.  

“Just Say No” Is Not the Right Answer

A generation of programmers has been trained to develop software using open source tools and components. The best and the brightest will not go to work for a company that requires them to start every development task with a clean sheet of paper. The goal is to manage the use of open source through efficient processes that are complementary to the company’s other internal controls. A policy of prohibition will just drive use underground, making it more difficult to manage.  

Software Companies Must Be Able to Produce a Bill of Materials for Their Software

OEM partners and acquirors will request a complete inventory of the company’s software – and this is the case even if the company does not distribute its software outside the organization. Enterprise customers’ security policies, particularly in the financial services and healthcare industries, require their IT managers to know exactly what is running in the data center. Compliance with open source license requirements is often not difficult, but it does require awareness. Unlike commercial software, which usually requires the company CFO to approve the payment of license fees, open source software can be obtained by developers without upper management’s knowledge or approval. Therefore, another internal process needs to trigger review of the use of open source.

Acquirors Will Have Different Open Source Diligence Processes, and Targets Must Get It Right the First Time

The management team should know what the due diligence process will be for your preferred acquisition exit and manage your operations accordingly. For many acquirors in the software industry, the first diligence request issued to the target will be for an inventory of all third party software used by the company. Many software industry acquirors also routinely require a scan of the company’s source code by a compliance tool vendor. It is extremely rare that the first scan of a code base does not discover remnants of open source, most of which can be easily remedied in subsequent versions of code.  

Companies should be fully prepared and should not expect to negotiate their way through this process with an acquiror. If the code scan reveals open source software that is not listed in the inventory provided, the acquiror’s confidence in your development control process will be eroded, and this concern may well transfer to other aspects of the proposed transaction. The result is a delay in closing until a deep dive diligence process is completed that is sufficient to re-establish confidence that the acquiror knows what it is buying. If the original list basically matches the scan results, the acquiror will quickly move on past the open source diligence issues toward closing.  

What You Can Do Now

Management of open source software should be an integrated, cross-functional business process, with established policies and identified owners within the organization. In addition to managing the risks associated with open source, these owners can identify opportunities to improve quality, reduce costs and attract talent. The management team should establish policies and procedures that are consistent with the company’s business plan, and consider reporting to the board regularly on the company’s ongoing compliance efforts.