United States: Managing Open Source Software Risks In M&A Corporate Transactions

Introduction

Open source software usage has become quite pervasive and its use is growing rapidly. The infrastructure of the Internet (e.g., mail transports, web servers, and FTP servers) is largely based on open source applications. In fact, everybody who sends email or uses the web is using open source software all the time. A few of the best known examples of open source software are the Linux Operating System, Apache Web Server and mySQL database. The most successful open-source platform is Linux, an open source operating system. Sales of servers running Linux increased 65% in 2003. Apache is currently the number one web server with twice the market share of its nearest ranked competitor, and mySQL's open source database market share is growing faster than Microsoft's SQL server and access database. Open source is also widely used in connection with network monitoring, diagnosis, and vulnerability testing tools such as the Sport and Kismet network intrusion detection systems, Nessus and Nmap security scanners, and Kismet wireless network detector.

Given the pervasiveness of open source software, it is critical to consider the risks of open source software in most mergers and acquisitions. In this article, we explain what open source software is and identify some of the key risks and strategies for handling these risks in an acquisition transaction.

Open source is a development methodology. The open source community believes that the open source model produces "better software than the traditional closed model, in which only a very few programmers can see the source." The idea underlying open source is based on the following premise:

"When programmers can read, redistribute, and modify the source code for a piece of software, the software evolves. People improve it, people adapt it, and people fix bugs. And this can happen at a speed that, if one is used to the slow pace of conventional software development, seems astonishing."

Stated another way, the open source community believes that the open source model "promotes software reliability and quality by supporting independent peer review and rapid evolution of the source code." Open source proponents believe that source code will get improved, adapted and corrected much faster in an open source model than in a closed source model. They believe that because anyone who makes fixes to software is allowed to distribute those fixes or improvements, the quality of the software will increase exponentially. Open source also may be reused for new purposes. This allows the open source software to be easily and creatively repurposed.

Another point stressed by open source proponents is that the open source licensee is not "locked into" a particular vendor and its "particular schedule of bug fixes, modifications and alterations." With open source, there may be many engineers who might fix bugs because the source code is available. In addition, the open source process is said to encourage interoperability. However, the interoperability of open source programs is usually not formally certified and due care needs to be exercised to ensure compatibility and interoperability requirements are met.

The open source definition is derived from the definition of "free software". Software meeting the definition of "free software" also usually meets the definition of "open source software".

The Free Software Foundation has defined "free software". The key text of that definition is as follows: "Free software" is a matter of liberty, not price. To understand the concept, you should think of "free" as in "free speech", not as in "free beer". Free software is a matter of the users' freedom to run, copy, distribute, study, change and improve the software. More precisely, it refers to four kinds of freedom for the users of the software:

• The freedom to run the program, for any purposes (freedom 0).

• The freedom to study how the program works, and adapt it to your needs (freedom 1). Access to the source code is a precondition for this.

• The freedom to redistribute copies so you can help your neighbor (freedom 2).

• The freedom to improve the program, and release your improvements to the public, so that the whole community benefits. (freedom 3). Access to the source code is a precondition for this.

A computer program is free software if users have all of these freedoms. Thus, users should be free to redistribute copies, either with or without modifications, either gratis or charging a fee for distribution, to anyone anywhere. Being free to do these things means (among other things) that users do not have to ask or pay for permission. Users should also have the freedom to make modifications and use them privately in their own work or play, without even mentioning that they exist. If users do publish changes, they should not be required to notify anyone in particular, or in any particular way. The freedom to use a program means the freedom for any kind of person or organization to use it on any kind of computer system, for any kind of overall job, and without being required to communicate subsequently with the developer or any other specific entity.

"Open Source" software is "associated with a different approach, a different philosophy, different values, and even a different criterion for which licenses are acceptable." Open source code is not secret, confidential or proprietary. The opposite of open source is "closed" or "proprietary" software. But open source does not mean that the source code is in the public domain. The Open Source Initiative ("OSI") has defined open source as software providing the following rights and obligations:

Free Distribution. Open source requires free redistribution of the open source software. The open source license may not restrict anyone from either selling or giving away open source software or require a royalty or other fee for such sale. It should be noted that this criteria does not preclude charging a fee to licensees for warranty, support, indemnity or liability obligations, or for charging fees or royalties to the extent the open source software is sold properly as part of a larger work or aggregate software distribution including proprietary software. In fact, some companies sell proprietary software add-ons or manuals for open source software. While licensees or licensors may choose to offer, and to charge for, warranty support, indemnity or liability obligations to one or more recipients, in such circumstances the fee-charging party must make it absolutely clear that any such warranty, support, indemnity or liability obligation is offered by such fee-charging party alone and must indemnify the original developer and any other contributor for any liability incurred as the result of warranty, support, indemnity or liability obligations. Depending on the open source product, there could be a large universe of indemnitees some of which may be unknown.

Source Code. The distributed program must include source code. Source code availability is a major requirement in open source licensing. The license must include a distribution of "unobfuscated" source code or a well-publicized means of obtaining the source code for no more than a reasonable reproduction cost. Today, many open source licensors make the source code available without charge on their website for downloading from the Internet. For example, reference is increasingly being made to source code being made available by an "Electronic Distribution Mechanism". The source code made available to open source licensees must be the preferred form in which a programmer would modify the software, since the purpose of open source is to make evolution easy. Some open source licenses provide that the source code can be compressed or in archival form, provided the appropriate decompression or dearchiving software is widely available for no charge. Deliberately obfuscated source code is not allowed. Similarly, intermediate forms such as the output of a preprocessor or translator are not allowed as substitutes for the source code.

Derived Works/Integrity of the Authors. The open source license must allow distribution of modified software or derivative works, and must allow them to be distributed under the same terms as the license of the original open source software. Another license concept relates to author recognition and integrity. Some open source licenses provide for specific attribution to the contributor. Recognition and attribution are open source motivators. To protect the author's reputation, the license may require derivative works to carry a different name or version number from the original software. Some open source developers seek to protect their reputation by prohibiting the use of their name as an endorsement or to promote derivative works based on the code they wrote. Open source licenses may require modified versions to be distributed as the original version plus patches for the purpose of modifying the program at build time. But the license must explicitly permit distribution of software built from modified source even though the patches are readily distinguished from the base source.

No Discrimination. Another open source requirement is that the license must not discriminate against any person or group of persons. The open source license may not restrict areas of use or groups. For example, most proprietary software licenses typically include export restrictions for certain kinds of software. A compliant open source license may warn licensees of applicable restrictions but may not incorporate such restrictions in the open source license itself. We will provide an example of this later in these materials. Also, the open source license must not restrict anyone from using the software in a specific field, or area, or for a specific purpose, whether commercially or otherwise. There may be no restrictions on fields of endeavor in the open source license.

Distribution of License. The rights attaching to an open source program must apply and flow through to anyone who receives the open source software without any additional licensing terms and conditions and without the need for the execution of an additional license by those parties. Each licensee agrees to pass the same terms to its own licensees and require those licensees to do the same throughout the chain of distribution. This requirement seeks to prevent a licensee from closing up open source software by indirect means, such as requiring a nondisclosure agreement. The rights to read, execute, modify and redistribute the open source software are the essence of "free" software. Importantly, however, a licensee is not required to redistribute to anyone if the licensee does not want to engage in redistribution.

License Not Product Specific. The open source license applies to the open source program as a whole and each of its components. The open source licensed program cannot be made exclusively part of a particular distribution. The open source programs can always be extracted independently and used with other distributions. For example, the open source programs that are distributed as part of an aggregation or larger work with proprietary software may be extracted from the aggregation or larger work and be used and distributed separately under the open source license applicable to the open source product. The license terms of the original open source license apply to the extracted open source program.

License Must Not Restrict Other Software. The open source license must not place restrictions on other closed source software that is distributed with the licensed software. Open source licensing permits open source programs to be distributed along with proprietary software. Furthermore, the license must not require that all programs distributed on the same medium with the open source program be open source too. Proprietary and open source software may be linked as long as they do not become a single work. If the proprietary code modifies or is a derivative work based on the open source, the entire work is then subject to the open source license. Version 1.9 of the OSI definition of open source removed the rationale in the GPL referring to "contamination" in the event a derivative work is created. This "contamination" aspect of the GPL is one of the most controversial issues relating to open source. Under the GPL, software that contains any part of the GPL program must be licensed under the GPL. A little piece of GPL code in a software program can infect the entire product making the entire product subject to the GPL license.

License Must Be Technology-Neutral. No provision of the license may be predicated on any individual technology or style or interface.

Open source software must comply with the preceding eight obligations. Open source software is software for which the source code is freely and publicly available, though the specific licensing agreements vary as to what one is allowed to do with the code.

One can distinguish open source licenses from proprietary licenses in the following way. With open source, everything is allowed except that which is forbidden. On the other hand, with a proprietary source, everything is forbidden except that which is allowed.

The OSI definition of open source licenses provides great flexibility in the form an open source license can take. Open source software is defined as software distributed under an approved open source license. As of writing this article, OSI has approved at least 54 open source licenses that are each posted at the OSI website, http://www.opensource.org. The number of approved licenses is continually growing, and new versions are being published as new issues are identified. These approved licenses may be divided broadly into two groups -- protective open source licenses and non-protective open source licenses. The non-protective open source licenses apply no restrictions on the distribution of derivative works because they do not protect the code from being used in non-open source applications. Protective open source licenses, on the other hand, apply restrictions on the redistribution of the open source program so that the code will always remain open.

Under the non-protective open source licenses, the licensed open source software can be readily incorporated into binary code and redistributed in binary form. Non-protective open source licenses do not impose a restriction on the replication and redistribution of the source code.

The vast majority of open source licenses follow one of four license models: (i) GNU General Public License (GPL License); (ii) GNU Lesser (or Library) General Public License (LGPL License); (iii) MIT (aka XII) License; and (iv) BSD-new License. These four open source licenses are sometimes referred to as the "classic" open source licenses. They were the most commonly used open source software licenses before the release of the Mozilla license in 1998. Now the Mozilla Public License has also become widely used. The predominant license form by far appears to be the GPL License. The Linux license is based on a GPL License. While GPL is still the dominant form of license, there seems to be many more license models that are being created, adopted and used.

Since there are many forms of open source licenses, each license must be separately analyzed. Different issues and problems may arise under the different forms of license. The analysis may involve software products covered by multiple open source licenses. For example, software may incorporate open source code or dynamically link to open source code. The code may be subject to different open source licenses, greatly complicating the analysis. Many open source licenses are incompatible with other open source licenses which makes the use of multiple open source licenses especially challenging.

In mergers and acquisitions, open source issues have become a significant concern. Open source considerations may affect the representations, warranties, indemnities, value and structure of a merger or acquisition transaction. Typical documentation used to "paper" merger transactions may have to be modified to reflect open source issues. For example, damages from a breach of representation due to open source may be "carved out" from indemnification coverage in some cases.

Fundamentally, open source issues impact a merger or acquisition transaction because buyers need to know what rights and liabilities are being transferred. Thus, if open source code is disclosed during due diligence, the buyer will need to determine the effect open source code has on the risks being evaluated by the buyer in the proposed transaction. For example, even though open source software being used by a target was only modified for internal use, it is possible in an asset transfer transaction that the open source derivative work rules may apply to the transfer of software assets containing open source code. Below are some questions to consider in merger and acquisition transactions:

• What seller products are affected by the open source code?

• How is the open source code incorporated in seller's products?

• What open source licenses apply to the open source code related to Seller's products?

• Will the open source code trigger the derivative work open source licensing requirements?

• May the open source code be replaced with closed proprietary code if necessary?

• What is the value of the product or products affected by open source to the overall deal?

• Do the affected products represent a substantial source of revenue to the company?

• Are the affected products part of an integrated software solution or suite of products?

• Are the affected products used solely for the internal operations of the company?

These are just some of the questions relating to open source that may arise in a merger and acquisition context. Resolution of some of the issues will require both legal and technical assistance. Companies are providing technical assistance on the diligence for the open source issue as a new business model. One company has developed technology that enables companies to conduct an automated scan/audit of Java code files in order to pinpoint open source components found, including the names of the applicable open source licenses. This technology could prove very useful to acquiring companies in an acquisition transaction. Another open source auditing product can be run in background on a target developer's computers. The product will monitor in real time any downloads of source code effected by the developer's computer and appropriately flag open source components.

Many potential target companies, who do not intend to redistribute open source they license and modify internally, may still find that open source issues will affect the sale of their company. If the sale is viewed as a redistribution, the open source redistribution requirements may be triggered. Thus companies should consider the treatment of open source software as a key business practice which might affect the risk profile being assessed by a potential buyer.

Conclusion

Open source risks have become a significant diligence issue in many mergers and acquisitions. Open source issues need to be included on today's due diligence lists. The treatment of open source at a target company may affect representations, warranties, indemnification, covenants and other contract provisions. Open source issues may affect the risk assessment and structure of the deal. These issues are likely to become more important in mergers and acquisitions in coming years as the presence of open source software in global businesses continues to grow.

This article is intended to provide information on recent legal developments. It should not be construed as legal advice or legal opinion on specific facts. Pursuant to applicable Rules of Professional Conduct, it may constitute advertising.