- about us
you are being redirected to the website of our parent company, Schönherr Rechtsanwälte GmbH
The new Digital Services Directive (DSD) aims to harmonise certain aspects of consumer protection law by providing consumers a mandatory warranty for digital content and digital services supplied by a vendor. First and foremost this concerns contracts on the purchase or rental of software (usually comprising licence agreements) or cloud services.
In theory, the DSD sets forth only a few changes to existing Austrian warranty law. Nevertheless, Austria chose to transpose the directive mostly by a separate law applicable only to consumers and largely resembling the wording of the DSD and the Sale of Goods Directive.
In general, Austrian warranty law has always stipulated that any good or service supplied for a price is to be delivered or rendered in conformity with respective contractual requirements, including qualities usually expected (but not explicitly specified in the respective contract) with such products or services. Such conformity would have to be maintained at the time of delivery in case of a purchase agreement or in case of a service, for the entire time such service is rendered.
Public statements of sellers or producers are regularly factored in when assessing what may usually be expected from a purchased product or service. This is applicable regardless of whether the contract is concluded B2B or B2C. However, the Austrian Consumer Protection Act provides for these provisions to be mandatory in nature in case of B2C agreements.
At first glance, the DSD seems to follow this idea for B2C contracts, but merely separates conformity requirements into requirements as stipulated in the respective contract (subjective conformity) and requirements that may be expected by a consumer pursuant to a detailed description of references to be considered when assessing such requirements (objective conformity).
As with existing Austrian law, the objective and subjective conformity of the software or service must be assessed at the time of supply if supplied in a single act of supply (i.e. purchase of a software licence not limited in time) or during the entire time the services are rendered if not supplied in a single act but continuously (software rental licence that has to be renewed regularly or any form of cloud services). It is therefore clear that continuous supply updates must be provided regularly so that the service fulfils conformity requirements at any point in time in which it is rendered. Otherwise the respective plaintiff would be entitled to the remedies provided by warranty law.
Up to now, no such requirement to provide for updates could be deduced from Austrian warranty law for software being provided in a single act of supply (e.g. purchased software).
However, this may change with the transposition of the directive. The DSD now also expressly stipulates that where software is supplied in a single act of supply for an indefinite period of time, updates are to be supplied to consumers so that the software remains in conformity not only at the time of supply but also for the period of time a consumer may reasonably expect "given the type and purpose" of the software.
In effect, this introduces a novel obligation to provide updates for software sold to consumers for as long as the software is initially expected to fulfil the measures of conformity. In the end, this will come down to how long a certain software product may be expected to be used for its intended purpose and when it may be expected to become obsolete.
Nothing in the DSD indicates that the respective standard for (objective) conformity of a certain (software) product would have to be reassessed continuously during the period of time in which conformity is to be maintained via updates supplied to the respective consumer. Hence, such updates do not need to comprise novel features or enhanced quality, performance or usability that go beyond what may be anticipated when the contract between the vendor and the consumer was concluded.
However, this standard for conformity may only be determined on an abstract level. As the mentioning of "security updates" in the DSD suggests, the inner workings of the software product itself may be viewed as a black box for such an assessment of conformity. Thus, only its required behaviour (input, output, performance, etc.) with regards to its hardware and software environment may be determined for the assessment of objective conformity. As such an environment may change with the passing of time (e.g. security vulnerabilities of the respective software become known, different network protocols are introduced/deprecated, or software dependencies may be upgraded), maintaining the same standard of conformity defines the required scope of such updates.
In many cases this may merely be limited to necessary security updates and slight adaptions. Additional features that have in the meantime become market standard do not need to be added.
Still, this may put a burden on software suppliers, since it means that technical developments that could affect an already delivered product (especially one creating security issues) must be closely watched and regularly updated.
The DSD makes clear that updates must not be automatically installed remotely by suppliers but that the consumer must remain free to choose whether to install newly provided updates or not. However, even a failure by the consumer to install provided updates does not preclude the vendor from liability for the resulting lack of conformity.
As is explicitly stated in the DSD, failure to install updates may only then preclude the vendor's liability for any lack of conformity resulting from such failure if the vendor informed the consumer about the availability of the update and the consequences of the consumer's failure to install it and the consumer's failure to install or incorrect installation of the update was not due to shortcomings in the installation instructions provided by the vendor.
This means care should be taken to inform consumers every time updates are supplied.
"Care should be taken to inform consumers every time updates are supplied."
As conforming with an update obligation may create a disproportionate burden, the DSD also allows for the exclusion or limitation of the update requirement (e.g. by limiting the timeframe, updates are made available or by limiting updates to certain aspects of the software). Pursuant to the DSD, this may be achieved prior to the conclusion of the contract by obtaining clear and separate consent from the consumer on the updates to be provided. This must be given separately from any other statements or agreements after the consumer was specifically informed about this intended deviation from mandatory updates as stipulated in the DSD.
Hence, consent could not be given in standard terms and conditions (which a consumer might not read) but must be required separately with regard to a clear and comprehensible statement/information about the said limitation (i.e. via a separate checkbox to be ticked). As by means of such consent other deviating elements may be agreed on, this may result in software suppliers requiring multiple consents to be on the safe side.
There are many situations where such an update requirement may be nearly impossible for consumers to fulfil. For example, if the software is a necessary part of the functioning of a hardware product, like a smart fridge, or in the case of firmware. Nevertheless, delivering a hardware product along with preinstalled software does not preclude the applicability of the DSD and therefore the required supply of continuous updates on purchased software. In principle, the contract on the respective good would have to be assessed separately for its software and its hardware. However, if the software that is supplied within the scope of the respective sales contract is necessary for the proper functioning of the respective good, the software may be qualified as being part of a so-called good with digital elements, to which the DSD does not apply in its entirety. So in the case of goods with digital elements there are no update obligations for the respective software.
The directive comprises the novel obligation to provide continuous updates for a period of time usually expected for products to maintain the proper quality and functioning of existing features concerning software delivered to consumers in a single act of supply. The update obligation is a novelty in Austrian law. Although limited to maintaining the proper functioning of the software, software vendors may be required to expend additional effort in connection with software already sold. To prevent this, consumers will in many cases likely be asked to waive the update obligation by means of an express and explicit statement.
author: Alexander Pabst
If you want to receive a print copy of roadmap22, please register here.
Attorney at Law