FSN: Negotiating software licence agreements

Negotiating software licence agreements

29th August 2005
Software licence agreements can be a minefield for the unwary but unfortunately negotiations are often left until a very late stage of software selection when the decision to buy a product has been made, alternatives have been discarded, and time is running short leaving the preferred supplier with all of the trump cards in his hand. Neil Copeland, Senior Writer, FSN suggests a more suitable approach to contract negotiation.

In common with all negotiations it is important that all parties to a software licence agreement feel content with the outcome. Any other position is likely to jeopardise the relationship in the long term and everyone suffers. Therefore it is vital that the negotiation is relaxed and non-combative with all parties seeking to arrive at a fair and realistic position

Whilst many negotiations are price driven it is critical that the negotiations do not pursue price to the exclusion of everything else that matters, for example, the process for user acceptance testing, the staging of payments and the process for bug fixing. Cutting implementation effort and training costs to save money are rarely a good idea. That is not to say that suppliers' initial quotes should not pass unchallenged but that most products are so complex these days that cutting implementation costs to the bone is usually a false economy.

The software licence agreement should of course reflect the commercial reality of the transaction. For most purchasers the essence of the deal is that the software does the job that it is required to do, at the agreed price, with the expected performance, support and maintenance. But what is the job it is required to do?

Articulating systems requirements is a specialist endeavour and becoming more difficult by the day as packaged software becomes more flexible, comprehensive and complex. You may have specified your requirements in an "Invitation to Tender" (ITT) or Statement of Requirements" but how well do the suppliers understand the requirements? They may claim that they can meet the requirements set out in your ITT and indeed may have confirmed this in writing but are they prepared to commit to meeting them contractually? This is often a contentious area of negotiation since a supplier's standard contract is normally drafted on the basis that software will meet the supplier's published specifications, systems and user documentation rather than the prospective purchasers ITT.

Looked at from the supplier's perspective, it is easy to understand why this is the case. ITT's are often drafted widely and written ambiguously leaving the requirement open to many interpretations. Indeed, when a supplier says he can meet a specific requirement in an ITT does he really mean that the software will do the job or is he really saying that the software can be 'bent' to meet the requirement or there is some other workaround, combination of tools, functionality and methods that can be employed to meet the need?

Perhaps the supplier's personnel have demonstrated an approach to meeting your needs and provided an assurance that the software can cope with your specific requirements. To what extent can you rely on these assurances or representations?

Unfortunately, most software licence agreements attempt to exclude normal levels of consumer protection such as the Sale of Goods Act ("fitness for purpose") and they normally always have an "entire agreement" clause. In other words, the standard contract is what counts and you are not entitled, they say, to rely on any salesman's representations during the sales process, the company's written response to your invitation to tender, or even some of your statutory rights! Therefore, if you have placed reliance on representations made during demonstrations or other meetings it is important that these are identified and appended to the contract since many "entire agreement" clauses can be modified by the parties agreeing to a change in writing and including it in the contract. This approach can often be extended to the ITT and with the agreement of all parties the requirements document and the supplier's response to it can all be incorporated in the contract as a record of the requirement and how it is to be satisfied.

Software contracts are often treated as passive documents to be negotiated and then placed in a drawer to gather dust but they are an integral part of the implementation process. For example, once the requirements are defined and contractually agreed they should form the basis of User Acceptance Testing, (UAT). In other words, does the software as implemented do what the users expect it to do? The contract should drive the conduct of UAT, what to do if the software fails aspects of UAT, and how errors should be reported, corrected and retested after fixing. Payment should be linked to successful UAT phases rather than the more usual 30% on order, 50% on delivery and the remainder in 60 days regardless of the success of testing. But the customer has obligations as well. For example, it is inherently unfair to the supplier for software to be delivered but lie fallow for several months because the customer has not allocated sufficient resources to implement and test the system. To prevent this happening, a number of contracts will have "deemed acceptance" clauses which will say that if the customer is inactive following delivery of the software then the supplier will be entitled to assume that it has been accepted and should be paid for after the passage of, say, 60 days.

This article highlights just a couple of potentially important clauses in software licence agreements but serves to highlight the importance of taking contract terms into account when selecting a software supplier. To this end it is important to start negotiations early in the selection cycle when both parties are keenest to get the job done. As someone once said, "The relationship between customer and supplier is usually never better than at the beginning", so if you stumble at the contract hurdle perhaps you should review whether this is a relationship worth pursuing.

About Us