Open Source Software Issues in Commercial Transactions, Contributed by Mark J. Bledsoe, Bradley Arant Boult Cummings LLP
By now, companies and legal practitioners alike are growing comfortable with the risks and rewards presented by the free and open source software (“OSS”) movement. M&A lawyers have revised their due diligence checklists, representations and warranties language, and indemnity parameters. Software development companies have carefully drafted and adopted policies relating to procurement and incorporation of third party code, and routinely audit their proprietary software products for compliance with these policies. Right?
Well, in case you have been preoccupied mulling over business problems, examining opportunities, exchanging rumors, and spreading gossip; this article provides a few helpful tips to make commercial transactions involving OSS more palatable, and perhaps more profitable. But first, a quick recap on why OSS Compliance is important.
Open Source Compliance Issues
Open source software is no longer the exception to the rule. Developers are familiar with its capabilities, and managers are familiar with its cost efficiencies. However, nothing in life is entirely free, especially open source software. Depending on the OSS component used, companies must comply with the associated open source license. Such licenses essentially take one of two forms: so-called copyleft licenses, and permissive licenses. The former gets its name from the downstream constraints placed upon recipients, in particular relating to derivative or incorporating works utilizing such open source components. The latter places no such restrictions on derivative or incorporating works, but rather attempts to protect upstream developers from liability.
Copyleft licenses come in various strengths and flavors, with compliance generally being mechanical once you become familiar with their terms. Stronger, more aggressive copyleft licenses include the GNU General Public License (multiple versions including the widely used GPLv2) and GNU Affero General Public License (used frequently by developers of web applications). Such licenses apply their terms to new code which either contains or is derived from an upstream work that is subject to the license, and generally prohibit the imposition of greater restrictions on downstream works – all while requiring that the complete source code be made available to developers. The policy behind such licenses serves to limit the ability of developers to combine OSS with proprietary enhancements and monetize what is essentially “free” software.
Weaker versions of copyleft licenses – including LGLP (multiple versions, the “L” standing for “Lesser”), Mozilla Public License (“MPL”), and the Eclipse Public License (“EPL”) – relax the prohibition on combining proprietary code with OSS by allowing pockets of OSS code to exist within larger programs without limiting downstream restrictions or requiring source code disclosure. Meanwhile, permissive licenses such as BSD, MIT, and Apache, embrace the free and open aspect of OSS, and merely require certain notice provisions and warranty disclaimers.
Now that the OSS license categories are loosely defined, software development companies and legal practitioners can identify the danger zones inherent in commercial transactions.
Most acquiring companies will already have a good idea of the various open source solutions utilized by the acquisition target, such that standard requests for listings of OSS utilized, and their related OSS licenses should at least confirm these suspicions. However, legal practitioners would be wise to request information relating to the target’s written OSS policies, compliance reviews, and version control systems. And if the response to these requests is “N/A,” “None,” or “Huh?” it may be time consult an open source license management company such as Palamida, Protecode, OpenLogic, or Black Duck Software. Each of these companies has access to OSS libraries and utilizes automated programs designed to identify code ownership and licensing obligations.
Representations and Warranties
Gone are the days when you could rely on broad reps and warranties to identify a target company’s use of OSS, the associated OSS license, and likely compliance therewith. Instead, these should be replaced with targeted reps and warranties regarding how OSS is used by the target, whether such code was modified, and how such code is integrated or interacts with the target’s other products. In other words, replace this:
Except as listed on Schedule __, the Target’s intellectual property contains no software source code that is covered by “open source” licenses
Target represents and warrants that all use and distribution of OSS is in full compliance with all Open Source Licenses applicable thereto. Schedule __ lists all OSS used by Target in its products, including without limitation OSS used in the development and testing of such products, and describes (1) the manner in which OSS is used, (2) whether OSS subject to copyleft licenses (“Copyleft OSS”) has been modified and distributed by Target, and (3) how Copyleft OSS interacts or is integrated with Target’s products.
Obviously, these representations and warranties should be combined with the due diligence measures mentioned above in order to place the proper parameters around indemnification discussed below.
Identifying compliance issues is important, but estimating exposure to liability can be useful in setting indemnification parameters such as caps, baskets, and time limits. There are two basic causes of actions available to OSS copyright holders against OSS licensees that fail to comply with the applicable OSS license: breach of contract and copyright infringement. Of the two, copyright infringement actions will carry the most devastating remedies: namely, attorneys’ fees and statutory damages.
Copyright infringement claims, however, are only available for those OSS licenses whose obligations are conditions on the scope of the license rather than independent covenants of the licensee. The court in Jacobsen v. Katzer1, one of the few reported cases on open source software licenses, held that the limitations on modification and distribution in the Artistic License were copyright-enforceable conditions rather than mere contractual covenants, opening up the remedies available under copyright law. However, on December 2010, the U.S. Court of Appeals for the Ninth Circuit in MDY Industries, LLC v. Blizzard Entertainment, Inc.,2 muddied the waters by introducing a “nexus” requirement to such license conditions. Namely, the Ninth Circuit has held that in order for a condition to limit the scope of a copyright license, thereby giving rise to a copyright claim, there must be a nexus between the violated condition and the licensor’s exclusive rights under the Copyright Act. As discussed above, most copyleft conditions involve prohibitions on the imposition of downstream restrictions, as well as source code distribution requirements, none of which have a nexus to the exclusive rights afforded under the Copyright Act.
Most open source disputes appear to settle before trial for undisclosed amounts; so, unfortunately, you are on your own when determining any specific amounts to hold back in the event due diligence reveals large pockets of exposure.
OSS Procurement and Use Policies
Companies looking to expand product offerings or capabilities through third party acquisitions would be wise to adopt careful practices relating to the incorporation of OSS in proprietary code. Software developers should work closely with legal counsel to identify OSS problem areas and develop version control systems to reduce the risk of inadvertent violations. Software developers would also be wise to always consider practical factors such as reliability, performance, quality, reputation, market acceptance, interoperability, and support before selecting a particular OSS solution. For subsequent exit events or divestitures, clearly defined practices and policies will go a long way towards satisfying the most scrupulous transaction attorneys.
While some may approach audits as scavenger hunts, they are better seen as oil changes. A regular and routine OSS audit will ensure your company’s software “engine” continues to run smoothly and efficiently for miles and miles ahead. To conduct an OSS audit, the legal team should meet with software developers and managers to review the company’s OSS policy, while reviewing any OSS license compliance requirements relating to any recent development. If it has been too long between “oil changes,” open source license management companies such as Palamida, Protecode, OpenLogic, or Black Duck Software can help salvage a company’s “engine” for a fee.
When used correctly and in compliance with applicable licenses, open source software will not only reduce product costs and operating expenses, but can also generate revenue. Bundling OSS solutions with related service agreements or product offerings, can lead to big money in today’s tech-savvy economy. Just make sure you bring a map and a guide to navigate the sometimes muddied waters of the open source software world.
J. Mark Bledsoe is a partner with Bradley Arant Boult Cummings LLP in Nashville, Tenn. His practice focuses on intellectual property and corporate law. He can be reached at firstname.lastname@example.org or 615.252.4635.
This document and any discussions set forth herein are for informational purposes only, and should not be construed as legal advice, which has to be addressed to particular facts and circumstances involved in any given situation. Review or use of the document and any discussions does not create an attorney-client relationship with the author or publisher. To the extent that this document may contain suggested provisions, they will require modification to suit a particular transaction, jurisdiction or situation. Please consult with an attorney with the appropriate level of experience if you have any questions. Any tax information contained in the document or discussions is not intended to be used, and cannot be used, for purposes of avoiding penalties imposed under the United States Internal Revenue Code. Any opinions expressed are those of the author. Bloomberg Finance L.P. and its affiliated entities do not take responsibility for the content in this document or discussions and do not make any representation or warranty as to their completeness or accuracy.
© 2011 Bloomberg Finance L.P. All rights reserved. Bloomberg Law Reports ® is a registered trademark and service mark of Bloomberg Finance L.P.