Software-as-a-service (SaaS) applications have become indispensable in companies and are a common solution for managing work processes. The best-known SaaS products include Microsoft Office 365 and Google Workspace, as well as various services from providers of video conferencing, which became more important than ever during the coronavirus crisis. This article will give you an initial overview of SaaS applications, and also show what advantages they offer and their legal status.
I. What is SaaS?
Software as a service means that the provider does not offer the software itself for purchase, but merely its use as a product. The software itself and associated IT infrastructure are operated by an external IT service provider. This means that software as a service is a sub-area of cloud computing. There are numerous use cases, from the office and video conferencing applications already mentioned to solutions for human resources, customer relationship and financial management.
Besides software as a service (SaaS), other terms frequently used in this context include infrastructure as a service (IaaS) and platform as a service (PaaS). These business models are also sub-areas of cloud computing and are often shown together with SaaS in a pyramid-shaped diagram, since they can complement each other in the use cases. For example, an SaaS provider may make its software available to use by programming the software itself and then hosting it on a server, the use of which the SaaS provider purchases from an IaaS provider. The IaaS provider then takes care of operating the server.
Using SaaS products often results in what are known as service provider chains. For example, the SaaS provider uses PaaS services and the PaaS provider uses an IaaS service. There are a few special aspects to consider in service provider chains, such as the distribution of access options and fail-safe design. Third-country transfers can also play a role. The service providers must ensure data confidentiality and the client should have an overview of which service providers come into contact with their data sets.
Infrastructure as a service forms the bottom of the pyramid. IaaS providers merely provide the basic infrastructure (e.g. computing power, storage). Everything else is done by the users themselves. Examples of this are the providers AWS and Microsoft Azure.
At the middle level of the pyramid is the platform-as-a-service business model. The primary target group here is programmers who are provided with a platform where they can develop their own applications – without having to manage the necessary infrastructure themselves. Examples of PaaS are Google App Engine and Heroku.
SaaS is at the top of the pyramid, because the services developed in this business model are aimed directly at the end user.
Differentiating SaaS from PaaS and IaaS can sometimes be difficult, as services are often intertwined. It helps to consider the underlying technical design. From a case law perspective, SaaS has not yet received much attention. Often rulings refer to older types of services and contracts which are becoming less and less important in practice today.
II. Advantages of SaaS contracts
Using SaaS products offers multiple advantages for users. The acquisition costs for SaaS products are usually lower compared to on-premise solutions, while billing is often possible according to the pay-as-you-go principle, with SaaS frequently sold in subscription form.
Furthermore, using SaaS software is simpler compared to on-premise solutions, because the software does not have to be installed, maintained, serviced or updated. The provider takes care of all of this. The infrastructure requirements are also much lower, with internet access and a standard browser usually sufficient. Ultimately, the end user only receives access to the software.
III. Legal status
Before concrete questions can be answered, for example on contract design, liability or warranty, it is first necessary to clarify the legal nature of SaaS contracts.
In an SaaS contract, elements from different types of contracts come together: the law on contracts to produce a work (German Werkvertragsrecht) (Sect. 631 et seq. of the German Civil Code, or BGB), service contract law (German Dienstvertragsrecht) (Sect. 611 et seq. BGB), and lease agreement law (German Mietvertragsrecht) (Sect. 535 et seq. BGB).
Where we talk of a contract to produce a work, in contrast to a contract for services, in addition to merely doing something the provider actually also owes the other party a result. The provider may actually owe the other party success in terms of things like data migration, software implementation or individual software customisation. In these cases, the provider is not only required to try to carry out a data migration, but to actually do it.
But the provider may also only be required to do something in the sense of a service contract – for example, in the case of software training sessions. The provider is only required to provide the training by appropriately qualified personnel, but is not responsible for any particular success, such as that the participants have understood the software and are able to use it.
However, the core of any SaaS contract is the law on lease agreements. This is also the opinion of the Federal Supreme Court (BGH, judgment of 15 November 2006 – XII ZR 120/04). The judgment was passed back in 2006, so it is older than many SaaS business models in use today. Overall, there isn’t a huge amount of case law on SaaS. Nevertheless: providing software for the purpose of use is most comparable to the transfer of possession under lease agreement law. This has long been disputed because lease agreement law requires that the lessee obtains possession of a thing and that the lessor completely relinquishes that possession. Under an SaaS contract, however, the software remains the property of the provider – only using it is made possible. Moreover, from a legal point of view, software is not a “thing”. However, according to the BGH, this transfer of use for a limited period of time is so comparable to the regulations and the purpose pursued by the law on lease agreements, that the latter defines the essential character of any SaaS contract.
The question often arises as to which part of the contract is subject to lease agreement law, which to the law on contracts to produce a work, and which to the law on service contracts. In principle, whichever law is applicable to the individual parts of the performance should be applied, so for example a data migration should be subject to the law on contracts to produce a work, while provision of the software itself would be covered by the law on lease agreements. If the contract as a whole is affected, or if a part of the performance cannot be separated in a meaningful way, then the law that forms the focus of the contract, usually lease agreement law, is applied uniformly. The specific law is applied accordingly in the case of defects in performance (if there is a defect in the data migration, for example, then the law on contracts to produce a work), whereas the termination of an SaaS contract is generally governed by the law on lease agreements.
Updates and upgrades should also be kept well apart legally. Since the differences between the two are not always technically distinct, they are not easy to distinguish. However, the difference is relevant from a legal perspective, because they are associated with different types of contract.
As is often the case when drafting contracts, there are plenty of potential pitfalls in the SaaS area. Without claiming to be exhaustive, the following addresses some typical issues that clients may encounter with SaaS contracts.
As a rule, SaaS contracts are provided as pre-formulated contracts and thus fall under the regulatory scope of standard business terms (Sect. 305 to 310 BGB). One of the consequences of this is that an invalid clause is automatically replaced by the statutory provision (the rest of the contract does not simply remain valid without the invalid clause). This is why particular caution is advised when using US contracts as templates for SaaS contracts. Often, for example, US SaaS contracts contain drastic liability exclusions that contradict the far more nuanced legal situation in Germany. If such a version is merely translated and subjected to German law, these liability exclusions are quite likely to be ineffective, with the consequence that only the statutory liability regime applies. According to German law, limitations are permissible in the case of strict liability (Sect. 536a BGB, e.g. unintentional programming error) or in the case of simple negligence (exception: breach of ‘cardinal’ obligations). Intentional or grossly negligent conduct as well as injury to life, limb or health cannot be excluded from liability (Sect. 307, 309 BGB). The same applies if the provider has assumed a guarantee or has restricted liability across the board.
SaaS products may change during the contract term. Functional descriptions and documentation must be adapted when the product changes. Often these changes take place platform-wide for a large number of users. To ensure that the contracts do not contradict these changes, these documents must be incorporated into the contracts in accordance with the GTC. One way of doing this is through the dynamic integration and labelling of links.
Furthermore, the service description should be carefully examined. This describes the software capabilities and features, thus defining the scope of services owed. A precise service description can thus also clarify the scope of liability.
Another important part of an SaaS contract is the service-level agreement (SLA). This includes provisions on the availability of the software, the accessibility of support, response and problem resolution times, maintenance windows and, if applicable, rights to reduce the price. Since the provision of the software is regularly subject to lease agreement law, provisions on the software’s availability represent a core point of the SLA. In principle, under a normal lease agreement the lessor owes the uninterrupted provision of the thing being leased. This can rarely be guaranteed to exactly the same extent with SaaS contracts. For this reason, the availability of the software and the consequences of any unavailability should be specifically agreed.
Special problem: Data protection
SaaS contracts usually involve what is known as processing on behalf of the controller pursuant to Art. 28 GDPR and therefore require a data processing agreement (DPA). There is an obligation to ensure technical and organisational measures to appropriately secure personal data. It is true that when using SaaS applications, the user’s data is processed and the user is fundamentally responsible for this data. However, since the software is operated and administered by the provider, the provider acts as a processor for the user and contractually assumes the guarantee with regard to data security. Furthermore, when processing data outside the European Economic Area, and not in a third country where the level of data protection has been declared comparable with that of the EU by the European Commission, an adequate level of data protection must be ensured. So the ECJ’s “Schrems II” ruling often plays a role when using SaaS as well.
IV. Conclusion and outlook
SaaS solutions are becoming increasingly popular and are being used more and more. They have great potential as a convenient and cost-effective solution for users.
The implementation of the Digital Content Directive will establish more clarity in the B2C sector. A legal framework for contracts on digital products will be created, which will also regulate points such as update obligations and payment with data by consumers.
In B2B contracts, on the other hand, it will still be necessary to consider each individual case and to examine many details more closely – from the content of the service being offered to questions of liability and warranty. Please contact us if you have any questions about software as a service and the law!