Cloud computing contracts

Types of contract

What forms of cloud computing contract are usually adopted in your jurisdiction, including cloud provider supply chains (if applicable)?

The answers below do not identify CSPs by name; they reflect a composite, high-level, view of the CSAs and related materials reviewed. Moreover, they do not attempt to assess the reasonableness, fairness or validity of the terms outlined. Here, we adopt the approach taken by the SLALOM Project team: readers will be aware that, in assessing these matters, much will depend on the context of the service and deployment and service model or models adopted, the relative bargaining strength of the parties, the economic basis of the cloud arrangement, cost or no-cost, and whether it is a beta product or service, etc.

Following the conclusion of the UK–EU Trade and Cooperation Agreement, and given the lack of mutual recognition arrangements for regulated sectors, UK-based CSPs offering services in the European Union will need to track EU-wide developments in this sphere, to ensure compliance with EU guidance. The European Commission actively promotes the development and use of fair standard cloud computing contracts and standardised service level agreements to guarantee the quality of cloud services in the European markets. Details of the initiatives currently being undertaken and revised by the European Commission include:

  • Publication of an EU Data Act (to facilitate switching by customers of service providers, including cloud providers and improve data portability);
  • launch of a European Alliance for Industrial Data, Edge and Cloud;
  • joint investment in cross-border cloud infrastructures and services to build next-generation cloud supply (and to enable Common European Data Spaces);
  • a European marketplace for cloud services, as a single point of entry to find certified cloud services; and
  • an EU Cloud Rulebook for cloud services and infrastructures, which will provide clarity on the compliance of cloud services with relevant rules. 


Finally, the role of international standards, such as ISO/IEC JTC1 SC38 for cloud computing and distributed platforms, will be ever-more important as applied to cloud computing services, service level agreements (SLAs) and CSAs. See also the ISO 27000 family of information security standards (in particular ISO 27001 and ISO 27017 and 27018). 

Typical terms for governing law

What are the typical terms of a B2B public cloud computing contract in your jurisdiction covering governing law, jurisdiction, enforceability and cross-border issues, and dispute resolution?

With limited exceptions, the governing law of the CSP’s home jurisdiction or a chosen regional location will apply. For certain purposes, for example, EU data protection standard contractual clauses (SCCs) will mean that the choice of governing law and jurisdiction may be those of the customer’s location (although the new EU SCCs envisage that parties in some circumstances be able to select the governing law and choice of jurisdiction of any EU member state, such as when the EU SCCs are to cover multiple originating country transfers). Courts (rather than arbitral tribunals) competent in the CSP’s jurisdiction are most commonly chosen, with just less than a quarter of CSPs surveyed opting for binding arbitration clauses (Queen Mary Cloud Study). US CSPs usually require all customers to commit to compliance with applicable US export controls, sanctions and related laws and regulations.

The Queen Mary Cloud Study indicates that of the 40 CSP terms of service (ToS) surveyed, around half were governed by English or Irish law (in respect of English contracting parties, although this is based on the authors identifying the law applicable to consumers in the United Kingdom, where the ToS provided for differing choices of law depending on the identity of the customer), with the remainder governed by the law of a US state, Luxembourg or Switzerland.  However, for the largest cloud providers offering services to UK customers, governing law for business customers is the law of Luxembourg (AWS), Ireland (Microsoft) and law of California (Google Cloud). 

Following the United Kingdom’s withdrawal from the European Union, it may be that UK-based CSPs making agreements with EU entities give extra consideration to the provisions which are most appropriate for jurisdiction and enforcement, although changes to clauses are probably only likely where a CSP identifies a particular local law issue in a relevant member state. We have already seen Alphabet change Google’s contracting entity for UK customers from an Ireland-based entity to Google LLC, which is registered in the US, and change the governing law to Californian law, which it ascribes to the United Kingdom leaving the European Union. VMWare has also updated its ToS so that the governing law is now the ‘laws of Ireland’ if the billing address is outside the United States (and the laws of the state of California and the federal laws of the United States, if the billing address is in the United States). It remains likely UK-based business customers may see (depending on post-Brexit changes to the data protection regime in the UK following the grant of the UK’s adequacy decision) more non-UK CSPs opting to contract through non-EU entities using US governing law and jurisdiction clauses. This would have an impact on UK customers’ ability to seek redress for breach of the terms of service.

Typical terms of service

What are the typical terms of a B2B public cloud computing contract in your jurisdiction covering material terms, such as commercial terms of service and acceptable use, and variation?

Pricing and payment

Pricing will, of course, vary depending on the deployment and service model offered, and whether the contract is formed online or offline. Some CSPs reserve the right to vary charges for existing services. There are usually remedies for late payment, including interest and, in some cases, the right for the CSP to suspend service for payment defaults. If the customer defaults on payment when due, all CSAs reviewed entitle the CSP to terminate them.

 Suspension of service by the CSP

It is common to see suspension rights in addition to specific termination rights (and sometimes for the same or overlapping triggering events). The most typical cause for suspension is where there has been a breach by the customer or an end user of the acceptable use policy (AUP), which will usually include the customer or an end user causing security risks to the cloud service, the CSP or other cloud service users, or infringing third-party rights or failing to pay or entering insolvency proceedings.

Suspension may be on notice or, where urgent (as in the case of security risks), without notice. In some cases, the customer will remain liable to pay the charges during the suspension period, while service credits will not accrue.


Acceptable use policies

The CSAs of all the major CSPs contain an AUP: it has become one of the defining features of CSAs in the United Kingdom and elsewhere. Readers will be familiar with the standard terms of AUPs, which address conduct by both customers and their end users in using the cloud services, and will include prohibitions on:

  • illegal activities of any kind;
  • violation of any third-party rights (including reverse engineering of the service) or conduct that violates any applicable law;
  • gaining or attempting to gain unauthorised access to any networks, systems, devices or data;
  • unauthorised disruption of any networks, systems, devices or data;
  • sending unsolicited messages or marketing; and
  • distributing malware.


There are also typically restrictions on the type of customer who can use the services (by age limit) and the purpose for which the service can be used.

Breach of the AUP may entitle the CSP to suspend or terminate the CSA – in some cases, a breach by a single end-user could result in suspension or termination. Other CSAs contain indemnities for AUP breaches. Where the AUP has been breached, or the CSP suspects the breach was due to illegal conduct, the CSP may report those activities to the authorities or interested third parties and reserve the right to cooperate with them.


One of the more disquieting terms of CSAs in the United Kingdom and elsewhere is that CSPs may, without the customer’s consent, vary cloud services, SLAs and other terms of the CSA, usually without any justification and, in some cases, without the obligation to notify customers beforehand. However, it is becoming more common for the CSPs to include a notice period for at least some types of changes to the terms (eg, where a provider discontinues a material functionality of a service or materially alters a customer-facing API). This is usually done by posting a revised version on a website, by emailing the customer or through a notification in the user interface, and customers who continued to use the service are deemed to have accepted the new terms. Some standard ToS now expressly permit a customer to terminate for variation of the terms of the CSA, although this places the burden on customers to monitor the ToS to identify when the terms vary and is burdensome for customers using a multi-cloud model.

A very small number of the ToS surveyed in the Queen Mary Cloud Study expressly stated that the CSP’s contract terms would not vary during the contract period, providing a greater level of contractual certainty as to the applicable ToS. In B2C contracts, suppliers may only alter the terms of a contract of indeterminate duration unilaterally after providing the consumer with reasonable notice of the proposed variation (Consumer Rights Act 2015, Sch. 2, 11, 23).

Typical terms covering data protection

What are the typical terms of a B2B public cloud computing contract in your jurisdiction covering data and confidentiality considerations?

To reflect the entry into force of the EU GDPR, all the major CSPs operating within, or providing services to, the European Economic Area introduced detailed data protection and processing terms for incorporation into their CSAs, in some cases in separate addenda or supplements. Where we use the terminology ‘GDPR’ this refers to both EU and UK GDPR.

Typically, the GDPR-related terms include:

  • the allocation of processor and controller roles and functions between the customer and the CSP, with the CSP as processor and with the right for the CSP to appoint sub-processors (subject to the customer's right to object to the appointment of new sub-processors and with concomitant sub-processor obligations);
  • the application of technical and security features provided to the customer to enable it to comply with the technical and organisational measures required by the GDPR;
  • deeming of ‘documented’ customer instructions to the CSP with regard to the CSP’s processing of customer data in accordance with the GDPR;
  • confidentiality obligations of the CSP in relation to customer data;
  • terms for the handling of data subject access requests;
  • detailed operational security provisions, including security breach notification obligations on the CSP;
  • CSP data security certification and audits;
  • provision for the transfer of personal data outside the United Kingdom or European Economic Area (as appropriate), with the incorporation of the SCCs accordingly;
  • the return or deletion of customer data on termination of the CSA;
  • obligations relating to record-keeping of all processing activities; and
  • terms ensuring the processor's cooperation with the relevant regulator in the performance of their duties.


As of the time of writing, there have been no reported legal challenges emanating from the United Kingdom to CSP GDPR terms.

Typical terms covering liability

What are the typical terms of a B2B public cloud computing contract in your jurisdiction covering liability, warranties and provision of service?


Understandably, all CSAs contain limitations and exclusions of liability: some are written from a US perspective, while others are localised. The CSP’s liability is commonly limited (sometimes mutually) to the amount of charges paid by the customer – typically during the 12 months preceding the event giving rise to liability, with absolute caps ranging from US$20 to US$100,000. Liability caps of this kind are sometimes tiered by reference to different services (eg, the greater of a specified monetary amount or the total charges paid, depending on the service). In negotiated contracts, we generally see customers agreeing to a ‘super cap’ for CSP data protection breaches, rather than looking for unlimited data protection liability.

Some CSAs exclude from this limitation the CSP’s liability for third-party intellectual property right infringements (whether under an indemnity or otherwise), and for confidentiality and data protection breaches.

It is common for CSAs to exclude liability:

  • in general for direct and indirect, consequential, incidental, exemplary, punitive or special losses or damages (even if some of those kinds of loss or damages are not recognised in the UK jurisdictions and even if the possibility of such losses have been brought to the CSP’s attention); and


for a range of:

  • specific losses, including loss of revenue, loss of profits, loss of customers or goodwill, loss of use of data, loss of anticipated savings, loss of the use of the cloud service, etc;
  • causes (eg caused by breach of contract, inability to access a service, force majeure event or security breaches); and
  • theories of liability (eg, contract, tort or breach of statutory duty).


Not all of the broader contractual exclusion provisions will be binding under English law even for B2B contracts however, as where parties contract on standard form contracts that limit liability for breach of contract or for negligence, these clauses are required to be fair and reasonable in light of the circumstances at the time the contract was made (Unfair Contract Terms Act 1977, sections 2, 3, 11). Liability caps could also be the subject of challenge under Unfair Contract Terms Act 1977, depending on the context of the particular contractual relationship.

Some CSAs disclaim liability for unauthorised access to, and for the loss or destruction of, uploaded content and data. In other cases, CSAs will acknowledge the CSP’s liability for content or data loss where the CSP has failed to meet its own security obligations. Many CSAs require customers to take responsibility for making backup copies of their own content and data or otherwise mitigating their own risks in using the cloud service.


Warranties and provision of service

Some CSAs contain a CSP warranty that it will deliver the services in accordance with the SLA or some other service description. Some CSAs state that cloud services are provided ‘as is’. Almost invariably, any other express or implied warranties (eg, as to fitness for purpose, satisfactory quality, non-infringement) are disclaimed to the extent permitted by law. Some CSPs specifically exclude any express or implied warranty that the operation of the cloud service or software made available through it will be uninterrupted or error-free. The picture is slightly different in the consumer context, where CSPs will typically commit to providing the services with reasonable skill and care.



It is common for the customer to have to indemnify the CSP against the following actions by the customer and any end user:

  • any act or omission or use of the cloud service that infringes any third party’s rights;
  • breaches of the CSA generally and the AUP specifically;
  • infringement of applicable law;
  • creation or use of uploaded content; and
  • in each case where the act, omission, use, etc give rise to claims, costs, losses etc.


Where there are detailed data processing provisions, including data transfer agreements, some CSAs will provide for customer indemnification of the CSP against breaches of data protection law caused by the customer or another end user.


Service availability, quality, service levels and service credits

Many B2B public cloud CSAs contain or incorporate by reference specific SLAs as applicable to the service modules provided to the customer. For an example of CSA service levels applied by the major CSPs (and some others), readers should refer to the SLALOM Project’s documentation.

While many CSAs provide that customers will not be entitled to claim for service unavailability for scheduled or unscheduled downtime or other service interruptions, we are seeing more CSPs offering SLAs in which they commit to deliver a certain level of service, and offer compensation to customers for failure to meet the SLA in the form of service credits. These are usually expressed as a percentage of the customer’s monthly fees, usually set on a scale depending on the uptime percentage, thereby linking service credits to monthly spending, and usually capped at a percentage of a month’s fees. Where service credits are included in an SLA, these are typically stated to be the customer’s sole and exclusive remedy (which suggests the customer could not sue the provider for damages in relation to the service being unavailable). Some CSPs make specific claims or promises about their levels of service and are willing to enable the customer to terminate the CSA for stipulated breaches of those service levels, subject to following mandated procedures for doing so, with repayment of any prepaid charges. Many CSAs contain caps on the maximum amount of service credits allowable in a specified period.

The SLAs also require the customer to track downtime and make reports to claim service credits, with very few providers committed to proactively reporting on service availability levels. This would, of course, make monitoring and enforcing the SLA or service credit regime difficult for the customer. In other situations customers are required, within stipulated deadlines, to follow specified procedures to report service-level breaches, as well as providing details of them for verification by the CSP, which may retain the option of rejecting a customer’s claim. The SLAs also tend to exclude service unavailability where this arises from factors outside the CSP’s control (eg, force majeure events, network or device failures outside the CSP’s data centre, customer actions, third-party actions, the CSP system being down for maintenance or customer breach of the CSA or AUP). Customers will therefore usually need to accept the CSP’s limited liability and factor this into the overall risk assessment of cloud service adoption (against the advantage of cost and scalability). To mitigate risks, customers may want to consider cyber insurance and resilience testing.     


Business continuity and disaster recovery

In general, unless the CSP is providing a cloud-based business continuity service, CSAs do not contain any, or in any detail, business continuity or disaster recovery terms – although it is typical for CSAs to contain force majeure provisions excusing the CSP’s performance in such cases. This is a feature of CSAs in the UK, US and elsewhere (see the useful report, Public Cloud Service Agreements: What to Expect and What to Negotiate Version 3.0 produced by the Cloud Standards Customer Council). 

Usually, the customer is expected or obliged to make its own backup arrangements to ensure continuity. Sometimes, CSAs will refer to CSPs having their own disaster contingency plans for their data centres, using redundant processing and storage capacity to back up data held in those data centres, but without any contractually binding commitment to implement such plans.

Typical terms covering IP rights

What are the typical terms of a B2B public cloud computing contract in your jurisdiction covering intellectual property rights (IPR) ownership in content and the consequences of infringement of third-party rights?

The customer usually warrants that it owns or has all necessary rights to use its content (eg, software, data) processed by the cloud service or to grant any licences to the CSP under the CSA, and that its content or end-users’ use of the customer’s content will not breach the AUP (which may entitle the CSP to suspend or terminate the CSA) or that the customer will not use the services in any way which will or is likely to infringe third-party IP rights. Some CSAs require the customer to suspend access of an end-user to the service offering when the customer becomes aware of the end-user acting in violation of the obligations contained in the CSA. Some CSAs also contain an obligation requiring the customer to defend (and indemnify) the CSP against any third-party claim that the customer’s content infringes third-party IP rights, and pay the amount of any adverse final judgment or settlement. For this to be effective in the consumer context, it would need to be appropriately flagged so as to be incorporated into the contract, so the consumer understands the consequences of the obligation it is undertaking.

The customer retains ownership of all IP rights in content uploaded or created by it in using the cloud service. The CSP is usually granted a limited licence to use the content to provide the cloud service (eg, covering rights of access, storage or distribution, as applicable) or to act on feedback, or to comply with regulatory or governmental directions or orders, and in some instances, the CSP’s rights of use of the customer’s content are extended to cover advertising.

The CSP may use without restriction any suggestions for improvements to the cloud service made by the customer, in some cases, with an obligation to assign the ownership in such suggestions to the CSP.

The CSP reserves rights in all IP rights relating to its cloud services, including IP rights in the applications and infrastructure used in providing the services. The scope of the licence granted to the customer to use the IP rights is typically very limited (ie, revocable, non-exclusive, non-sublicensable and non-transferable) and granted solely so that the customer can use the services. CSAs also typically include a prohibition on decompiling or reverse-engineering the services, or access and use of the services, to develop a competitive product.

If the cloud services are found, or understood by the CSP, to infringe any third-party IP rights, the CSP may at its discretion, and usually as a preferred remedy, procure the necessary rights for customers to continue using the services, modify the services so that they become non-infringing without any material loss of functionality, or provide equivalent services in substitution for the infringing services; or failing that, to terminate the part of the cloud services offering concerned (in some cases making an express commitment to refund a prorated portion of the fee paid). In some cases, instead of the above ‘work around’ language, the CSP will undertake to defend or indemnify the customer against the claims, costs, losses, etc, arising from final judgments. These are usually expressed to be the sole remedies available to the customer. The AWS terms also emphasise that AWS shall have no responsibility for the customer’s use of third-party IP rights after it has notified a customer to discontinue such use and other CSAs make the customer’s ability to claim under an indemnity subject to the customer notifying the CSP within a short specified time period. Where CSAs are governed by the laws of a US jurisdiction, customers may find that the obligation to defend does not include the obligation to indemnify – though this is, of course, to be determined under the relevant US jurisdiction if validly chosen.

In addition, where a CSP’s offering comprises any open source software, this software will be made available to the customer under the terms of the applicable open source software licence. The VMWare terms of use enable a customer to obtain a copy of the licences and any source code (and modifications) that VMWare is required to make available under the open-source licences.

Typical terms covering termination

What are the typical terms of a B2B public cloud computing contract in your jurisdiction covering termination?

CSAs may allow termination for convenience on specified notice for both the customer and the CSP.

Either party will usually have a right to terminate for the material breach of the other, change of control of the other, or the insolvency of the other. There is often also a range of specific rights of termination by the CSP, including:

  • Non-payment by the customer of due invoices. Note that the ability of a supplier to terminate a contract where the counterparty has entered an insolvency or restructuring process has been limited by the new measures introduced into the Insolvency Act 1986 in June 2020 (by the Corporate Insolvency and Governance Act 2020), which render these types of ipso facto termination clauses in goods and services contracts ineffective. However, the ban on these clauses does not apply in respect of contractual arrangements with insurers, banks, electronic money institutions and operators of payment systems and infrastructure providers.
  • Where the cloud service is dependent on third-party IP rights (eg, software licences), when a relevant third-party licence expires or is terminated.
  • For a specified period of customer inactivity.
  • Where the customer or an end user’s use of the cloud service presents a security risk to the CSP or any third party (typically contained in the AUP).
  • General discontinuance of the service by the CSP.
  • Contravention of export and sanctions controls laws and regulations. 
  • One or more (other) breaches of the AUP or any other term of the CSA by the customer or an end user.


A CSA containing a termination clause allowing a CSP to terminate a contract of indefinite duration with a consumer without reasonable notice is liable to be unfair under UK consumer protection law, which may mean a termination clause is unenforceable against a UK consumer.

The consequences of termination may include:

  • the customer’s obligation to cease using or to return any proprietary material (eg, software), or to destroy any content provided by the CSP;
  • that the CSP will not erase the customer’s data for a specified period after termination (unless otherwise required by law), and in some cases that the customer will be entitled to retrieve its data for a limited period following termination, prior to the data being deleted (usually also subject to a charge by the CSP);
  • where the CSP has terminated for cause, that the customer must pay all unpaid charges for the remainder of the term; and
  • where the customer has terminated for cause, that the CSP will refund any prepaid charges for the remainder of the term.
Employment law considerations

Identify any labour and employment law considerations that apply specifically to cloud computing in your jurisdiction.

There is none that applies specifically to cloud computing.

However, depending on the cloud deployment model or service model adopted and the circumstances of the migration to cloud or the termination of the cloud service, cloud customers and CSPs should consider the application of the Transfer of Undertakings (Protection of Employment) Regulations 2006, as amended by (among others) the Collective Redundancies and Transfer of Undertakings (Protection of Employment) (Amendment) Regulations 2014 (together, TUPE). TUPE implements in the UK the EU Acquired Rights Directive 2001/23/EC.

In outsourcing transactions, particularly because the application of TUPE is so well established in the United Kingdom (since 1981), it has become customary for the customer and outsourcing providers to provide, in a specific and detailed manner, for the legal, regulatory and financial implications of TUPE in the outsourcing contract, allocating duties, risk, costs and liabilities between them. In public and hybrid cloud contracts, the issue is often simply not considered and, therefore, is not provided for, most probably because the parties do not expect that TUPE will apply to such cloud arrangements or because CSPs that are based outside the European Union are unaware of the Acquired Rights Directive and TUPE.

However, neither CSPs nor their customers should assume that TUPE cannot or does not apply in relation to any of the cloud deployment models or service models. They should at least consider the question and take advice accordingly. The application of the Acquired Rights Directive and TUPE to, and their effect on, outsourcing are now widely understood in relation to the UK, where since 2006 the government has increased the focus of TUPE’s application to outsourced services with the intention that TUPE should (if conditions are met) generally apply to outsourcing transactions. It is worth reiterating that TUPE is mandatory: parties cannot disapply or contract out of TUPE.

In broad terms, where TUPE does apply, it transfers automatically by operation of law the staff from one organisation to another. Their terms and conditions of employment and continuity of service are preserved, and there are other procedural and substantive protections for the staff before and after a ‘TUPE transfer’ (eg, protection against dismissal and protection against changes to the transferring staff's terms and conditions of employment). There are also prescribed information (and in some cases, consultation) processes that must take place before any transfer. Accordingly, if TUPE applies to a cloud computing arrangement (in which one of the key drivers is cost-reduction) the potential financial implications resulting from the constraints and obligations arising out of TUPE may be significant and could undermine the economics of the arrangement.

In the UK, the most relevant triggers for TUPE in the context of cloud computing will be (1) a ‘service provision change’ where an in-house IT service ceases to be provided by the customer itself and is then provided by the CSP – or (2) is migrated from one CSP to another CSP, or (c) the service is migrated from the CSP back to the original customer if it wishes to resume the IT service in-house. These all constitute a service provision change under TUPE Regulation 3(1)(b). The workforce (organised grouping) carrying on the activities of the service, which is liable to transfer, must be based in Great Britain and the principal purpose of that workforce must be to carry out those activities for the customer. In broad terms this means they must work wholly or mainly for the customer in the provision of the services; although they may still do work for others (see TUPE Regulation 3(3), and the government’s guidance on business transfers, takeovers and TUPE). More significantly for cloud computing arrangements, the activities to be carried out by the CSP must be ‘fundamentally the same’ as those previously undertaken by the customer‘s staff (see TUPE Regulation 3(2A).

So, the threshold question for a service provision change TUPE transfer in cloud computing migration is most likely to be: will the activities to be undertaken by the CSP be ‘fundamentally the same as those undertaken previously by the customer's IT staff?’ This will come down to an analysis of fact and degree. One – and only one – factor will be a reduction in the volume or scope of work, which is likely to be the case in a migration from traditional IT activities to the cloud (see Department for Education v Huke and another UKEAT/0080/12 and OCS Group UK Ltd v Jones and another).

At first glance, IT activities or services migrated to, say, a public or hybrid cloud, from which the customer may then receive very different cloud services (at least by reference to the scope and possibly volume) to the services or activities previously provided in-house, simply do not intuitively look and feel ‘fundamentally the same’ in the cloud. And – if they addressed the question at all – it would be understandable if the customer and CSP considered that the activities to be carried out by the CSP are not ‘fundamentally the same’ as the original in-house IT activities so that TUPE would not apply. This could be a very costly mistake. In addition, there could still be a ‘traditional transfer’ of an undertaking that retains its identity under TUPE.

Because the fundamental aim of TUPE and the Acquired Rights Directive is to protect the rights of transferring employees, the 'fundamentally the same' bar is a high one, and not easy to cross. 

There will, of course, be other questions about which of the customer’s staff members and how many of its IT workforce are in scope for TUPE, if it is likely to apply (see the government’s guidance on business transfers, takeovers and TUPE).

It is worth reiterating that TUPE can apply equally to the subsequent move by the customer from one CSP to another, or back in-house to the customer, subject to the rules referred to above.

In cloud computing arrangements, it is quite likely that the CSP will be based outside the UK or that the cloud services will be provided from an offshore location. If there is an assigned workforce based in the United Kingdom, TUPE can apply to such arrangements, even if the service is provided from offshore. This is, however, likely to result in that assigned workforce becoming redundant.