During 2010, Forrester clients bombarded us with an increased volume of questions and complaints about software contract issues. Every year, greater numbers fall foul of compliance audits, face unexpected costs, or suffer unreasonable restrictions on their use of the software they have purchased, or thought they had purchased. Some of the problems were quite new when we first highlighted them two years ago but now appear more frequently - server virtualisation, for example - while others began to crop up only recently.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
The common themes behind these deficient agreements are:
- Outdated language and terms do not apply to the current environment. Software companies insist that licence agreements are based on their contract template to ensure they protect their vital intellectual property rights (IPR) at all costs. This is fair and reasonable, but problems occur because the templates are based on decades-old original designs and have not been updated sufficiently.
- Imprecise clauses fall between the knowledge cracks in the negotiation teams. Software sourcing professionals are often caught between the internal customer who has technical knowledge but runs away from legalese; the legal advisor who may lack the software domain expertise; and the software vendors that are perceived to be inflexible and unreasonable. As a result, no one currently gets the holistic view needed to answer the key questions: what does this clause mean in today's technology context, and will it still apply in two or three years' time?
Contracts improve dramatically when three critical issues are addressed
Lawyers, even technology-savvy ones, may not appreciate the full impact of new concepts such as cloud computing and virtualisation. Sourcing professionals should review draft agreements in the context of the current and future business technology environment and question terms that, although familiar, may now be or soon become obsolete. The most common sources of problems are the clauses covering metrics, scope, platforms and audits.
Metric definitions: what are the compliance, cost and control implications?
The software product manager picks metrics that he believes will roughly measure the value that customers will get by using his product. Licensing metrics fall into four categories that each have their own advantages and disadvantages (see figure). At a minimum, sourcing professionals must check that their companies will be able to measure the relevant dimensions to ensure licence compliance. Ideally, they should also be able to control the metric to prevent accidental cost escalation.
Figure: Four types of licence metrics create different challenges for sourcing professionals
Licence scope - who, what, where and why?
At its core, a software licence agreement authorises the customer to use the product but places certain restrictions on that use. Most users assume that any usage is permitted unless it is technologically prevented, but this is not the case; the result is that the client is non-compliant with their contract.
To prevent unintentional misuse by their organisations, sourcing professionals should check that licence scope language defines sufficiently broad usage rights to cover: all the subsidiaries; all possible users (not only internal and contractors); all products necessary to deliver on the capability promised in the sales process; any (future) switch of platform; any location (including outside the home country); and any purpose (not merely "solely for your internal business purposes").
Compliance auditing: is the process as painless as possible?
It is completely reasonable for vendors to monitor compliance with the licence agreement to safeguard their IPR. So many companies deliberately or recklessly underlicense that other customers cannot reasonably complain about this minor imposition. That does not mean, however, that customers need to give auditors carte blanche. Sensible negotiators will define how an audit would be done to make it easier for both parties by specifying:
- A focus on software asset management (SAM) controls. Substantive testing - such as checks for executables across the entire network - are more expensive, invasive and disruptive than process-based audits that review controls and SAM records. The audit team should not be allowed to do comprehensive "rabbit hunts" unless it discovers flaws in the customer's SAM process.
- One enterprise-wide process. Some clients complain that they receive a continual stream of audit requests from global vendors' country organisations wanting to audit the local affiliate. A single process will prevent duplication of effort. It will also avoid problems caused when the customer's allocation of licences to business units is out of step with the vendor's records.
- Reasonable notice, from the customer's perspective. Software licence compliance teams want to create a sense of urgency to prevent prevarication, but they cannot expect asset managers to drop everything at a week's notice. The vendor's team may have to wait in line behind their peers auditing the same victim.
- A strict time limit on fishing expeditions. Compliance teams should not be able to infest a company for months while they look vainly for a licence breach. Some seem to want to hang around wasting the target's time until it pays them to go away. The contract should specify that audit teams must follow Homer Simpson's motto: "If at first you don't succeed, give up".
Duncan Jones is principal analyst at Forrester Research, where he primarily contributes to Forrester's offerings for sourcing and vendor management professionals. He is a leading expert on software pricing and licensing and helps clients understand and address the effect of technology changes on software contracts. Duncan Jones blogs at: http://blogs.forrester.com/duncan_jones/
Previous Forrester articles in the series: