The legal aspects of multi-cloud: DECIDEdly not unimportant! - Part 4 Other legal issues and Conclusions

In this fourth blog post, some of the remaining legal challenges are addressed and a conclusion is offered in regard to the current status of the project in M12 in legal terms.

Other legal issues

Other than GDPR, many legal issues surround the multi-cloud scenario proposed in DECIDE. Traditional issues in the cloud relate to security, confidentiality, access and control, jurisdiction etc. This is not different in a multi-cloud scenario. On the contrary, the use of cloud resources from different CSPs and the regular and dynamic re-deployment of applications definitely exacerbates these issues should something go wrong.

It should be considered whether DECIDE will engage with these potential issues and if so, to what extent and how. The most logical approach at this point seems to be that DECIDE either does not deal with these issues at all and leaves them with the application developer and their potential clients or decides to have a limited interaction with these issues by providing information on several aspects of the CSPs and their services endorsed in ACSmI, however without taking any responsibility or any active approach whatsoever.

Much like in relation to the legally relevant GDPR-related aspects that are to be flagged in ACSmI, DECIDE could flag information in relation to the security level and certifications a CSP offers, the level of confidentiality it contractually guarantees or the level of control and access by the CSP to the data stored in the container of the micro-service deployed with their resources. However, sharing such information is not straightforward. Either the CSP has to be incentivized to provide this information or it has to be otherwise obtained or mined from publicly available information. DECIDE is currently on the process to decide on the extent of involvement it considers necessary and/or appropriate here. Again, codes of conduct, certification or standardization tools may prove useful here. Such information is easy to obtain and there is often the involvement of a third party who has fact-checked certain statements.

Another issue relating to cloud computing is restrictions to the free flow of non-personal data identified by the European Commission, which spurred the recent “Proposal for a Regulation of the European Parliament and of the Council on a framework for the free flow of non-personal data in the European Union (COM(2017)495)”. The regulation aims to address laws, regulations, rules, practices or presumptions which aim at or simply have the effect of restricting the free flow of non-personal data within the Union, and liked to it, cloud-uptake within the EU. While this is of considerable importance for DECIDE from a future exploitation point of view, one could question how DECIDE can play a useful role in data localisation requirements incompatible with EU law or practices, beliefs, perceptions or presumptions having an equivalent effect of local storage and more limited cloud-uptake. If for example an authority from Member State X requires a bank to store certain information inside Member State X, DECIDE should accommodate for this through data location as an NFR, and DECIDE should clearly flag which CSPs contractually guarantee data to be stored in Member State X, but it should not touch upon the core matter that Member State X has restrictions of this kind. The bank in question should know this and inform the application developer of this (whether external or in-house). Unlike security or confidentiality, restrictions on the free flow of non-personal data have little to do with the CSP relationship or the CSPs themselves, but rather with the national legislation applicable to the application user.

In any case, whether for GDPR-relevance or otherwise, any information provided through DECIDE on legal aspects contains no guarantee that the information is correct or that the obligations or commitments contained therein will be followed. DECIDE needs to be careful to make clear it takes no responsibility whatsoever in this.

This question of responsibility connects to a last major legal challenge in DECIDE which has to be addressed, namely the general contractual framework and the contractual relationships within DECIDE. There is of course the contractual relationship between the DECIDE user and the consortium or the entity exploiting the DECIDE tools (which relates to how the DECIDE tools will be made available, in the cloud or as locally installed software), but the more important contractual relationship relates to how CSP services are contracted through the use of DECIDE.

In order to assess this, first the contracting point has to be determined. The contracting point is the first point in the DECIDE workflow where an actual binding contract needs to be present. OPTIMUS for example, can generate the most optimal deployment configuration based on the information available in ACSmI on the different available cloud resources, without having to actually contract these services. However, it is not necessarily so that binding contracts are only needed at the time of deployment. After all, applications created and run through DECIDE will also need to offer certain contractual terms to their users. The Service Level Agreement (SLA) offered to the users will actually be in the case of DECIDE a Multi-Cloud Service Level Agreement (MCSLA), composed of the SLAs of the underlying cloud services used, with adaptions made based on a pre-defined function in order to account for the fact that a multi-cloud application is more or at least different from a mere combination of the underlying services in terms of what service level can be offered. It has to account for Nonetheless, in order to run this function and create the MCSLA, the actual terms of the contracted SLA need to be known. For example, if all services involved offer 99% availability, the final application cannot offer 99% or more availability itself. As such, the contracting point is definitely earlier than right before deployment of the service, so that the tool involved in proposing a MCSLA to the application developer can run with verified and legally binding information. The application developer can then adapt these terms if desired.

Knowing the contracting point in DECIDE aids in determining the contracting parties, or, rather, in determining the desired contracting parties. In a straightforward scenario it is the application developer who directly contracts the services from the CSPs. This however, poses certain problems.

Earlier posts in this series already touched upon issues of contractual leverage and their relationship with GDPR obligations. Moreover, given that DECIDE aims at and relies upon dynamic and regular re-deployment of applications (although without touching upon continuity), direct contracting might not be able to reach the desired level of dynamism given that one needs to contract different CSP services separately and obtain different credentials to access these services. If ACSmI on the other hand, as touched upon before, would contract all available CSP resources and re-sell them through the DECIDE channel as a whole, application developers would only need to authenticate themselves in the DECIDE framework and all re-deployment could more easily be done through accessing CSP services through DECIDE only, the ACSmI special purpose vehicle (i.e. a separate company) having accessed the CSP’s platform and contracted the services before. This will facilitate the real-time creation of a MCSLA based on the SLAs in force for the contracted services needed for deployment. The MCSLA editor would run the function, proposing a final MCSLA, to which the application developer can make certain adaptations before offering it to the application customers. That way, the composing SLAs underlying the MCSLA will be secured without any effort on the part of the application developer being required. DECIDE could even opt to enable the application developer to go back to OPTIMIUS at this stage or even to make adaptations in the application description so as to tailor the MCSLA that results from this to the needs of its customers.

Another reason to go for this option of having a special purpose vehicle (i.e. a separate company) is that smaller CSPs often do not allow for equally dynamic contracting as the bigger players do. Contracting services through Amazon for example is very easy and practically only requires a credit card and an Internet connection. These services can be easily purchased, as well as easily discontinued. Opting in and opting out of the use of the service is very well facilitated and as such naturally allows for dynamic contracting. Smaller CSPs typically do not allow for this and work on the basis of a more traditional contract, which includes commitments in terms of volume, time etc. and is typically accompanied by penalty clauses of some kind in case the terms of the contract are not fulfilled. The business model of these smaller (SME) CSPs clearly justifies this approach. These players add value by providing a bespoke solution to the customer, addressing specific (local) needs. Involving these players in DECIDE through dynamic direct contracting seems very challenging. However, if these players have a long running contract with ACSmI, nothing opposes the more dynamic re-selling of these services through DECIDE, even if set-up time would be slightly longer than that needed by the large CSPs on the market. Having smaller CSPs offering their services in DECIDE is of great importance to enable competition and because smaller CSPs might offer specific services characteristics larger CSPs do not offer e.g. in terms of location in a specific country Member State rather than in a certain region. Moreover, if some applications need a bespoke solution, at least in part, a specialized CSP might provided those service through DECIDE, with the more generic parts of the application being run on cheaper cloud resources offered by larger CSPs. Enabling all different approaches through the DECIDE framework massively adds value to the whole of the solution, rather than only offering the services of the dominant players.

DECIDE aims to address all these contractual challenges successfully in order to enable successful future exploitation.

Conclusion

In this series of blog posts, the DECIDE project was analysed through the eyes of a layman – in this case a lawyer. The aim was to offer a basic understanding of the aims of the project and to highlight some of the main legal challenges surrounding the project. Arguably, the blog posts open up more questions than they answer. This was the author’s intent. After all, at this stage of the project (month 12 of 36), it is quite normal that issues have been identified but not entirely solved and that important choices need to be made.  These blog posts aim to inform the general public as well as partners and their affiliates about those issues, with the underlying goal to spark discussion and invite feedback. While legal reflections are often overlooked in technical projects, DECIDE will not make the same mistake, acknowledging, as the title already reveals, that the consortium is aware that the legal aspects of multi-cloud are decidedly not unimportant.

This project has received funding from the European Union’s Horizon 2020 research and innovation programme under grant agreement No 731533