Guest post: Avoiding Open Source Surprises When Buying Proprietary Software


We’re happy to bring to our readers a brief note by Protecode on protecting against the risks of Open Source Software being incorporated in purchased proprietary software without the knowledge of the buyer. 
A bit about the authors: Mahshad Koohgoli, CEO of Protecode, has more than 25 years of experience in the technology industry. Previously, he was founder and CEO of Nimcat Networks (acquired by Avaya in 2005) and founder of Spacebridge Networks and Lantern Communications Canada. Mahshad has a BSc and a PhD from the University of Sussex, England. Diana Marina Cooper has been working with Protecode as an open source corporate strategy consultant since 2011. She obtained a BA in Politics and Governance and an MA in Globalization Studies. She is currently a JD Candidate (2013), and is pursuing a concentration in Law and Technology.
Introduction
Open source software (OSS) has probably been the biggest driver of complex software solutions in the last decade. Access to a large variety of quality, peer-reviewed software has accelerated product development, reduced product introduction intervals and lowered the costs for producers of software and for those of us who leverage third party software in our projects.
Although OSS is generally free in the monetary sense, usage of OSS is subject to obligations spelled out in a license. There have been a number of legal cases in North America and Europe with companies using OSS improperly in their products. The problems arise regardless of where software has been developed. This includes software that is developed for final shipment to a client in North America or Europe as is the case with many suppliers in India. You may think that your organization is safe because you are buying proprietary software. However, if your software supplier unknowingly incorporated OSS into its product, you are still liable for infringement of OSS license obligations.
The good news is that there are various tools available at your disposal that can assist your organization in protecting itself from such open source surprises. These include:
• Contractual measures such as representations and warranties and indemnities; and
• Extra-contractual tools such as software audits and a structured Open Source Software Adoption Process (OSSAP).
The following is a brief review of both contractual measures and due diligence tools available to
parties engaged in the software supply chain.
Contractual Measures
Commercial contracts include various provisions that protect and allocate risk among the buying and selling parties. Among the most important are representations and warranties (“reps and warranties”) and indemnities. Reps and warranties are assurances made by one party that are intended to provide certainty to the other party that relies on them. However, in many instances it is impossible for contracting parties to fully guarantee the accuracy of a statement. In these cases, parties opt to provide reps and warranties that are qualified by the knowledge of the party providing them, and can be problematic from the perspective of the party that seeks to rely on them. Indemnities provide security against losses that are triggered by the occurrence of contractually specified events. Unlike reps and warranties, recovery from indemnities is not contingent upon whether a misrepresentation was made.
Reps and warranties vs. indemnities in an open source world
In the software procurement context, it is important for buyers to determine whether open source code is incorporated into the software that is being purchased. The primary reason for this is that open source license obligations are binding. Additionally, if a buyer purchases  software without the knowledge that it includes open source, the buyer runs the risk of commercializing the product in a manner that violates the license that covers the open source code.
Because of the implications of intellectual property infringement suits, a software buyer will often require its supplier to represent and warrant that the software being purchased does not contain any, or specific type of, open source code. However, as we mentioned earlier, it is often difficult for contracting parties to fully attest to the accuracy of a representation. This situation arises in instances in which the contracting party experiences knowledge gaps. In these cases, a contracting party will seek to limit its liability by narrowing the representation to apply to the knowledge that it possesses.
Software audit can minimize exposure
Rather than taking the risk of open source surprises, software purchasers can engage resources (internal or external) that have the ability to analyze software to determine the presence of open source prior to executing the purchase. Reps and warranties and indemnities should not be regarded as due diligence replacements. Although open source reps and warranties and indemnities can provide software purchasers with remedies for losses arising from intellectual property infringement suits, they cannot shelter the buyer from being sued in the first place, or from experiencing the loss of goodwill in relation to litigation.
A software audit always entails machine-assisted code scanning aimed at detecting third party and open source code. An expert reviews and signs-off on the machine-generated reports and provides the purchaser with an audit report detailing the identified code and associated license obligations. The audit process can take anything between a day to a couple of weeks depending on the size and complexity of the software. Performing such audits at the pre-purchase stage allows the buyer to understand whether the license obligations of the open source code are in line with the intellectual property policies of its organization, and if not, then the buyer is positioned to request the supplier to replace the code in question, or to engage an alternate supplier.
One of the contexts in which software audits are particularly beneficial is in the supply chain. As an example, shortly after Cisco acquired Linksys in 2003, it was faced with an infringement suit relating to the use of GPL covered chip-driver code in its router firmware. It turned out that the infringing chipset was provided to Linksys by Broadcom, which in turn outsourced the development of the driver to a third party. As a part of the settlement that was reached, Cisco was forced to make the infringing source code freely available on its website, appoint an open source compliance officer, and make a monetary contribution to the Free Software Foundation. Shortly afterwards, Cisco removed the product from its portfolio. As the Cisco case suggests, software audits can be a helpful tool at the pre-purchase stage when dealing with a supply chain context in which the immediate supplier has little control or knowledge over the code pedigree of the final product.
Review of available contractual tools
Software purchasers have contractual tools (reps and warranties, and indemnities) at their disposal to protect their organizations from open source liabilities, however it is important to remember that not all tools provide equal protection. While reps and warranties can provide the buyer with a remedy against misrepresentation, in instances where these assurances are qualified by the knowledge of the supplier, the buyer may be left without recourse. From this perspective, indemnities offer increased protection to software purchasers concerned about intellectual property infringement claims in relation to the use of open source.
Open source indemnities are also beneficial in comparison with reps and warranties, as they do not impose an obligation upon the party relying on them to take any action to minimize their own losses in the event of a breach.
Although open source reps and warranties and indemnities can provide software purchasers with means of recovery from intellectual property infringement claims, these contractual measures provide for an imperfect after-the-fact solution to a problem that lends itself well to management practices that would reduce the risk in the first place. Structured open source license management practices such as Open Source Software Adoption Process (OSSAP), and software audits aimed at identifying third party and open source code and ensuring open source compliance, provide an optimal level of protection. These tools provide certainty regarding code pedigree, and enable software purchasers to avoid the negative consequences arising from intellectual property infringement suits.

One comment.

  1. AvatarJace

    You appear to be mixing up open source with copyleft. Copyleft licenses (like the GPL and AGPL) have significant consequences in commercial use. Permissive open source licenses (BSD, Apache, MIT, pretty much anything not copyleft) in general do not have implications for commercial use.

    Please do not paint all open source with the same brush.

    Reply

Leave a Reply

Your email address will not be published.