There are many possible justifications for the uptick we’re seeing in inquiries regarding the indemnification of open source software. It could be a natural consequence of the increasing role that open source is directly playing within traditional proprietary software businesses. It could be the public and private veiled threats regarding potential patent liability for vendors and customers alike.
In any event, indemnification is a topic of increasing interest to judge from our inbound traffic, and so I thought it would be useful to answer a few of the most common questions we hear on the subject.
Q: What does indemnification mean in the context of open source software?
A: As Wikipedia defines it, indemnification means essentially that “a sum paid by A to B by way of compensation for a particular loss suffered by B.” As it pertains to open source, then, indemnification generally implies that a commercial supplier or backer of a particular open source asset will indemnify or protect the users of said product from potential liabilities related to their usage of said asset.
Q: Why is indemnification of interest to customers?
A: Enterprises – the organizations typically engaging in commercial relationships with vendors – are risk averse. In many cases this is for good reason; one of the original use cases for IBM’s MDM suite, after all, was identifying so-called “slip and fall” candidates. That is to say, people for whom one of their primary revenue sources is entering large retail sources, only to fall and sue.
Any opportunity, therefore, to reduce their risk – whether said risk is real or merely perceived – will be sought. This is natural and to be expected. The question is what priority potential customers assign to indemnification.
Q: And what priority do you see being assigned to it, generally?
A: It’s exceedingly low in the majority of cases, in my experience. At some organizations, of course, particularly those with limited or no exposure to open source software, it becomes a more important factor in buying decisions. But this is atypical, in my experience.
As an example, Sun for many years touted its indemnification of the Solaris codebase as a differentiator against competing offerings from the likes of Red Hat Linux (though it’s worth noting that Red Hat does in fact offer indemnity at this point). But as is well known, indemnity or no indemnity, Red Hat surged into the Solaris install base winning significant share in a relatively short span of time.
Are there exceptions? Certainly. But in my experience, indemnification tends to be an “all things being equal” differentiator, and situations where all things are indeed equal tend to be rare.
Q: Is it general policy to offer indemnification for open source products?
A: It largely depends on the derivation of a given asset, but it is certainly not a given that a commercial supplier of open source will indemnify the assets that you are purchasing support for.
Historically, many commercial open source suppliers have – like Red Hat pre-2006 – declined to provide indemnification to their customers. That trend appears to be reversing, however, as a variety of suppliers have either launched programs or explicitly detailed their support or options.
Q: Is all indemnification created equal?
A: An excellent question. In short, the answer is no. Much like insurance, there are limits and thresholds that must be explored. More to the point, indemnification options are frequently offered by vendors that are dwarfed by potential litigants. Ergo, the value of indemnification does depend on both the nature of the offering as well as the size and resources of the vendor offering it.
Q: Who are the would-be attackers in scenarios in which the shield of indemnification becomes important
A: Focus typically centers on larger commercial institutions whose offerings are potential threatended by competitive open source offerings, notably Microsoft. This is understandable, in light of the rhetoric coming from Steve Ballmer which included, the following:
“Novell pays us some money for the right to tell customers that anybody who uses SUSE Linux is appropriately covered,” Ballmer said. This “is important to us, because [otherwise] we believe every Linux customer basically has an undisclosed balance-sheet liability.”
While it remains possible – at least as long as Ballmer is at the helm – that Microsoft could pursue litigation against customers, I think highly unlikely.
For a brand that relies highly on rank and file recognition and adoption, pursuing an RIAA-style course of action that includes legal action against its direct customers would be the worst kind of brand suicide. So while Ballmer might hint at such actions in attempt to disincent usage and adoption of the technologies, it’s unlikely that it would go further than that. If not because of the PR implications, then because of the mutually assured destruction scenarios that would likely result in retaliatory lawsuits from competitive vendors with patent portfolios of their own.
The bigger threat, in my opinion, are smaller firms with less to lose, like a SCO or the so-called IP vulture firms. The latter refers to commercial entities who typically produce no software, but acquire patents for the sole purpose of litigating around them.
To date, the only attempted customer litigation that I’m aware of relating to open source software came from this quarter, with SCO attempting to sue multiple customers of Linux.
Q: So there is some risk?
A: Of being litigated? Certainly, just as there is, frankly, with proprietary software. The question is whether or not the litigation can be successfully prosecuted; SCO, you’ll note, is no longer an ongoing concern.
Q: So what are the actual risks?
A: Exceedingly low, from a historical perspective.
Q: Then why are enterprises so interested in indemnification?
A: Well, I’d dispute that they are in fact terribly interested, but as discussed previously it is in an enterprise’s best interests to limit risks, regardless of their likelihood.
Q: Is open source uniquely vulnerable to patent and such claims?
A: No, this is a common misperception. It may be simpler to discover blatant infringement in source code that is open source and widely available versus that is closed and fiercely guarded, but as fundamentally broken as our patent system is, no software – open or closed – is risk free. After winning a patent infringement suit against Java – which was not open source at the time, Kodak received $92 million from Sun in settlement.
Q: If I’m a commercial supplier of open source, should I be offering indemnification to my customers?
A: Much of it depends on the context: are they asking for it? Are competitors offering it? If the answer is yes in both cases, it should be considered.
At which point it becomes a basic risk/reward equation: what is the risk versus the potential return? In many respects, it’s basically trying to decide whether or not insurance – which is essentially what indemnification becomes – is a worthwhile line of business for you to enter. Or an important enough feature that it cannot be omitted.
One approach I’ve recently recommended to a client: equate it to the reliability signified by 5 9’s. It’s achievable, of course, but at a cost.
Another factor worth considering is size: just as smaller vendors are less attractive indemnifiers from a customer perspective because of their limited resources, so too are they less attractive targets to would be attackers.
Q: Is it safe to say, then, that you are skeptical of the value of indemnification?
A: Yes. I don’t dismiss it, of course, because larger enterprises are right to lower their attack surface through such mechanisms. But it is not – to me – a feature worth either paying a premium for or altering a buying decision about.
Historically, the probability that you will require indemnification is minimal, and the future prospects are low in an environment that tends to favor vendors settling such matters amongst themselves.
Disclosure: IBM, Microsoft and Sun are RedMonk clients, while Red Hat is not.
