Open source procurement: Indemnity

No readers like this yet.
Change the model

Opensource.com

All over the world, I encounter both governments and companies claiming they have a policy permitting or even favouring open source software--indeed, the new President of Brazil just issued a decree on that subject. Yet when you actually look at what they are doing, you find that there's still a huge amount of proprietary software being procured.

A policy alone is not enough. To implement it, legacy procurement rules have to be changed, especially in government. Procurement rules evolve over time in the light of experience, and gradually accrete into a sizeable corpus that is inflexible by design. While these rules may provide both protection and value for procurement of products and services the enterprise has seen before, they typically discriminate against new approaches, which are the "friendly fire" casualties of unintended and unforeseen consequences. Legacy procurement rules stifle innovation.

One of the most common problems that legacy procurement rules cause is in the area of requiring indemnity for software. Procurement rules usually ask for substantial penalties to be associated with promises that the software doesn't contain any misappropriated copyright, abuses no trademarks, and does not knowingly infringe any patents.

The reason you need contractual indemnity when you procure proprietary software is you have no other way to attempt to protect yourself against careless or malicious infringement of the rights you or others can reasonably expect to be protected. You thus require the company that owns the software - the one entity that has the data to know the risk - to put their money and reputation behind the assertion that they have not allowed anything harmful to enter the software before it was delivered.

A company selling a subscription around an open source project isn't actually selling the software. The subscription may superficially resemble a right-to-use or end-user license agreement, containing as it does both a service level agreement and an agreement to continue developing the software, but there's no actual software supply involved.  The software is entering their customers' enterprises under the terms of an open source license, direct from the many community participants.

As such, the company selling the subscription won't offer an indemnity for two reasons. First, they aren't the supplier of the software - the community is. Second, there's another way to mitigate the risk from the software--see if the community is happy to be using it, because as long as there’s a sufficiently diverse community, this is likely to be sufficient risk mitigation. This mystifies procurement staff enforcing legacy procurement rules. The transaction looks to them like a software purchase, and yet there's no indemnity.

This is one of the key problems that needs to be fixed if you intend to move your enterprise to favour open source software. It's not enough just to say you do; you'll need to fix your procurement rules so open source software can get through your defences.

This article first published at ComputerWorld UK. Follow Simon as @webmink on Twitter and Identi.Ca

Simon Phipps (smiling)
Computer industry and open source veteran Simon Phipps started Public Software, a European host for open source projects, and volunteers as President at OSI and a director at The Document Foundation. His posts are sponsored by Patreon patrons - become one if you'd like to see more!

3 Comments

One answer is to great lawyers who understand these complexities; The other is to educate.

I'm lucky enough to work in place that has both. Our open source procurement has taken on many different nuances- which led to a separate team for open source.

As former lead of that team, we focused on framing the acquisition process as an evaluation partnership with the requestor.

We provided informative metrics and a 'score' that would pertain to the open source world (think community size and participation, forums activity, development pace & documentation) and our requestor provided their expertise in vetting potential solutions and their ability or tolerance to fill the gaps (or not) that may exist in functionality.

Resistance was enormous at first, but it has largely eroded over the last couple years.

I agree with your comment. I find that in most cases of government procurement unless you have hired a legal team that understands the intricacies of open source procurement it really comes down to education. Most of the time in involved education of all the parties involved. This is especially true if you are a company that is offering open source support as part of a larger software bid.

Getting procurement agents to understand the law as it relates to open source software and more often than not the bigger hurdle of the process with which they normally procure software is a long road. One that takes lots of patience, lots of time, and usually lots of conference calls. :)

As a vendor of open source subscription service, we do include an indemnity clause but limit it to the obligations under the subscription agreement; and
any action by employees or contractors - not the software itself. We also have a low cap. What is more challenging for us is that government buyers do not like a disclaimer for community based code - they want express warranty which is clearly problematic when community code is involved. It is difficult to warrant against the use of 3rd party IP although insurance with regular audits is possible. We can also stand behind the quality of our support staff but warrantying the product beyond the intent of the subscription is challenging. Any thought on this much appreciated.

regards
Richard

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 3.0 Unported License.