Open source software has probablybeen the biggest driver of complex software solutions in the last decade.Access to a large variety of quality, peer-reviewed software has acceleratedproduct development, reduced product introduction intervals and lowered thecosts for producers of software and for those of us who leverage third partysoftware in our projects.
Many of us have heard about thetrouble that organizations have come across when using open source improperly…remember Cisco/Linksys, Katzer, and the BusyBox chronicles? You may think thatyour organization is safe because you are buying proprietary software. However,if your software supplier unknowingly incorporated open source into itsproduct, your organization may face unexpected legal and financial consequencesarising from open source licensing obligations and the resulting intellectualproperty infringement claims. The good news is that there are various tools availableat your disposal that can assist your organization in protecting itself fromsuch open source surprises, such as contractual measures such asrepresentations and warranties and indemnities; and extra-contractual toolssuch as software audits and a structured Open Source Software Adoption Process(OSSAP).
Some Basics About Commercial Contracts Relevant to Software Purchases
Commercial contracts includevarious provisions that protect and allocate risk among buying and sellingparties. Among the most important are representations and warranties (“repsand warranties”) and indemnities. Reps and warranties are assurances madeby one party that are intended to provide certainty to the other party thatrelies on them. For example, a hypothetical software company (“SoftcoSupplier”) may represent and warrant that it owns all of the intellectualproperty rights in the software it sells. If Softco Supplier does not in factown all of the intellectual property rights in the software, the buyer (“SoftcoBuyer”) has a right to claim damages for Softco Supplier’smisrepresentation.
However, in many instances it isimpossible for contracting parties to fully guarantee the accuracy of astatement. In these cases, parties opt to provide reps and warranties that arequalified by the knowledge of the party providing them. These types of reps andwarranties can be problematic from the perspective of the party that seeks torely on them. We will return to this in the following section, whichspecifically deals with the application of reps and warranties, and indemnitiesto open source.
Indemnities provide securityagainst losses that are triggered by the occurrence of contractually specifiedevents. Unlike reps and warranties, recovery from indemnities is not contingentupon whether a misrepresentation was made. In our example, if Softco Supplier(the “indemnitor”) indemnifies Softco Buyer (the “indemnitee”)for any intellectual property infringement claims against the software beingsold, then in the event that such claims arise, Softco Supplier is obligated tocompensate Softco Buyer for its losses.
Reps and Warranties vs. Indemnities in an Open Source World
In the software procurementcontext, it is important for buyers to determine whether open source code isincorporated into the software that is being purchased. The primary reason forthis is that open source license obligations are binding. Failure to complycould have a diminishing impact on software value, as some open source cannotbe mixed into products that have trade secret value. Additionally, if a buyerpurchases software without the knowledge that it includes open source, thebuyer runs the risk of commercializing the product in a manner that violatesthe license that covers the open source code. This can leave the buyer exposedto costly intellectual property infringement claims.
The recent focus on open sourcereps and warranties and indemnification is linked to the growing instances ofintellectual property infringement claims involving open source software. Ascourts in the United States, Germany and elsewhere have acknowledged theenforceability of open source licenses, notable violators have succumbed tocostly settlements, and enforcement organizations such as the Free SoftwareFoundation have become more aggressive in launching suits.
Because of the immense financialand legal implications of intellectual property infringement suits, a softwarebuyer will often require its supplier to represent and warrant that thesoftware being purchased does not contain any open source code. If open sourceis later discovered in the software, then the buyer is entitled to seek damagesfrom the supplier for the breach of the representation. However, as mentionedearlier, it is often difficult for contracting parties to fully attest to theaccuracy of a representation. This situation arises in instances in which thecontracting party experiences knowledge gaps. In these cases, a contractingparty will seek to limit its liability by narrowing the representation to applyto the knowledge that it possesses. Taking our earlier example, if SoftcoSupplier had acquired code from a third party, or engaged in outsourcing ofprogramming, it may not be positioned to fully attest to the fact that thesoftware it sells does not contain any open source. As a result, SoftcoSupplier will represent and warrant that ‘to the best of its knowledge, opensource is not incorporated into the product’. In this case, Softco Buyer isonly entitled to damages if it can show that Softco Supplier knew that itsrepresentation was untrue at the time that it was made. If this fact cannot beestablished, Softco Buyer is left without a remedy for any losses arising fromSoftco Supplier’s misrepresentation.
Unlike reps and warranties,recovery from indemnities is not contingent upon whether a misrepresentationwas made. Thus, if Softco Supplier indemnified Softco Buyer for open sourceinfringement claims against the software, then Softco Supplier would beobligated to fully cover the losses arising out of any such claims. In thiscase, it would be irrelevant whether Softco Supplier had knowledge of thepresence of open source, as liability is triggered by the occurrence of thecontractually specified event (the presence of open source) rather than themisrepresentation made by Softco Supplier.
Buyer’s Duty
Another important distinctionbetween reps and warranties and indemnities in our example is in relation tothe duty imposed on Softco Buyer to mitigate its own loss. Common law imposes arequirement on parties relying on reps and warranties to take action tomitigate their own losses. In the context of open source reps and warranties,once a software buyer becomes aware that open source is embedded in thesoftware, the buyer must take action to minimize its loss, for example byimmediately replacing the code, or making the code freely available. Incontrast, there is no parallel requirement for the beneficiaries of indemnitiesto mitigate their own losses.
Software Audit Can Minimize Exposure
Although open source reps andwarranties and indemnities can provide software purchasers with remedies forlosses arising from intellectual property infringement suits, they cannotshelter the buyer from being sued in the first place, or from experiencing theloss of goodwill in relation to litigation. As a result, reps and warrantiesand indemnities should not be regarded as due diligence replacements. Ratherthan taking the risk of open source surprises, software purchasers can engage resources(internal or external) that have the ability to analyze software to determinethe presence of open source prior to executing the purchase.
A software audit entails codescanning aimed at detecting third party and open source code. After the scanningstage, the purchaser is provided with an audit report detailing the identifiedcode and associated license obligations. Performing such audits at thepre-purchase stage allows the buyer to understand whether the licenseobligations of the open source code are in line with the intellectual propertypolicies of its organization, and if not, then the buyer is positioned torequest the supplier to replace the code in question, or to engage an alternatesupplier.
Software Audit in the Supply Chain
One of the contexts in whichsoftware audits are particularly beneficial is in the supply chain. Shortlyafter Cisco acquired Linksys in 2003, it was faced with an infringement suitrelating to the use of GPL covered code in its router firmware. It turned out thatthe infringing chipset was provided to Linksys by Broadcom, which in turnoutsourced the development to a third party. As a part of the settlement thatwas reached, Cisco was forced to make the infringing source code freelyavailable on its website, appoint an open source compliance officer, and make amonetary contribution to the Free Software Foundation. As the Cisco casesuggests, software audits can be a helpful tool at the pre-purchase stage whendealing with a supply chain context in which the immediate supplier has littlecontrol or knowledge over the code pedigree of the final product.
Review of Available Contractual Tools
Software purchasers havecontractual tools (reps and warranties, and indemnities) at their disposal toprotect their organizations from open source liabilities; however it isimportant to remember that not all tools provide equal protection. While repsand warranties can provide the buyer with a remedy against misrepresentation,in instances where these assurances are qualified by the knowledge of thesupplier, the buyer may be left without recourse. From this perspective,indemnities offer increased protection to software purchasers concerned aboutintellectual property infringement claims in relation to the use of open source.
Open source indemnities are alsobeneficial in comparison with reps and warranties, as they do not impose anobligation upon the party relying on them to take any action to minimize theirown losses in the event of a breach.
Although open source reps andwarranties and indemnities can provide software purchasers with means ofrecovery from intellectual property infringement claims, these contractualmeasures provide for an imperfect after-the-fact solution to a problem thatlends itself well to management practices that would reduce the risk in thefirst place. Structured open source license management practices and softwareaudits aimed at identifying third party and open source code and ensuring opensource compliance, provide an optimal level of protection. These tools providecertainty regarding code pedigree, and enable software purchasers to avoid thenegative consequences arising from intellectual property infringement suits.
