IT consulting contracts
There is no such thing as a one-stop software contract that covers all services. This is because, when creating the Austrian General Civil Code (ABGB), the legislature did not consider the 21st century software industry with software as a service (SaaS), application service provider (ASP), platform as a service (PaaS) or infrastructure as a service (IaaS) contracts. In most jurisdictions, including Austria, there is generally no legally regulated contract-type obligation.
This makes it tricky in the software sector, because the core of every IT contract is to identify the specific good or service owed, describe it in detail and classify it legally under the correct contract type. Only then can the resulting legal consequences be contractually regulated. In practice, this poses a great challenge to entrepreneurs, customers and lawyers.
The problem in the software sector is that many IT goods and services offered can be the subject of different contract types, such as a purchase agreement, a work contract, a service agreement or a lease agreement. Depending on the classification, this can also result in different warranty, indemnity or risk transfer rights. It should be noted that the Austrian legislature provides special provisions for lease agreements (eg, according to section 1096 of the ABGB, the landlord must hand over and maintain the property in a usable condition). On the other hand, warranty law is only applicable to work, lease and purchase agreements, but not to service agreements.
Thus, the provider of a work contract owes a specific measurable success. In practice, services or goods under a work contract are often precisely defined in statements of work (SOW). If the provider does not fulfil these, it is not entitled to any remuneration for work and services.
In a service agreement, on the other hand, only diligent efforts (to be precisely defined in the agreement) are owed, but no explicit success. The specific quality of the service is usually categorised in detail in service level agreements (SLAs). In addition, lease elements can also be added to a service, for example when infrastructure is provided in separate units. In this case, the condition considered to be usable or unusable must be defined in the agreement, because not every fault is a defect in the legal sense and automatically makes the property or infrastructure unusable.
In disputes over interpretation, contractual ambiguities are always at the expense of the party who has made use of them (section 915 of the ABGB). A precise definition of the respective service or goods is therefore essential to avoid expensive and protracted disputes later on.
The danger is that the overall performance offered (including different services or goods) cannot be classified under a single type of contract, but this is not regulated clearly enough in the existing contractual text. In such cases, the absorption theory may be applied to the disadvantage of one party. Accordingly, the rules of the "dominant" contract type apply to all performance (all services and goods) sections.
The legal art therefore often lies in dividing the overall performance into individual parts at the time the contract is drafted and subjecting each part to the corresponding type of contract (combination theory). The following examples are the six most common types of IT contracts and are intended to provide a rough outline of how complex such a classification can be.
In this type of contract, the buyer acquires permanent ownership of hardware (eg an IT system or a physical server). This is a classic purchase agreement within the meaning of section 1053 ff of the ABGB. If the purchased hardware does not meet the contractual or customary requirements, it is defective. In such cases, the seller must provide a warranty in accordance with the general rules of section 922 ff of the ABGB, usually in the form of replacement or improvement, or (in the case of not insignificant defects) a price reduction.
This type of contract includes expert consulting for a wide variety of IT projects. Depending on the project, a distinction can be made here as to whether it relates to a concrete success, such as the performance of a penetration test on IT systems (work contract) or an accompanying consultation (eg, in the area of IT project management (service agreement)).
The classification becomes more complicated when software is not implemented locally on the customer's PC (client) but is hosted as a web application on an external server. The subject matter of an application service provider (ASP) contract is therefore the implementation of the software, support and software maintenance in return for a monthly usage fee. The provider is obliged to make the software available on its server. An example of this is an enterprise resource planning system. Depending on how they are structured, ASP contracts can therefore contain several elements (of varying degrees) of different contract types. The implementation phase can be regarded as a work contract, under which successful integration of the software into the customer's processes is owed. A lease component is the provision of this software. Software maintenance and support can be incorporated into the overall contract as an element of the service agreement.
In an infrastructure-as-a-service (IaaS) contract, the customer is offered an infrastructure in the sense of computing power, storage space, network bandwidths, virtual servers or server operating systems with firewalls. The customer is responsible for the installation and operation of its software components. However, the provider is usually responsible for a certain monitoring function and for ensuring that the infrastructure is operational. Examples of this are Amazon web services or Google computer engine. If the service is merely temporary access to storage capacity, it is a lease agreement. However, if the service includes, for example, website hosting, printing and postal services, it may also be a work contract. The support, monitoring and operating services offered are to be qualified as service agreements.
Platform-as-a-service (PaaS) is primarily addressed to software developers in companies, small and medium-sized enterprises and start-ups, which are provided with a development platform in which they can develop and distribute web-based applications for their end users. However, if access to this development environment is only agreed for a certain term, the underlying contract will have to be qualified as a lease. Examples of this are Google App Engine or Windows Azure. However, a work contract would have to be concluded if it is a development project for a PaaS customer. If only modules are to be sold for integration into developments of the PaaS customer, this is a purchase agreement for the respective module.
Software-as-a-service (SaaS) is a kind of successor to ASP, but one in which cloud-based concepts are in the foreground, offering the customer even broader usability. Here, the customer buys the use of ready-to-use application software via web browser or client software that runs on third-party servers or server farms. The customer gets access to the functionalities and interfaces provided by the provider via the web interface (or a program interface with limited adaptation rights). The customer only has to take care of the data exchange between its systems and the SaaS. The provider therefore not only operates the software itself, but also the entire required infrastructure and platform, as well as all the necessary updates and upgrades. In principle, no separate software licences are granted for this, but a monthly usage fee is paid. The advantage of using an application via SaaS is usually the low usage costs due to the "pay as you go" principle. Of course, SaaS can also lead to lower hardware (less storage space) and maintenance costs. An SaaS contract is therefore most similar to a lease agreement. Depending on its structure – such as in the case of customising in the sense of individual adaptation of the software (eg, a graphical user interface) – it may also be structured as a work contract.
The structure of an IT contract in Austria is often tied to the requirements of the individual IT project. Inaccurate service descriptions are the most frequent sources of error and therefore the most essential component of IT contracts. The design of the legal performance description depends on the respective delivery or service. Therefore, when drafting the contract, care should be taken from the outset to divide the individual service sections, if possible, and classify them under the respective contract types. In the case of software services that are structured as a work contract, it is therefore all the more important to define the specific success as precisely as possible in the SOW. In the case of more complex services, it is also advisable to define just as precisely the defects for which the provider must provide a warranty.
For services, it is essential to define the service itself as well as its quality and characteristics in the SLA, according to objectively measurable criteria. In addition, it is advisable to state in the SLA that no continuous 100% availability of the service is guaranteed.
In addition, for larger projects it makes sense to include strict penalties for violations of the SLA. The amount of these penalties is usually based on a percentage of the total or annual fee. When determining the amount of the penalty, parties should consider that this should provide the customer with an effective control tool to persuade the provider to comply with the SLA, but not bankrupt the provider in the event of a breach. Finally, parties should ensure that any agreement on penalties does not exclude any additional claims for damages on the part of the customer.
For more information on this topic please contact Tullia Veronesi at Schoenherr by telephone (+43 1 534 37 0) or email ([email protected]). The Schoenherr website can be accessed at www.schoenherr.eu.