Technology Contracts Decrypted: Part 2

Last month, Saleem Ashrafi Adam of Trowers and Hamlins covered the concept of what Information Technology (IT) contracts were and took us through what IT law is and some interesting issues surrounding IT-related contracts. More particularly, he focused on the fundamentals of a contract, giving advice to the procurement division of a company on the safeguards it should adopt to avoid accepting the standard terms of any a supplier. He also addressed the pre-tender stage of high value IT contracts and what customers should be doing to ensure they got the best deal, for example, allocation of risk in instances of failure was discussed in considerable length. This article, the concluding part of the two-part series, focuses on the establishment of a service-level agreement and a service credit regime, the implications of failure and the crucial concept of intellectual property rights in IT contracts.

Service Levels and Service Credits
Scenario from Part 1:

A new insurance company, intending to launch operations on March 1 in order to establish itself in a new market, launches an advertising campaign as a run up to the launch date. Its Billing Supplier knows this as the former’s project plan states that the billing system has to be live by March 1. But, the Billing Supplier has a problem and wants the launch date to be put deferred until April 1. Should the Billing Supplier be liable for wasted advertising costs? And should it be liable for any potential lost business?

If the new insurance company’s answers to the above questions are ‘yes’, then it will need to make sure that there is a clear Service Level Agreement (SLA) and service credit regime included in its contract with the Billing Supplier. When defining an SLA, the new insurance company should consider the following:

- The SLA should contain a clear and agreed list of the services that will be provided to the insurance company by the Billing Supplier. The new insurance company should insist on clear and associated obligations to ensure that the services are supplied to an agreed quality and standard. For example, a clause like “services shall be provided to the Billing Supplier’s best endeavours” means little. If the parties to a contract do not know what such a clause means, then they should not leave it to the courts to interpret it for them.

- The SLA should also explicitly and clearly contain a description of the services that will have to be delivered by the Billing Supplier. The new insurance company should also ask itself the following questions:

What services will be provided and how will quality be measured (Quality Control)? What is the permitted deviation from quality control and what are the means to quantify this deviation?

What time-scales are allowed for service delivery? What are the implications of not meeting such time-scales? (See Service Credits)

Whose responsibility is it for monitoring and reporting. Should it be the Billing Supplier’s? If so, how can the data reported be trusted?

The new insurance company should also consider stating a maximum permitted tolerance of service level quality and targets for re-performing inadequate services and time to re-perform the service.

Finally, a service credit regime will need to be established for paying the new insurance company credits in the event of the Billing Supplier’s non-performance. This could be a percentage of monthly charges for performance below the SLAs (such as for the deviation from tolerated quality control, availability, failure to meet deadlines or targets according to the specified SLAs). The new insurance company may also want to express in the contract the importance of an IT system to its business. The insurance company can include in the service credit principles (as genuine pre-estimated loss), the concepts of wasted advertising costs and potential business loss for a delayed launch. Therefore, it is crucial that adequate legal advice is sought when negotiating business critical IT contracts.

Most people have a fairly good idea about copyrights — it protects creativity expressed as a literary work (such as a book or play), music, pictures, movies and sculptures. It also, specifically, protects software, documentation and other materials relevant to IT.

What is Copyright?
Copyright arises as soon as a work is recorded in some way, whether in paper or in the electronic form. Even the “look and feel” of a website or user interface can, in some circumstances, be protected by copyright. There is no need to register copyright or to add the copyright symbol “©”, although it is a good practice to use the symbol, particularly where the right is to be relied on internationally. The name of the copyright owner and the date should also be added. Oman Economic Review ran a comprehensive article on intellectual property issues more specific to Oman in its July 2006 edition and, therefore, this article will not consider this issue in detail. Here, the implications of the Free Trade Agreement between Oman and the US on copyright protection should be considered, especially since Oman is required to enact the FTA by next year. However, interested parties should seek specific advice relating to copyright protection provided under the FTA.

Traditionally, copyright gives the owner exclusive rights over a protected work: essentially, these include the right to use and copy the work, and to issue copies to third parties. In the context of IT, the copyright owner generally issues licences to third parties to use software in return for either a one-off or a continuing payment.

Copyright generally vests with the creator of the work: the author of a book or the writer of software code. If the copyright is created by a software developer for a customer under a contract, then it should be specified who owns the copyright. These issues cause endless confusion in the IT industry. The answer to any potential confusion is always to deal expressly and clearly with issue of ownership of copyright in the IT contract. For example, consider the following scenario:

Bank 1 hires a software developer on a temporary basis, for three month, as a consultant to design and develop some software. Given the temporary nature of the work, Bank 1 uses the consultant’s standard terms to govern the relationship. The three months comes to an end and the consultant leaves Bank 1. After some months, Bank 1 finds that the consultant has been employed by a competitor, Bank 2. More worryingly, it discovers that the consultant has sold software developed during his time at Bank 1 to Bank 2. A review of the terms of contract that it had entered into with the consultant reveals that the copyright of all works created by the consultant vests with it. In such circumstances, there is very little Bank 1 can do to stop the consultant from selling his products to Bank 2.

To avoid the above scenario, it essential that customers receive adequate legal advice to ensure that sufficient provisions are contained within all contracts, clearly specifying who owns the developed software. If a customer’s objective is to simply use the software, then a licence will suffice. Of course, a customer will need to be advised on determining that such licence meets its requirements. Most software can easily be copied and distributed, and where these acts are carried out extensively, the value of the software as an asset can be adversely affected and result in loss of licensing revenue for the software owner. Consequently, any supplier will seek to grant as limited a number of licences as possible–typically, for use by an individual customer alone, with no (or limited) rights to copy, modify or sub-license the software. Suppliers also often limit licences of their software by restricting use to a specified number of users or sites, to specific hardware or for use in conjunction with a specified operating system. Also, they expect upgrade fees if a customer’s use of the software changes. Consequently, it is imperative that a customer understands the scope of a licence and its implications.

If a customer wants outright right on any developed software, then relevant expressed wording will need to be included in the contract. The developer will also need to be obligated to do what is necessary to make sure the copyright subsists with the customer, as the diagram below illustrates:

Conclusion
As is evident, there are a number of issues that customers and suppliers should consider when negotiating IT contracts. It is essential that the terms of the contracts should be plainly laid out in advance and customers should not hesitate in discussing the concept of risk allocation. Procurement divisions should consider undertaking an audit to ensure there are systems in place to avoid the outright acceptance of any supplier’s terms. More importantly, the standard terms of all procurement divisions should be regularly reviewed and updated. The concept of service levels and service credits should be clear and explicit in all contracts, as this is the basis on which the customer shall have the right to claim for delays in delivery without heading for the courts. The principle of intellectual property rights in IT contracts is also very critical and the scenario above depicts the dangers associated with not having clearly covered the copyright ownership issue in a contract.

Top^