Skip to content
Skip to main content

About this free course

Download this course

Share this free course

Software and the law
Software and the law

Start this free course now. Just create an account and sign in. Enrol and complete the course for a free statement of participation or digital badge if available.

5.2 Contract analysis

When hardware is supplied it is usual for the purchaser to be the owner of that hardware, as with any other physical property. However when software is supplied the property rights to it may not be bought, merely licensed, with ownership remaining with the supplier or whatever other party supplied the software. Only in the case of bespoke development might the intellectual property become the purchaser’s, though even then the agreement might entitle the supplier to further develop the software and sell it to other clients where this does not lead to loss of competitive advantage for the original purchaser. The details need to be spelled out in the contract.

Software or hardware would normally be given a warranty during the period of which any defect identified after delivery would be remedied free of charge. In the case of hardware the warranty period may be one year, but for software it may be significantly shorter. A warranty period of just three months is far too short a time for many defects to have arisen (such as those related to large volumes of data that build up only over several years), let alone to be demonstrated unambiguously. Software supply contracts would usually be followed by maintenance contracts.

In any case involving the supply of goods or services there always is the danger that the supplier goes out of business, and the contract should include clauses about what would happen then. In the case of the supply of software – especially where this involves continued maintenance – or of licensing a useful fallback position would be to have access to the software’s source code so that alternative developers and maintainers could be found. This can be arranged through an escrow agreement, whereby it is agreed that a copy of the source code will be held by some third party – perhaps a bank – and be released to you should certain conditions arise, such as bankruptcy of the supplier. The escrow clause would normally also require that the supplier place new releases in escrow so that the latest copy is always available should the need arise.

Payment for products or services under a contract are typically staged so that some initial payment is made, and followed by further payments at key milestones in the project, such as delivery of hardware and then its commissioning or, for software, at the time of agreement of functional requirements or of delivery of software into alpha trials. Payments may be for time and materials, covering costs, perhaps with a small allowance for profit in a ‘cost-plus’ contract. However, in order to avoid cost escalation the contract may specify a fixed or maximum acceptable cost as a ‘limit of liability’. With fixed cost the supplier takes most of the risk relating to time or cost overruns, whereas with maximum acceptable costs the customer takes some of this risk, up to the ‘limit of liability’, with the supplier assuming the risk for any cost overruns beyond this limit.

Other standard clauses may also need to be included in the contract. You may need to declare that the only agreements in force are those in the contract – that the contract constitutes the entire agreement. Some things can go wrong for which the parties to the contract cannot be held responsible, such as flooding destroying the supplier’s premises – a case of ‘force majeure’ – and what happens in such a case needs to be covered in the contract. If dispute should ensue it is important to declare which legal system should apply – the jurisdiction for any settlement of a dispute. In some cases it might be appropriate to include a restraint on trade following the contract – for example, to prevent a supplier or employee working for a rival company for a specified number of years.

Because setting up a contract may take a considerable time, and work typically needs to start immediately, it is common practice for a purchaser of goods or services to issue a letter of intent, indicating that a contract will be issued but work can begin beforehand. However, it is important to make such work subject to contract, so that when the contract has been agreed and signed, this is the only document that counts.

Prior to the letting of a contract there is likely to have been a tendering stage, during which potential suppliers responding to the tender may have invested a considerable sum – perhaps as much as 10 per cent of the contract value – developing partial solutions to the requirements of the contract. It is important that if you are tendering you take steps to protect this investment – it has been known for designs proposed by one tenderer to be given to another tenderer for implementation in the contract, with the creator of the designs receiving no recompense.

Now complete Activity 5.

Activity 5: Contract analysis

Take any one of the contracts for supply of software or software-related services listed at Red Hat Agreements [Tip: hold Ctrl and click a link to open it in a new tab. (Hide tip)] , and analyse it in terms of the issues described above. Does your chosen example grant unreasonable powers of termination to the supplier? Is the purchaser of the software protected should the supplier go out of business?

Discussion

You can see some of the standard contract elements in the examples we have given in the case studies above. If you can, get hold of the complete contracts – you will find clauses about jurisdiction and entire agreement, and about termination of the contract from the supplier’s end. However, you may not find any escrow protection or favourable clauses for termination by your side.

Contracts need to be carefully drawn up to protect the interests of all parties across a range of contingencies.