1.1 The Use Of Heads Of Agreement

1.1.1 Introduction

There are many occasions when you negotiate on the Suppliers standard form of contract and it may be that many of the terms remain intact, complete and unchanged and that what are changed are only a few clauses for example those relating to pricing, delivery dates, ownership of intellectual property rights to name a few.

In some cases very few of the Suppliers standard terms and conditions are used and larger companies and corporations use the provider's terms and conditions or standard forms as a starting point only.

There are other occasions, particularly where the deal relates to bespoke software, integration projects and B2B Exchanges where the parties start negotiations with a blank sheet of paper and create a final contract based around each others specific requirements within the deal. There are standard terms which will always been necessary in any form of software supply or development licence, but how do the parties in negotiation construct a satisfactory contract from a blank sheet of paper with or without their lawyer being present throughout the deal making? Perhaps by the use of Heads of Agreement or a Memorandum of Understanding.

1.1.2 Contract Skeleton

There are essential elements in any form of contract and the who, what, when, where, why and how process is applicable here. In other words, you need to agree on who the parties are; what the product is and the other essential elements of the deal are; when delivery is to take place and when other milestones are to be achieved; where delivery is to take place, where the software is to be located, where the territory is to be in terms of distribution; why certain obligations of the parties arise and why this particular contract is being formed; and finally how will certain obligations be performed, certain disputes settled and how will the contract come to an end or be terminated.

In building the contract there are certain logical places for certain specific terms to be included. Without stating the obvious the first portion of the contract should deal with the date of the contract, the details of the parties, the reasoning for the contract being entered into and the definitions. So firstly you will have outlined the effective date of the contract, who the contract is being made between, why it is being entered into and finally what all the subsequent specific terms and words in the contract will mean.

In effect the next portion of the contract is the major portion and which includes the essential terms such as the nature of the program, the duration of the contract, the rights granted and excluded, the obligations of the parties, the warranties, the ownership of intellectual property rights, acceptance tests and so on.

The next major portion of the contract are what in the UK are known as 'boiler plate' clauses such as severability, arbitration, governing law and jurisdiction, force majeure, notices and so on.

Finally, there may be schedules which give the opportunity for the parties to list detailed and specific items such as milestones, detail on the software products, list of intellectual property rights attaching to them such as trade names, trade marks, patents and so on.

1.1.3 Drafting the Heads

The Heads of Agreement or Memorandum of Understanding forms not only an aide-mémoire during the course of negotiations but also registers in plain language the terms agreed.

Heads of Agreement are not prepared with the intention that they are the contract itself but rather that they are the pre-cursor to the full form contract which the parties lawyers will finalise.

As to whether the Heads of Agreement are in themselves contractually binding will depend upon the nature of the wording of the Heads of Agreement but it is the writer's opinion that Heads of Agreement should be 'subject to formal contract' and certainly signed with the wording 'Subject to Board approval' or 'Subject to final Contract'. In this way whilst the terms negotiated and agreed by the negotiating teams are reduced to written form neither party is bound by the Heads of Agreement but will only be bound at the point that the final agreement is signed, dated and exchanged.

When producing the Heads of Agreement keep the language simple and plain but cover the essential points. It is often difficult in the computer industry to avoid jargon but where jargon is used it may be worth while defining it (particularly where the customer is not experienced but the Licensor is) and even if both parties understand the jargon remember that the purpose of Heads of Agreement are to record the negotiated deal in case of a breakdown and where a breakdown occurs it may be a lay person who will have to decide the precise interpretation of jargon.

Keep the clauses short and clear. Heads of Agreement are precisely that - they are bullet points or headings and are not intended to be lengthy clauses - that is something for the final Agreement.

Try and use consistent numbering or phrasing so that whoever prepares the final Agreement can logically follow through and interpret the particular bullet points and their sub-headings.

Be sure that words are correctly spelt. A typing error can have a dramatic effect. For example 'the Licensee is not entitled to more than 1 free copy' means something entirely different from 'the Licensee is now entitled to more than 1 free copy'.

1.1.4 Three Golden Rules

During the course of negotiations although the parties may agree on points, certain assumptions may have been made, and the Licensor and the Licensee's view of what has been agreed may be entirely different from each other

The first golden rule applicable to drafting contractual documents whether Heads of Agreement or not is:-

Those who think they have agreed generally have not

Where the negotiating teams have gained mutual respect and believe that they are working towards the same common goal the second golden rule applies-

Those who think that they get on well will generally fall out.

Finally, whether negotiations take a matter of hours, a matter of days or a matter of months and nothing has been reduced to final contract form but the parties are already dealing with each other as if there were contracts, the third golden rule applies:-

A oral agreement is not the worth the paper it is written on.

1.2 The following is a list of do's and don'ts for the initial stages of negotiation. Act reasonably and in a friendly manner as the object of negotiations is to reach agreement and not to win an argument.

When a written statement has been submitted by your opposite number (OPPO):-

Do

  1. enquire about each significant point asking why it is made unless it is obvious;
  2. appear ignorant, even if this is not true, in order that a particular statement that you do not agree with can be explained at length;
  3. note points with which you disagree and reserve your position;
  4. make certain each point has been fully understood even if this means going over the ground twice. This applies particularly if the languages are not the same;
  5. test out the strength of OPPOs view of each point of significance so that at a later time one can assess how far a particular point is a sticking point or is negotiable;
  6. be aware of the inter-relationship between different contract points and the possible counter arguments which will be developed if success is achieved on any particular one;
  7. correct your OPPO if he is proceeding on a false belief as to a factual position for which you are responsible.

Do Not

  1. speculate on OPPOs reasons or put words into his mouth;
  2. show the depth of your knowledge by answering questions put to your OPPO by another member of your team;
  3. agree significant points immediately, even if agreement will be reached in the end;
  4. snatch at what appears to be a favourable bargain or interpretation or OPPOs views;
  5. be drawn into lengthy arguments on any individual point for which it may be difficult to withdraw;
  6. betray feelings by showing anger, surprise or delight at OPPOs remarks;
  7. improve OPPOs judgment unless it is advantageous.

When you have submitted a written proposal:-

Do

  1. limit answers to questions to the minimum necessary;
  2. test out the strength of OPPOs suggestions by seeing if he will withdraw them without requiring any corresponding concessions.

Do Not

  1. elaborate at length on motives;
  2. concede anything or be drawn into trade off negotiations before all points have been discussed.

When no written statement has been submitted by either side:-

Do

  1. identify all the points to be discussed;
  2. cover each point in sufficient depth for both sides to be aware of each others position;
  3. keep the discussion explanatory;
  4. correct your OPPO if he is proceeding on a false belief as to a factual position for which you are responsible;
  5. be aware of the inter-relationship between different contract points and the possible counter arguments which will be developed if success is achieved on any particular one.

Do Not

  1. let the discussions ramble on without any defined order;
  2. concentrate the discussion on one point to the exclusion of all others;
  3. be drawn into definite commitments either in the form of making a firm concession or taking up a position from which may be difficult later to withdraw.

In the course of initial negotiations it may be necessary to reveal confidential information to your OPPO, which you will necessarily need to protect should the deal not proceed, and I suggest either a letter of confidentiality is entered into or if the circumstances dictate a more comprehensive non-disclosure agreement is signed.

Following initial discussions or negotiations one can make an initial check list as follows:-

  1. Names of parties;
  2. Licence/duplication agreement/distributorship agreement in respect of products known or to be known as
  3. Exclusive/non-exclusive licence;
  4. Territory;
  5. Terms of use;
  6. Reservation of rights;
  7. Confidentiality;
    1. Licence to use trade marks;
    2. Requirement to maintain trade marks;
  1. Method of payments - advance fee or not - minimum royalty guarantee;
  2. Marking of products;
  3. Acknowledgement as to ownership of products;
  4. Term of agreement.

Subject to approval of the Board of Limited.

Following on from the initial check list it is possible then to proceed to the final Heads of Agreement incorporating all the items in the initial check list but in a more specific nature and containing any other terms which have not been incorporated in the initial check list which may cover points such as:-

Definitions of terms
Systems for which products shall be used upon
Licensor's warranty as to intellectual property rights
Samples and inspection of products
Costs and expenses
Method of termination of agreement
Sub-licensing
Assignment
Indemnities
Waivers
Notices
Governing law
Arbitration/dispute resolution
Insurance

As in all matters time is usually of the essence and negotiations are often conducted against a time pressure, usually brought upon the parties by other market forces, and at the point at which Heads of Agreement are signed with a view to formal documents being prepared by Lawyers, there is little time left for the Lawyers to make their own views known as to the legal consequences of the points made in Heads of Agreement. It therefore follows that the sooner the Lawyers can be involved the better in order to prevent points being agreed by the parties which are not workable or may indeed be void at law.

2. Necessary Provisions

2.1 Key Licence Provision From The Provider's Viewpoint

2.1.1 Introduction

Vendors and licensors in English-speaking countries are somewhat more consistent and predictable than their customers in terms of their feelings toward contract clauses. This is not to say that all vendors and licensors recognise the same contract terms as "absolutely necessary", or even that all or nearly all recognise the importance of contracts. Also, some key provisions in some UK and US contracts might be illegal and unenforceable in other countries. The point here is that when compared with customers as a whole, most software providers who have survived or will survive their first decade in the industry are attuned to the importance of contracts and three fundamentally necessary categories of contract provisions. These categories are discussed below and examples of key terms from the licensor's viewpoint are included in the discussion.

2.1.2 What Will I Provide, When, And For How Long?

Answers to this question are key terms that should always be found in a contract for a major software transaction. A lack of clarity or full information on this topic simply sets the stage for confusion, unhappy customers, disputes, and possibly litigation. All goods and services provided should be identified to some reasonable level of detail, and specified in the quantity or for the duration or project agreed upon.

There should be no difficulty in identifying off-the-shelf software or other products. Smart custom-software developers-licensors also recognise the importance of detailed specifications for their projects. Most major projects are done on a fixed price or "not to exceed" basis rather than on an unlimited time and expenses basis. In this context specifications are a two-edged sword, but also a two-sided benefit. They state requirements which the developer-licensor must satisfy, they define products which the customer desires and expects, and they state the standard by which a failure or possible breach of contract may be measured. In addition, specifications define the limits of responsibility, or the maximum obligation, beyond which the developer-licensor can require additional compensation. Since the specifications for most customising projects and most custom-made software development projects are altered, supplemented or redefined by the customer, the developer-licensor can reasonably utilise the specifications ("specs") and desired changes as the basis for add-on revenue requirements.

If no specifications are developed, the developer-licensor opens the door to a situation where it can be taken advantage of by a customer who changes its mind about the definition of the deliverable and thereby requires additional work without increasing the project's fixed price or ceiling. From the developer's standpoint, specifications and a mechanism that allows increased billings for changes in specs are prudent and even essential elements of a large development project. From the customer's standpoint, specifications and a mechanism that allows mutually agreed upon changes in the specs for a major software development or customising project are equally essential because the clear definition of deliverables which specifications state are the heart of the project, and because the change mechanism gives the customer flexibility.

The "when?" issue directs us to delivery commitments. The standard, printed form contracts of many software providers, like those of many of their equipment provider cousins, do not stipulate a time frame for delivery and installation. The question of "When must I deliver the software?" is intentionally not raised in these agreements. The burden is on the customer to require delivery and installation dates or time frames, or a project completion schedule with this information. Usually the provider benefits slightly from an unspecified delivery and installation deadline. The lack of such a requirement in the parties' agreement gives the provider flexibility and may help the provider avoid a breach of contract for a delayed delivery or installation, whether it was unavoidable or subject to the provider's control. RECOMMENDATION: in a major deal the customer should insist upon clear delivery and installation deadlines in the parties' agreement(s). Of course, such deadlines may be conditional on such factors as the suitability of the environment for the delivered software, access to the customer's equipment, the availability of the customer's personnel to test the delivered product, or other reasonable conditions. Also, the delivery deadlines can take the form of specified dates, specified events, a specified number of days after an event, or some other form.

2.1.3 What Will I Receive, When, And For How Long?

This question boils down to: "When and how will I be paid?" The answers are always necessary in a contract for a major software transaction. Most business people understand this point very well, hence it will not be examined closely. If a licensor's standard-form contract is clear about nothing else, the answers to this question are usually very clearly stated.

A related topic that sometimes triggers discussion is the question of whether a cure period for correction of failures to perform in accordance with the contract should apply to late payment requirements. This topic can be important to all sides of a major transaction and it has some potential to become a "deal breaker". The cure period commences at some point after a deadline is missed and it delays a breach of contract until the period expires. The problem-solving compromise in some negotiations over whether to apply the cure period to late payments is to allow the cure period but to agree upon interest for late payments. A variation is to allow a reduced cure period to apply to late payments and a longer cure period apply to other breaches of the parties' contract. Of course, some vendors and licensors require interest on late payments and refuse to allow any cure period. However, few providers are ready to terminate a customer immediately after a payment's due date. As a practical matter most customers will receive the benefit of a short grace period on payments, at least during their first transaction with a provider.

2.1.4 What Business And Legal Risks Do I Face That I Should Minimise Or Neutralise?

This third category of fundamentally important contract terms, from the licensor's viewpoint, contains provisions that are common in contracts for various transactions in many industries.

Liability Safeguards: most licensors who are or will be survivors in their markets recognise early in their history that there are three basic, conventional, ways to safeguard against liability: to incorporate, to buy insurance, and through protective contract provisions. Incorporating and contract language usually cost less than insurance such as a general liability policy, a product liability policy, or an errors and omissions policy. Incorporation is a common first step for a new software provider. Smart entrepreneurs usually develop standard, protective contracts within the first few years of their business life. A failure to insurance may result in a court decision that an exclusion of liability is unreasonable, if appropriate insurance was available at a reasonable price.

Risks: business people tend to worry about revenue, cash flow, return on investment, and market share and other business worries, but the greatest risks anticipated are usually litigation and disputes that would (1) raid the company's accounts, or (2) throw it into bankruptcy, or (3) generate so much bad publicity that the business would be hurt badly or wither and die. These risks are generally perceived as risks which the provider should always strive to minimise or eliminate.

Protective Contract Terms: the standard protective clauses found in most UK and US vendor contracts, as well as in those of UK and US software licensors, include: (A) an exclusion of consequential damages; (B) a limited warranty with a specified exclusive remedy (such as the repair or replacement of a defective unit) and an alternate exclusive remedy of the refund of money paid or part of the money paid; (C) an exclusion of other express warranties; (D) a disclaimer of all implied warranties; and (E) a limitation on recoverable damages to some specified amount, to part of the sum paid, or to the entire payment for the item(s) giving rise to the dispute or litigation. Examples of these provisions can be found in the chapter containing a checklist of software licence agreement terms. While these provisions can be overdone, in most software agreements some variation of these provisions are reasonable and make good business sense. Of course, other types of liability limitations or exclusions are sometimes demanded by software providers. The reasonableness and importance of each of these provisions must be analysed on a case-by-case basis.

2.1.5 Other Provisions

Depending on the nature of the software transaction other contract provisions may assume the status of a key clause. Source code licenses are usually sensitive transactions for the software provider claiming trade secret law protection for some or all of a product's source code. A provider may reasonably insist on protective clauses in source code licence agreements that supplement or toughen those normally found in executable code licence agreements. For example, disclosure of the source to non-employees may be absolutely prohibited, only those licensee employees with a need to access the source in the course of their assigned duties may be allowed to use a copy, and use of the source may be specifically limited to the agreed upon purpose for which the licensee intends to employ the code. Also, sign-out and sign-in logs for all copies of source may be required together with an audit provision. Removal of source from the building in which it is housed may be prohibited. These provisions or some variation of them are generally considered to be reasonable and essential in the context of a source-code licence agreement where the source is a valuable asset of the licensor and it has not previously fallen into the public domain.

One argument for not providing an escrow source code is that the code for well known products will normally have a commercial value and will be an asset realisable by a liquidator. The purchaser is likely to be a third party maintainer wanting to do business in maintaining the well known product.

2.2 Key Licence Provisions From The Customer's Viewpoint

2.2.1 Introduction

The provisions, topics and considerations surrounding major software transactions can be categorised in several ways. For example, customers often divide issues for negotiation into "financial," "technical," "legal," and "other business needs" categories, and then negotiate the categories in some selected sequence. In addition, customers often search for and attempt to identify for negotiation purposes the "key" provisions. However, customers are not as consistent as providers in their identification of key contract terms.

The "key" software licence provisions from the customer's viewpoint will vary to some degree, but not completely, from one major software transaction to another. Customers tend to see two general groupings of key terms, but thereafter the number and nature of key terms will vary from customer to customer and deal to deal. The major variables that affect the classification of a contract provision as a key clause in your licence agreement are listed below after the two general categories of key terms. Of course, reasonable people may disagree about the importance of any contract clause or topic. The variables listed in the second half of this chapter explain some of the reasons for such disagreements.

2.2.2 Key Questions

Regardless of whether the customer and supplier employ one contract or several agreements to capture a transaction, regardless of whether the customer is an end-user or a middleman, and regardless of whether software or some software related service is provided, the customer can ascertain a number of key contract terms by asking the questions listed in sections 7.2.2.1 and 7.2.2.2

2.2.2.1 What Do I Receive, When, And For How Long?

Answers to this question are terms that are always necessary in a contract for a major software transaction. Some of these answers could be conveyed by implication. For example, if you purchase equipment, purchase and transfer of title language imply that you can keep the equipment forever if you wish, assuming you pay for it in full and on time. Nonetheless, the acquiring party should always know what is being acquired, when it will be delivered and installed, and how long it may be used, distributed, modified, displayed, and so on, before it must be returned, destroyed or discarded, if ever. Some examples of answers to this question follow.

2.2.2.1.1 The goods and/or services you will receive should be identified in clear detail. Vaguely identified deliverables often create problems for customers. Some examples of deliverables that should be specified clearly and in detail in your contract include:

  • equipment, by manufacturer or private label; by model, quantity, characteristics, specifications, and serial number (as soon as the serial number is available);
  • off-the-shelf software by name, characteristics, specifications, and quantity of copies;
  • custom-made and tailored systems ("CMATS");
  • mutually acceptable functional and technical specifications for the CMATS;
  • mutually acceptable design and acceptance criteria for the CMATS;
  • a detailed, mutually acceptable implementation plan for the CMATS;
  • an incremental payment plan, or other mutually acceptable payment arrangement, for the CMATS; and
  • custom-made database designs, report designs, screen designs, screen and data nomenclature and definitions, interfaces and access protocols, all according to clear, detailed specifications and a detailed implementation plan therefor, both of which are created, reduced to writing, and agreed upon before work begins, as should be the case with the CMATS deliverables.

2.2.2.1.2 What you receive in terms of ownership of the deliverables, or in rights to use, reproduce, distribute, modify, display, relocate or transfer the deliverables, should be clearly and precisely stated in complete detail. Surprises on these topics after a contract is signed may be hazardous to your career, not just to your organisation. Some examples of these contract provisions are listed below:

  • title to equipment (when does it pass to you or is it never acquired?)
  • title to the copy of software operating on the equipment, or your rights under your software agreement's licence grant provision and the limitations on those rights, which are often scattered in several contract provisions; and
  • ownership of the intellectual property rights in custom-made software, or your rights to use, reproduce, distribute, modify, display, relocate or transfer this software to other equipment, to different sites, to different users, and so on.

2.2.2.2 What Do I Pay, When, And For How Long?

Answers to this question should always be essential contract provisions from a customer's viewpoint. Common sense demands this information in addition to business and legal requirements. It is rare for a customer to have a good business reason to be indifferent about the price, when it must be paid, or when payments must commence, their frequency, and their duration. All required and contingent payments should be clearly specified in the parties' agreement. The timing of all payments should be clearly set forth, for example, due dates and any cure period for late payments. Conditions on the payments must be identified, for example, passage of acceptance tests. Some examples of these payments follow:

  • equipment prices, instalment payments or lease charges and any buy-out option price for leased equipment;
  • software licence fees or purchase prices, listed separately unless there is some advantage to the customer to accept a bundled cost, for example, operating system software bundled with the equipment purchase price (insisting on an unbundled cost is likely to produce a higher total cost);
  • maintenance charges, unbundled so that you can control them through negotiated discounts and a ceiling or cap on periodic increases; and
  • other service charges such as vendor programming, design, or analysis service charges, separately specified.

2.2.3 Other Provisions

In addition to the foregoing, a few other contract terms are likely to be perceived as essential in most major software transactions. Almost any contract term can become critical to the customer's success under circumstances that elevate its importance. The following variables identify some of these circumstances and some of the contract provisions they make necessary.

2.2.3.1 The Nature Of The Transaction

The nature of the transaction can play a major part in your deciding whether a contract term is essential. For example, in an off-the-shelf software licence agreement, the license-grant clause is absolutely necessary. However, in a facility management deal customer personnel may not be the authorised user of any software, and hence the customer may not need a licence grant. Similarly, a customer might feel that a data processing service provider need not warrant its internally used software against defects, but a software licensor is often required to provide such a warranty.

2.2.3.2 Needs, Goals And Concerns, And Your Sense Of Urgency

The customer's needs, goals and concerns, and the urgency of its specific needs are all primary factors determining which contract provisions are essential in a software or related service transaction. For example, if the customer has an urgent need, there may be no time for negotiations and the customer may be willing to sign any licensor document as is. In this situation getting the product is the absolute need, not contract terms. Of course, this thinking can be dangerous and unpleasant surprises sometimes result from ignoring or treating lightly the content of contracts, for example, if you find out your licence grant does not let you do what you need to do with the licensed software after you have signed the agreement.

If you have a critical need to avoid downtime, then the ability to move software to a disaster recovery location may be a necessity, or you may decide you must have on-site spare parts and three-shift, on-site maintenance service, or you may decide you must self maintain your licensed software and/or equipment. In the latter event, access to source code is an absolute necessity, and either sending your employees to the vendor's maintenance personnel training courses, or hiring vendor maintenance engineers probably becomes a necessity as well.

Are you concerned about the financial strength of your licensor and the possibility of its bankruptcy? Here obtaining source code or a source code escrow may be perceived as absolutely necessary.

Does your "enterprise view" require the acquisition of software that will support your data designs and data flow in your internal databases? If so, then it may be absolutely necessary to develop some interface software when some new off-the-shelf software is acquired from a new supplier. By extension, contract provisions addressing this interface development project become absolutely necessary.

Are you concerned about whether a new system will be compatible with your existing systems. If so, a benchmark test, or an acceptance test, a trial use period, and/or a compatibility requirement and warranty might be considered essential.

2.2.3.3 Budget

Is your budget for the acquisition or alliance more than adequate, inadequate, or barely adequate? This variable could make instalment payment terms, or deferred payment language, critical to the success of the deal.

2.2.3.4 Policies

Your organisation's policies sometimes dictate the importance of contract terms. For example, your law department may have a policy of requiring your country's law as the law which governs the contract.

Your organisation's policies may require you to develop and use standard contracts in lieu of the supplier's standard contracts. In this situation more than a few contract terms are necessities. Standard contracts contain numerous business decisions and limitations on risks. At least some of the provisions that capture these concepts will typically be considered absolutely necessary and "sacred cows" that are unchangeable.

In addition, your organisation may have a policy that requires tailor-made, detailed, and thorough acceptance tests for each major acquisition. Contract provisions that capture and require the application of such acceptance criteria then become necessities.

Does your organisation have a policy requiring on-going standards of performance, or performance bonds? If so, then these provisions become extremely important.

Your organisation may require a ceiling on maintenance service charge increases. This "cap" provision then becomes a necessity.

Do you require the flexibility to terminate ongoing payments for some or all of the software you licence if your budget is reduced? If so, contract terms giving you this flexibility are vital.

Suppose you are about to acquire a new switch and you need on-site spare parts for this telecommunications system. Further suppose that you want to buy used parts from other sources because they are significantly cheaper than new parts from the vendor. Now assume that the vendor insists upon inspecting and testing these parts to ensure that they do not short circuit the new system covered by the vendor's standard maintenance policy. If the vendor charges a very small fee for this inspection and testing, then you may not object. However, you may have a firm policy against payment of expensive inspection, testing and "certification" charges for the vendor's approval and coverage of these spare parts under its standard maintenance policy. Avoiding expensive certification charges may be important to a customer, and a refusal to pay them has killed more than one multi-million-pound acquisition.

Many other examples could be cited, but these few should illustrate the importance of organisation policies in ascertaining the key contract terms in your deals.

2.2.3.5 Culture

The environment in which you function can dictate the necessity of some contract terms as well as your attitude toward suppliers. Your organisation's style of doing business may require you to be aggressive and demanding with suppliers, or even handed, or easy going and friendly. If your organisation's culture requires aggressive negotiations in a major deal, a "most-favoured customer" provision may be an absolute necessity in your contract.

If your organisation is fast moving, decisive and willing to take risks, you may not hesitate to make unqualified commitments to a supplier. On the other hand, if your organisation is slow-moving and careful, or is highly political in nature, then contract provisions giving you flexibility to make changes after the contract is signed, and/or numerous protective provisions, may be practical necessities or politically prudent.

2.2.3.6 History

Your organisation's history in dealing with a particular supplier may dictate the necessity of some contract terms, for example: warranties and representations against shut-down, slow-down, or use limitation devices in software; or a clause requiring responses to maintenance problems within a specified period. Of course, provisions like these are appropriate in contracts for major acquisitions absent a negative history with a supplier, but they become more important after a bad experience.

2.2.3.7 The Individual

The position of the individual within the organisation and his or her risk-taking orientation are major factors in determining the absolutely necessary terms of a particular deal. To illustrate, in many companies junior and middle management personnel tend to focus on their individual concerns or the interests of their unit, department, section, or group. The best interests of the organisation as a whole may not be their primary consideration. The paradigm examples are (A) the lawyer who focuses only on protecting the organisation against risk, and (B) the techie who focuses only on the technical evaluation of the licensed software. Such a focus is not necessarily "wrong", but it helps to dictate the contract provisions that these individuals will deem absolutely necessary. Of course, some techies and some attorneys see the big picture as well as the trees and are business oriented. Hence, in some transactions the needs of the organisation will be understood and well served by these individuals.

The risk-taking orientation of the individual may help to dictate vendor selection as well as the number and variety of protective provisions that are deemed "absolutely necessary." Examples of such protective contract provisions include liability limitations, source-code escrows, credits for downtime, flexibility in termination, or other forms like bid bond or performance bond requirements.

2.2.4 Clarity And Precision

From the customer's viewpoint, clarity and precision in contract language are as necessary as the key terms we have reviewed. Vagueness and ambiguity almost always favour the licensor whether or not the licensee recognises the ways in which vague provisions can be harmful. For example, some customers insist upon vague, subjective acceptance language in the parties' contract, reasoning that it gives them control and discretion regarding acceptance of the items delivered. Perhaps these customers also feel they have insufficient time to identify and negotiate objective acceptance criteria. One difficulty with this reasoning is that a subjective acceptance mechanism invites disagreement over whether the supplier's product or service should be, or should have been, accepted. Except for some major, glaring deficiency in the product or service supplied, the supplier can claim that its product or service should be accepted as easily as the customer can claim it should not be accepted. Of course, such disagreements sometimes lead to a strained relationship, a loss of future business for the supplier, a loss of a valuable supplier to the customer, or a law suit. Such disagreements are needless and many can be avoided through the use of objective acceptance criteria. In general, vagueness and ambiguity in the parties' agreement should be tolerated by the licensee only if it helps the licensee in some significant manner.

The content of this article is intended to provide a general guide to the subject matter. Specialist advice should be sought about your specific circumstances.