Just to work through one example, consider the case of an indemnity requirement, that red-herring issue I heard last week. You need contractual indemnity when you procure proprietary software because you have no other way to protect yourself against careless or malicious infringement of the rights you 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 its money and reputation behind the assertion it has not allowed anything harmful to enter the software before it was delivered.
By contrast, a company selling a subscription for an open source project isn't actually the owner of 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. However, there's no actual software supply involved. The software is instead entering your enterprise under the terms of an open source license, direct from the many community participants.
As such, the company selling a subscription guaranteeing ongoing development and support of that software 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 using it. 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, yet there's no indemnity.
Of course, such a company might offer indemnity, but if it does (and is doing so honestly!), it will also need to purchase its own insurance to cover the risk it is taking. It will pass that cost on to you, plus some markup. So, it is cheaper for you to buy the indemnity insurance yourself if you truly need it.
That's a short and simplistic explanation, but it illustrates the issue. Open source isn't just another kind of software that's cheaper. It's software developed in a new way, by developers exploiting licenses and community rules guaranteeing them the rights to use, study, modify, and distribute the resulting software any way they want. For your enterprise to truly get the most from those open source freedoms, you need to make sure your procurement rules don't force you to use only proprietary-software vendors.
Maybe it's time for a review?
This article, "Open source's unlikely enemy: Your procurement rules," was originally published at InfoWorld.com. Read more of the Open Sources blog and follow the latest developments in open source at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.