Writing Homework Help

Week 5 Discussion: Prior Art

For this discussion, we will be focusing on the relationship between contract law and intellectual property law. Read through the assigned chapters for this week in a Manager’s Guide to IT Law. The reading provides an overview of the process of writing a contract. Sometimes when it comes to intellectual property ownership of a produced work may be split between multiple entities in proportion to their contribution towards the work. The “work” can be any type of patent or
In the scenario for this discussion, you will be reviewing a sample intellectual property contract between a university employee and the university regarding ownership and rights of an intellectual-property work. The contract lays out four different types of scenarios regarding how the work was created and you are asked to fill in the blanks for each scenario regarding who and how the work should be owned. In particular, read through the contract and focus on the yellow highlighted portion in each section and answer how you would fill in the blank.

1.      Independent Work
a.       ____ year(s) following the termination of Creator’s employment with the University.
2.      Work Created with Minimal University Support
a.       ____ year(s) following the termination of Creator’s employment with the University.
b.      During employment, ownership equity of the Work shall be shared between the University and the Creator with ___% possessed by the Creator and ___% possessed by the University
3.      Work Created with Substantial University Support
a.       In exchange for the substantial support provided by the University it is understood and agreed that the University and Creator shall share equally in the ownership of such Work for a period of ___ years.
4.      Work Commissioned by the University: (pick one)
a.       (___) 100% ownership and equity to the University for the life of the copyright or patent protection provided by law, or:
b.       (___) ____% ownership and equity to the University and ___% ownership and equity to the Creator for ___________ (period of time).

After filling in the blanks to describe how you would divide up the work and for how long in each scenario explain why chose to divide it up in the way that you did. In your two responses to your peers, respond to your peer’s analysis and response, and discuss how they are both similar and different from yours. Follow up with your own post regarding the same.

A Manager’s Guide to IT Law, Second Edition

Chapter 1 – IT Contracts

Chapter 1: IT 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 all of the chapter, the appendix to this chapter 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 must 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
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. A list of the more important boilerplate clauses is shown in the box.

IMPORTANT BOILERPLATE TERMS

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 etc. This is likely to be invoked by the supplier more than the client. This clause effectively absolves the supplier from responsibility, so the

forget we are engaged in contract first aid here. If all else fails, concentrate on what the supplier is going

 

circumstances in which it can be invoked should be checked carefully to ensure that they are no wider than is reasonable.

Entire Agreement – this says that the entire agreement between the parties is set out in the written

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 25 years ago). 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 a rational decision 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 because this will only lead to worry and tears later.

LETTER OF INTENT

The supplier may ask for a letter of intent from you because it 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. Alternatively, you may like to suggest one so that you are not pressurised into signing the contracts before you have gone through 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 the letter of intent from you to the supplier must contain a statement 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. The first is the rate for the job (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 other is an overall cap on your liability 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

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 start and amend them to your satisfaction. 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.

WHAT CONTRACTS ARE THERE LIKELY TO BE?

Any computer system will require the purchase of hardware (e.g. servers, PCs, printers etc.), software (the application software and the operating system software) and services (such as support and maintenance). When computers first started to be widely and routinely used in business life about 30 years ago the emphasis was very much on the hardware, which was comparatively unreliable. Nowadays the emphasis is much more on the software and services. It is normal to decide upon the software first and then to choose the appropriate hardware. If the contract relates to the procurement of a new system, the reader is referred to Chapter 2. The rest of this chapter deals with the purchase or licence of individual services or components.

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 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 there is a need for 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. This 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 and confidentiality 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 goes almost without saying that the consultant should be obliged to keep confidential any information given by the client about its business. 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).

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 also that 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 because, 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.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 Hardware PurchaseComputer hardware is much more reliable than it used to be, so 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 ofthe 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), which 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. Profit margins on hardware are relatively low, so 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 because 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 MaintenanceHardware maintenance is more of a commodity than software maintenance and there are likely to be more alternative 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 USA 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. The annual amount varies but can often be between 10 per cent and 15 per cent of the list price of the hardware. 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 theConsumer Price Index); and
• refuse to cover equipment that is more than five years old or which 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); and
• allow the supplier reasonable access to the equipment.Contracts for Software LicencesAt 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 can not use it any more or that you have got to pay more money. It follows, therefore, that one of the first checks that 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 who 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 (see Chapter 6). Consequently, provision for the transfer of the licence from the client to an outsourcing company should be made in the original software licence agreement.

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 and so 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 because 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.
• 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 a number of 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 because the bulk of the supplier’s expenses are salaries.

• Payment arrangements – Payment is almost invariably made in advance. In the past, it was for a year, but now it is more commonly paid three months or a month 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 DevelopmentSoftware 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 for 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 fixed price or time and materials. Payments will normally be made conditional upon project milestones being reached. The client will 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, all the client needs is to use the software; the client needs neither to own it nor to develop it further. There is a benefit to the client in the supplier having 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. 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 (see Chapter 5). 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.Service Level AgreementsService 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 following:

• 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 responsetimes, batch processing times, ‘uptime’ or processor availability, by specifying what? when? how? andby whom?
• Deliverables (e.g. regular reports).
• The consequences of failing to meet service procedures or standards (e.g. compensation in the form ofservice 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 supplierunder the agreement).
• Terms dealing with access to, and security of, the client’s site and data.
• A procedure for disaster recovery (either upon a system failure or a catastrophe).
• The agreed frequency of meetings between the client and the supplier to review the supplier’sperformance 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. In some ways, the process of creating the SLA is as valuable as the agreement itself. 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, that is it may be the schedule that stipulates how well the services have to be provided and what happens if the supplier does not provide this.What Form should a Service Level Agreement Take?At its weakest, an SLA may be a simple oral understanding, documented by an exchange of letters. The best form is a formal legal agreement with the technical procedures and specifications annexed as separate schedules.What Happens if the Terms of a Service Level Agreement are Broken?If the breach is fundamental, the party not in breach will be entitled to terminate the agreement and sue for the loss suffered as a result of the breach. In other circumstances there will be a system for measuring breach and apportioning cost. These systems range from an event-based system (i.e. if… then…) to a more sophisticated system of ‘failure points’ (i.e. if there are more than five examples of… then…). The functions of such compensation systems vary from simply drawing attention to a problem to compensation for loss. Compensation for loss is difficult to quantify and, if it is excessive, will be unenforceable by a court. In practice, the right to withhold payment is a valuable weapon. The end (or slowing down) of payments by the client into the supplier’s accounts department is likely to put pressure on the supplier. Escalation clauses are undervalued and should be more widely used. These provide for a problem to be escalated up the various tiers of management on both sides if it cannot initially be resolved. Even the best SLA does not last for ever and there must be a procedure for orderly termination and (if necessary) migration from the supplier’s system to another system.The failure to include such clauses was a frequent weakness of early SLAs. Migration is critically important in relation to facilities management contracts and, as a rule of thumb, a year is generally allowed for this. The

supplier should also be required to provide all reasonable assistance to the client with the migration to another system.

Contracts Relating to Cloud Computing

Cloud computing is sometimes called software as a service. It appears set to revolutionise the computer industry over the next few years. See Chapter 10 for a description of what cloud computing is and the contracts that you are likely to need.

APPENDIX: MAIN POINTS OF AN IT CONTRACT

Read this on its own if you have not got enough time to read the rest of this chapter. But read it carefully.

• Make sure that you know exactly what you want and what is achievable because if you do not know, then you are not going to get the contract right. (Among the most common causes of computer project failure are unclear client requirements and unrealistic client expectations.)
• Make sure that all the prospective suppliers sign a confidentiality agreement with you. If you are going to give them a detailed functional specification of what you want and information about your business you do not want there to be any question of that confidential information being obtained by your competitors.
• Beware of falling into the trap of entering into a contract before you intend to. There are no legal formalities in this country about entering into a computer contract, so make sure that all pre-contract correspondence is headed ‘subject to contract’. If you leave discussions about a written contract incomplete (e.g. lots of draft contracts sent between you and the supplier but nothing ever signed), then a court is likely to take the last undisputed draft as being the basis of the contract between you and the supplier.
• If a particular point is important to you make sure that you get it in writing from the supplier. It may well be that an aspect that is critical to you 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, possibly, included as a schedule or as an attachment. If the supplier drags its 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.
• Make sure that you get the supplier to agree to supply support and maintenance for the products purchased for a decent length of time (e.g. 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.
• • Make sure that you order enough training. One of the most common reasons for the failure of a computer project is inadequate training. It is sadly all too common that, if there is an overspend in other areas, the amount budgeted for training is cut. As a rule of thumb, roughly 20 per cent of a project‘s cost should be spent on training. If it is substantially less than that you should ask why.
• • 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.

• • Make sure that you can get access to the source code of the software programs supplied if the suppliereither goes into liquidation or stops supporting the software. Ideally, this source code should be deposited with an independent third party (see Chapter 5) and kept updated by the supplier as each new version comes out.
• • Finally, never forget that the contract is a delivery mechanism for ensuring that a project is completed in the right way at the right time by the right person and for the right price. No more, no less

Chapter 2 – Systems Procurement Contracts

Chapter 2: Systems Procurement Contracts

Jeremy Newton

Terms like ‘computer contract’ or ‘system procurement contract’ cover a broad range of commercial transactions, from the purchase of a single CD-ROM from a high street retailer through to multimillion pound agreements for consultancy or outsourcing services. This chapter outlines the legal issues that need to be addressed in any contract of this type, using examples from actual case law to illustrate the kinds of dispute that commonly arise in relation to systems procurement, and discusses how the process of drafting and negotiating the agreement can be used to prevent some of the most common problems.

THE NEGOTIATION PROCESS

The function of a written contract is to record the terms governing the supply of goods and services. In the absence of a clear, express understanding between the parties, certain terms may be implied into the contract as a matter of law, for example, that products will be delivered within a ‘reasonable’ time and that they will be of ‘satisfactory’ quality. The main terms that can be implied into a contract as a matter of law are summarised in the box.

TERMS IMPLIED BY LAW

Certain terms may be implied into a contract as a matter of law: this means that the contract will include these provisions automatically, unless the parties expressly agree to exclude them. The main implied terms are summarised below.

Title – All contracts of sale include an implied term that the seller has the right to sell the goods in question (Sale of Goods Act 1979 s.12(1)). If the seller fails to transfer ownership (e.g. because the goods are subject to the rights of some third party, such as a bank), then it will be in breach of this term and the buyer may reject the goods and recover the price, plus damages.

Quiet possession – This right is, in effect, a promise by the seller that no person will in the future acquire rights over the goods and enforce them against the buyer (Sale of Goods Act 1979 s.12(2)). If this should happen (e.g. because the use of the product turns out to infringe some third-party intellectual property right), then the buyer will be entitled to claim damages. In the worst case, where the third party exercises its rights in such a way as to prevent the buyer using the goods at all, the buyer’s damages will be assessed as the cost of buying a replacement, in effect returning the original purchase price.

Correspondence with description – Goods must correspond with the description given by the seller (Sale of Goods Act 1979 s.13). This description can take many forms: a standard printed specification, an agreed user

requirements specification, and even claims made by the sales force or set out in the manufacturer’s publicity material.

Quality and fitness for purpose – Goods must be of satisfactory quality and reasonably fit for their purpose (Sale of Goods Act 1979 s.14). ‘Satisfactory quality’ means that the goods meet the standard that a reasonable person would regard as satisfactory, taking account of any description of the goods, the price (if relevant) and all the other relevant circumstances.

Reasonable care and skill – The law also implies a term into contracts for services (such as consultancy, development or support), to the effect that the services will be provided with reasonable care and skill (Supply of Goods and Services Act 1982 s.13).

Apart from the above terms, which are implied as a matter of statute law, terms may also be implied from the facts and circumstances of the particular contract, if they are necessary to give ‘business efficacy’ to the contract.

However, given the vagueness of the implied terms and the unpredictability of their legal interpretation, any prudent buyer or seller of IT systems will prefer to ensure that the parties’ intentions are recorded as clearly and unambiguously as possible.

The negotiation process that leads to the written contract should help ensure that the parties understand each other’s expectations and commitments.

Many IT projects fail precisely because the parties do not exercise sufficient care to ensure that their expectations match, and often because of an uncritical acceptance by the customer of the supplier’s standard terms of business (or indeed, by the supplier of the customer’s standard procurement contract).

Any well-drawn contract will have provisions relating to three broad categories of expectation. The aim of the negotiation process is to ensure that no essential terms are missing from the final agreement, and this chapter will address each of the categories in turn:

• Contract mechanics – who delivers what, and when?
• Commercial highlights – what is the price, who owns the resulting intellectual property rights, andwhat warranties are given in respect of the system?
• Problem management – what happens if the project goes wrong and what remedies are available?BEWARE THE STANDARD CONTRACTThe dangers of agreeing unquestioningly to the standard supply terms (or, for that matter, to a client’s standard terms of procurement) are illustrated by the case of Mackenzie Patten v. British Olivetti.A law firm bought an Olivetti computer system to run their accounts. They discussed their needs with the salesperson and signed up to Olivetti’s standard terms. These dealt only with the system’s technical performance: they did not address certain other important issues that had been discussed between the parties.

In the event, the system proved unsuitable for the firm’s purposes: it was slow, difficult to use, and could not expand to cope with new business, but none of these matters was dealt with in the written contract. Even though a court found that Olivetti was bound by its salesperson’s claims that the system would be suitable for the law firm’s needs, the firm had by that stage expended significant time and money in the litigation and still had to find a replacement system.

Put another way, ‘standard’ forms are only suitable for entirely ‘standard’ transactions, and will often fail to address some essential point that the parties had in mind for their particular deal.

CONTRACT MECHANICS

Principal Obligations

An IT contract need not be a complex document. It does not even need to be in writing, though a written document is clearly desirable to record fully each party’s commitments to the other. In the simplest case, however, a written contract need say no more than this: that the supplier will provide a system X computer to the client; and that the client will pay £Y to the supplier.

That is the essence of the commercial relationship and there is nothing else (from the strict legal point of view) that requires to be said. However, if the aim of the contract process is to ensure that the project goes ahead smoothly and with the minimum scope for disagreement between the two sides, the contract should be considerably more specific in terms of what is being delivered, when and how.

Specification

A clear specification is the foundation stone of a successful systems supply contract. Although the law implies a term into a contract that the system will conform to its description and be of satisfactory quality, this is no substitute for ensuring that the supplier and the client agree (and document, in as detailed a manner as possible) exactly what is to be provided and the performance and quality standards to be achieved.

Every system supply contract should, accordingly, include a detailed specification setting out:

• the required functionality (what the system is required to do);
• performance targets (how well it is supposed to do it);
• compatibility requirements for interfaces with other systems.The Need for a Formal System SpecificationThe legal implications of not developing a proper specification are illustrated by the case of Micron Computer Systems Ltd v. Wang (UK) Ltd.One of Micron’s complaints against its supplier was that the Wang system did not provide ‘transaction logging’.The judge observed that ‘the acknowledged absence of a transaction logging facility is not in reality a fault in the system that was sold. Micron can only complain about its absence if Micron can establish a contractual term … to the effect that the system included such a facility. In order to make good its case in transaction logging, Micron must therefore establish that they made known to Wang that they required such a facility’.

The judge found that Micron had not made its requirement for transaction logging clear to Wang and accordingly that part of Micron’s case failed.

Timetable

The process of preparing the specification should enable the parties to assess the likely timescale for the project and to prepare a project plan setting out key deliverables (or ‘milestones’) and their expected dates. In almost all major systems implementations, staged payments will be triggered by the achievement of individual milestones. It is, accordingly, essential that these are identified with as much precision as possible and generally reflect the terminology of the contract.

The buyer will usually have in mind a timescale within which the system should be provided, although the sophistication of the timetable will vary according to the complexity of the project and how closely the payment arrangements are tied into the achievement of specific milestones.

Delivery

Although the law provides for an implied term that goods will be delivered ‘within a reasonable time’, deliveryarrangements should always be dealt with expressly. From the point of view of contractual certainty, the ideal approach is for the contract to set out specific delivery dates, but it should also go on to deal with the ‘mechanics’ of delivery and installation. The contract should address:

• the date on which delivery is to be made;
• whether all the elements of the system are to be delivered at one time or whether it is to arrive ininstalments;
• who has responsibility for installation and testing;
• the implications of late delivery or non-delivery (e.g. an express provision permitting cancellation of thecontract, with or without compensation to the buyer, if the goods are not delivered by some cut-off date or if some other key milestone is not achieved by the required date).Acceptance TestingFormal acceptance testing arrangements are a crucial aspect of any successful procurement. The system is required to meet the functions and performance targets set out in the specification, but until it is tested the parties can not determine whether those requirements have been met.The nature of acceptance tests varies widely between projects. Where a major piece of development work is involved, the parties may negotiate and document detailed testing arrangements as part of the contract. At the other extreme, the acceptance procedure may simply be that if the buyer uses the system ‘live’ for, say, 30 days without rejecting it, then it is deemed to have been accepted.From the point of view of creating contractual certainty, then, the acceptance procedure should:
• provide for an objective and measurable ‘yardstick’ as to the standards of performance and functionality to be demonstrated;
• address all those elements that are necessary to demonstrate, to the buyer’s satisfaction, that the system meets its requirements; and

• be clear as to the consequences of both the passing and failing of the acceptance test.

Acceptance will generally trigger payment of the whole or the final instalment of any lump sum charges, or the start of periodic charges, and following acceptance the buyer’s remedies will be limited to a claim under the warranty provision.

In the event of failure of the acceptance tests, the contract will typically provide for a period during which the supplier may rectify problems and then retest; but further failure will signal the premature end of the contract, with the buyer able to return the hardware and software in exchange for a refund of any money paid.

Client Obligations

The successful implementation of a complex IT system normally requires the performance of obligations not just by the supplier, but also by the client. Although primary responsibility for providing a system rests with the supplier, the client may well have obligations in relation to providing information about its business, testing the software, providing employees to be trained and so on.

These obligations need to be spelled out in the contract every bit as clearly as the supplier’s commitments.

Change Control

Client requirements may change frequently over the lifetime of a project. The parties need to agree a procedure for specifying and agreeing changes to the scope of work. The proper management and documentation of these changes will help to avoid disputes about what each party’s obligations actually were.

The contract should include a formal ‘change control’ clause, setting out a mechanism whereby the client can request (and the supplier can recommend) changes to the specification, the project plan, or any other aspect of the deal. Any such change needs to be considered from the point of view of:

• technical feasibility;
• impact on the respective obligations of the supplier and client;
• cost implications;
• impact on the timetable.As a general rule, no change should take effect unless it has been formally agreed and documented by both parties.TerminationProvision has to be made for termination of the contract, setting out the circumstances in which the contract may be brought to an end and the consequences of that action. These provisions will vary according to the nature of the contract and the deliverables.Apart from a general right to terminate the contract in the event of material breach or the insolvency of the other party, the following points should be considered:
• The client may wish to reserve a right to cancel or terminate the contract for convenience (say, because its business requirements change). In that event, the parties will need to discuss what compensation (if any) should be payable to the supplier.
• Contracts for development services are typically terminable by the client if specific time-critical milestones are significantly overdue. Provision should be made for treatment of the developed software on termination, including delivery of all copies (and source code) and certification that no copies have been retained.
• Contracts for continuing services (consultancy, support and maintenance services, bureau services) should be terminable on notice. The length of the notice and the earliest dates on which it may be effective are matters of negotiation in each case.COMMERCIAL HIGHLIGHTSPricing and PaymentThere are as many pricing and payment structures as there are types of IT deal, and there is little to be gained from making generalisations about pricing and payment terms. The one point worth making is that, where payments are tied into specific targets (such as system acceptance or other milestones), the terminology and structure of the payment schedule should accurately reflect that of the timetable.There are several payment-related mechanisms that are commonly used to ensure that both parties have incentives to perform their obligations:
• The client may wish to provide for payment by instalments as the various parts of the system are delivered, retaining a proportion of the price until the complete system has been tested. The retention of a significant proportion of the charges will give the buyer some assurance that the supplier will finish the job.
• In respect of periodic fees, specifically, the buyer will be concerned about the supplier’s rights to increase the fee and may seek to limit rises by agreeing to, for example, only one increase a year or by tying increases to an appropriate index.
• It is common for hardware suppliers to retain title in the goods they supply as security for payment. This means that although the buyer gets possession of the goods, ownership remains with the seller until certain conditions (normally payment in full) are met. If the buyer fails to comply with the conditions, the seller can repossess the goods and sell them to recoup its losses.Intellectual Property Rights (IPRs)System supply contracts generally entail the transfer of technology and information from one party to another, for example, specifications, software, data and confidential business information. The lawful use of technology and information depends on compliance with the laws relating to copyright, confidentiality, database rights and other forms of intellectual property (see Chapter 4), so system supply contracts must deal comprehensively with IPR issues. There are two key IPR aspects to consider: ownership, and warranties and indemnities in respect of third-party IPRs.In relation to ownership, the contract should specify what IPRs are to be created or used, and precisely who owns them (including identifying the owners of any third-party IPRs that are to be used or licensed). Copyright law contains a common trap for the unwary in relation to contracts for software development or consultancy

work. The IPR in work undertaken by a contractor (as opposed to an employee) will normally vest in the supplier rather than the client. This means that an express, written assignment of copyright is needed if the aim is for the client to own these IPRs outright.

In relation to ownership, the contract should specify what IPRs are to be created or used, and precisely who owns them (including identifying the owners of any third-party IPRs that are to be used or licensed). Copyright law contains a common trap for the unwary in relation to contracts for software development or consultancy work. The IPR in work undertaken by a contractor (as opposed to an employee) will normally vest in the supplier rather than the client. This means that an express, written assignment of copyright is needed if the aim is for the client to own these IPRs outright.

In relation to warranties, most system supply contracts will contain an assurance that the client’s use of the system will not infringe third-party rights and an indemnity in respect of any claims that may arise against the client. The contract should set out any express warranties required by the client as to the supplier’s ownership or entitlement in respect of the IPRs comprised in the system, together with a process for addressing any breach of those warranties.

In relation to the possible infringement of third-party IPRs, the client will typically impose a formal obligation for the supplier to deal with any such allegations, especially if the system is a critical part of the client’s business and merely rejecting it and claiming back the purchase price would be insufficient. A typical IPR indemnity clause will provide:

• a right for the supplier to take over, litigate and/or settle any such action;
• a right for the supplier to modify the system so that it does not infringe the alleged right, provided that itstill conforms with the specification; and
• an indemnity given by the supplier against the client’s losses in the event of a successful third-partyclaim.Supplier WarrantiesThe client will normally require the supplier to give certain other express assurances in respect of the system to be delivered. Ideally, the client will want to obtain a warranty that the system will comply with its specification and/or meet specified performance criteria.Such warranties are often subject to time limits or other restrictions. It is not unusual for the supplier to seek to limit the warranty to, say, six months from acceptance: after that point, any defects are rectified under maintenance and support arrangements (paid for by the client) rather than under warranty.PROBLEM MANAGEMENTContractual RemediesThe parties must consider at the negotiation stage what happens if a contract does not go according to plan, for example if the supplier fails to deliver a working system within the contracted time frames. Although damages and other remedies may be available as a matter of general law, it is preferable to spell out expressly the remedies that each party may have in particular situations.

One common mechanism for managing such disputes is to provide for payment of ‘liquidated’ damages for certain breaches. This involves setting out in advance the precise sum to be paid as compensation for certain breaches (e.g. late delivery at £X per day). Provided that the sum is a genuine estimate of the likely losses and not a penalty to force the other party to perform, the clause will be enforceable.

If the breach in question persists for a specified time or reaches a specified level of severity, the innocent party may also want a right to terminate the contract outright.

Limitations and Exclusions of Liability

IT suppliers generally seek to restrict their potential exposure to actions resulting from breach of contract or defects in the system. This is treated by some as purely a ‘legal’ issue, but in fact is a major question of commercial risk assessment and allocation, and these provisions can be amongst the most hard-fought in any contract negotiation.

A typical standard exclusion clause may take the following form:

• The supplier does not exclude liability for death or personal injury caused by negligence.
• The supplier seeks to exclude liability altogether for certain kinds of loss, often termed ‘special’,‘indirect’ or ‘consequential’.
• The supplier accepts a limited degree of liability for certain other classes of loss.From the legal point of view, exclusion clauses need to be considered from two broad angles. First, suppliers will often argue that they should have no liability for ‘consequential loss’, on the basis that the nature of IT products means that their uses (and so the potential losses resulting from failure) are not easily foreseeable at the time the contract is made and the potential exposure is in any case disproportionate to the contract value. Whether this is an acceptable commercial stance depends on the nature of the system and the extent of the client’s dependence on it. However, the courts have exercised considerable ingenuity in manipulating and interpreting expressions like ‘consequential loss’ in ways that the parties may not originally have intended.CONSEQUENTIAL LOSS: THE SEMANTIC LABYRINTHAlthough they are commonly used in all sorts of commercial agreements, the meaning of the expressions ‘special’, ‘indirect’ and ‘consequential’ in the context of contractual claims is open to interpretation by the courts, and there is often a resulting lack of certainty as to the precise effect of an intended exclusion.The usual starting point for any discussion of consequential loss is the case of Hadley v. Baxendale. In that case, the court distinguished two classes of loss that could be recovered for breach of contract. These are:
• Such losses as may fairly and reasonably be considered either as arising naturally, that is according to the usual course of things … or such as may reasonably be supposed to have been in the contemplation of both parties at the time they made the contract as the probable result of the breach of it.
• If the parties were aware of special circumstances at the time the contract was made, the losses which they would reasonably contemplate would be the amount of injury which would ordinarily flow from a breach under these special circumstances.

That basic distinction has been reworked several times over the years, but the terminology that is widely used in IT contracts does not fit neatly into the Hadley v. Baxendale rules and in fact means different things to different people. Indeed, the courts are repeatedly restating the meaning of these expressions in an effort to bring clarity to the concepts, but two cases will illustrate the kind of semantic problems that can arise.

In the 1999 case of British Sugar Plc v. NEI Power Projects Ltd, NEI had supplied some defective power equipment, with a headline value of about £100,000, to British Sugar. The sale contract expressly limited the seller’s liability for ‘consequential loss’.

As a result of breakdowns, increased production costs and resulting loss of profits, British Sugar put in a claim of over £5 million. British Sugar argued for the narrowest construction of the term ‘consequential loss’, interpreting it to mean ‘loss not resulting directly and naturally from breach of con