De NLdigital-voorwaarden
NLdigital is de branchevereniging voor ruim 650 ICT-bedrijven. Oude namen voor deze organisatie zijn ICT~Office, Fenit en COSSO.
NLdigital geeft standaard leveringsvoorwaarden uit. Deze voorwaarden worden door veel leden van de vereniging 1-op-1 gebruikt. Ook dienen de voorwaarden ter inspiratie voor veel IT-leveranciers.
10 clausules in normaal Nederlands
In onze ervaring kunnen veel afnemers niet altijd even goed duiden wat er nu precies in de voorwaarden staat. Daarom zetten we hier tien clausules op een rij in normaal Nederlands.
1. Altijd betalen
3.6 Klant is niet gerechtigd tot opschorting van enige betaling en evenmin tot verrekening van verschuldigde bedragen.
In normaal Nederlands: de afnemer moet altijd betalen, ook al is er ergens discussie over tussen partijen of de leverancier hem nog geld verschuldigd is.
Volgens de wet mag je als afnemer je betalingsverplichtingen opschorten op het moment dat leverancier niet (meer) presteert (6:262 BW), of wanneer er gegronde vrees is dat het niet goed gaat (6:263 BW). De gedachte van de wetgever is heel simpel: je hoeft niet te betalen als het werk uitblijft en je hoeft ook niet te betalen wanneer je al kunt aan zien komen dat het project aan het ontsporen is.
Opschorting is dus een heel normaal en ook gezond middel om als afnemer in handen te hebben. De NLdigital voorwaarden slaan dit middel uit handen.
2. Budgetten zeggen niets
3.2. Aan een door leverancier afgegeven voorcalculatie of begroting kan een klant geen rechten of verwachtingen ontlenen, tenzij partijen schriftelijk anders zijn overeengekomen.
In normaal Nederlands: budgetten zeggen niets.
IT-projecten staan er om bekend dat ze veel uitlopen, zowel in tijd als in kosten. Juist daarom wordt er vaak gewerkt met een planning en begroting die vooraf wordt gemaakt. Van een ervaren leverancier mag je ook, gelet op de zorgplicht, verwachten dat een dergelijk afgegeven begroting (binnen bepaalde bandbreedtes) ook gewoon gehaald wordt. Of dat er anders tijdig aan de bel wordt getrokken indien dit niet het geval is.
De NLdigital voorwaarden contracteren dat aspect van de zorgplicht weg. Budgetten en begrotingen zijn niets waard.
3. Leverancier hoeft niet te luisteren naar de klant
11.4 Leverancier is niet gehouden bij de uitvoering van zijn diensten aanwijzingen van zijn klant op te volgen, in het bijzonder niet indien dit aanwijzingen betreft die de inhoud van de overeengekomen diensten wijzigen of aanvullen.
In normaal Nederlands: de leverancier hoeft niet te luisteren naar de klant.
Volgens de wet is een leverancier gehouden instructies op te volgen, tenzij die instructies onredelijk zijn (7:402 BW). De wetgever heeft hier een mooie balans gevonden: in principe bepaalt de klant (het is immers ook zijn IT-omgeving), tenzij de klant wensen heeft die onverantwoord zijn (de ‘dit moet je niet willen’-verzoeken). Ook hier zie je de wettelijke zorgplicht mooi terug: het is normaliter de leverancier die, gelet op zijn expertise, de klant moet behoeden voor domme dingen.
De NLdigital voorwaarden contracteren ook deze zorgplicht weg.
4. De planning zegt niets
14.1 Leverancier spant zich er redelijkerwijs voor in de door hem genoemde of tussen partijen overeengekomen al dan niet uiterste (leverings)termijnen en/of (oplever)data in acht te nemen. Door leverancier genoemde of tussen partijen overeengekomen tussentijdse (oplever)data, gelden steeds als streefdata, binden de leverancier niet en hebben steeds een indicatief karakter.
In normaal Nederlands: de planning zegt niets, als de leverancier zich er niet aan houdt heeft dat geen gevolgen.
Normaalgesproken mag je verwachten dat een planning wordt gehaald. De Hoge Raad overwoog een paar jaar terug nog dat een leverancier niet mag wachten met presteren tot hij aangemaand wordt. Afhankelijk van wat partijen afspreken en hoe ze dat over en weer hebben begrepen, kan het zelfs zijn dat termijnen per definitie gehaald moeten worden (‘fataal’ zijn).
Wanneer je echter overeenkomt dat termijnen nietszeggend zijn – zoals dat in de voorwaarden gebeurt – mag je er ook geen verwachtingen meer van hebben. De NLdigital voorwaarden contracteren ook hier dus het wettelijk systeem weg.
5. Fatale termijnen zijn toch niet fataal
14.3 In alle gevallen – derhalve ook indien partijen een uiterste (leverings)termijn of (oplever)datum zijn overeengekomen – komt leverancier wegens tijdsoverschrijding eerst in verzuim nadat klant hem schriftelijk in gebreke heeft gesteld, waarbij klant leverancier een redelijker termijn stelt er zuivering van de tekortkoming (op het overeengekomen) en deze redelijke termijn is verstreken.
In normaal Nederlands: ook al spreek je af dat termijnen fataal zijn, dan nog moet je de leverancier een extra kans gunnen (=verdere uitloop) indien de termijn niet gehaald wordt.
In menig IT-project zijn deadlines belangrijk. Er moet bijvoorbeeld tijdig worden voldaan aan nieuwe wet- en regelgeving of er moet tijdig een alternatief worden gevonden voor een koppeling die niet langer ondersteund wordt. Wanneer dergelijke deadlines worden geschonden, dan kan de bedrijfsvoering ernstig in gevaar komen (bijv. omdat er niet meer betaald wordt).
Volgens de wet en gelet op de rechtspraak zullen dergelijke hele belangrijke deadlines in de regel gelden als fatale termijnen (wel afhankelijk van wat partijen er verder over besproken hebben met elkaar). Idealiter schrijven partijen natuurlijk zelfs expliciet op dat de termijn fataal is (je wilt niet gokken op de interpretatie van de omstandigheden van het geval of een termijn werkelijk als fataal geldt).
De NLdigital voorwaarden maken die belangrijke deadlines echter onbelangrijk. Het schenden van die deadlines heeft geen consequentie en de leverancier krijgt alsnog extra tijd om het werk te doen.
6. Specificaties kunnen wijzigen en ondersteuning wetswijzigingen niet geborgd
30.2 Leverancier kan wijzigingen in de inhoud of omvang van de SaaS-dienst aanbrengen (…).
31.3 Leverancier staat er niet voor in dat de SaaS-dienst tijdig wordt aangepast aan wijzigingen in relevante wet- en regelgeving.
48.3 (…) Leverancier kan uit een vorige versie van de programmatuur ongewijzigd overnemen, maar staat er niet voor dat elke versie dezelfde functionaliteit bevat als de voorgaande versie.
In normaal Nederlands: het systeem kan op dag 1 voldoen aan je eisen, op dag 2 kunnen de specificaties wijzigen. En ook al heb je een systeem aangeschaft juist om te voldoen aan bepaalde wettelijke vereisten, er is geen enkele garantie dat dit ook het geval is (laat staan blijven).
Als afnemer kun je hierdoor klem komen te zitten. Je kiest immers voor een bepaalde SaaS-oplossing of voor bepaalde ‘on premise’ software, juist omdat deze (op het moment van selectie) aan de voor jou relevante eisen voldoet. Er is 0 zekerheid dat dit ook het geval blijft.
Daar komt nog eens bij dat ook iedere verwachting omtrent functionaliteiten is weggecontracteerd. Waar op grond van rechtspraak je – in ieder geval bij ‘on premise’ software – waarschijnlijk mag verlangen dat de software voldoet aan de eigenschappen die je redelijkerwijs mocht verwachten (zoals: een boekhoudprogramma voert berekeningen correct uit), contracteren de voorwaarden al die redelijke verwachtingen weg (artikel 40.1).
7. Leverancier hoeft slechts te proberen bugs op te lossen
31.1 (…) Leverancier zal zich naar beste vermogen inspannen fouten als bedoelde in artikel 36.3 in de onderliggende programmatuur binnen een redelijke termijn te herstellen (…).
36.8 (…) Leverancier zal zich naar beste vermogen inspannen de bedoelde fouten binnen een redelijke termijn te herstellen, waarbij leverancier gerechtigd tijdelijke oplossingen, programma-omwegen of probleemvermijdende beperkingen aan te brengen.
40.1 Leverancier zal zich naar beste vermogen inspannen fouten in de van artikel 36.3 binnen een redelijke termijn te herstellen….
47.2 (…) Na ontvangst van de melding zal leverancier zich overeenkomstig zijn gebruikelijke procedures naar beste vermogen inspannen fouten te herstellen en/of verbeteringen aan te brengen in latere nieuwe versies van de programmatuur.
In normaal Nederlands: leverancier hoeft slechts te proberen bugs op te lossen, of bugs daadwerkelijk worden opgelost is onzeker. Het is zelfs denkbaar dat bij de pogingen tot herstel van gebreken de software er verder op achteruit gaat in functionaliteit.
Laat even indalen wat dit betekent: de maker van een product hoeft niet in te staan voor de kwaliteit daarvan. Dat is werkelijk nergens anders in de maatschappij denkbaar dan in de IT-sector.
Het standaard tegenargument is dan altijd dat software maken complex is en dat foutloze software niet bestaat. De complexiteit ontken ik niet; die bestaat echter ook bij allerlei andere producten en diensten in onze samenleving. Complexiteit in zichzelf is geen argument om veiligheidsrisico’s te accepteren (sterker nog: de vraag is of de passende reactie op complexiteit niet veel grondiger testen zou moeten zijn).
En dat foutloze software niet bestaat wil ik ook graag geloven (ik programmeer zelf op hobbyniveau en een foutje sluipt er zo in). Dat lijkt me echter geen reden om dan vervolgens achteruitgang in functionaliteit te aanvaarden. Dat zou immers in feite betekenen dat het ontwikkelrisico bij de klant wordt gelegd (die verliest opeens functionaliteit), terwijl je van een deskundige programmeur (in beginsel) mag verwachten dat deze op voorhand goed nadenkt over risico’s en ook dat deze bij een onvoorzien risico zelf daar de consequenties van draagt. Dit nog daargelaten dat je van een professionele leverancier ook grondig en kundig testen mag verwachten voor oplevering.
8. Er wordt nooit geld terugbetaald
15.2 Indien klant op het moment van de ontbinding al prestaties ter uitvoering van de overeenkomst heeft ontvangen, zullen deze prestaties en de daarmee samenhangende betalingsverplichtingen geen voorwerp van ongedaanmaking zijn, tenzij klant bewijs dat leverancier ten aanzien van het wezenlijke deel van die prestaties in verzuim is.
In normaal Nederlands: leverancier betaalt nooit geld terug, ook al heeft hij het project verprutst.
Het uitgangspunt van de wet is dat wanneer de leverancier niet presteert er ontbonden kan worden en dat bij ontbinding het betaalde geld wordt terugbetaald (behoudens voor zover de geleverde prestaties van waarde zijn geweest).
De NLdigital voorwaarden doen dit teniet. Volgens de NLdigital voorwaarden wordt er alleen terugbetaald over dat deel van de prestaties waarover de leverancier in verzuim is. De belangrijkste grond voor verzuim is vertraging en daarover staat in artikel 14.3 al dat vertraging geen verzuim oplevert (zie hiervoor).
Ook andere gronden voor verzuim gaan niet op. Eigenlijk blijft alleen de situatie van blijvend onmogelijke nakoming over. Wanneer duidelijk is dat het blijvend onmogelijk is geworden na te komen, maar de leverancier blijft toch factureren (waarvoor dan precies is onduidelijk…..), dan zou het te veel betaalde teruggevorderd kunnen worden.
9. Leverancier mag gegevens verminken en vernietigen of laten uitlekken
16.4 (…) Eveneens is uitgesloten de aansprakelijkheid van leverancier verband houdende met verminking, vernietiging of verlies van gegevens of documenten.
In normaal Nederlands: leverancier mag gegevens verminken en vernietigen of laten uitlekken en is toch niet aansprakelijk.
Het uitgangspunt van de wet is dat de partij die gegevens verminkt of vernielt aansprakelijk is voor de dientengevolge geleden schade. Logisch ook, wie zijn fiets wegbrengt naar de fietsenmaker mag ook verwachten dat de fietsenmaker de fiets heel laat (sterker nog: repareert). En wie een ruit ingooit zal de schade moeten vergoeden.
NLdigital gaan rechtstreeks tegen dat rechtsgevoel in. Helemaal in een tijd waarin steeds meer ICT niet meer on premise maar op afstand wordt verleend (SaaS, cloud) is dit werkelijk een bizarre clausule. In die situaties is de IT-leverancier immers de enige partij die de gegevens überhaupt nog heeft. Het contract ziet juist in de kern op het netjes omgaan met die gegevens.
Wonderlijk genoeg heeft zelfs de Autoriteit Persoonsgegevens deze clausule goedgekeurd door de goedkeuring van de Data Pro Code.
10. Leverancier is nauwelijks aansprakelijk
16.4 Indirecte schade, gevolgschade, gederfde winst, gemiste besparingen, verminderde goodwill, schade door bedrijfsstagnatie, schade als gevolg van aanspraken van afnemers van klant, schade verband houdende met het gebruik van door klant aan leverancier voorgeschreven zaken, materialen of programmatuur van derden en schade verband houdende met de inschakeling van door klant aan leverancier voorgeschreven toeleveranciers is uitgesloten.
In normaal Nederlands: leverancier is in de praktijk niet tot nauwelijks aansprakelijk.
Wat precies moet worden verstaan onder termen als indirecte schade en gevolgschade en dergelijke is niet evident. In de context van de gehele opsomming wordt echter wel duidelijk dat bedoeld is om een heel breed scala aan schadesoorten uit te sluiten. En dat schuurt behoorlijk.
- IT grijpt immers diep in de organisatie in. Wanneer de IT niet goed werkt, dan kan de hele organisatie plat komen te liggen. Juist dat soort schade zal snel vallen onder deze uitsluiting (‘bedrijfsstagnatie’, ‘gevolgschade’, ‘schade als gevolg van aanspraken van afnemers van klant’).
- IT wordt ook vaak juist ingezet om besparingen in de onderneming te realiseren. Daarvoor worden hele business cases doorgerekend, regelmatig samen met de leverancier. Menig leverancier adverteert ook met (vermeende) besparingen die gerealiseerd zouden kunnen worden. Wanneer echter die business case door een fout van dezelfde leverancier niet wordt gehaald, is de leverancier hiervoor niet aansprakelijk (‘gemiste besparingen’).
Er zal in de praktijk (bijna) geen directe schade zijn.
Het is wonderlijk dat in een tijd waarin IT van steeds groter belang is voor de samenleving, dit soort clausules nog bestaan. In andere branches waar een afhankelijkheidsrelatie bestaat, zoals in de gezondheidszorg, staat al lang in de wet dat het beperken of uitsluiten van aansprakelijkheid gewoon niet mag (7:463 BW). Ook in andere landen wordt kritisch gedacht over dit soort clausules.
Ten slotte
Deze 10 voorbeelden zijn zeker niet de enige eenzijdige bepalingen in de NLdigital voorwaarden. Het geheel van de voorwaarden maakt simpelweg dat je als klant niet weet wat je krijgt, wanneer je het krijgt en wat het kost. Wat je bij deze voorwaarden wel zeker weet is dat je leverancier (bijna) niets te verwijten valt. Als afnemer moet je hier dus niet mee instemmen.
Het is ook wel opmerkelijk dat leveranciers dergelijke verstrekkende voorwaarden nodig denken te hebben. Wat zegt dit over hun eigen beeld over de eigen bedrijfsvoering?
Hoe dan ook, onderschat als afnemer deze voorwaarden dus niet. Kijk kritisch naar wat er in het contract staat en bezint eer ge begint. We zien te vaak dat contractonderhandelingen een haastklus zijn en dat pas bij de mislukte implementatie opnieuw naar het contract wordt gekeken. Wees dat voor en onderhandel op voorhand kritisch over de voorwaarden.
En houd u zich vervolgens zelf ook aan dat uitonderhandelde contract (want ook dat gaat te vaak mis). We zien iets te vaak dat er wordt 'doorgemodderd' in projecten. Ook dat doet uw juridische positie geen goed. Durf in te grijpen waar nodig.
Heeft u hier vragen over? neem gerust contact op.
Edit 26-09: een typo aangepast bij punt 4 (partijen => termijnen)
Gerelateerd
IT
