Law and technology

It is too early to tell whether the collapse of the Government – Microsoft “G2009″ licensing negotiations signals a desire by the Government to see an increased use of open source software. Certainly, the Government should be actively considering OSS for reasons of economy (at least as a bargaining chip in future commercial negotiations) and, more importantly, to develop its own (shared) intellectual capital in our public IT infrastructure.

The sticking point has always been support. The question is often framed thus: How can a Government agency, or any commercial / professional organisation for that matter, responsibly afford to risk using software that doesn’t have the backing of a major commercial vendor? To adapt an old adage, nobody ever got fired for buying Microsoft.

The term “support” here is used broadly and includes: helpdesk services, on-site support, bug-fixes, training, documentation, upgrade paths and the general “comfort” from dealing with a reputable commercial vendor (also known as “having someone to sue if it all turns to custard”). At least anecdotally, these are often raised as factors for ruling out a non-vendor-backed solution.

But how real is the “support” gained from dealing with a commercial vendor? Let’s consider each type of vendor support mentioned earlier, in the context of a major customer such as a government agency:

In summary: standard contracting and licensing practices mean that commercial software vendors actually give very little, if anything, in the way of “support” to customers, other than what the customer and vendor are prepared to expressly include and pay for.

However, it is important to separate the “support” arising from the software license (and the fact it is provided by a major vendor) from support (and other rights) arising under a commercial contract. Virtually all software licenses exclude all forms of liabilities and warranties to the fullest extent permitted by law (which in the case of business customers can be everything). Open source licenses such as the GPL are no different in this regard. The nature of software is such that it is infeasible to accept such liability or provide other than the most trivial warranties. Therefore they are customarily all excluded (and often in upper-case text for some reason), and most software vendors – closed or open source – are very reluctant to change their license terms.

The rights gained by a customer under the commercial or services component of a deal are quite different, and can be negotiated on a case-by-case basis. The obligations of the service provider (the software vendor or a third party) to support, integrate, implement, customise, etc., will be whatever the parties agree upon.

This is where OSS has the potential to shine, as both customer and service provider can contract with the comfort and knowledge of having:

1. Full, unrestricted access to the source code;
2. The ability to fix, modify, maintain and document the software;
3. The freedom to recontract with another service provider should the need arise.

This arguably provides a higher level of “support” (as defined above) than dealing with a commercial vendor ever could. This is particularly so when, as is often the case, the customer is not actually licensing software from the entity it is dealing with. For example, Microsoft New Zealand Limited may negotiate a licensing deal, but the software license is actually a contract between the customer and Microsoft Corporation in the US – a separate legal entity (although the customer’s commercial contract may be with the New Zealand entity).

If a technology decision is made in favour of OSS, it should not be overruled on the basis of a commercially-supported solution if the “support”, on closer inspection, is in fact illusory.