Open Source Software in Mergers & Acquisitions

Careful OSS planning and record-keeping will pay off when an M&A is at hand.

Open Source Software (OSS) is a vital part of business’s technology platforms. Businesses use OSS either for their own operations, to run their computer servers (mostly through Linux, BSD or Solaris operating systems), or to develop proprietary software for commercial sale (through the use of the GCC compiler, debuggers and other software tools). Indeed, surveys find that more than 50% of Fortune 500 companies rely upon OSS in their operations.

The use of OSS is prominent in high tech companies, particularly startups. They incorporate OSS in the products they distribute or offer: software, embedded systems, and Software as a Service (SaaS). OSS permits technology companies to shorten their development cycles, allowing them to focus on what they do best instead of writing all software from scratch.  In addition, with OSS, technology companies benefit from well-proven – indeed, sometimes industry-standard – software, avoid vendor lock-in, and take advantage of free community support.  Significantly for cash-strapped start-up companies, use of OSS reduces licensing expenses to practically zero.

Yet OSS does not come without costs. In the memorable words of Richard M. Stallman, a founder of the Free Software movement, OSS is free as in “free speech, not free as in free beer”. With OSS, one gets access to the software’s source code in exchange for obligations imposed upon him by the OSS license.

OSS licenses are categorized in two groups:

• Some of them permit free use, modification and distribution of the software they cover. Such Permissive Licenses are often referred to as Academic Licenses. The limitations they pose are usually few and easy to follow. Typical examples of such licenses include the BSD, MIT and Apache 2.0 licenses
• Others require the user to maintain the terms of the license when the user distributes OSS further. Hence, distributing the OSS down the stream must include access to its source code and retain all rights provided by the license. These are called Reciprocity Licenses and often referred to also as “Copyleft” licenses. Some apply their provisions only to the original code and to its modifications, a doctrine known as “Weak Reciprocity”. The Mozilla Public License is a good example of a Weak Reciprocity license. Others apply to any combination of OSS with proprietary code. The GNU General Public License is the most widely used and best example of these “Strong Reciprocity” licenses. Strong Reciprocity licenses may apply to code that companies want to keep as a commercial secret to preserve a competitive edge.

When a start-up company reaches its exit point, it can no longer ignore the costs associated with OSS. A potential acquirer’s due diligence process would require the target company to list all OSS components it uses and their respective licenses. A typical representation in an acquisition or merger agreement is “As of the Closing Date, no OSS that is or has been incorporated or otherwise integrated into, aggregated or compiled with the Company Proprietary Software is licensed to subject to the terms of, or on terms substantially similar to” certain OSS licenses. What seem to be a simple task – providing a list of OSS components and their respective licenses – may be the most daunting of all due diligence burdens, one that may delay the closing for weeks or, even worst, cause the potential acquirer to walk away.

The reason lies in companies’ poor control and management of their OSS: They either don’t have a comprehensive list of OSS they utilize, or they have an insufficient and incomprehensive one (poorly maintained Excel sheets tend to be the favorite choice). In that respect developers tend to forget that even if they maintain a list of OSS, the components they incorporate in their software rely upon other OSS components in order to function. A fully detailed list may include dozens, hundreds and even thousands of OSS libraries and programs. In the heat of development, when reaching the market is management’s top priority, the legal nitty-gritty is often neglected. This neglect can later blow up in the face of the start-up company’s management, angering investors and potentially scuttling deals.

Controlling the use of OSS, is therefore of the outmost importance. The benefits are clear: deciding in advance what OSS to use and how to use it reduces legal risks involved with OSS and paves the way for a smooth exit.

In order to achieve such control, organizations need both an OSS Compliance Policy and a repository of its OSS:

• A solid OSS Policy requires that no use of OSS is made unless it is approved in advance. Approval may be given by single OSS Office (in the case of a newly born start-up), by an Open Source Board that will typically include representatives of the company’s IT, IP and Legal departments (if a more mature company is involved) – or otherwise as may be provided by the Policy. The challenge is to draft an approval process that not only meets the legal standard of care, but also provides an answer as fast as the developments process requires (usually, much faster than lawyers tend to believe…)
• The Repository of OSS is best created and marinated automatically. This is achieved through industry standard yet expensive tools such as Black Duck– or through the use of other tools that have become available lately, some of which are OSS themselves.

Investing in a reliable OSS policy and maintaining a comprehensive list of OSS will definitely pay-off when a long-awaited acquirer knocks upon a company’s door.