EM Law Liquidated Damages

Liquidated damages – are they payable even when the contractor does not complete the works?

For this reason, the parties to these contracts often pre-determine the level of damages to which a party is entitled in the event of certain specified breaches occurring. These pre-determined damages are known as liquidated damages and are often triggered when there is a failure to complete works within a specified time. In this blog we take a look at the recent case of Triple Point Technology Inc v PTT Public Company Ltd and consider whether a liquidated damages clause can survive the termination of a contractor’s engagement.

Liquidated damages - current position 

The question of whether or not a liquidated damages clause will trigger a payment obligation when a contractor does not complete works has been disputed by the courts on numerous occasions over the past few years. The conventional position, derived from earlier case law, is that an employer will be entitled to claim liquidated damages for delay up to the point of termination but must bring a general damages claim for any delays which accrue after that date. The logic is that, after termination, the contractor loses control of the time for completion, especially if another contractor is employed to complete those works. However, the cases of Halland another v Van Der Heidenand GPP Big Field v Solar EPC Solutionsmuddied the waters by concluding that an employer could claim liquidated damages for the period after termination. So where do we stand now? The recent Court of Appeal case of Triple Point Technology Inc v PTT Public Company Ltd has offered some much needed clarity on this issue.  

Triple Point Technology background 

In 2012 Triple Point Technology entered into a contract with PTT Public Company Ltd for the supply of a software system. Under the contract, Triple Point were to provide the new software system in two phases, with each phase having multiple stages of work. In the first phase, the new CTRM System would replace PTT’s existing system, and in the second phase the new CTRM System would be developed to accommodate new types of trade. The contract also contained a liquidated damages clause, referred to as Article 5(3), which stated:

“if contractor fails to deliver work within the time specified and the delay has not been introduced by PTT, the contractor shall be liable to pay the penalty at the rate of 0.1% of undelivered work per day of delay from the due date for delivery up to the date PTT accepts such work…” 

In February 2013 Triple Point Technology began working on the project however the first two stages of phase 1 were completed 149 days late. Nevertheless, Triple Point submitted an invoice in respect of this work, which was duly paid by PTT. Triple Point then submitted further invoices in respect of work which had not yet been completed, on the basis that the payment dates for such work had passed. However, PTT refused to make such payments and in May 2014 Triple Point Technology suspended work. By February 2015 PTT had terminated the CTRM contract and Triple Point technology had commenced proceedings in the High Court. 

High Court decision

Following termination of the contract, Triple Point Technology commenced High Court proceedings against PTT for the sums it said they were due. PTT counterclaimed for damages for delay and damages upon termination. In the High Court, Mrs Justice Jefford dismissed the claim and awarded PTT just under $4.5 million of which just under $3.5 million represented liquidated damages for delay pursuant to Article 5(3) of the contract. As the further milestones had not been reached, Triple Point Technology were not entitled to further payments. Triple Point were therefore not entitled to suspend work in May 2014 and were accordingly in repudiatory breach of contract. 

The appeal decision 

Triple Point Technology appealed Mrs Justice Jefford’s decision. Among other grounds of appeal, Triple Point Technology argued that Article 5(3) should not be engaged because it should only apply when work was delayed, but nonetheless completed and then accepted by the employer. In this case, the work was delayed and the contract was subsequently terminated. 

The Court of Appeal held that there were three different approaches towards clauses providing liquidated damages for delay, namely: 

  • The liquidated damages clause would not apply at all (as in the case of British Glanzstoff manufacturing Co Ltd v General Accident, Fire and Life Assurance Co Ltd);
  • The liquidated damages clause would only apply until the point of termination (as in the case of Greenore Port v Technical & General); or
  • The liquidated damages clause would continue until the second contractor achieved completion (as in the case of Hall and another v Van Der Heiden).

In the court’s view, the question of whether the liquidated damages clause ceased or continued to apply up until termination, or even beyond that date, depended on the wording of the clause itself and there was no blanket rule that applied by default. Relying heavily on the reasoning in British Glanzstoff manufacturing, Sir Rupert Jackson stated that there was “no invariable rule that liquidated damages must be used as a formula for compensating the employer for part of its loss.”

Sir Rupert Jackson also held that Article 5(3), which focused specifically on delay between the contractual completion date and actual completion, had no application in a situation where a contractor never completes the work. It followed that PTT was entitled to recover liquidated damages of $154,662 in respect of Triple Point Technology’s 149 day delay and would have to bring a claim for general damages in respect of any other delays. Although Sir Rupert Jackson emphasised that every case would turn upon the wording of the clause in question, he did cast doubt on the previous decisions in Halland GPP

Liquidated damages - concluding thoughts

The case of Triple Point Technology v PTT Public Co illustrates how the law in relation to liquidated damages is far from settled. Parties to construction or software contracts should think carefully about when they want their liquidated damages provisions to apply. Clear and effective drafting is therefore key to ensure that you do not encounter any surprises when bringing a claim for breach of contract. If you have any questions about liquidated damages clauses in construction contracts or software agreements please contact Neil Williamson.


EM Law technology lawyers

Artificial Intelligence - Some Legal Issues

When someone says “Artificial Intelligence” what do you think? Robots taking over the world? Machines replacing you in your job? Or an opportunity for you to put your feet up and let someone else or rather something else do the chores? Although AI may be daunting for some, there is no doubt that it will transform the way we live. This blog takes a look at some of the legal aspects of AI and what you should consider when developing such a system.

What is Artificial Intelligence?

AI is essentially machine-learning technology used to complete tasks that previously required the skills or intellect of human beings. AI systems will typically demonstrate problem solving skills, knowledge and perception and, to a lesser extent, social intelligence and creativity. Take Ai-Da as an example, a robot named after computer pioneer Ada Lovelace and designed to draw people from sight with a pencil in its bionic hand. With cameras in each of its eyes, Ai-Da will be able to recognize human features and mimic your expression to create a lifelike portrait. Self-driving cars, mobile banking apps and Apple’s personal assistant Siri are further examples of AI technology that we may come across in our everyday lives.

Artificial Intelligence – some of the legal issues

AI regulation

The UK, like the rest of the world, recognises the potential of AI. However, the UK, like the rest of the world, does not currently regulate AI in any significant way. In April 2018 the House of Lords published a report titled “AI in the UK: ready, willing and able?” In this report the House of Lords suggested that blanket AI-specific regulation, at this stage, would be inappropriate. Instead, existing sector-specific regulators were best placed to consider the impact of potential AI regulation on their sectors. The Automated and Electric Vehicles Act 2018, which came into force last July, provides an example of this. This act does not apply to AI generally, but applies specifically to automated vehicles, putting the burden of liability onto the insurer.

In December 2018 the European Commission published a draft of ethics guidelines for the development and use of artificial intelligence (AI). The Commission has opened the guidelines for comments and states that discussions are also taking place through the European AI Alliance, the EU’s multi-stakeholder platform on AI.

The guidelines emphasise “trustworthy AI” as their guiding principle. Trustworthy AI has two components:

  • it should respect fundamental rights, applicable regulation and core principles and values, ensuring an “ethical purpose”; and
  • it should be technically robust and reliable since, even with good intentions, a lack of technological mastery can cause unintentional harm.

The Guidelines set out a framework for trustworthy AI that include:

  • the fundamental rights, principles and values that it should comply with;
  • the requirements for trustworthy AI and offering an overview of technical and non-technical methods that can be used for its implementation; and
  • concrete but non-exhaustive assessment list for trustworthy AI. 

AI development contracts

Whilst some AI developers will attempt to build bespoke hardware, the majority of today’s AI systems will be implemented as software. Contracts to develop AI systems will therefore need to take account of the usual issues associated with developing software. Such issues include the ownership and licensing of any pre-existing IP rights as well as any rights that are developed as part of the project. The software development agreement should also provide for indemnities relating to any infringement of third-party IP rights by the developers of the AI system.

AI generated intellectual property

Traditional copyright law in the UK protects the original creations of authors. Author is defined in the Copyright, Designs and Patents Act 1988 as the person who creates the work. An author must therefore be a human. This poses a potential issue for purely autonomous AI systems, where computers make decisions and carry out functions without any form of human involvement at all. Copyright law does however acknowledge the possibility that works could be “computer-generated”. The author of “computer-generated” work is deemed to be the person “by whom the arrangements necessary for the creation of the work are undertaken”. Under UK Copyright law the software programmer would therefore most likely be the author and first owner of a copyright work generated by an AI. This seems simple enough but the situation becomes complicated for AI which involves human collaboration and input at various stages of development. Who in this scenario will be the owner? Will there be multiple joint owners? As things at present are not clear, you should ensure that any new agreements for the development and use of AI clearly state which parties will own any protectable IP resulting from the AI.

AI and Data Protection

Data processing lies at the heart of AI with AI projects often involving the processing of large amounts of personal data. The ICO published a paper in September last year setting out a number of recommendations for organisations to follow. Organisations should, for example, carefully consider whether their AI system actually requires the processing of personal data or whether they could anonymise the personal data before analysis. As anonymised data does not relate to an identified or identifiable person, it is not personal data for the purpose of the GDPR. Organisations should also carry out a data protection impact assessment. A data protection impact assessment will help organisations identify and minimise the data protection risks of a project. A recent example of AI in the data protection context is the case of Royal Free Hospital v DeepMind. In this case, the Royal Free Hospital handed over the personal data of 1.6 million patients to DeepMind, an AI company and subsidiary of Google. The ICO decided that the hospital had failed to comply with a number of data protection principles and also found that DeepMind was in fact a data controller, rather than a data processor as previously thought.

AI and product liability

A smart car hits a person. Who is at fault? The programmer in the office with the source code? The owner on the road in the smart car? The manufacturer in the lab with the testing protocols? The general principles of tort law (negligence) are likely to apply to the widespread use of AI but under existing law AI is personal property, not a person. AI machines cannot therefore be held liable for negligent acts or omissions that cause damage to third parties. So, who will be held liable? As there are many parties involved in an AI system, this may be difficult to establish and there are many factors that should be taken into consideration. These factors include whether the AI system was following instructions, whether damage can be traced back to the design or production of the AI system and whether the AI system provided any general or specific limitations. Contributory negligence will also be considered as a factor here.

It has also been suggested that liability could be established for AI systems under a similar framework to the Animals Act 1971. Under this Act, when an animal runs onto another person’s property and causes damage, the animal’s owner is liable for this damage. As this is strict liability, there is no need to prove negligence or intent. It may be the case that for some forms of physical AI, for example robots, similar legal framework will be put in place.

Conclusion

Artificial Intelligence is evolving rapidly but the law around it is not. This does not mean that no legal frameworks around artificial intelligence exist – they do but they are rooted in regulation or legal doctrine that do not answer all the questions. From the perspective of AI developers while this creates challenges such as understanding the kind of liability that the products they are developing can throw back at them, this also creates opportunities for developers to inform and shape regulation as it tries to keep up with the paths that developers chose to go down. If you have any questions about AI and what you should be considering when developing such a system please contact Neil Williamson.

 

 

 

 


EM Law SaaS

Software as a service (SaaS)

SaaS is now the model that most software suppliers are aiming for. From the supplier side, SaaS helps protect intellectual property rights, it makes things easier when it comes to support and maintenance and the supplier retains greater all-round control. If the customer doesn't pay then the supplier can switch off access easily. From the customer side, support and maintenance and service availability is less of an issue because the supplier is servicing hundreds or thousands of other customers. Customers can rest assured that the supplier will be doing all they can to ensure the system is working. This article gives a very brief overview of SaaS and the things you should be aware of if you are thinking of signing a SaaS contract. Our lead software lawyer is Neil Williamson who is an expert in all software law matters.

What is SaaS?

SaaS (software as a service) is a software supply model through which a supplier hosts software applications on its platform and permits its customers to access and use that software over the internet. A SaaS customer will not receive a physical or installed copy of the software. Instead, the software is available via the internet using a standard browser. The customer will login to the supplier’s platform using credentials provided by the supplier and, once logged in, the customer can then use the software on the platform.

Access to SaaS is provided to customers on a subscription basis. When you stop paying the subscription fee, your rights to access the SaaS will end. Additional fees may also be payable, for example, in respect of any additional or enhanced user subscriptions or for any data stored in excess of any data storage limit that may be imposed.

Examples of popular SaaS applications include Dropbox, Amazon Web Services and Salesforce however there are many niche providers in the market now. These suppliers tend to be offering a platform where customers can upload and process data.

Advantages of SaaS

There are numerous advantages to SaaS. Commonly, SaaS providers host their services and store all of their customers’ data in the cloud so the data can be accessed and processed from anywhere with an internet connection.

This structure also allows providers to offer customers major cost savings as a result of economies of scale achieved by managing multiple customer solutions in a single operation.

SaaS eliminates upfront costs of purchase and installation and means that customers do not have to invest heavily in hardware, software or professional skills to obtain a wide range of functional capabilities. Additionally, the SaaS “pay as you go” model allow businesses to pay only for what they are using. This can be particularly advantageous for small businesses because it provides access to expensive, technical software that might have been otherwise unobtainable through conventional purchasing methods.

As well as being able to offer cost savings, SaaS providers can benefit from only having to support one version of their software and delivering their service on a single platform. SaaS providers can make changes to their software easily, especially when compared to a model where the software is installed on the customer’s servers. The provider can also implement enhancements at its data centre and make those changes available to its entire customer base. SaaS is designed to be user-friendly and should therefore minimise specific training requirements.

Other advantages include protection of intellectual property rights and general overall control for the supplier. Under the SaaS model, the customer does not receive a copy of the software making it much harder for the customer to copy it. As software is delivered as a service, the service can be switched off at any time by the supplier disabling the customer's log-in credentials.

Disadvantages of SaaS

There are also disadvantages to SaaS. Although some SaaS providers offer customer-specific customisation services, the majority of services provided are a “one-to-many” model. SaaS is therefore generally regarded as more useful for standardised software applications such as email, data processing and accounting. You will need to evaluate each application individually to make sure that the SaaS offers the features that you need to do business.

Some businesses may also be concerned about the lack of control and security of SaaS. In-house software applications give business owners a high degree of control. When you use a hosted solution, you give much of that control over to a third party provider. If you aren’t comfortable relying on a third party to manage critical business applications, a SaaS model may not be right for you. There may also be compliance (for example, data protection) issues and a risk of hidden extras for additional users, storage and so on.

What do I need to consider when entering into a SaaS agreement?

As SaaS providers usually have high numbers of contracts globally, they generally seek to offer their services on standard terms. These terms tend to be strongly advantageous towards the provider and exclude liability for data loss, corruption or service failure. Consider the following provisions in particular:

• Charges and payment (including any price increases);
• The treatment of customer data;
• Service levels;
• Confidentiality provisions;
• Term and termination; and
• What happens to customer data when the contract ends.

From the supplier’s perspective, a SaaS model is lower risk than other forms of software supply. However, as with all contracts, careful drafting is needed. All of the above provisions are important from the supplier’s as well as the customer’s perspective and, in addition to these, appropriate intellectual property rights provisions should be included.

Licensing

Although in a software as a service model software is not being physically supplied to the customer, appropriate software licences still need to be granted. This is because the customers are using the software at a computer and, without a licence, this would be copyright infringement. These licences are usually very narrowly defined and limited to use of the online application for their own business needs. The supplier should warrant to gain and maintain all necessary licences, consent, and permissions necessary for the performance of the agreement.

If you have any questions around software as a service agreements or you need support drafting a software as a service agreement contact Neil Williamson.