§12.0 Introduction

No matter what you subsequently do to earn your living, you are going to be affected by the question of contracts to do this, that or the other

• Contracts form the basis for almost all defined activity
  - as a very simple example, there is no job (or shouldn't be!) without a contract of employment.

• You are going to need clear definitions of the systems you are required to produce

• Even now, you are bound by the opposite of this, in terms of the licences under which you use things like Word or Netscape or Windows.

There is clear guidance on this, essentially from an ethical viewpoint, in professional codes like BCS' code of practice (do well what is relevant) and code of conduct (pay attention to your wider responsibilities), which we discussed in Chapter 6

• And, as a professional, that advice will help to guide you ...

  ... but it doesn't bother the cowboys in the fields of software and hardware design, with whom you will alas have to deal

So ... what should you do?

• Firstly, ensure you have an adequate background in this general area
  • At the very least, read and think about the contract material in the text book by Bott, Coleman, Eaton & Rowland

• Secondly, treat with care things like the licences which accompany most software packages!
  • Read them and put a sensible interpretation on what they say!

• Thirdly, if you are involved in the preparation or signing of a contract, then hire a lawyer!

Having said all that, what are the principal issues?

§12.1 Introduction - UK View

Remember, these notes are prepared by a computer scientist in the context of a computer science lecture; they are not from a lawyer!

Contracts can be written, or oral

• So, beware: an obligation can exist even without a formal contract
  which means that carelessly given, casual advice can land you in trouble
  • For a professional computer scientist to give incompetent computing advice is tantamount to professional negligence, no matter how casual the circumstances under which the advice was given

  • If blameworthy over this, you could be sued, as in section 12.3 below!

What forms a contract? Hm! The key question!

• Under English Law, there must be a financial consideration,
  which is to say, something must change hands in each direction - usually the goods and a payment

• But that is something not necessary in Scots law

So the relevant legal system matters!

Under many circumstances, you can get away with the use of a standard contract

• Where only minimal changes from some standard are required for each re-use
• This is excellent computer science practice, but unfortunately a potentially dodgy legal one!
  • Nonetheless, used with care the concept can be very successful

• When you can't capitalise on a standard contract, then it's back to basics, and you'll need to provide for at least all the items referenced in the next section.

§12.2 Essential Contents

When a contract is being drawn up, you will need clauses to give suitable definition in each of the following areas. So, with appropriate legal advice you need to consider:

• Between whom is the contract being made?
  • Who are the parties to the contract?

• What documents make up the contract?
  • A clear and unambiguous list is wise!

• What is required?
  • What is the contract actually about? A short summary can be helpful, provided careful attention is given to the following related points

  • The relevant Requirements Specification must be unambiguously referenced, for example by version number and by date

  • What exactly are the deliverables?
    • Class 52 222 Programming Project introduces the idea of deliverables, where what is required for submission for the class is development and testing documentation, as well as the actual code and a user manual

    • But how about issues of staff training? Of subsequent support? Of maintenance?

• When the contract is completed, who will own the various intellectual property rights in the completed system?
  • Will the contractor be free to re-use design and code ideas elsewhere? Or the client or customer free to reproduce the software?

• What issues of confidentiality are involved?
  • In part this relates to the previous question - but only in part!

• Payment terms?
  • After acceptance testing? Or installation? Or delivery? Or are stage payments involved?

  • If they are, what is the basis of calculation to be?

• What obligations are placed on the client or customer?
  • For example, the provision of data for initial analysis, or for ongoing testing?

  • Or the provision of particular hardware facilities on which to deploy new software?

• What standards are to be used in the system? For measuring progress? At final acceptance?
  • The issue of the standards to be deployed in the development of software and computing systems is an important one. Sometimes the standards to be used are defined within the range of the International Standards Organisation (ISO). There are, for example, later classes concerned with the questions of evaluating software and with the special requirements of high integrity systems. Some of these standards are industry specific, others are more general in nature.

• Warranty - indemnity - future maintenance?

• Arbitration and possible termination?
  • Despite everyone's best efforts, something about the contract - or the work being undertaken under it - may go wrong. Before you start, agree how you are going to handle that scenario.

• Penalty clauses for incomplete or late achievement?
  • These look attractive, for the contractor as a way of demonstrating confidence, for the purchaser as a form of guarantee; but often they do more harm than good, simply diverting effort and money into a consequential legal battle.

  • Any penalty clauses must be reasonable in the context of the project as whole. More to the point - can they really be enforced?

• Which is the relevant legal system?
  • As a general rule, whenever you can, use the legal system which is local to your own base.

All these are points which require a well considered position, and one which is clearly and unambiguously expressed - and there may be other points appropriate to your particular pieces of work. If you have any doubts about the desirability of clarity, read again the licences you hold for some of the software deployed on your own computer!

§12.3 When Things Go Wrong

When a contract goes wrong, there are essentially two legal ways to gain recompense

• On the grounds of breach of contract (in its many sub-variants)
  • where financial damages will be limited to the relevant loss

  • that is, the loss which is implicit in contract
    • so, if you are the supplier, be very aware what the contract really means to your customer

    • and, if you are the purchaser, ensure your supplier really is aware of the importance the software or whatever has for you!

• Or on the grounds of negligence in the work done
  • where the damages, the compensation, will be restricted to whatever is required to put you back where you would have been without the negligence.

In legal Latin these two are respectively "ex contractu" and "ex delictu"

• And, if the situation needs a legal tag, then you need a lawyer!

You must understand the interplay between technical computer science issues and associated legal ones ...

... but be very wary about believing (unless you really do have relevant education and knowledge in both areas) that you understand both the law and the computer science!