Subcontracting: An Overview and Should you Back-to-Back?

Subcontracting is seen in a number of sectors including construction, transportation, manufacturing and information technology. A subcontract will always be related to another contract - often called the ‘main contract’ or the 'prime contract'. Two parties will have entered the main contract and then one of those parties may wish to subcontract some of their obligations. The scope of these subcontracted obligations can be as wide as the parties wish (subject to any subcontracting rules in the main contract). The key point here is that the main contract is still in place with the two original parties remaining liable to one another. The party to the main contract who subcontracts will therefore remain liable for any work undertaken by their subcontractor.

Subcontracting – general

For clarification we will use the following terms throughout this blog:

  • Customer – the party to the main contract who is paying the Main Contractor for the work that the Main Contractor must carry out.
  • Main Contractor – the party to the main contract who has agreed to carry out the work that the Customer needs.
  • Subcontractor – the third party who has been subcontracted by the Main Contractor to carry out some or all of the work that the Main Contractor has agreed to carry out under the main contract.

In general, the Customer is obliged to accept the Subcontractor’s performance if the Subcontractor fulfils all that the Main Contractor had agreed to do under the main contract. Although this may not suit the Customer, if they failed to expressly prohibit subcontracting in the contract they will be deemed to have consented to the subcontract, unless they can bring themselves within the scope of one of the legal restrictions on subcontracting.

Subcontracting – liability

This is the way the chain of liability will work in a subcontracting relationship: if the Subcontractor’s work does not fulfil its assigned obligations in the main contract, the Customer will be able to sue the Main Contractor for breach of the main contract, and the Main Contractor will be able to sue the Subcontractor for breach of the subcontract:


Main Contractor


It would seem therefore that the Subcontractor would not be liable to the Customer. This is not always the case, however. A Subcontractor could be liable in tort, for example, where the Subcontractor is found to owe a duty of care to the Customer and is negligent in carrying out the work such that they, for instance, cause physical damage to the Customer’s property.

Back-to-back or stand-alone?

The term ‘back-to back’ agreement is used to refer to a particular kind of subcontract. This expression is used when all of the terms used in the Main Contract are incorporated by reference into the back-to-back subcontract. They are normally used when the rights and duties of the Subcontractor in relation to the Main Contractor closely mirror those under the main contract. Creating a back-to-back agreement might be as simple as changing the names of the parties on the main contract and including a 'back-to-back' clause therefore transferring all the duties in the main contract to the subcontractor. However, as we discuss in the next section, this can create problems.

In a full back-to-back subcontract agreement, the Main Contractor is essentially a front man for the Subcontractor. As such, the Subcontractor will normally be willing to assume full liability for the performance of the works as defined in the main contract, and there is often little difference in the pricing or wording of the two contracts. In a partial back-to-back agreement, the Subcontractor agrees to discharge some but not all of the main contractor’s obligations under the main contract.

A stand-alone subcontract agreement can be read and understood without reference to the main contract. The clauses in this sort of subcontract might have little in common with those in the main contract. The Main Contractor will need to be careful to ensure all the relevant obligations and liabilities are still passed to the Subcontractor.

Disadvantages of back-to-back agreements

Many reasons are given for being wary of back-to-back agreements. These include:

  • A mirror back-to-back layout will most likely not be appropriate for every clause in a main agreement. Careful consideration should be given to the question as to whether the simple transfer of an obligation from the main agreement to the back-to-back agreement will result in obligations that achieve the original intention of the parties and that they are enforceable. Provisions that might not ‘back-to-back’ neatly include intellectual property, confidentiality, limitations of liability, liquidated damages and data protection.


The main contract says that the Main Contractor will keep the Customer’s (as defined above) intellectual property confidential. The back-to-back subcontract will then say that the Subcontractor will keep the intellectual property of the Main Contractor confidential. This is wrong. The subcontract should say that the Subcontractor will keep both the Main Contractor’s and Customer’s intellectual property rights confidential (or any other arrangement agreed by the parties)!

  • Where there are multiple subcontractors and a complicated specification in the main agreement it can be difficult to work out which obligation falls on a particular subcontractor. Defining the subcontractor’s scope of work may result in as much effort as the drafting of a stand-alone subcontract.
  • A back-to-back contract is only as good as the main contract. The customer might be content to have simple sweeping obligations in the main contract, but the main contractor might see the need to spell out more detailed obligations in a tailor-made subcontract.

Should we have a standalone (not back-to-back) contract?

It depends on the context. As the answer will usually require careful analysis it is advisable to seek professional guidance. The solution we usually come up with is a hybrid - a back-to-back contract which also covers those areas in the contract where simply back-to-backing rights and obligations doesn't work.

Restricting subcontracting

The following are ways in which subcontracting can be restricted:

  • The main contract expressly or implicitly prohibits subcontracting. If a party wishes to stop subcontracting, they should include an express clause in their contract stating so. This usually comes in the form of a boilerplate clause.
  • The contractual obligations are of a special nature that require personal performance by the original contracting party. Examples include contracts for composing music or writing a book.
  • It can be implied from the circumstances that the original contracting party has promised performance. If it can be shown that the original contracting party was chosen because of their particular personal qualifications, skill, competency or financial position, then performance cannot be subcontracted.
  • Statutory or regulatory restriction. Certain regulated contracts can only be carried out by authorised persons, for example, insurance contracts, consumer credit agreements. If the subcontractor doesn’t hold the appropriate licences, the subcontract will be unenforceable.

Subcontracting - Data protection

It is important to consider that data protection obligations will pass down the subcontracting chain. The Subcontractor will be a sub-processor and all sub-processing arrangements are prohibited unless the Customer has given prior written consent. The Main Contractor should check the data processing provisions and subcontracting provisions in the main contract to see what they say about sub-processing. The Main Contractor must enter into a sub-processing agreement with the Subcontractor that imposes the same data protection obligations on the Subcontractor as are imposed on the Main Contractor by the Customer. The Main Contractor, as with other obligations assigned, will be fully liable for the performance of the Subcontractors’ data protection obligations.


  • Is subcontracting allowed? Check that the main contract does not prohibit subcontracting.
  • Boilerplates in the main contract. The back-to-back agreement will incorporate by reference all the terms of the main contract including boilerplate clauses. Boilerplate clauses are found at the end of most contracts and cover issues found in all contracts such as how notices should be given or which legal system the contract operates in. It will be important to check that the boilerplate clauses in the main contract, if back-to-backing, are giving sufficient legal protection and do not need adding to.
  • Flow down of obligations from the main contract to a back-to-back agreement need to make sense.
  • Where there is an international element to the arrangements you need to ensure that the governing law of the main contract gives the main contractor effective recourse against the subcontractor and vice-versa.
  • Sub-contracting of data processing obligations – check that the Customer has given its prior written consent to the sub-contracting of any data processing obligation set out in the main contract.

Final thoughts

Subcontracting is common practice, especially in large projects requiring delivery of a range of skills and services, so it is important to understand how subcontracting works. If you are planning on engaging a subcontractor to help you deliver a project then make sure that you have the right contract in place that mirrors your obligations under the main contract. If your subcontract agreement is not drawn up properly you could be left being sued by the Customer because of your subcontractor's poor performance while unable to sue the subcontractor yourself.

If you have any questions about subcontracting or about contract law more generally please contact Neil Williamson.

liquidated damages clauses

Liquidated Damages Clauses: Supreme Court Overrules on Failed Software Delivery

Liquidated damages clauses exist to create certainty around how much can be claimed when a contract is breached. Put another way, they are introduced to deal with the difficulty of predicting the amount potentially recoverable as damages for breach of a contract. A recent ruling by the Supreme Court in Triple Point Technology Inc v PTT Public Company [2021] UKSC 29, explored liquidated damages clauses effectiveness in the context of the failed delivery of a software system. The case also explored the effectiveness of exclusion clauses and the definition of negligence.

Liquidated damages clauses

Liquidated damages clauses frequently appear in commercial contracts and, most commonly, in relation to late or defective performance, particularly in the fields of construction, engineering, supply of goods and shipping contracts. Advantages of liquidated damages clauses include:

  • The parties can know in advance what their liability is and how much they could receive in a breach specified by liquidated damages clauses.
  • They could make recovery of damages easier. This is due to the fact that liquidated damages clauses are enforceable regardless of needing to quantify the loss actually suffered by the innocent party, as would be the case when considering the amount payable to the innocent party when unliquidated damages apply (read our blog on the topic: Damages for Breach of Contract). The claimant simply must show that a breach of contract falls within the scope of the liquidated damages clause. It therefore follows that a claimant may be able to recover more than would be recoverable if the damages were unliquidated (as affirmed in Philips Hong Kong v AG of Hong Kong [1993] 61 BLR 41).
  • Vice-versa, liquidated damages clauses can work in favour of the party responsible for the breach where the damages caused would be more if unliquidated. When considering the drafting of such a clause, it is important to have these considerations in mind, including who is likely to be in breach and what sort of magnitude is imaginable, whilst also being aware that if liquidated damages clauses do not represent a genuine pre-estimate of potential damages, they could be deemed invalid.
  • They help with dealing with minor breaches in long-term contracts (such as construction) and so help to maintain a commercial relationship when there have been minor breaches throughout. In this vain, liquidated damages can be applied to specific obligations in a long-term commercial agreement and so compartmentalise potential breaches.

Can you still claim for general damages when liquidated damages clauses are included in the contract?

Usually, liquidated damages clauses relate to specific breaches and so only apply to the scope of the breaches referred to in the clauses themselves. Therefore, general damages will be claimable for breaches beyond the scope of liquidated damages clauses, subject to any other provisions in the contract. There have, however, been some unusual exceptions to this rule. Including:

So long as liquidated damages clauses clearly state the sort of breach they apply to and how they will operate, the exceptions referred to above should not apply. In Triple Point v PTT the case hinged upon some ambiguous wording in a liquidated damages clause, further proof that such clauses need to be considered at length. We now explore this recent case in depth.

Liquidated damages clauses: Triple Point v PTT

Triple Point Technology Inc (Supplier) contracted to design, install and maintain a software system for PTT Public Company (customer). Payment was due in instalments on completion of milestones. The supplier’s performance did not meet the contractual timetable. Some of the delayed work was accepted and paid for but the customer refused to make other payments for work not yet completed. The supplier suspended work and the customer terminated the contract.

Liquidated damages clauses point in Triple Point v PTT

The supplier brought an action for payment of its unpaid invoices. The customer counterclaimed for damages and liquidated damages under the contract, as provided under article 5.3:

“If the supplier fails to deliver work within the time specified and the delay has not been introduced by the customer, the supplier shall be liable to pay the penalty at the rate of 0.1% (zero point one percent) of undelivered work per day of delay from the due date for delivery up to the date the customer accepts such work, provided, however, that if undelivered work has to be used in combination with or as an essential component for the work already accepted by PTT, the penalty shall be calculated in full on the cost of the combination.”

As shown in bold above, the point here was whether PTT had to accept the work for the liquidated damages to be payable. Put another way, article 5.3 could be interpreted to mean that damages for delay would only be payable under this clause if the work was eventually completed and accepted by PTT, which was not the case. Whilst the Court of Appeal held that the clause did not apply because the work was never completed, the Supreme Court criticised this and ultimately overruled it, deeming it inconsistent with commercial reality and the accepted purpose of liquidated damages clauses. The Supreme Court said that parties must be taken to know the general law, that is, that the accrual of liquidated damages comes to an end on termination of the contract, and so given the work had not been completed up to this point, the clause would apply. After that point in time, the parties must seek damages for breach of contract under general law.

The limitation clause point in Triple Point v PTT

Article 12 of the contract placed a cap on the amount of damages that could be recovered and included an exception from that cap for “negligence”:

“… The total liability of the supplier to the customer under the contract shall be limited to the contract price received by the supplier with respect to the services or deliverables involved under this contract. … This limitation of liability shall not apply to the supplier’s liability resulting from fraud, negligence, gross negligence or wilful misconduct of the supplier or any of its officers, employees or agents.”

The Court of Appeal held that the word ‘negligence’ must mean some independent tort and did not mean breach of a contractual duty of skill and care. In other words, the Court of Appeal concluded that the cap applied to negligently performed contractual duties and therefore Triple Point’s liability for its negligent approach to contractual duties would be limited by the cap. The Supreme Court disagreed, holding that negligence should be given its natural and ordinary meaning of removing from the cap all damages for negligence on the supplier’s part, including damages for negligent breach of contract. Therefore Triple Point’s negligent approach to contractual duties was not capped and their total liability (including under the liquidated damages clause) amounted to just over $14.5 million.

Draft carefully

The context in which liquidated damages clauses classically apply is in a construction context. This is because construction projects span many years, many stages of development and, usually, many parties. Consequently, to thread these various elements together without allowing small-scale breaches to break down a project, liquidated damages clauses are a useful way to define exactly what remedy is available for failed or delayed sections of work. As shown by Triple Point v PTT, these clauses are also significant in any long-term delivery supply contract and employment contracts also often make use of them. This ruling will be received with relief by many, especially considering many were concerned by the lack of commercial consideration in the Court of Appeal’s decision.

What becomes clear from looking at case law in this area is that the wording of liquidated damages clauses can have a significant impact on how they will be interpreted if a contractual relationship goes to litigation. Given the often-bespoke nature of these clauses because they concern the specific work to be done and any imaginable remedies, there is a risk that the wording can be loose and therefore seeking legal advice is very important. These clauses need to be meticulously thought through.

If you have any questions about liquidated damages clauses or about contract law more generally please contact Neil Williamson.

Managing Data

Managing Data – Software Services And AI Legal

Managing data is an essential part of the operation of a growth business. It’s a cliché often bandied around that today data is more valuable than oil. But as with oil, it’s only how the resource is used that defines its value. Whereas oil can be relied upon to produce energy in all circumstances, data cannot be relied upon to produce useful insights at all times. Therefore, the means and purpose by which it is processed becomes all the more important. Given its potential, it comes as no surprise that initiatives, public and private, for managing data more effectively are commonplace. The legal sphere attempting to regulate this burst of energy gets more complex by the day. Here is our introduction to some general issues you may face when managing data for profit, or to simply improve the running of your business.

GDPR and Brexit

Before GDPR came into force in all EU member states on 25 May 2018, the ICO commissioner stated in the ICO’s March 2017 paper, Big data, artificial intelligence, machine learning and data protection, that ‘it’s clear that the use of big data has implications for privacy, data protection and the associated rights of individuals… In addition to being transparent, organisations… need to be more accountable for what they do with personal data’.

At the end of the Brexit transition period (January 1st 2021), the GDPR and parts of the Data Protection Act 2018 became part of a new body of retained EU law. Essentially replicating the old regime in the UK. Data protection legislation in the UK is now comprised of the UK GDPR and the DPA 2018. From a UK perspective the GDPR operating in the EU will be known as the EU GDPR.

As the EU GDPR will continue to have extra-territorial effect (Article 3, EU GDPR) it may continue to apply to UK organisations who act as controllers or processors and have an establishment in the EU, or who offer goods or services to data subjects in the EU; or monitor their behaviour, as far as their behaviour takes place within the EU. UK businesses could therefore find themselves subject to parallel data protection regulatory regimes under both the UK GDPR and the EU GDPR.

Are you managing data as a processor or controller?

If offering a service, for example a software platform that allows companies to process personal data, then it would often be prudent to ensure you are defined as a data processor, and not a data controller, for data protection purposes. This is because, as opposed to data controllers who bear primary responsibility for the personal data involved, data processors have less obligations under data protection laws. Processers are essentially processing data under the instructions of the data controller. Whilst a data controller determines ‘the purposes and means’ of processing the personal data (Article 4(7), UK GDPR). A helpful way of thinking about it is that a data controller has direct duties to data subjects whereas a data processor only has duties to the data controller.

The distinction between controller and processor in an AI context was first considered in the ICO’s July 2017 decision on an agreement between the Royal Free Hospital and Google DeepMind. Under the agreement DeepMind used the UK’s standard publicly available acute kidney injury algorithm to process personal data of 1.6 million patients. The ICO ruled that the hospital had failed to comply with data protection law and was ordered to perform an audit on the system. The hospital’s law firm, Linklaters, concluded in the hospital’s audit report, Audit of the acute kidney injury detection system known as Streams, that DeepMind had been properly characterised as a data processor. This was because Streams ‘does not use complex artificial intelligence or machine learning to determine when a patient is at risk of acute kidney injury. Instead, it uses a simple algorithm mandated by the NHS’. It was therefore the lack of complexity involved in the ‘means’ of processing the personal data which meant that DeepMind were considered to be a data processor. A complex algorithm would have constituted a level of agency on DeepMind’s part which would have rendered their processing that of a data controller. It was deemed, however, that their services were simple enough to be doing nothing more than following the hospital’s instructions. This grey area should be of concern to anyone planning to use AI to analyse data. Make an algorithm too complex and you may take on the liability of a data controller and hence liability towards data subjects.


Managing data to make it anonymous would fall under UK data protection laws. This is because the purpose with which the personal data was originally collected needs to be aligned with the purpose that it is later anonymised for. There are certain circumstances in which collecting personal data to begin with is not necessary and, if still useful, highly desirable for businesses wishing to process the data as they wish. If the data is originally collected in an anonymous format, then UK GDPR no longer applies. As GDPR states at recital 26, ‘the principles of data protection should… not apply to anonymous information, namely information which does not relate to an identified or identifiable natural person or to personal data rendered anonymous in such a manner that the data subject is not or no longer identifiable’.

In an ICO report, Anonymisation: managing data protection risk code of practice, the ICO lists anonymisation as one of its six key recommendations for AI. It states ‘organisations should carefully consider whether the big data analytics to be undertaken actually requires the processing of personal data. Often, this will not be the case; in such circumstances organisations should use appropriate techniques to anonymise the personal data in the data sets before analysis’.

Profiling and automated decision making

AI’s ability to uncover hidden links in data about individuals and to predict individuals’ preferences can bring it within the GDPR’s regime for profiling and automated decision making. Article 22(1) states that ‘a data subject shall have the right not to be subject to a decision based solely on automated processing, including profiling, which produces legal effects concerning him or her or similarly affects him or her’.

However, this is qualified by article 22(2) which states that this right does not apply to a decision that ‘(a) is necessary for entering into or performance of a contract between data subject and data controller; (b) is authorised by… law to which the controller is subject and which also lays down suitable measures to safeguard the data subject’s rights and freedoms and legitimate interests; or (c) is based on the data subject’s explicit consent’.

This is further qualified: ‘in the cases referred to in points (a) and (c)…, the data controller shall implement suitable measures to safeguard the data subject’s rights and freedoms and legitimate interests, (including) at least the right to obtain human intervention on the part of the controller, to express his or her point of view or contest the decision’. Having automated decision making within software performing data analysis can therefore introduce new obligations. Such obligations often being onerous for a data controller. This can include it being necessary to perform a Data Protection Impact Assessment or getting explicit consent from data subjects.

Other suggested compliance mechanisms

The ICO makes five recommendations for using AI to analyse data:

  • Privacy notices.
  • Data protection impact assessments – embed a privacy impact assessment framework into data processing activities to help identify privacy risks and assess the necessity and proportionality of a given project.
  • Privacy by design – implementing technical and organisational measures to address matters including data security, data minimisation and data segregation.
  • Ethical principles.
  • Auditable machine learning algorithms.

Treasure trove

Finding new and innovative ways for managing data is a treasure trove many wish to unlock. It is important to be wary of the growing regulatory landscape underpinning the sector. The world was shocked by the accusations made against Cambridge Analytica and making sure you display compliance is a must for maintaining a good reputation and attracting clients. With Brexit comes the potential for the complexity inherent in potentially diverging legal regimes. Being up to date on the development of the Privacy and Electronics Communications Regulations (PECR) will also be useful. Read our blog on PECR here.

EM law specialises in technology and data protection law. Get in touch if you need advice on data protection law or if you have any questions on the above.

Systems Integration Contracts

Systems Integration Contracts: Co-op v IBM

Systems integration contracts govern the relationship between the parties involved in an IT implementation project. Such a contract can make for a complicated relationship and a messy dispute, as seen in CIS General Insurance v IBM [2021] EWHC 347. Few of these kinds of projects ever see their day in court, arguably due to inherent complexities and the expense of their unpicking. This case concerned the implementation by IBM of a new IT solution for Co-op’s insurance business. The agreement was supposed to deliver the system by December 2017 and used an Agile methodology (read our blog).

Success with system integration contracts often relies upon customer co-operation and participation as much as the supplier’s delivery. The simple question of defining what a customer wants from the outset can be a challenge when creating bespoke software. A number of alternative contractual and management solutions (Agile for example) have developed in an attempt to match this complexity. In short, systems integration contracts need to be meticulously thought through and understood. IBM’s failure to use relief mechanisms under its agreement with Co-op left them with few legs to stand on when their subcontractor failed to deliver, leading to an award of £15.8 million in damages to Co-op.

Customer’s requirements

In systems integration contracts, the purpose of a customer’s requirements section is to set out clearly and comprehensively all the functionality that the customer requires from the system. This is about letting the supplier know exactly what the project needs to achieve - which can be difficult and so customers often seek help from third parties. Consultants can be used to investigate the various interest groups within the customer’s company to discern exactly what is needed and then to write up the requirement’s document for the customer. Consultants can then also be instructed to undertake market research with a view to suggesting potential suppliers.


Once a customer’s requirements are known, it is then the supplier’s job to specify exactly how those requirement’s will be achieved. This means a more technical outlining often called a ‘specification’. The customer’s requirements therefore represent the customer’s interests and the specification represents the supplier’s abilities. This opens up a spectrum of ways for the two parties to contract. Firstly, a customer could agree that it doesn’t care how their requirements are achieved so long as they are achieved. Secondly, a customer could agree to accept a product that fulfils all the obligations a supplier sets for itself in a specification. And thirdly some kind of balance between the two which gives the supplier an assurance that certain specifications will be accepted by a customer, but also the customer confidence that their requirements will be met. The third option is likely to be the most desired, but also the more difficult to communicate in a contract. This is why various alternative approaches have emerged, such as Agile, with a view to making software development more co-operative. However, as seen in CIS v IBM, the Agile Alliance’s manifesto principle ‘customer cooperation over contract negotiation’ proved ineffective when IBM was held to be responsible for critical delays to this very large ‘Agile at scale’ project.


Timetables give suppliers the opportunity to outbid other potential suppliers at the tender stage – pushing down their delivery time to the greatest possible extent. It is no wonder, therefore, that IT projects are notorious for exceeding their original contractual timetables. This can be the result of a number of factors. And not just the result of overly aggressive bidding. It could be due to customer changes or faults made by the supplier. This is all tied together by the fact that timetables are usually unrealistic at the outset.

It should therefore be in both parties’ interests to try and be as realistic as possible when it comes to timetabling in systems integration contracts. It can also be useful to introduce phase-level assessments which mean that customers have to accept early stages of development before moving on to later ones. This is where a third party consultant or project manager can come in handy – someone who can introduce a stronger notion of objectivity.

Intellectual property rights

Ownership in or licensing of intellectual property rights in the software being supplied are a fundamental consideration in software projects and must be addressed in systems integration contracts. It may seem logical that the creation of software for a customer should lead to the intellectual property rights of that software being transferred to the customer, when such projects are finalised. However, the current trend is towards the granting of licences to customers. This is because the bespoke software developed on the project will often include modules which the supplier has already created and may even be licencing to other customers. If the licence rights are wide enough and the customer’s use of the software is for its own internal operations then in practice it shouldn’t matter whether the software is owned or licensed by the customer as far as the customer’s use of the software is concerned. However, what if the customer is undertaking the project in order to give it some competitive advantage? This advantage  would be undermined if a supplier was able to licence the new software to competitors.

Another consideration is that, given the extensive involvement of customers in such projects, it can often be the case that key ideas underpinning the development of the software have the potential to come from the customer – what rights should the customer receive (if any) as a result of its input into the development of the software?


It is common practice to include acceptance testing clauses in systems integration contracts. Without such provisions there is greater scope for debate between the parties around whether the supplier has created software that does what it is supposed to. A failure of acceptance tests usually gives rise to an obligation for the supplier to fix the software and re-submit it for testing. If the product continues to fail, this usually gives customers the option to:

  • Ask for the product to be fixed and tested again.
  • Accept the system with its faults, but with a reduction in price.
  • Introduce a third party to carry out the work.
  • Terminate the contract.

CIS General Insurance v IBM

This recent case is a compelling warning of how systems integration contracts can go awry. From the start of the second phase of user acceptance testing in October 2016 until termination, 1,784 defects were recorded, of which 116 were severity level one, 432 severity level two, 1,052 severity level three and 184 severity level four. With a defect in severity level one or two constituting a failed acceptance test. This put IBM in a sticky situation. Not helped by their failure to obtain relief for certain problems when they were attributable, in part, to the customer (Co-op). This was because IBM needed to promptly serve notice of such customer caused problems, which it failed to do.

The case ended up taking nearly three years to get to court with the parties then spending two months in court and a judgement taking a year to be finally produced. IBM were deemed to have successfully excluded liability for “indirect or consequential losses, or for loss of profit, revenue, savings (including anticipated savings), data, goodwill, reputation (in all cases whether direct or indirect” and so Co-op’s primary claim for £128 million of wasted costs on the abandoned project was dismissed. Co-op was successful in its secondary claim for additional costs incurred in supporting the project as a result of IBM’s breaches and was awarded £15.9 million in damages set off by a £2.9 million counterclaim against Co-op resulting from an unpaid invoice.

Final observations

It can easily be argued that the failings of IBM to ensure its subcontractor delivered was the main cause of their downfall. But that doesn’t make this case a simple question of a supplier failing to supply. The nature of the agreement, being a systems integration contract, meant that Co-op (the customer), had obligations to ensure the system delivered all it needed. When Co-op failed to correctly co-operate, IBM (the supplier) failed to serve notice to claim against such customer failings, leaving them with nothing more than a defect ridden piece of software and a set of customer caused problems which they had failed to properly address. Systems integration contracts needs to be thoroughly understood before such projects go ahead. Otherwise you could find yourself in a similarly sticky situation.

EM law specialises in technology law. Get in touch if you need advice on systems integration contracts or other technology law matters.


UsedSoft Today – Software Licencing, SaaS and Brexit

Software licencing was put into controversy by the 2012 case UsedSoft GmbH v Oracle International Corp (C-128/11) (UsedSoft). The case questioned the instances in which a licensee would be able to re-sell purchased software. With the rise of cloud computing and Software-as-a-Service (SaaS) consequently becoming a more attractive option for developers and consumers, the significance of the ruling has decreased. Brexit has also had an impact. We felt it was time to review the impact UsedSoft has had in the technology sector, noting that its growing irrelevance is very much a sign of the times and future.

Exhaustion Principle

It seems common sense, especially when physical objects are in mind, that once a person has purchased an item, such purchaser has gained the right to sell that item on. Second hand cars, second hand books, second hand furniture – where would my mid-twenties self be without such amenities. The logic therefore follows that such an ability should extend to digital goods. E-books say (as explored in Nederlands Uitgeversverbond and Groep Algemene Uitgevers v Tom Kabinet Internet BV and Others (C-263/18)) or, as in UsedSoft, software.

This ability is covered in Article 4 of Directive 2009/24/EC (Software Directive) which details legal protection of computer programs and software licencing in EU law. The legislation goes as follows:

  1. A computer program rightsholder has the exclusive right to do or authorise:

“(a) the permanent or temporary reproduction of a computer program by any means and in any form, in part or in whole; in so far as loading, displaying, running, transmission or storage of the computer program necessitate such reproduction, such acts shall be subject to authorisation by the rightsholder;

(b) the translation, adaptation, arrangement and any other alteration of a computer program and the reproduction of the results thereof, without prejudice to the rights of the person who alters the program;

(c) any form of distribution to the public, including the rental, of the original computer program or of copies thereof.

  1. The first sale in the Community of a copy of a program by the rightsholder or with his consent shall exhaust the distribution right within the Community of that copy, with the exception of the right to control further rental of the program or a copy thereof.”

A slightly headache inducing bit of legislation on first read, it essentially means that, in certain circumstances, (Article 4(2)) when you sell a copy of a program, or piece of software, you exhaust the right to distribute that sold copy. The legislation therefore needed case law to define exactly what ‘selling’ meant in this context. That’s where UsedSoft came in to define it within the context of software licencing.

UsedSoft ruling

The European Court of Justice (ECJ) ruled in UsedSoft that under Article 4(2) the right to distribute a copy of a computer program was exhausted if the rightsholder permitting the download of the copy from the internet to a licensee had also granted a right to use that copy for an unlimited period of time. It was also required that a lump sum be paid for the licence. It therefore follows that the purchaser could sell a computer program (piece of software) licenced under these conditions on to someone else.

Arguably the biggest consequence was that software developers/vendors could not rely on contractual provisions in these circumstances when trying to protect against transfer or assignment following a purchase. If software is licenced for an unlimited period for a lump sum, the exhaustion principle will apply, regardless of the terms of a relevant contract.

UsedSoft’s limitations

The ECJ did qualify its ruling on software licencing with the following points:

  • The exhaustion principle would not apply to maintenance agreements related to the software licence i.e. whoever the purchaser would sell the software on to could not receive the benefit of any maintenance agreement in place between the original licensee and seller.
  • The purchaser of the software who wishes to sell it on cannot divide up the licence i.e. you must sell the software as a single package in the way you originally bought it.
  • When the resale occurs, the original purchaser of the software who is performing the resale must render its version/copy of the software unusable.


Increases in cloud computing capabilities has rendered software licencing under the UsedSoft model, i.e. for a one-off fee for an unlimited period of time, increasingly rare. Cloud computing has meant that software developers/vendors can make software available over the cloud on a subscription basis. This means they can run the program on their own servers and update it without having to send anything physical to customers (as used to be the case with CD-ROMs etc.).

The SaaS model essentially means that no software licence exists and that the software is really being provided as a contractual service. Such developments away from unlimited licencing to subscription based servicing has made the ruling in UsedSoft less and less relevant. UsedSoft will only apply to unlimited time period software licenced for a lump sum.

For more information on SaaS and software licencing read our blogs: SaaS Contracts – Things To Look Out For; Software as a Service (SaaS) – Some Key Aspects and Software Licences – Different Legal Structures.


On 31 January 2020, the UK left the EU and the UK-EU withdrawal agreement entered into force. Following the end of the transition period on 31 December 2020, retained EU Law was created, the remaining withdrawal agreement provisions came into operation, and the future relationship agreements (including the UK-EU trade and co-operation agreement (TCA)) started to apply on a provisional basis.

All EU case law, including UsedSoft, that was current at the end of the transition period was retained as part of UK law. However, the UK courts may depart from that case law, subject to certain limitations set out in the UK-EU agreement.

The TCA replaces the EU rules on freedom of movement of goods with a more limited free trade area regime and going forward effectively brings to an end in the UK the EU rules on freedom of movement of services. This applies to intellectual property rights and therefore to software licencing. As shown by Part Two, Heading One, Title V (Intellectual Property) of the TCA which simply states that the TCA:

“does not affect the freedom of the parties to determine whether and under what conditions the exhaustion of intellectual property rights applies”.

The position on exhaustion of rights in the UK is now covered by the Intellectual Property (Exhaustion of Rights) (EU Exit) Regulations 2019 and for the moment favours EU developers/vendors. This legislation makes the relevant changes:

  • Any software put on the market before 2021 in the UK or EU, and to which the exhaustion principle applies, will continue to be deemed exhausted for distribution rights as per the Software Directive and ruling in UsedSoft.
  • For software placed on the market in the EU after 2020, exhaustion will apply in the UK. Therefore a UK software developer/vendor cannot stop an EU purchaser of their software selling it back into the UK once it has been exhausted.
  • For software placed on the market in the UK after 2020, exhaustion will not apply in the EU. Therefore a EU software developer/vendor can stop a UK purchaser of their software selling it back into the EU once it has been exhausted.

Sign of the times

UsedSoft’s effectiveness provides a useful microcosmic example of the development of software licencing. Firstly its relevance has been diminished by increases in the capability of cloud computing and the Software-as-a-Service model. Such a trend seemingly irreversible. This has changed the nature of agreements between software developers/vendors and customers. Secondly, Brexit has tipped the balance in favour of EU software developers/vendors for the time being. Giving them the right to bar imports of their software sold in the UK under certain circumstances. How these two changes will continue to develop UK/EU software licencing law will be interesting to observe.

It is important to note that the UsedSoft ruling only applied to software and not to all digital goods. This was explored in the 2019 case, Tom Kabinet, mentioned above. In this instance it was ruled that the exhaustion principle did not apply to downloading an e-book for permanent use because that activity was covered by the communication to the public right which is not exhaustible. Whereas the distribution right in UsedSoft for software developers could be exhausted. It is unclear where a right becomes one to the public or one to distributers, but Tom Kabinet seems to show that it is in some way based upon the nature of the digital good.

EM law specialises in technology law. Get in touch if you need advice on software licensing, SaaS and Brexit or have any questions on the above.


E-Privacy – PECR and Brexit

E-Privacy regulations complement data protection laws by setting out privacy rights for electronic communications. The idea being that whilst widespread public access to digital mobile networks and the internet has opened up new possibilities for businesses and users, they have also created new risks for privacy. E-Privacy regulations have been a point of contention within the EU and reform has been expected for some time. On 10 February 2021, 4 years after the European Commission’s initial legislative proposal and to the surprise of many, the European Council reached a compromise agreement on their position on the E-privacy Regulation. What this means for E-privacy rules in the UK remains to be seen. With Brexit behind us, and therefore no obligation to introduce new EU legislation in the UK, but with an adequacy decision pending, and therefore a desire for the UK to align with the EU on data protection, it is hard to say whether or not the UK will choose to implement them. For more information on data protection and a potential adequacy decision after Brexit read our blog.

E-Privacy and PECR

PECR are the Privacy and Electronic Communications Regulations which comprise the E-privacy regulations in the UK. Their full title is The Privacy and Electronic Communications (EC Directive) Regulations 2003. They are derived from European law. PECR have been amended a number of times. The more recent changes were made in 2018, to ban cold-calling of claims management services and to introduce director liability for serious breaches of the marketing rules; and in 2019 to ban cold-calling of pensions schemes in certain circumstances and to incorporate the GDPR definition of consent.

What kind of areas do PECR cover?

PECR cover several areas:

  • Marketing by electronic means, including marketing calls, texts, emails and faxes.
  • The use of cookies or similar technologies that track information about people accessing a website or other electronic service.
  • Security of public electronic communications services.
  • Privacy of customers using communications networks or services as regards traffic and location data, itemised billing, line identification services (eg caller ID and call return), and directory listings.

How does this fit with the UK GDPR?

The UK GDPR sits alongside PECR. PECR rules apply and use the UK GDPR standard of consent (which is a high threshold). This means that if you send electronic marketing or use cookies or similar technologies you must comply with both PECR and the UK GDPR. Unsurprisingly, there is some overlap, given that both aim to protect people’s privacy. Complying with PECR will help you comply with the UK GDPR, and vice versa – but there are some differences. In particular, it’s important to realise that PECR apply even if you are not processing personal data. For example, many of the rules protect companies as well as individuals, and the marketing rules apply even if you cannot identify the person you are contacting.

If you are a network or service provider, Article 95 of the UK GDPR says the UK GDPR does not apply where there are already specific PECR rules. This is to avoid duplication, and means that if you are a network or service provider, you only need to comply with PECR rules (and not the UK GDPR) on:

  • security and security breaches;
  • traffic data;
  • location data;
  • itemised billing; and
  • line identification services.

Electronic and telephone marketing

PECR restrict unsolicited marketing by phone, fax, email, text, or other electronic message. There are different rules for different types of communication. The rules are generally stricter for marketing to individuals than for marketing to companies. Companies will often need specific consent to send unsolicited direct marketing. The best way to obtain valid consent is to ask customers to tick opt-in boxes confirming they are happy to receive marketing calls, texts or emails from you.

E-Privacy: Cookies and similar technologies

Companies must tell people if they set cookies, and clearly explain what the cookies do and why. You must also get the user’s consent. Consent must be actively and clearly given. There is an exception for cookies that are essential to provide an online service at someone’s request (e.g. to remember what’s in their online basket, or to ensure security in online banking). The same rules also apply if you use any other type of technology to store or gain access to information on someone’s device.

Communications networks and services

PECR are not just concerned with marketing by electronic means. They also contain provisions that concern the security of public electronic communications services and the privacy of customers using communications networks or services. Some of these provisions only apply to service providers (e.g. the security provisions) but others apply more widely. For example, the directories provision applies to any organisation wanting to compile a telephone, fax or email directory.

EU Council position on E-Privacy rules

On 10 February 2021, EU member states agreed on a negotiating mandate for revised rules on the protection of privacy and confidentiality in the use of electronic communications services. These updated E-privacy rules will define cases in which service providers are allowed to process electronic communications data or have access to data stored on end-users’ devices. The agreement allows the Portuguese presidency to start talks with the European Parliament on the final text. The agreement included:

  • The regulation will cover electronic communications content transmitted using publicly available services and networks, and metadata related to the communication. Metadata includes, for example, information on location and the time and recipient of communication. It is considered potentially as sensitive as the content itself.
  • As a main rule, electronic communications data will be confidential. Any interference, including listening to, monitoring and processing of data by anyone other than the end-user will be prohibited, except when permitted by the E-privacy regulation.
  • Permitted processing of electronic communications data without the consent of the user includes, for example, ensuring the integrity of communications services, checking for the presence of malware or viruses, or cases where the service provider is bound by EU or member states’ law for the prosecution of criminal offences or prevention of threats to public security.
  • Metadata may be processed for instance for billing, or for detecting or stopping fraudulent use. With the user’s consent, service providers could, for example, use metadata to display traffic movements to help public authorities and transport operators to develop new infrastructure where it is most needed. Metadata may also be processed to protect users’ vital interests, including for monitoring epidemics and their spread or in humanitarian emergencies, in particular natural and man-made disasters.
  • In certain cases, providers of electronic communications networks and services may process metadata for a purpose other than that for which it was collected, even when this is not based on the user’s consent or certain provisions on legislative measures under EU or member state law. This  processing for another purpose must be compatible with the initial purpose, and strong specific safeguards apply to it.
  • As the user’s terminal equipment, including both hardware and software, may store highly personal information, such as photos and contact lists, the use of processing and storage capabilities and the collection of information from the device will only be allowed with the user’s consent or for other specific transparent purposes laid down in the regulation.
  • The end-user should have a genuine choice on whether to accept cookies or similar identifiers. Making access to a website dependent on consent to the use of cookies for additional purposes as an alternative to a paywall will be allowed if the user is able to choose between that offer and an equivalent offer by the same provider that does not involve consenting to cookies.
  • To avoid cookie consent fatigue, an end-user will be able to give consent to the use of certain types of cookies by whitelisting one or several providers in their browser settings. Software providers will be encouraged to make it easy for users to set up and amend whitelists on their browsers and withdraw consent at any moment.


PECR continues to apply after the UK's exit from the EU on 31 January 2020. The draft ePR, described in detail above, which is still in the process of being agreed, was not finalised before 31 January 2020 and will therefore not become directly applicable in the UK. Once it is directly applicable to EU member states (which is likely 24 months after its coming into force), the UK will then need to consider to what extent to mirror the new rules. In any case, given that UK companies will continue to process data of EU end users, it will still be necessary to be aware of any discrepancies created by E-privacy reform in the EU.

The deadlock is over

It has long been considered that EU E-privacy regulations have lagged behind the technological progress seen in online marketing techniques and EU negotiations around reform have at times seemed never-ending. The agreement reached by the EU council will therefore be seen as a necessary improvement in legal certainty, although plenty of questions still abound.

PECR in its pre-reformed state will continue to apply in the UK. On 19th February 2021, the European Commission issued its draft adequacy decision that would allow EU-to-UK data transfers. While the E-privacy Regulation is not strictly relevant to the UK’s continued adequacy status, alignment on E-privacy rules would likely be viewed positively by the EU institutions, which could prompt the UK to update its laws in line with the new EU regime. The reforms will of course also be relevant to any UK business that operates in the EU. Even if the Regulation is finally adopted this year, it will not apply for a further two years meaning, these changes will likely not come into effect until 2023 at the earliest.

If you have any questions on E-privacy and data protection, data protection law more generally or on any of the issues raised in this article please get in touch with one of our data protection lawyers.

Space Law

Space Law: The Commercial Space Race Begins

Space law is the body of law governing space-related activities, encompassing both international and domestic agreements, rules, and principles. Parameters of space law include space exploration, liability for damage, weapons use, rescue efforts, environmental preservation, information sharing, new technologies and ethics. SpaceX, in May 2020, became the first private company to send humans to space. What this implies is hard to say. A recent article in the Harvard Business Review sees the sky, or should I say heavens, as the limit. With a healthy interplay between public and private investment, international co-operation and a rule of law suited to this harsh environment, it suggested that NASA’s prediction, in their 1977 report ‘Long-Term Prospects For Developments In Space’, that extra-terrestrial economies could one day out-strip terrestrial ones, was not so far-fetched. The Artemis Accords, signed in 2020 by the directors of 10 national space agencies, also indicates a shift in space law that better accommodate commerce.

Space-for-space economy

An important distinction made in the Harvard Business Review article was between a space-for-earth economy and a space-for-space one. The space-for-earth economy uses space to deliver benefits to those on earth. The use of satellites for telecommunications, internet infrastructure, or earth observation capabilities and national security. The real shift will be when companies are able to offer services in space for use in space – the space-for-space economy. However, creating such a market will require the existence of consumers beyond the stratosphere. Which may not exist for some time. In the meantime private companies will have to rely on public contracts. Hopefully, being able to supply to government space agencies will enable and invigorate supply to future commercial markets. Here are some examples of work being done:

  • SpaceX hopes to support transportation for large numbers of private space travellers. Currently their space-for-space transport solutions have been for government bodies (NASA) only. But with future decreases in the cost of launching spacecraft, SpaceX could be instrumental in putting people into space and creating the demand necessary for a space-for-space economy to develop.
  • Made In Space, Inc. is currently exploring high-quality fibre-optic cable, manufactured in zero-gravity for sale on earth. The company also recently received a $74 million contractto 3D-print large metal beams in space for use on NASA spacecraft. Such construction capabilities will be essential in a developing space-for-space economy.
  • In February 2020, Maxar Technologies was awarded a $142 million contractfrom NASA to develop a robotic construction tool that would be assembled in space for use on low-Earth orbit spacecraft. Such tools will be just as useful for a future private sector.
  • In 2015 Argotec and Lavazza collaborated to build an espresso machine that could function in the zero-gravity environment of the International Space Station. Such luxuries will be crucial for the development of an economy in space, even if for the moment they are mostly publicity stunts.
  • In 2010, Planetary Resources, Inc.and Deep Space Industries, were set up with space mining as their objection (lunar mining). Both failed because the lack of a space-for-space economy made the cost of extracting minerals to be brought back and sold on earth too high to be viable. The natural resources known to exist on the moon will, if a space-for-space economy develops, become big business.

Space law

In what legal system is this commercial activity taking place? Space law is by its nature extra-terrestrial and extra-territorial. Accordingly, its usage is governed by an extensive international legal framework, under the aegis of the United Nations (UN), made up of treaties, agreements and conventions governed by international law, which may be implemented into national law. The Artemis Accords have reinforced many of these frameworks and laid the groundwork for more commercially orientated space law.

The Artemis Accords

The Artemis Accords are named after the NASA project which aims to send the first woman and another man to space by 2024. They are an international agreement for cooperation in the civil exploration and use of the Moon, Mars, comets, and asteroids for peaceful purposes, and are grounded in what is often considered the foundation of space law, the Outer Space Treaty of 1967. The stated purpose of the Artemis Accords is to "provide for operational implementation of important obligations contained in the Outer Space Treaty and other instruments." The provisions:

  • Affirm that cooperative activities under these Accords should be exclusively for peaceful purposes and in accordance with relevant international space law.
  • Confirm a commitment to transparency and to share scientific information, consistent with Article XI of the Outer Space Treaty.
  • Call for a commitment to use reasonable efforts to utilize current interoperability standards for space-based infrastructure, and to establish standards when they do not exist or are inadequate.
  • Call for a commitment to take all reasonable efforts to render necessary assistance to personnel in outer space who are in distress.
  • Specify responsibility for the registration of objects in space.
  • Call for a commitment to publicly share information on their activities and to the open sharing of scientific data.
  • Include an agreement to preserve outer space heritage, which they consider to comprise historically significant human or robotic landing sites, artifacts, spacecraft, and other evidence of activity, and to contribute to multinational efforts to develop practices and rules to do so.
  • Include an agreement that extraction and utilization of space resources should be conducted in a manner that complies with the Outer Space Treaty and in support of safe and sustainable activities. The signatories affirm that this does not inherently constitute national appropriation, which is prohibited by the Outer Space Treaty. They also express an intent to contribute to multilateral efforts to further develop international practices and rules on this subject.
  • The Accords provide for the announcement of "safety zones", where operations of other nations or an anomalous event could reasonably cause harmful interference.
  • Include a commitment to mitigate space debris and to limit the generation of new, harmful space debris in the normal operations, break-up in operational or post-mission phases, and accidents.

National framework – UK

The UK has some of its own space law. The UK Outer Space Act 1986 sets out the UK's obligations under the various international treaties and principles covering the use of outer space. This Act also covers entities in certain of the UK's overseas territories and the Channel Islands, as well as the Isle of Man, and requires all those seeking to launch or procure the launch of a space object, operate a space object or undertake any activity in outer space, to obtain a licence. Licensing and other powers are conferred on the Secretary of State for the Department of Business, Energy and Industrial Strategy (BEIS), who carries out these powers through the UK Space Agency (UKSA). The UKSA was launched in April 2010, bringing all UK civil space activities under one single management. The UKSA began operation as a full executive agency on 1 April 2011.

The Space Industry Act 2018 is space law intended to make provision for space activities including vertical launches and suborbital activities in the UK. The UK government intends that licences under it, including for launch and sub-orbital activities, will be granted by 2021. Secondary legislation will be enacted to cover specific aspects of the Act, including licensing and insurance requirements.


The status and liability of commercial use of outer space, including the moon and other celestial bodies, is not very clear under the existing space law regimes. According to Article VI of the Outer Space Treaty 1967 and Articles II and III of Liability Convention 1972, the country in which the launch of the spacecraft takes place is liable for any activities in outer space. Even in the case of non-governmental activities, the launching state is liable. The possible litigation relating to the commercial activities are mainly the financial consequence of damage caused and also the technical complications that private entities face in case of supply of defaulted parts to national space agencies.

Legal status of resource exploitation

No nation claims ownership of any part of the Moon's surface, and the international legal status of mining space resources is unclear and controversial.

Russia, China, and the United States are party to the 1967 Outer Space Treaty (OST), which is the most widely adopted treaty, with 104 parties. The OST treaty offers imprecise guidelines to newer space activities such as lunar and asteroid mining, and it therefore remains under contention whether the extraction of resources falls within the prohibitive language of appropriation in the treaty. Although its applicability on exploiting natural resources remains in contention, leading experts generally agree with the position issued in 2015 by the International Institute of Space Law (ISSL) stating that, “in view of the absence of a clear prohibition of the taking of resources in the Outer Space Treaty, one can conclude that the use of space resources is permitted”.

Seeking clearer regulatory guidelines, private companies in the US prompted the US government, and legalized space mining in 2015 by introducing the US Commercial Space Launch Competitiveness Act of 2015. Similar national legislations legalizing extra-terrestrial appropriation of resources are now being replicated by other nations, including Luxembourg, Japan, China, India and Russia. This has created an international legal controversy on mining rights for profit. James R. Wilson, a legal expert stated in 2011 that the international issues "would probably be settled during the normal course of space exploration." In April 2020, U.S. President Donald Trump signed an executive order to support moon mining.

The final frontier

With the huge commercial potential that space offers comes the huge mobilisation required for its realisation. More than a little bit of luck will be needed to see dreams realised in the near future. Three things are certain: the private sphere will need invigoration by both government contracts/investment and their willingness to deregulate, such as allowing private space travellers to take on more safety risks than government funded ones; a vigorous upholding of the rule of law will create a bedrock for competitiveness; and a transcendence of geopolitical divides will ensure safe and unimpeded economic development.

Whilst the Artemis Accords have introduced some co-operation between nations on the question of how to regulate activity in space, it lacked two signatories: China and Russia; and failed to clarify whether, under space law, resource extraction could constitute national appropriation of areas in space.

EM law specialises in technology law. Get in touch if you have any questions on the above.

Robot Manufacturing

Robot Manufacturing: Product Liability Law

Robot manufacturing is a growth industry as the costs of producing robots are going down while the savings in labour costs are rising. With the rise and rise of automation in all areas of life, the word robot has come to mean a wider variety of things. Artificial intelligence (read our blog on some legal issues) has received the most amount of attention recently especially given its crossover with big data (read our blog). But what about the more conventional notion of a robot – the walking, talking lump of steel, more willing to do jobs we’re not so keen on. The sort that product liability law applies to more obviously. This blog covers some issues that a robot manufacturer may encounter when putting such a product on the market.

Robot Manufacturing - product liability and safety risk management

Product liability lies in the accountability faced by a manufacturer of a sub-standard, defective or dangerous product. Such accountability applies to the members of the public who purchase such a product and those below a manufacturer in the supply chain. Contractual protections, insurance and effective risk management can be used to protect a manufacturer from such liability.

Can liability for a dangerous or defective product be excluded or limited?

Contractual protections create a variety of scenarios. Whilst a manufacturer may wish to limit its own liability to parties beneath it in the supply chain, they may well wish to enhance the liabilities of a manufacturer above it. The terms of a contract are the vehicle by which this can be achieved. Additionally a robot manufacturer will want to be certain that quality and safety standards are judiciously applied to every level of its supply chain, especially key suppliers. Given the potential technological complexity of such an industry, it may even be useful to seek the advice of specialist consultants who have the know-how to ensure all the liability that should be attributed to suppliers is and that a comprehensive set of standards is agreed to in the contract.

There are various ways that robot manufacturing companies can do this. Limiting and excluding liabilities within their contracts can be one way – but this is only possible for certain things. There are restrictions on limiting liability for dangerous or defective products. Restrictions that overrule contractual clauses. Robot manufacturers should therefore look to other means, i.e. non-contractual, to control their risk.

Different considerations need to be taken into account when dealing with the various parties within the supply chain. For example, manufacturers, distributors, importers and retailers will all have concerns specific to the role that they undertake.

Is there an effective quality and safety assurance programme in place?

Effective quality assurance is at the heart of non-contractual risk aversion for product manufacturers. This is particularly important in the robot manufacturing industry given that the products usually involve a lot of automation and therefore the blame for something going wrong is more likely to fall on the manufacturers’ shoulders, rather than the customers. Setting up an internal committee to oversee product safety is useful first step. The team should incorporate members from all over the business to ensure nothing is missed. The committee's function should be: to review products and their associated documents; ensure that all appropriate regulatory and internal procedures have been followed and documented before and after marketing; authorise any necessary action (for example, changing warnings or design); review after-sales monitoring reports for trends and significant incidents; review insurance arrangements.

Additionally, keeping good records of exactly what was supplied when and by whom can simplify such a committee’s job.

Is there an effective enquiries and complaints system in place?

A robot manufacturing company must be able to respond to any complaints or enquiries with regard to a product’s safety. This is a legal requirement as well as being based on a desire to look out for your customers and improve your product. Things to think about: does the company have a system to handle customer enquiries and complaints? If so, could it be improved? Are staff adequately trained? Does the company have a policy of recovering allegedly unsafe items and investigating and recording the items and circumstances? Is there a systematic review of adverse incident information involving multi-disciplinary input from different departments? Can the company identify repeat claimants who may not be genuine?

The Services Directive (2006/123/EC), before Brexit, created an obligation to inform customers of how to make complaints and how manufacturers should deal with such complaints. The Services Directive is implemented in the UK by the Provision of Services Regulations 2009 (SI 2009/2999) (PSRs). The PSRs apply to most product manufacturers in the UK and introduce obligations around how to respond to enquiries or complaints about their products.

After Brexit, the Provision of Services (Amendment etc.) (EU Exit) Regulations (SI 2018/1329) implemented this EU law into UK law. All of the obligations around how to deal with enquiries or complaints essentially remain the same. Although some changes were made to EEA-specific provisions. This included the revocation of a requirement not to discriminate against customers based on their place of residence. This means that manufacturers in the UK could treat customers in the EEA differently to customers in the UK now that we have left the EU. The practical implications of this change are yet to be seen.

Robot Manufacturing - Data protection and privacy

The use of robots (drones being a good example) fitted with cameras or other sensors which can collect personal data such as images of people or vehicle plate numbers, geolocation data or electromagnetic signals relating to an individual's device (for example, mobile phones, tablets, Wi-Fi routers, and so on) can have privacy implications.

At EU level, there is no data protection legislation specific to the use of robots/drones; the applicable legal framework is contained in the General Data Protection Regulation (EU) 2016/679 (GDPR). In the UK, the processing of personal data via robot/drones is subject to the GDPR and the Data Protection Act 2018 (DPA) and the legal provisions applicable to CCTV systems. After Brexit, the GDPR will be retained in UK law and amended to become the UK GDPR. For more information on data protection after Brexit read our blog.

The GDPR and the DPA set out the conditions under which personal data can be processed and provide for certain exemptions and derogations, the most relevant being:

  • Household exemption: This applies to the processing of personal data in the course of a purely personal or household activity. This exemption could potentially apply to individuals using robots/drones for their own purposes. However, the ECJ has narrowly interpreted this exemption in the context of the use of CCTV camera. As a result, its application will depend on the specific circumstances of each case. The Information Commissioner's Office (ICO), the UK data protection regulator in charge of enforcing GDPR and DPA requirements, has issued guidance in relation to the use of drones. The ICO makes a distinction between the use of drones by "hobbyists" and their use for professional or commercial purposes. Although "hobbyists" would be likely to be exempted from the GDPR and the DPA on the basis of the household exemption, the ICO has provided tips for the responsible use of drones, inviting people to think of privacy considerations and to apply a common sense approach when recording and sharing images captured by a drone.
  • Journalistic exemption: In cases where personal data is collected through drones with a view to the publication of some journalistic, academic, artistic or literary material. In this case, processing would, under certain conditions, be exempt from many data protection obligations to the extent that such obligations would be incompatible with the purposes of journalism, academic, literary or artistic purposes which are sought by the processing.

Here to help

Robot manufacturing companies come up against many of the same legal issues as other product manufacturing companies. Having risk assessment procedures in place, as well as mechanisms to deal with potential faults, should reduce liability. However, robots are likely to be able to collect data and so data protection law also becomes important.

EM law specialises in technology and contract law. Get in touch if you need advice on Robot Manufacturing or have any questions on the above.

Selling A Software Business

Selling a Software Business - Things to Consider

Software comes in all shapes and sizes, serving a diversity of customers broadened by the internet and strengthened by the onset of generations for whom its application is second nature. Whilst selling a software business will meet unique challenges, there are a number of common threads when considering the legal side. This blog covers a range of topics that, if the seller takes on board, could ensure a buyer’s trust and cooperation when negotiating an agreement.

Selling a Software Business - Intellectual Property Rights

A likely first thing on the mind of a buyer will be to understand and secure all intellectual property rights in the target software. This will mean carrying out due diligence and if necessary obtaining an assignment from the owners of such rights. The business and its licensors should own all the relevant rights but if things haven't been done properly the owners could, for example, be consultants to the business. Difficulties arise when dealing with previous consultants who take such rights with them after leaving the developers or business which originally created such software. A seller should therefore do all it can to review intellectual property rights when creating software that it may one day wish to sell. If all else fails, indemnities may be the only way to ensure a buyer is comfortable with the purchase.

Software often uses licenced-in intellectual property rights from third parties. Having a strong understanding of exactly what these are and whether it is possible to grant sub-licences under them should be considered. This will mean reviewing the software’s process of production to ensure that no such rights are missed.

Open source software (OSS) is software code that is usually made available to developers for free and can be licenced in a variety of ways. It would be a incorrect to assume that OSS is licenced in an unrestricted manner at all times, even though in recent years it has generally become less restrictive. BlackDuck is a tool which offers companies the opportunity to search the source code of products for any OSS. Any unclear licences can then be satisfied and again it is likely that a buyer will want indemnities or warranties to ensure that all the OSS has been dealt with. At the very least OSS usually requires an acknowledgement of the original author.

Selling a Software Business - Existing Customers

When selling a software business, a buyer is going to want to assess the revenues of your business, the reliability of such revenue and risks involved with providing services to each customer. Issues likely to arise in customer contracts include:

  • Limits and exclusions of liability.
  • Post-contract services such as maintenance and support obligations.
  • Termination rights - whether through an explicit change of control clause or termination periods, or by unclear drafting in the contract. Much can rest upon whether or not a buyer can rely upon long-term customers to continue to use the software after purchase.
  • Non-compete, exclusivity and similar restrictions. As well as affecting the software’s freedom to operate under such restrictions, they may give rise to competition law issues.

Selling a Software Business - Employee retention

Employees can in some cases be as valuable as the software itself, especially if the buyer is looking to develop the software. Employees often have a breadth of knowledge and experience with a piece of software that is difficult to put onto paper. If key employees are lost then as much information as possible should be put down in the software documentation. Employee retention or at least a point of contact with former employees of a software business may well be the pre-requisite of such an acquisition.

Selling a Software Business - Technology Infrastructure

The issue of technological infrastructure is changing. Before the existence of such readily available online platforms with which companies can access and build their own software, technological infrastructure was, for the most part, hardware. This meant that infrastructure was often difficult to integrate into a buyer’s system.

A seller needs to consider whether the technological infrastructure is shared with anyone (say a subsidiary or other company in the seller’s group), whether they plan to integrate the software into the buyer’s technological infrastructure and whether the software is in any way being provided by a third party:

  • Infrastructure shared with other members of the seller’s group – a number of solutions exist to this issue, the most common being licensing or transitional services arrangement within the group that is often limited in time and to particular services.
  • Integration in to buyer’s infrastructure – as well as technical issues of integration and compatibility, if the infrastructure is duplicated, the target should undertake an assessment of whether these duplications can be eliminated and if the seller can terminate relevant supplier contracts.
  • Third parties – it used to be the case that companies using software would share a server with other companies and such hardware would have to be maintained to reach the requirements of each company. With the trend towards virtualisation of the computing environment, seller’s will often be beholden to a variety of third-party platforms to provide cloud space and hosting capabilities. Sellers should therefore review their position in relation to all such third parties to ensure they have the necessary rights to transfer ownership of any such agreements.

Selling a Software Business - Data protection

Data protection is an increasingly important issue for any software business. In assessing your business, and its IT systems, it is important to understand what personal data is handled, the protections and policies surrounding this, including any instances of breach of these policies, and the applicable laws such as the UK GDPR (for information on how Brexit has affected data protection law read our blog). It is attractive for a buyer to know that the seller takes data protection seriously and has built-in mechanisms to support it.

Developments in software supply have accounted for an increased risk in data protection. Subscription based services which often store customer data on the sellers platform (for instance, if it supplies software under a software as a service (SaaS) model) run into such issues as an obligation is created to secure and lawfully process the personal data being stored by the seller. Software often used to be sold anonymously, and without updates, external content, or other means to identify the user, and the seller was not storing personal data for its customers (because there were usually no logins or other data collections linked to a cloud-based platform). Data protection law is forever morphing in response to the rapidly developing technological landscape and so it could be wise to review your position at multiple points along the timeline of implementing the acquisition of a software business.


Cybersecurity is set to become an increasingly important issue for sellers in any software acquisition. On 10 May 2018, the Network and Information Systems Regulations 2018 (SI 2018/506) (NIS Regulations) came into force. They place minimum cybersecurity and incident notification obligations on relevant digital service providers. If the software qualifies as an in-scope digital service provider under the relevant legislation, then it will be important for the seller to understand:

  • What network and information systems it relies upon to provide its services.
  • What measures it takes to manage the risks posed to the security of those systems (including with a view to ensuring continuity of its digital services).
  • What means it has of monitoring and assessing any incidents that have a substantial impact on the provision of its digital service.
  • How it reports such incidents to the Information Commissioner's Office (ICO), the UK regulator in this area, and in what timescales.
  • Failure to abide by the minimum cybersecurity standards and incident notification requirements set out in the NIS Regulations, can attract substantial regulatory fines in the UK of up to £17 million. Relevant digital service providers are also under an obligation to ensure that they have adequate documentation available to enable the ICO to verify compliance with the relevant security obligations, meaning that in practice the ICO may request to see (and buyers will want to diligence) various policies including those relating to system security, incident handling, security monitoring, business continuity management, and compliance with international standards.

Here to help

Selling a software business comes with a range of challenges, whether or not it involves software. Software does, however, introduce some specific issues. The greatest change in recent times has been from software sold for on-premises installation, to software being available to sell via, in most instances, a SaaS platform. This means that, as a software business owner, you are more likely to rely upon third parties to deliver your services. Making sure that your relationship with these third parties is transferrable to a buyer is important. Equally significant is the likelihood of intellectual property rights being scrutinised by a potential buyer. Knowing that you own all aspects of the business you intend to sell will always be high on a buyer’s list of assurances. Software has a uniquely high chance of infringing IPR’s without being aware of it. For more information on this read our blogs Open Source Software and Legal Protection of Software.

EM law specialises in technology and corporate law. Get in touch if you need advice on selling a software business or have any questions on the above.

software as a service

Software as a Service (SaaS) - Some Key Aspects

Software as a Service (SaaS), instead of on-premises software licencing, continues to grow as a model. It is sometimes referred to as ‘on-demand software’, and was formerly referred to as “software plus services” by Microsoft. In a nutshell SaaS is a software licencing and delivery model in which software is licenced on a subscription basis and is centrally hosted by the provider. It exists on the cloud as opposed to being installed on the customer’s on-premises computing system. Read more about cloud computing in our blog.

Software as a Service is a growth area

SaaS has grown its share of the global enterprise software market from less than 2% in 2009 to 23% in 2019. By 2022, the global SaaS market is expected to be worth $140.63 billion. For customers, the service can offer greater access, convenience, and flexibility at a lower cost. And for vendors, it is easier, faster, and less expensive to roll out and sell to customers compared with traditional on-premises software development.

Common characteristics of SaaS arrangements

  • The service software is not installed or stored on the customer's computer systems. The SaaS provider (or its subcontractor) hosts core SaaS software applications. While the customer may receive limited client-side software to aid connectivity to the provider's network, the customer accesses the provider's software remotely on the internet or another public, private, or hybrid public and private cloud network.
  • The SaaS services and infrastructure are managed by or for the SaaS provider and shared by multiple customers. Each SaaS customer accesses the service applications remotely from various client devices, but does not configure, manage, or control the underlying cloud infrastructure.
  • Service customization is limited. The software configuration is largely or entirely uniform throughout the provider's customer base.
  • The supplier maintains the service software and provides service support subject to service levels. SaaS agreement maintenance and support provisions typically specify service levels and standards for the provision of support. Service levels define how well the provider needs to perform and are often accompanied by service credits if the provider fails to maintain certain service level standards.
  • Service fees accrue and are payable on a recurring, periodic basis. Fees may be based on provider subscription rates, the volume of customer use, or both.

Is Software as a Service More Cost Effective?

SaaS deployments are more cost effective (at least initially) than on-premise installations. SaaS customers generally pay a flat monthly fee per user for the software. SaaS implementations are also cheaper because companies don’t have to buy additional hardware or infrastructure to make the software work, so there are no capital expenditures with SaaS. You also generally don’t have to hire consultants to get the software installed as you often have to with traditional enterprise software. (There are exceptions to that generalization. For details, see Stephanie Overby’s article, “The Truth About On-Demand CRM.”) SaaS customers like the idea of a low up-front investment and a predictable expense stream, even though the cost advantages of the SaaS model may be counter-intuitive after three to five years of monthly fees.

Commercial risks in Software as a Service

Suppliers have quite understandably been marketing the potential benefits of usage-based payment models offered as part of cloud services. However, this carries an upside risk for customers if their usage of the services exceeds their expectations and budgeting. One of the key risks here is storage. If customers pay extra for more storage, they need to be certain they have policies in place to control increases in storage of information and data. Businesses need to think clearly about how long they really need to keep information (there is a clear link to legal obligations under data protection).

The most common approach now is a committed term of 1 to 3 years when signing up to an enterprise SaaS service. Suppliers want to be able to recognise revenue in their accounts and customers want to have a good degree of stability in their ICT delivery arrangements.

The commercial and contractual models for cloud service provision transfer risks back to customers, as compared to the outsourcing business model. Customers need to be able to manage a range of service delivery arrangements and to cope with the integration demands arising from using multiple cloud services. Customers need to be self-aware regarding their own capabilities to manage these risks. This may involve changes to business processes and cultures that ensure cloud services are used as efficiently as possible.

Cloud service provision, through its emphasis on standardised and commodity ICT, mean that ICT delivery organisations must work within the constraints of a standardised service offering. Businesses need to design and adopt processes that make the best use of the cloud service as it stands. A number of the traditional outsourcing providers provide consultancy-type services to assist cloud services users in these activities.

Data escrow

Software as a service data escrow is the process of keeping a copy of critical software-as-a-service application data with an independent third party. Similar to source code escrow, where critical software source code is stored with an independent third party, SaaS data escrow applies the same logic to the data within a SaaS application. It allows companies to protect and insure all the data that resides within SaaS applications, protecting against data loss.

There are many and varied reasons for considering SaaS data escrow including concerns about vendor bankruptcy, unplanned service outages, and potential data loss or corruption. Many businesses either ensure that they are complying with their data governance standards or try to enhance their reporting and business analytics against their SaaS data.

SaaS in the financial services sector

Firms subject to regulation by the Financial Conduct Authority (FCA) also have to comply with FCA security requirements.  The FCA has jurisdiction over data security breaches committed by financial services firms and continues the policy of its predecessor, the Financial Services Authority (FSA), in this area. The FCA actively pursues firms that fail to have adequate systems and controls in place to protect their customers' confidential details from being lost or stolen. For example, in 2018 it fined Tesco Bank over £16 million for failures relating to a cyber-attack.

Under the regulatory regime applying to financial institutions, firms have a responsibility to assess the risks of data loss and take reasonable steps to minimise the risks of this loss occurring. In this context, reasonable steps are deemed to be those that are proportionate to the nature, skill and complexity of the operations taking place.

Although the obligations of a financial institution are no different whether data is stored in a cloud or not, the cloud presents certain challenges in managing third-party suppliers who are responsible for handling such data within a cloud environment. At the centre of this is who has access to the data. It is easier to establish in more traditional models of service provision where the data is and who has access to it at any given time. This is more of a challenge in cloud service provision models.

The FCA has issued guidance to clarify the requirements on firms when outsourcing to the cloud and other third-party IT services. It sees the cloud as encompassing a range of IT services provided in various formats over the internet. This includes, for example, private, public or hybrid cloud, as well as Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS).

Here to help

SaaS is ubiquitous and any business looking to use or deploy IT solutions today will encounter it. The COVID-19 pandemic has accelerated the already fast-paced adoption of cloud computing by everyone from start-ups to multinationals. A key issue for customer and supplier is ensuring that the correct contractual and commercial agreements are in place to safeguard value for money but also that the software meets the specific needs of the customer. Software development for companies used to be highly bespoke and whilst SaaS creates opportunities for speed of access and off-premises maintenance, it also has the potential to leave a customer the victim of over-standardisation i.e. one-size fits all software solutions that don’t meet the customer’s business needs.

EM law specialises in technology and contract law. Get in touch if you need advice on a SaaS agreement or have any questions on the above.