Magnifying glass Close

Wat te doen met ‘as is’ in softwarecontracten?

Wie met enige regelmaat een contract voor het gebruik van software onder ogen krijgt, kent de term ‘as is’.  Varianten die tegenwoordig opduiken zijn ‘as is, where is’ en ‘as is, as available’. Waar staan deze termen voor en wat moeten we ermee?

Software is een ingewikkeld product. Bij een ingewikkeld product komen complexe vragen kijken. Ook bij de beoordeling of de software die wordt (op)geleverd,  voldoet aan hetgeen de afnemer op grond van de overeenkomst mag verwachten.

Want wat mag de afnemer eigenlijk van software verwachten?

  • dat de software tenminste voldoet aan gangbare kwaliteitsstandaarden/eisen van vakmanschap?
  • dat de software voldoet aan vooraf opgestelde specificaties van functionaliteit en eigenschappen van de software (‘conformance to specifications’)?
  • dat de software daadwerkelijk geschikt is voor (normaal) gebruik (‘fitness for use’)?
  • dat de software geschikt is voor door de afnemer beoogde gebruiksdoelen (‘fitness for purpose’)?

Aan welke eisen moet software volgens de wet voldoen?  

De wet kent geen specifieke regeling die bepaalt aan welke eisen software moet voldoen. Wel kan getoetst worden aan de bepaling van artikel 7:17 BW. Dat artikel (eigenlijk bedoeld voor koop van zaken) bepaalt dat een zaak moet beantwoorden ‘aan de overeenkomst’ en dat is niet het geval indien de zaak:

“mede gelet op de aard van de zaak en de mededelingen die de verkoper over de zaak heeft gedaan, niet de eigenschappen bezit die de koper op grond van de overeenkomst mocht verwachten.”.

De koper mag verder verwachten dat de zaak de eigenschappen bezit die voor een ‘normaal gebruik’ daarvan nodig zijn en waarvan hij de aanwezigheid niet behoefde te betwijfelen. Alsmede mag hij de eigenschappen verwachten die nodig zijn voor een bijzonder gebruik dat bij de overeenkomst is voorzien.

De wettelijke regeling is echter van regelend recht, zodat professionele partijen daarvan kunnen afwijken (dat is overigens wel anders bij contracten met consumenten).

Van groot belang is dan ook wat partijen zelf in hun contract zijn overeengekomen. Het gaat er niet om of de software op zich ‘goed’ of ‘slecht’ is, maar of deze voldoet aan de eisen die in het contract worden gesteld.  Een slecht contract zet dus de deur open voor slechte software.

Wees alert op ‘as is’, ‘where is’ en ‘as available’

De ‘as is’-bepaling vindt zijn oorsprong in Anglo-Amerikaanse contracten. Zeker Amerikaanse leveranciers maken vaak in de Terms & Conditions of in de EULA gebruik van een clausule van de strekking dat de software (of de software-as-a-service) wordt geleverd ‘as is’. Oftewel zonder enige recht of garantie ten aanzien van gebruik, geschiktheid of anderszins.

Ook hier komen we de bepaling geregeld tegen. Een (bekend) voorbeeld is de bepaling van artikel 30 lid 1 uit de Nederland ICT Voorwaarden (modelvoorwaarden van de branchevereniging):

“…indien partijen geen  acceptatietest zijn overeengekomen, aanvaardt de klant de programmatuur in de staat waarin deze zich op het moment van aflevering bevindt (‘as is, where is’), derhalve met alle zichtbare en onzichtbare fouten en gebreken (…)”

In de varianten van de ‘as is’-bepaling met de toevoegingen ‘where is’ of ‘as available’, wordt doorgaans gedoeld op de beschikbaarheid: waar of wanneer ook ter wereld. Bij Software-as-a-Service of andere online dienstverlening kan immers een onbeschikbaarheid tot kwalijke gevolgen en schade bij de afnemer leiden. In de varianten ‘as is, where is’ of ‘as is, as available’, wordt beoogd de verantwoordelijkheid van de leverancier daarvoor uit te sluiten.

Het is raadzaam om alert te zijn op de aanwezigheid van ‘as is’-bepalingen in contracten. Accepteer deze bij voorkeur niet. Met een enkele clausule wordt namelijk de wet opzij geschoven en uitgehold wat normaal gesproken zou mogen worden verwacht.

Partner van Inkoperscafé
Partner van Inkoperscafé

Reacties

Partner van Inkoperscafé
Sluiten

Inloggen met

of met e-mailadres