A Practical Guide to IT Law

1IT CONTRACTS

Jeremy Holt

This chapter outlines the contents of a contract and lists the matters that should be covered by different types of contract. If you do not have time to read the rest of the chapter, the appendix lists the main points that you should consider.

INTRODUCTION

Pity the unfortunate manager. It has been bad enough trying to get the computer project organised. Now, possibly at the last moment, the contracts have arrived, some with print small enough to make the reader go blind. The manager suspects (rightly) that these contracts are one-sided in favour of the supplier, but knows that the project will only proceed if those contracts (or something similar) are signed. How does the manager work out what needs to be done and from whom advice can be obtained? This chapter provides a practical framework of help in this situation. If you are looking for an academic guide to computer contracts, you will need to look elsewhere.

PARTS OF A CONTRACT

The first point to consider is the form that contracts normally take. At its simplest, a contract consists of:

the date on which the contract was entered into;

the names and addresses of those entering into the contract;

a short description of what the contract is about (generally entitled ‘Background’, ‘Recitals’ or even, regrettably, ‘Whereas’);

definitions of terms used in the contract;

what the supplier is going to do for you;

what you must do for the supplier;

what you must pay the supplier.

Do not forget we are engaged in contract first aid here. If all else fails, concentrate on points (5) and (7), that is, what the supplier is going to do for you and what you are expected to pay. Standard terms that are not specific to this individual contract (what lawyers call ‘boilerplate’) are generally grouped together at the end of the contract.

IMPORTANT BOILERPLATE TERMS

These are some of the more important boilerplate clauses you may come across.

Force majeure – this says that neither party shall be liable for any failure to perform the contract because of circumstances beyond its control such as an Act of God, fire, flood and so on. This is more likely to be invoked by the supplier than the client because this clause effectively absolves the supplier from responsibility.

Entire agreement – this says that the entire agreement between the parties is set out in the written contract and so no other previous representations by the supplier may be relied upon by the client. This is a reasonable principle, but the client must make sure that the contract deals with all the important points.

Notices – this specifies the agreed means of sending formal notices. Normally, this requires a notice to be in writing, to avoid issues surrounding an oral notice (i.e. proving delivery and contents). However, what qualifies as ‘writing’ may differ from contract to contract. For example, some clauses may expressly state that a notice is not valid if sent by email. A notices clause may also specify the personal details of a party on whom a notice must be served to ensure it comes to the attention of the appropriate party.

Dispute resolution – it is sensible to agree an alternative dispute resolution procedure (such as mediation) that must be carried out before any dispute is referred to the courts or to arbitration.

Governing law and jurisdiction – ideally this should be English law enforced in the English courts. An alternative is to agree arbitration, but as this happens behind closed doors then the supplier may worry less about bad publicity.

WHO ARE YOU GOING TO CALL?

You are not going to be able to do all this on your own. You are going to need professional advice. Computer law is a specialist area, and a rapidly changing one (it did not even exist as a field of legal practice 30 years ago) and the correct advice from a lawyer experienced in this field can save a great deal of trouble later. The function of a good lawyer is to assess risk, help the client to understand the level of risk and then reduce it.

There are two directories of lawyers that you might like to consult: Chambers’ Guide to the Legal Profession and The Legal 500. New versions are published each year, and each has sections on lawyers who specialise in computer law (sometimes called ‘information technology law’). These two books can generally be found in the reference section of a public library, and can also be searched without charge on the web. Alternatively, you can ring the Law Society or the Society for Computers and Law for suggestions of lawyers who work in this field and who could help you.

CHECKING OUT THE SUPPLIER

It may seem like an obvious point but make sure that you know who you are dealing with. This will mean, at least, doing a company search. A credit check would do no harm. As the Army maxim has it, ‘time spent on reconnaissance is seldom wasted’. If you discover that the supplier company was set up last year and has an issued capital of £1, you may like to consider asking for a guarantee of the contract from a more substantial body.

Business is not all about making rational decisions on paper. Do you get good vibes from the supplier? On small things, do they do what they say that they will do? If, for whatever reason, you do not trust them, do not go ahead with the contract under any circumstances, as this will only lead to worry and tears later.

LETTER OF INTENT

As the supplier may need to start work on your project before contracts are signed, and because the negotiation and agreement of the contract terms may take a little while, the supplier may ask for a letter of intent from you. Alternatively, you may like to suggest one so that you are not pressurised into signing the contracts before you have reviewed them properly.

A letter of intent is no more than written confirmation from you of your intention to enter into a contract with the supplier. What is critical, however, is that your letter of intent states that the letter is not intended to be contractually binding. Otherwise, you may unwittingly enter into a contract earlier than you intended.

Where there is a non-binding letter of intent and the supplier, at your request and to save time, starts work on the project, it is reasonable for the supplier to ask to be paid for this initial work carried out regardless of whether the project proceeds or not. There are two important matters to agree here. The first is the rate for the work carried out (e.g. a daily rate). Work normally starts under a letter of intent on a time and materials basis; the definitive contract may include a fixed price for a specified deliverable. The second is an overall cap on the total amount of payment to the supplier for this work. This obligation to pay the supplier should be contractually binding (unlike the rest of the letter of intent).

THE SUPPLIER’S TERMS

It is a good idea to ask for the supplier’s proposed terms at as early a stage as possible. Do not wait until you have told them that they have been awarded the contract. There is of course no obligation on you to accept that you will purchase a new computer system on the basis of the supplier’s terms. You could propose your own terms entirely – this is certainly an approach taken by large organisations with extensive experience of computer contracts. However, it is generally better to use the supplier’s contract terms (unless they are completely unreasonable) as a starting point and amend them to your satisfaction.

If a particular point is important to you, make sure that you get it in writing from the supplier. It may well be that a critical aspect is not dealt with in the supplier’s draft contract at all. If so, you must, for evidence’s sake, get it in writing from the supplier. An ordinary letter from the supplier is sufficient provided that it is either referred to in the main contract or included as a schedule or as an attachment. If the supplier drags their heels and, despite repeated requests from you, refuses to confirm a point in writing, you should write to the supplier saying that you are only entering into the main contract on the basis that this point is agreed. If the matter ever goes to court, the production of your letter will be of great assistance to your case.

WHAT CONTRACTS ARE THERE LIKELY TO BE?

Any computer system will require the purchase, licence and maintenance of hardware (the server, PCs, printers, etc.), software (the application software and the operating system software) and services (such as support and maintenance). Previously, the emphasis was very much on the hardware, but nowadays the focus is much more on the software and services. Nevertheless, this chapter discusses all the contracts you are likely to need.

Generally, it is better to decide upon the software first and then to choose the appropriate hardware. Alternatively, you may enter into a contract for consultancy services first, to assist with this process. Consequently, this chapter will deal with such contracts in this order.

Contracts for consultancy services

Long before the order for a new system is placed, the client may enter into a consultancy contract, perhaps relating to a feasibility study, analysing requirements, recommending a system to meet those requirements, helping to select the appropriate suppliers, or assisting with preparation of an invitation to tender. A large part of the work carried out in the computer industry is under consultancy contracts. The client may need help on a one-off basis or require skills that do not exist within the client’s workforce, so need an outside consultant to carry out the work. Sometimes the consultancy arrangement is dealt with by means of an exchange of letters; a formal consultancy agreement, however, is a better option for both parties.

Defining the deliverables – one of the most important issues that must be dealt with in such a contract is a detailed description of what the consultant is expected to do. If the description is loose or inexact, this can give rise to differences between what the client is expecting to receive and what the consultant is expecting to deliver – which can, predictably, lead to disputes. So, defining the nature and quality of the deliverable is particularly important.

Payment arrangements – the payment to the consultant by the client may be on a time and materials, fixed price or estimated maximum price basis. It is an aspect of consultancy that the amount of work required will be uncertain. The disadvantage of a fixed price payment mechanism (as with any other contract) is that the consultant will inevitably include a contingency element in the price quoted. If the consultancy can be broken down into a series of stages, payment against milestones will allow each party to gauge how the work is going.

Copyright – copyright will almost always be an issue. Broadly speaking, there is a simple choice as to how the parties deal with ownership of copyright in the consultant’s work. Either the consultant can assign to the client all intellectual property rights in whatever is produced (provided that the consultant has been fully paid) or the consultant can grant a perpetual licence to the client to use such intellectual property rights for the purposes of the client’s business (see Chapter 4 for more details). It is important to note that if there is no agreement with a consultant about copyright, the client does not automatically get ownership of such copyright. It stays with the consultant (although there may also be an implied licence for use of the copyright by the client).

Confidentiality – it goes almost without saying that the consultant should be obliged to keep confidential any information given by the client about its business. The problem is that once a consultant has carried out an assignment for one client in an industry, the consultant may be ideally placed to carry out assignments for other clients within that same industry. Sometimes, therefore, clients go further and stipulate in the contract that not only must their own information be kept confidential, but the consultant must agree not to carry out projects for the client’s competitors for a period (perhaps a year) after the work is completed.

Insurance – in order to provide peace of mind to the client, the client may require the consultant to take out professional indemnity insurance. This is still relatively inexpensive as, in practice, it is rare for claims to be made under such policies.

Key personnel – the client will want to know the identity of the staff who the consultant will be using to carry out the work. It is normal for the client to be able to veto any staff members of whom they disapprove for whatever reason.

Termination – the client will want to retain the right to terminate the consultancy contract if the consultant is guilty of serious misconduct or any other conduct likely to bring the client into disrepute.

Contracts for software licences

At its simplest, any contract for software should allow you to use the software in the way that you envisaged without the risk that anyone can come along later and say either that you cannot use it any more or that you have to pay more money. It follows, therefore, that one of the first checks you should do is to confirm that the software supplier either owns the copyright in the software or has the right to license it to you. It is a feature of the computer industry that software is often licensed to end users by organisations other than the actual owner (for example it may be sub-licensed by a distributor or channel partner). You should not put up with oblique answers to your demand for evidence that the supplier can license the software to you. They should be able to produce it immediately.

At this point you may wonder why a licence agreement is necessary at all; why can the supplier not simply sell you the software? The supplier is not actually selling you ownership of the software because they would like to continue to license it to other people. The licence is only a permit for you to use the software for your own purposes.

This leads onto the next important point. You must check in the licence agreement to whom the software is licensed and for what purpose. Is the software to be licensed to your particular company or can it be used by the whole of your group (in which case the software supplier will want more money)? Alternatively, is the software to be restricted to a limited number of users and, if more than that number use it, then do you have to pay an additional licence fee? This is one of the oldest tricks in the software supplier’s book. They allow the client to sign up for a very limited number of users and then the supplier makes a considerable profit from the additional users that will almost inevitably be required by the client later. The supplier, of course, responds that this simply reflects the extra use (and, as a result, commercial benefit) that the client is making of the software.

It is also possible that, at some time in the future, the client may want to outsource its computer operations. Consequently, provision for the transfer of the licence from the client to an outsourcing company should be made in the original software licence agreement.

Additionally, make sure that the procedure for acceptance testing is known and agreed. If this has not been sorted out in the contract, how are you going to stop a bad system from being installed? In the past, the test data were generally supplied by the client; nowadays it is more acceptable for it to be provided by the supplier.

Contracts for software maintenance

No software of any complexity is ever free from errors. The older the system, the more likely that it will need maintenance. Furthermore, if a system is installed in a rush (e.g. to meet a particular deadline), then it is likely not to have been tested properly so may require more attention after it has been installed. In some ways, future charges for maintenance are the icing on the cake for software developers. If they can generate sufficiently wide sales of the software, then support fees can be guaranteed for years to come. It is important for managers to be aware of this as three-quarters of a budget for software may be for future software maintenance. The client is well advised to check how wide the maintenance supplier’s client base is (the wider the better) and to look at the offices from which the supplier will be providing the support (and how many people will be providing such support). The maintenance contract will almost certainly be prepared by the supplier. Some of the most common provisions are discussed below.

Charging arrangements – sometimes the cost of the software licence is bundled with the first year’s maintenance charges. One interesting point is from when the support charges should run. Some clients argue that they should start from the end of the warranty period for the software. However, it is now generally accepted that they should begin from acceptance of the system, as warranty and support are separate matters.

Scope of maintenance services – maintenance or support will normally cover the investigation by the supplier of errors in the system reported by the client as well as updated documentation and telephone or, more frequently nowadays, online advice. It will, in most cases, cover updates to the software (but not necessarily new versions of the software). The client may want to categorise different kinds of problems into those that could be critical for its business and those that are no more than an irritation and could be dealt with next time a new version of the software comes out. The supplier’s response time will be different depending on the severity of the problem. The supplier will not normally commit to a fix within a particular period – only that they will start to fix it within a particular time.

Length of maintenance – make sure that you get the supplier to agree to supply support and maintenance for the products purchased for a decent length of time, for example five years. You do not want the supplier cancelling support after a couple of years just when your new system is working well. Note that you do not have to commit to take the support and maintenance for five years – ideally your commitment should be on a year-by-year basis. It is just that the supplier agrees to make the support available to you for at least five years if you want it.

Exclusions from scope – the maintenance supplier will also be keen to list in the contract what maintenance does not cover. Most of these exceptions are reasonable. They generally include problems arising from changes to the software made by people other than the supplier, incorrect use of the software by the client, or events beyond the control of the maintenance supplier such as hardware failure, fluctuation of electrical supplies or accidents. Normally, the maintenance supplier will still seek to help the client where the exceptions apply (indeed there should be a contractual obligation to do so). However, the supplier may want to make an additional charge for such work and will not guarantee any particular recovery time. From the supplier’s point of view, it becomes difficult to manage support if the client base is using several different versions of the software. Consequently, the supplier normally restricts support to the latest two versions of the software and will refuse to support earlier versions.

Charge increases – the client will want to ensure that the maintenance charges will not rocket up. One means of doing this is to tie the maintenance charges to a percentage of the list price of the software (e.g. 10–15 per cent) but, of course, the supplier has control over the list price. Alternatively, any increase in maintenance charges can be tied to a recognised index. Clients sometimes suggest the Consumer Price Index. However, suppliers (who know that increases in salaries are generally greater than increases in retail prices) prefer to tie them to an earnings index. There is some logic in this, as the bulk of the supplier’s expenses are salaries.

Payment arrangements – payment is almost invariably made three to six months in advance. This is so that if the supplier goes into liquidation the client will not have overpaid very much and the client can also swiftly withhold the payment of maintenance charges if there is a problem with the service provided.

Termination – it is important for the client to look at the termination clauses of the contract offered by the supplier. The client will want to know how much notice they have to give to end the maintenance contract. This is often three or six months. It is a good idea for the client to ask the supplier to commit on its part to supply maintenance (if the client wants it) for the potential life of the software (e.g. five years).

Contracts for software development

Software will often need to be customised for the client by the supplier. However, this is really only a tinkering with the main programs. In certain circumstances, it may be necessary for the client to commission new software because there is no existing software that meets the client’s needs.

Contracts for software development are complex and it is wise for the client to seek professional advice both about the specification for the software and the contract under which the software will be written. This is all the more important because software development projects have a reputation for taking longer, and costing more, than originally forecast. Consequently, background research by the client into the proposed supplier is particularly worthwhile. Pricing for the project will be either for a fixed price or for time and materials. Payments will normally be made conditional upon project milestones being reached. The client should seek to ensure the quality of the software product delivered by the supplier by requiring acceptance tests of the software and a warranty from the supplier that the product will be in accordance with the agreed specification.

A thorny question is whether the client should own the copyright in the software program produced. At first glance, it might be thought that this should obviously belong to the client who has paid for it. However, the client only needs to use the software, not to own or develop it. It may benefit the client if the supplier has an incentive to carry out further development of the software program and license it to other clients; the original client does not then pay the total cost of all the subsequent fixes and has the benefit of the faults reported by other users. However, if the supplier becomes insolvent, then the client needs access to the source code of the software in order to maintain it. For this reason, the client should require the supplier to put a copy of such source code in escrow with an independent third party so that it is available if required. The supplier will normally provide a warranty that defects in the software reported within a particular length of time after the start of its use will be rectified. This is frequently 90 days after acceptance of the software by the client.

Contracts for hardware purchase

Since computer hardware is so much more reliable than it used to be, contracts for the supply of hardware are not generally contentious. A hardware purchase contract requires the following details:

a detailed description of the hardware (this is likely to be in a schedule);

a warranty about the quality of hardware (normally this warranty applies for a year after acceptance of the hardware by the client);

delivery dates;

price;

acceptance testing;

future maintenance;

training.

Problems can arise if the hardware is not large enough for anticipated demand, and with the integration of hardware (such as servers and printers) that may have been supplied by different suppliers.

In many cases the cost of the hardware is not a large percentage of the total system cost. As profit margins on hardware are relatively low, the software supplier may be relaxed about whether the client obtains the hardware from the software supplier or from a third-party supplier. It is always worth asking the software supplier to quote for supplying the hardware as they may have better bargaining power than you would have on your own.

At the end of the day, the two most important matters in a contract for hardware are to check that there is an exact description of what you are buying and that there is an obligation on the supplier to repair or replace it if it does not work properly.

Contracts for hardware maintenance

Hardware maintenance is more of a commodity than software maintenance and there are likely to be more suppliers for the maintenance of hardware (and so prices are keener). There are two different types of hardware maintenance: preventive maintenance and corrective maintenance. Preventive maintenance covers the regular testing of the hardware (e.g. once every six months) before any problem is reported. Corrective maintenance deals with faults as and when they arise, normally in response to a service call from the client.

With corrective maintenance, the key element is the response time – how quickly will the supplier start to respond to the problem once it is reported? This is generally within a fixed number of working hours. For example, an engineer may have to arrive at the site no more than eight working hours after the problem has been reported by the client. This does not mean that the engineer will solve the problem within eight hours – merely that a start will be made to try to solve it. Sometimes online diagnosis is used: the client’s hardware is linked by telecommunications to the supplier who can solve the fault at a distance. (The impetus for online diagnosis came from the US, where the distances were so great it was often not practicable to send an engineer in person.)

Payment for hardware maintenance is generally made in advance on a monthly or quarterly basis. Other points that will normally be covered in a hardware maintenance contract include a right for the supplier to:

make an additional charge for frivolous or unnecessary call outs;

increase the charges from time to time, perhaps in accordance with a recognised index (such as the Consumer Price Index);

refuse to cover equipment that is more than five years old or is past its reasonable working life.

The client will be under an obligation to:

pay for corrections that are not caused by the equipment itself (e.g. faults arising from electrical fluctuations);

notify the supplier of problems promptly after they arise (so that time does not make them worse);

allow the supplier reasonable access to the equipment.

Service level agreements

Service level agreements (SLAs) are critical to the computer industry, but they are rarely fully understood. Under an SLA, a supplier undertakes to supply a service to a client at a particular level.

Perhaps because so few lawyers have a reasonable working knowledge of the computer industry, SLAs are often drawn up by the participants without legal advice.

A service level agreement should cover:

the service required (i.e. what the client wants and what the supplier is prepared to commit to supply);

quality standards (i.e. the standards or levels the supplier must achieve), such as host/terminal response times, batch processing times, ‘uptime’, or processor availability, by specifying what? when? how? and by whom?

deliverables (e.g. regular reports);

the consequences of failing to meet service procedures or standards (e.g. compensation in the form of service credits);

procedures for the client to monitor performance of obligations by the supplier;

procedures for change control (i.e. changing part of the service that is being provided by the supplier under the agreement);

terms dealing with access to, and security of, the client’s site and data;

procedures for disaster recovery (either upon a system failure or following a catastrophe);

the agreed frequency of meetings between the client and the supplier to review the supplier’s performance of the agreement, properly minuted with subsequent action plans and awards of priority.

Ideally, an SLA should be a self-enforcing agreement within a continuing relationship. There should be no need for either side to litigate and changes required should be dealt with through a change control procedure. For example, a clause may specify that any additional features requested by the client would require an extra cost to be paid to the supplier, and for this to be confirmed in writing by both parties. In some ways the process of creating the SLA is as valuable as the agreement itself.

What form should a service level agreement take?

SLAs can be between different businesses or between different parts of the same organisation (such as the IT department and its users). Facilities management agreements, software maintenance agreements and managed data network agreements are all examples of SLAs. Alternatively, the SLA may be one aspect of a larger agreement for services,