Open Source Procurement: Indemnity

All over the world, I encounter both governments and companies claiming they have a policy permitting or even favouring open source software. 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.

One Response

  1. […] a leitura do artigo “Open Source Procurement: Indemnity” (em português), título deste post, escrito por Simon Phipps em seu web site. Nesse artigo […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: