Blue Oak Council

Blue Oak Council opens the software commons up to those who can’t find or afford specialized legal help by bringing experienced lawyer-technologists together to publish free, practical materials about software licenses.

Open Source Software in Mergers and Acquisitions

This article will help you understand and negotiate representations and warranties regarding open source software in M&A and other agreements. Note: The model representation suggested in this article appears at the end.

Actual practice in drafting open source representations still lags behind best practices. In the late 1990s to early 2000s, open source representations started to crop up in M&A deals, and these early drafting attempts at managing open source compliance risk have persisted as first conceived, despite decades of later developments, including mass adoption of open source software.

Representations about open source software in M&A deals—as in investment, commercial licensing, and other deals, for that matter—fall into three categories:

The purpose of these representations is to:

This article does not address sellers who themselves publish open source software, rather that use open source software published by others. That risk is not a compliance risk, but a valuation element for the deal. It is usually addressed in other representations of the agreement, which require seller to disclose any seller-authored code that has been publicly disclosed in source code form.

No Open Source?

Open source is everywhere. Today, representations that a product contains no open source software are almost always false. Those representations still crop up, and those who write them usually say that they are intended to force disclosure. Even so, it is better to take a representation that prescribes the full substance of the disclosure. Otherwise, sellers are likely to create disclosures that shift risk to the buyer, but lack the information necessary for the buyer to assess its risk. Using a robust listing representation will skip this iteration.

Listing Representations

Open source representations require the seller to list the open source software it uses. This disclosure helps the buyer assess compliance risk, but also helps with post-closing integration, especially in creating license notices where they are all too often missing.

In practice, listing representations often ask for too much. The most significant open source risk in an M&A deal results from the non-compliant use of open source in the seller’s product. But listing representations often ask for more. There is a school of thought that you can’t have too much diligence. But disclosure of remote potential risks burns up time and energy of both buyer and seller and exposes the buyer to knowledge of problems that can form the basis for sandbagging claims—claims that a seller is not responsible for claims that its buyer is aware of, even if the agreement says otherwise.

It is a best practice, instead, to ask only for the information needed to identify meaningful risks.

Pieces of third-party open source software used by sellers generally fall into one of three categories:

When representations require sellers to list all open source software used by the seller for any purpose, they ask for too much.

For example, most websites today use Linux, an open source “operating system” that fills much the same role on server computers as Windows or OS X on home computers. Unless the seller is in the business of developing or selling operating systems, its use of Linux is unrelated to any risk the buyer needs to identify. In fact, the seller is probably already using that software in its business.

So, the first way to improve open source representations is to avoid a “capture” of software used in a manner ancillary to the business that does not present a risk specific to the transaction at hand.

Development tools are a second category that represent a slightly higher level of risk, but still a modest one. For the most part, they are no more risky than general business tools. But some development tools require the software being developed to include pieces of code included with the development tool. For this reason, listing development tools can help identify software included in products indirectly. The requirement to list tools is merely a failsafe to ensure that all sources of open source code in the seller’s product gets included.

Therefore, listing representations can be limited to open source being used in the seller’s software product.

Even this category can be too broad, depending on the circumstances. For example, a SaaS product generally runs on top of a large “stack” of open source software whose licensing has nothing to do with the SaaS application. So-called “LAMP Stack” components, particularly when they are not modified by the seller, pose minimal risk and are often already being used by the buyer. Listing all of this open source software is not helpful and does not identify risks. The best practice is to scope the disclosure to fit the needs of the buyer.

Thus:

The Disclosure Schedule Section ___ lists all of the Open Source Software included in, or designed to be included in, the Seller Product.

And not:

The Disclosure Schedule Section ___ lists all of the Open Source Software used in the Seller’s business.

However, just listing components is not enough, and forces the buyer to do too much homework to conduct diligence. Any listing representation should require disclosure of:

Versions of software are helpful in case a license change needs to be confirmed or investigated to resolve compliance issues. In practice, license changes usually coincide with version changes. A link to the website helps follow-up diligence.

Adding this in to the listing representation:

The Disclosure Schedule Section ___ lists all of the Open Source Software included in, or required to compile or build, the Seller Product, and, for each Open Source Software component: the component name and version, the license applicable to that component (including version, if any), the location on the Web where the component is available, whether it has been modified by Seller, and whether it has been distributed by Seller.

Some listing representations also require information about how each software component is integrated, but this information is not necessary to assess compliance with the most common, and generous, open source licenses (such as those listed here: https://blueoakcouncil.org/list. So, requiring it for every license is make-work. This is one reason to require disclosure of modifications.

Of the most popular copyleft licenses, only GPL and LGPL require integration information to assess compliance on unmodified software. GPL code must not be combined in the same executable process as proprietary software, and LGPL can be difficult to comply with unless the code is used as a dynamically linked library. A full explanation of the conditions of these licenses is beyond the scope of this article. However, buyers usually need to know how GPL or LGPL software is integrated with the seller’s product to assess compliance,

Most so-called “weak copyleft” licenses, such as Mozilla Public License, use a file-based scope, and allow integration with seller proprietary code in any manner that keeps the respective source files separate. Therefore they are difficult to violate if the seller applies proper notices and does not modify the software.

Some open source licenses, copyleft or permissive, require certain notices if the software is modified. But overall, very little open source code tends to be modified by individual users. Asking for information about modification is therefore a good way to eliminate further diligence where the compliance risk is low.

Code Audits and Due Diligence

As a corollary, open source audits conducted in connection with M&A deals should review only the open source software with any appreciable risk. That is, not coincidentally, the same software that needs to be listed in the disclosure. Scoping is an important first step in any audit process. Casting too broad a net will be expensive and time consuming; casting too narrow a net will fail to identify potential risks.

Compliance Representations

Most deals contain some kind of anti-infringement representation for the seller product or business. Open source compliance legal claims are always pled as infringement claims (though they may also be characterized as contract claims). Most open source licenses terminate immediately upon breach, others may give the licensee a brief cure period. Therefore, any violation of an open source license would be either an actual infringement, or the basis for an infringement claim. Moreover, GPL source code delivery conditions will invoke other representations that exist independently in many M&A agreements, such as that no person has the right to receive improvements to the seller product, or that the seller has no obligation to disclose its proprietary product in source code form. If you remember that open source compliance representations are usually a subset of the broader intellectual property representations in your deal you may avoid a hard fought negotiation that has already been conceded.

Sellers should always make representations that their products are compliant with applicable third party open source licenses. There is really no excuse not to do so. Moreover, it makes no sense to add materiality qualifiers, because even non-material violations can terminate the license. It makes no sense to add knowledge qualifiers, because the facts and rules surrounding compliance are easy to determine, and seller should not benefit from wilful disregard of open source compliance. In other words, no seller should object to an unqualified compliance representation, unless “AS IS” treatment is a specific deal point.

Therefore, this representation makes sense:

Seller is in compliance with all Open Source Licenses applicable to the Seller Products.

Notably, the most common violation of open source licenses is failure to include notices in distributed code. Such violations are easy to discover and prove, and therefore can subject seller and buyer to risk. But they are also relatively easy to remedy, at least going forward, by adding or improving notice files. Therefore, if notices are entirely lacking for a seller product, generation of notices and formulation of a means to convey them with the product is often either a condition to closing, or a post-closing task.

The Trouble with Copyleft

Finally, many M&A deals contain no-copyleft representations. This last kind of representation is mostly redundant if a complete disclosure is also required; given licensing information, buyer can tell just as well as seller what is a copyleft license.

The problem with this kind of representation is that there is no commonly used or easy definition of copyleft. Nevertheless, many deals contain a cumulative representation of the type quoted below. This particular example is an amalgam of current practice, but by no means unusual. The notes below point out why this approach does not work, and how to improve upon it.

Company’s use of and activities with respect to any open source software in connection with the Business do not and will not require re-distribution of such software under terms that: (i) allow licensing, disclosure or distribution to any other person of any software or intellectual property owned by or licensed to Buyer or its licensees or licensors; (ii) prohibit or limit the receipt of consideration in connection with the licensing, sublicensing or distribution of any Buyer Materials to other persons, or (iii) allowing any person to decompile, disassemble or reverse engineer any Buyer Materials.

These representations are simultaneously too broad and too narrow. Item (i) would cover all grant-backs, which are often included in proprietary licenses. Item (ii) sweeps in many not-for-resale or value added licenses, which allow free redistribution only coupled with other software or products. Item (iii) covers any license without a reverse engineering restriction. These are just examples. While this kind of representation is intended to force disclosure of copyleft licenses, on face it requires disclosure of many other kinds of licenses as well— most of which will already be required to be disclosed by other parts of the intellectual property representations. Note the “or” formulation, which sweeps in all licenses that meet any of the three descriptions standing alone.

Moreover, if the objective of the representation is inform the buyer about the inclusion of software under copyleft licenses like GPL, then read strictly, it does not do so. Technically, GPL has no “requirements” but only conditions.

A better approach, though not commonly used, is to require that all open source licenses listed be permissive. This category is easier to define, and reference can be made to the Permissive List.

Sometimes, representations attempt to require that all open source software used by a seller is under an OSI-approved license. While in some cases that may be true, it is a problematic threshold, because OSI does not approve all open source licenses. Particularly for legacy licenses, whether a license appears on the OSI list is arbitrary based on whether the license was submitted for approval; many are not.

Note also that the phrase “do not and will not” makes this a forward-looking representation, and this is not reasonable for the buyer to ask. Open source licenses like GPL and LGPL may be used in a compliant fashion in the seller’s product, but downstream changes by the buyer, such as changing the build parameters for the product, can render it non-compliant. The seller should only be held responsible for its own products, not post closing changes.

The bottom line is that the no-copyleft representation is treacherous to draft, and makes little sense for a deal in which the buyer has had the opportunity to do diligence and receive a complete listing of the open source software in the seller’s products. Given the challenges it presents, this kind of representation should be deprecated, or when absolutely necessary because of a specific requirement by the buyer, flipped to say that all of the open source code at issue is under permissive licenses.

Extra Bells and Whistles

If we lived in the best of all possible worlds, every company would have a written open source compliance policy—Blue Oak Council provides free templates for small and large organizations—and undertake responsible compliance efforts accordingly. In actual practice, many companies have very poor compliance processes in place, or none at all.

Some open source representations require the seller to disclosure its written open source policy, and some go so far as to require the seller to represent it is compliant with Open Chain, https://www.openchainproject.org/, a specification that identifies the key requirements of a quality open source compliance program. However, as the state of the art currently stands, these elements are almost always lacking. Therefore, while such things may be queried in diligence, they are rarely covered in the representations in a working agreement.

Model Representation

Taking the above into account, here is a suitable representation for most M&A deals.

The Disclosure Schedule Section [NUMBER] lists all of the Open Source Software included in, or required to compile or build, the Seller Product, and, for each such Open Source Software component: the component name and version, the license applicable to that component (including version, if any), the location on the Web where the component is available, whether it has been modified by Seller, and whether it has been distributed by Seller. Seller is in compliance with all Open Source Licenses applicable to any such Open Source Software.

[definitions]