|By Diana Marina Cooper||
|July 9, 2012 07:00 AM EDT||
Open source software 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.
Many of us have heard about the trouble that organizations have come across when using open source improperly... remember Cisco/Linksys, Katzer, and the BusyBox chronicles? You may think that your organization is safe because you are buying proprietary software. However, if your software supplier unknowingly incorporated open source into its product, your organization may face unexpected legal and financial consequences arising from open source licensing obligations and the resulting intellectual property infringement claims. 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, such as 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).
Some Basics About Commercial Contracts Relevant to Software Purchases
Commercial contracts include various provisions that protect and allocate risk among 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. For example, a hypothetical software company ("Softco Supplier") may represent and warrant that it owns all of the intellectual property rights in the software it sells. If Softco Supplier does not in fact own all of the intellectual property rights in the software, the buyer ("Softco Buyer") has a right to claim damages for Softco Supplier's misrepresentation.
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. These types of reps and warranties can be problematic from the perspective of the party that seeks to rely on them. We will return to this in the following section, which specifically deals with the application of reps and warranties, and indemnities to open source.
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. In our example, if Softco Supplier (the "indemnitor") indemnifies Softco Buyer (the "indemnitee") for any intellectual property infringement claims against the software being sold, then in the event that such claims arise, Softco Supplier is obligated to compensate Softco Buyer for its losses.
Reps and Warranties vs. Indemnities in an Open Source World
In the software procurement context, it's 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. Failure to comply could have a diminishing impact on software value, as some open source cannot be mixed into products that have trade secret value. In addition, 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. This can leave the buyer exposed to costly intellectual property infringement claims.
The recent focus on open source reps and warranties and indemnification is linked to the growing instances of intellectual property infringement claims involving open source software. As courts in the United States, Germany and elsewhere have acknowledged the enforceability of open source licenses, notable violators have succumbed to costly settlements, and enforcement organizations such as the Free Software Foundation have become more aggressive in launching suits.
Because of the immense financial and legal 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 open source code. If open source is later discovered in the software, the buyer is entitled to seek damages from the supplier for the breach of the representation. However, as mentioned earlier, it's 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. Taking our earlier example, if Softco Supplier had acquired code from a third party, or engaged in outsourcing of programming, it may not be positioned to fully attest to the fact that the software it sells does not contain any open source. As a result, Softco Supplier will represent and warrant that ‘to the best of its knowledge, open source is not incorporated into the product.' In this case, Softco Buyer is only entitled to damages if it can show that Softco Supplier knew that its representation was untrue at the time that it was made. If this fact cannot be established, Softco Buyer is left without a remedy for any losses arising from Softco Supplier's misrepresentation.
Unlike reps and warranties, recovery from indemnities is not contingent upon whether a misrepresentation was made. Thus, if Softco Supplier indemnified Softco Buyer for open source infringement claims against the software, Softco Supplier would be obligated to fully cover the losses arising out of any such claims. In this case, it would be irrelevant whether Softco Supplier had knowledge of the presence of open source, as liability is triggered by the occurrence of the contractually specified event (the presence of open source) rather than the misrepresentation made by Softco Supplier.
Another important distinction between reps and warranties and indemnities in our example is in relation to the duty imposed on Softco Buyer to mitigate its own loss. Common law imposes a requirement on parties relying on reps and warranties to take action to mitigate their own losses. In the context of open source reps and warranties, once a software buyer becomes aware that open source is embedded in the software, the buyer must take action to minimize its loss, for example by immediately replacing the code, or making the code freely available. In contrast, there is no parallel requirement for the beneficiaries of indemnities to mitigate their own losses.
Software Audit Can Minimize Exposure
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. As a result, reps and warranties and indemnities should not be regarded as due diligence replacements. 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.
A software audit entails code scanning aimed at detecting third-party and open source code. After the scanning stage, the purchaser is provided with an audit report detailing the identified code and associated license obligations. 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.
Software Audit in the Supply Chain
One of the contexts in which software audits are particularly beneficial is in the supply chain. Shortly after Cisco acquired Linksys in 2003, it was faced with an infringement suit relating to the use of GPL covered code in its router firmware. It turned out that the infringing chipset was provided to Linksys by Broadcom, which in turn outsourced the development 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. 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 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.
- DevOps Loses Its Religion | @CloudExpo #AI #ML #IoT #FinTech #Blockchain
- What ‘Software-Defined’ Really Means | @CloudExpo #AI #SDN #SDX #DevOps
- Beware Your Digital Blind Spot | @CloudExpo #Cloud #Agile #DigitalTransformation
- Bad PR Might Sink #ArtificialIntelligence | @CloudExpo #BigData #AI #ML #DL
- Finding Transformational Success by Ignoring Labels | @CloudExpo #Agile #DigitalTransformation
- Deconstruction of #DigitalTransformation | @CloudExpo #IoT #AI #ML #DX
- SOA Governance Best Practices – Architectural, Organizational, and SDLC Implications
- SOA Best Practices - Four Steps to Securing Your Web Services
- Katerina Moutsatsos, Kayikci and SOA World
- Cloud Expo New York Speaker Profile: Dave Linthicum – Cloud Technology Partners
- Why Are APIs So Popular?
- Why SOA Is a Good Fit for CRM Solutions
- Small Cancers, Big Data, and a Life Examined
- ARM Server to Transform #BigData to #IoT | @CloudExpo #DigitalTransformation
- 1st Annual Government IT Conference & Expo: Themes & Topics
- Service Versioning For SOA