• 1. Inleiding

  Wie IT gebruikt, gebruikt inmiddels niet alleen software die is geïnstalleerd op de eigen apparatuur (of apparatuur waarover diegene zeggenschap heeft), maar ook software die is geïnstalleerd in de omgeving van de leverancier die de software verstrekt (of in een omgeving waarover die leverancier zeggenschap heeft¹x Bijv. wanneer de SaaS-leverancier voor de hosting gebruikmaakt van een cloudomgeving van Microsoft, Amazon Web Services of Google.). Die software is dan beschikbaar via het internet. Voor het gebruik van software die is geïnstalleerd in de eigen omgeving verkrijgt men licenties. Voor het gebruik van software die is geïnstalleerd in de omgeving van de softwareleverancier gaat men dienstverleningsovereenkomsten aan (waarbij licentieverlening ook nog een rol speelt). In deze bijdrage bespreek ik veelal onderhandelbare aspecten van dergelijke dienstverleningsovereenkomsten.

  De focus van deze bijdrage ligt bij Software as a Service-overeenkomsten, kortweg SaaS-overeenkomsten: met dergelijke overeenkomsten wordt via internet toegang verkregen tot werkende software (één of meer applicaties) in de omgeving van de leverancier; het is een vorm van cloudcomputing. Daarnaast worden nog twee andere vormen van cloudcomputing onderscheiden:²x Zie bijv. L. Ferreira Pires, Wat is cloud computing?, Computerrecht 2011/63, en www.bmc.com/blogs/saas-vs-paas-vs-iaas-whats-the-difference-and-how-to-choose/. Platform as a Service (PaaS), waarbij een operating platform ter beschikking wordt gesteld voor het installeren van applicaties, en Infrastructure as a Service (IaaS), waarbij een infrastructuur ter beschikking wordt gesteld, bijvoorbeeld voor het inrichten van een operating platform.³x Een op de infrastructuur geïnstalleerde softwarelaag waarop vervolgens applicaties kunnen worden geïnstalleerd. Vanuit contractenrechtelijk perspectief doen zich daarbij dezelfde uitdagingen voor als bij SaaS,⁴x Namelijk de uitdagingen die hierna worden besproken. maar minder vaak en met minder ingrijpende consequenties omdat het meestal makkelijker is over te stappen naar een andere (cloud) infrastructuur of ander platform dan naar een andere applicatie.⁵x Bij een overstap van een PaaS- naar een andere PaaS-dienst of van een IaaS- naar een andere IaaS-dienst vindt een verhuizing plaats van applicaties – die moeten voor zo’n verhuizing vaak wel een beetje anders worden geconfigureerd, maar omdat IaaS- en PaaS-diensten juist zijn ingericht om er makkelijk naartoe te verhuizen, zijn de noodzakelijke ingrepen over het algemeen gering (vergelijk: het verplaatsen van kleding van de ene kast naar de andere). Het vervangen van een applicatie vergt meestal dat de nieuwe applicatie weer geheel opnieuw moet worden ingericht voor de gebruiker (vergelijk: het vervangen van een semi-maatpak door een ander semi-maatpak). Dat kost meer tijd en geld en verslechtert daardoor de onderhandelingspositie van de klant ten opzichte van de leverancier.

  Omdat SaaS-leveranciers waarschijnlijk bekend zijn met de hier besproken aandachtspunten is gekozen voor het perspectief van de professionele afnemer. De hier besproken aandachtspunten spelen bij allerhande typen overeenkomsten: of u nu (naar aanleiding van een mogelijk omvangrijke order) onderhandelt met een leverancier als Microsoft, Salesforce of SAP, of onderhandelt met een leverancier van software die een marketingtool biedt, of een systeem voor het administreren van de rekeningen van een bank.⁶x Zie voor overeenkomsten die zonder onderhandelingen tot stand komen T.J. de Graaf, Pitfalls in ICT-contracten, Contracteren 2013/3, p. 99-107. Deze bijdrage gaat niet in op dwingend recht ter bescherming van consumenten of andere kleine partijen,⁷x Bijv. C.M.D.S. Pavillon, Herijking van consumentencontractenrecht: duurzaamheid als nieuw ijkpunt?, in: C.M.D.S. Pavillon & W.H. van Boom, Privaatrechtelijke bescherming herijkt. Preadviezen (Nederlandse Vereniging voor Burgerlijk Recht), Zutphen: Uitgeverij Paris 2021; E. Neppelenbroek, De verstrekking van juridische voorwaarden in het voorportaal van de cloud, Contracteren 2020/4, p. 132-143. noch op sectorspecifieke vereisten.⁸x Bijv. www.eiopa.europa.eu/document-library/guidelines/guidelines-outsourcing-cloud-service-providers. Deze bijdrage besteedt evenmin aandacht aan de verwerking en bescherming van persoonsgegevens. Daar is door anderen al het een en ander over geschreven.⁹x Bijv. A. Karimi & J. Toornstra, De nieuwe standaardcontractbepalingen (SCCs) voor de doorgifte van persoonsgegevens naar derde landen: aandachtspunten voor organisaties, Tijdschrift voor Internetrecht 2021/5, p. 197-203; K. Daniëls & P. Kits, Contracteren in de cloud – ken uw risico’s, Contracteren 2015/1, p. 2-16.

  Bij wijze van introductie bespreek ik in paragraaf 2 eerst enkele verschillen en overeenkomsten tussen licenties en SaaS-overeenkomsten. Daarna bespreek ik in opeenvolgende paragrafen het bedrijfsmodel van veel leveranciers (dat heeft invloed op de contractstructuur en welke onderwerpen belangrijk zijn om over te onderhandelen), de functionaliteit, het onderhoud en de verdere ontwikkeling, het toegelaten gebruik, de vergoedingssystematiek, de implementatie, de beschikbaarheid, de remedies, de vrijwaring voor inbreuk op andermans IE-rechten, en de looptijd en het einde.

• 2. Enkele verschillen en overeenkomsten tussen licenties en SaaS-overeenkomsten

  Softwarelicenties en SaaS-overeenkomsten kennen belangrijke gelijkenissen én belangrijke verschillen. Meestal wordt gecontracteerd op basis van een model van de leverancier. In verreweg de meeste gevallen is dat opgesteld naar het recht van New York of Engeland,¹⁰x State of New York c.q. England and Wales. maar vaak is wel onderhandelbaar dat de overeenkomst wordt beheerst door Nederlands recht. Zowel bij softwarelicenties als bij SaaS-overeenkomsten wordt gebruikgemaakt van software: de afnemer krijgt een licentie (toestemming) voor gebruik van auteursrechtelijk beschermde werken.¹¹x ‘Gebruik’ is auteursrechtelijk geen relevante term. Bij het gebruik van software (computerinstructies) worden bij elke instructie stukjes van de betreffende software gekopieerd en aan de computer gevoerd, zodat die kan doen wat de bedoeling is. Dat kopiëren van stukjes software vormt het auteursrechtelijk relevante ‘verveelvoudigen’, waarop de auteursrechthebbende het monopolie heeft. Daarvoor is dus diens toestemming nodig. De ‘licentie’ is die toestemming. Daarbij zal de leverancier licentievoorwaarden opnemen die ertoe dienen dat de afnemer niet meer gebruiksrechten krijgt dan waarvoor hij betaalt. Zo blijft zo veel mogelijk nog niet voorzien gebruik voorbehouden aan de leverancier. Dan kan die een extra vergoeding verlangen wanneer de afnemer meer wenst te gebruiken dan aanvankelijk voorzien (waarover meer in paragraaf 7). Bij beide typen overeenkomsten is het dus zaak op te letten welk gebruik is toegelaten, wie het mag gebruiken en hoe wordt bepaald of moet worden bijbetaald. In principe geldt: als het gebruik niet expliciet is toegelaten, mag het waarschijnlijk niet.

  Vragen die ook bij beide typen overeenkomsten spelen zijn: Wie verzorgt de configuratie en implementatie? Welke gebreken worden door de leverancier (hoe snel) opgelost? In welke mate zorgt de leverancier voor verdere verbetering? Welke aansprakelijkheid accepteert de leverancier? Welke oplossingen bestaan voor het door de afnemer afsplitsen van een deel van de onderneming of kopen en integreren van een andere?¹²x Als de licentie wordt verstrekt aan een vennootschap en haar groepsmaatschappijen mogen het in dat verband ook gebruiken, houdt het gebruiksrecht van zo’n groepsmaatschappij in beginsel op zodra de aandelen daarvan aan een derde zijn geleverd en die dus geen groepsmaatschappij meer is. Als daarbij is afgesproken dat alleen de op een lijst vermelde groepsmaatschappijen het mogen gebruiken, mag een nieuwe groepsmaatschappij het pas gebruiken wanneer zij aan die lijst is toegevoegd.

  Belangrijke verschillen doen zich voor met betrekking tot het verbeteren van de software. De meeste leveranciers bieden afnemers de mogelijkheid een onderhoudsovereenkomst af te sluiten voor foutcorrecties, verbeteringen en andere aanpassingen die nodig zijn om in een veranderende omgeving te blijven functioneren. Bij een licentie waarbij de software in een eigen omgeving draait, zal de afnemer dergelijke patches (kleine verbeteringen), updates (vervangingen door iets verbeterde software) en nieuwe versies (gewoonlijk met aanzienlijke verbeteringen) meestal zelf moeten installeren. Bij SaaS doet de leverancier dat gewoonlijk – die beschikt immers toch al over de omgeving waarin de software draait en kan zo voorkomen dat gebruikers met oude problemen een beroep doen op een servicedesk, terwijl er inmiddels al een nieuwe versie (patch of update) is die dat probleem heeft verholpen.

  Bij een licentie voor gebruik in eigen omgeving zullen de data van de afnemer ook in die eigen omgeving blijven. Bij SaaS kan het ook anders. Soms blijven de data opgeslagen bij de klant en worden alleen die data naar de leverancier gestuurd die voor de desbetreffende verwerking nodig zijn. Voor het opstellen van een factuur met de SaaS verstuurt de klant bijvoorbeeld alleen de voor die factuur relevante data. Of de SaaS genereert rapporten of verstuurt berichten op basis van data die daarvoor worden ingezonden. Na verwerking zal de leverancier de desbetreffende data verwijderen uit zijn omgeving. Soms echter worden de desbetreffende data opgeslagen in de omgeving van de leverancier. Dan moeten meer afspraken worden gemaakt over beveiliging, behoud, teruggave en vernietiging van die data.

  De leverancier van software die draait in de omgeving van de klant wil kunnen controleren of die klant niet meer of anders van de software gebruikmaakt dan afgesproken. Dergelijke auditrechten zijn minder ingrijpend wanneer gebruik wordt gemaakt van SaaS. Dan kan de leverancier immers veel makkelijker bijhouden welk gebruik er van de software wordt gemaakt. Technisch zijn veel softwareleveranciers ook in staat het gebruik door klanten op afstand te controleren, maar veel klanten hebben bezwaar tegen een dergelijke achterdeur, onder andere uit beveiligingsoverwegingen.

  Ten slotte bestaat een belangrijk verschil met betrekking tot de continuïteit van de dienstverlening. Bij een installatie in de eigen omgeving bepaalt de afnemer in hoge mate de continuïteit van de beschikbaarheid. Bij SaaS is de afnemer geheel afhankelijk van de leverancier en diens leveranciers (en de dataverbinding met de leverancier, meestal het internet). Er moeten dus afspraken worden gemaakt over die beschikbaarheid.¹³x Waarover par. 9 hierna. Ook leidt het door de leverancier stoppen van de dienstverlening (bijvoorbeeld vanwege faillissement) onmiddellijk tot een probleem bij de afnemer. Anders dan bij een licentie voor hosting binnen een eigen omgeving kan dat probleem niet worden opgelost met een escrow van de broncode (het vooraf toegang regelen tot die broncode door deze onder te brengen bij een onafhankelijke derde) en een licentie voor het gebruik daarvan. Het is dan ook nodig de omgeving waarin die software draait (en data worden opgeslagen) te kopiëren (spiegelen) of daartoe een directe toegang te regelen. Continuïteitsoplossingen bij SaaS zijn dus ingewikkelder dan bij klassieke overeenkomsten.

  Hoezeer licenties (met onderhoud) en SaaS ook van elkaar verschillen, het bedrijfsmodel van de leverancier komt sterk overeen.

• 3. Het bedrijfsmodel van de leverancier

  Bij de eerste aankoop kan de klant meestal kiezen tussen verschillende aanbieders en die tegen elkaar uitspelen: concurrentie disciplineert. Dat biedt mogelijkheden om een flinke korting te krijgen op de lijstprijs en om de standaardvoorwaarden van de leverancier wat bij te schaven. Het implementeren van een applicatie kost vaak veel geld en tijd: vaak moet de standaardsoftware zo worden geconfigureerd dat die geschikt is voor de specifieke bedrijfsvoering van de klant, veelal moeten interfaces (verbindingen tussen verschillende applicaties) worden gemaakt of aangepast, soms moeten databestanden opnieuw worden geconfigureerd of opgeschoond, vaak moeten gebruikers worden getraind. Als de klant een applicatie eenmaal heeft geïmplementeerd, zijn de kosten van het overstappen naar een andere applicatie hoog – dan moet opnieuw worden geïmplementeerd. Dat geeft de bestaande leverancier een betere onderhandelingspositie. Veel leveranciers sturen er daarom op de gebruiksrechten van de klant zo beperkt mogelijk te beschrijven. Alleen het bij het aangaan van de overeenkomst met grote zekerheid voorziene gebruik wordt gedekt: als later meer gebruik wordt verlangd, is de lijstprijs weer het uitgangspunt. Het is daarom niet alleen van groot belang goed na kijken of en te bedingen dat het beoogde gebruik wordt gedekt, maar ook te bedingen tegen welke voorwaarden additioneel gebruik kan worden bijgekocht: wat daarvoor de licentievoorwaarden zijn.¹⁴x Dergelijke opties worden ook wel een ‘price hold’ genoemd.

  De meeste softwareleveranciers worden gewaardeerd op basis van hun omzet en winstgevendheid. Voor Amerikaanse leveranciers gelden daarbij specifieke accountancystandaarden, waardoor zij een toekomstige inkomstenstroom al meteen bij het ondertekenen van de overeenkomst boeken als omzet, voor zover die inkomstenstroom vaststaat¹⁵x Met name wanneer die kan worden toegerekend aan het licentiëren van bestaande software. en niet te onzeker is (bijvoorbeeld omdat deze afhankelijk is van prestaties die mogelijk niet kunnen worden geleverd of omdat de klant ook zonder aan de leverancier verwijtbare reden (‘for convenience’) kan opzeggen). Om die geboekte omzet zo groot mogelijk te laten zijn willen dergelijke leveranciers overeenkomsten sluiten die langjarig zijn en niet tussentijds kunnen worden opgezegd (of in omvang beperkt). Daartoe krijgen klanten een korting als zij een overeenkomst aangaan voor een langere termijn (c.q. moeten ze meer betalen als ze een overeenkomst wensen voor een kortere termijn). Wil de leverancier de betreffende omzet kunnen boeken, dan moet die nagenoeg zeker zijn, bijvoorbeeld niet afhangen van een succesvolle implementatie of nog te ontwikkelen functionaliteit. Dat verklaart waarom leveranciers de implementatie veelal liever door een derde laten doen, of ten minste willen regelen in een losstaande overeenkomst. Het verklaart ook deels waarom leveranciers wel een ‘roadmap’ willen delen over hun plannen met betrekking tot nog te ontwikkelen software, maar ter zake geen verplichting willen aangaan. Is die nog te ontwikkelen functionaliteit cruciaal, dan zal de klant zich pas voor langere tijd willen verbinden wanneer die functionaliteit er ook daadwerkelijk is, of juridisch bindend wordt toegezegd, of dat het op andere wijze nagenoeg zeker is dat die er zal komen, bijvoorbeeld als die wettelijk verplicht is of als de leverancier veel marktaandeel zal verliezen wanneer die functionaliteit niet tijdig beschikbaar is (maar dat is natuurlijk lastig in te schatten).

  Omdat SaaS bijna altijd standaarddienstverlening is, is er weinig ruimte voor specifieke aanpassingen voor een klant en is het dus extra belangrijk dat de dienst doet wat de klant daarvan verwacht: welke functionaliteit wordt geboden.

• 4. Functionaliteit

  SaaS-dienstverleners zijn geneigd hun dienstverlening limitatief te beschrijven. Voor wat de software doet (de functionaliteit) wordt gewoonlijk verwezen naar de gebruikersdocumentatie. Die is niet altijd gemakkelijk toegankelijk en wordt soms ook pas verschaft na aankoop.¹⁶x Een poging tot vernietiging wegens niet-beschikbaarheid van een deel van de algemene voorwaarden stuit niet alleen vaak af op art. 6:235 BW, maar heeft ook weinig zin vanwege de constructie dat de dienst ‘as is’ wordt verkocht, met als uitzondering dat wel in hoofdzaak wordt geborgd wat in de documentatie staat. Dan leidt het vernietigen van die documentatie als algemene voorwaarden tot minder rechten. Dan zou artikel 6:248 lid 1 van het Burgerlijk Wetboek (BW) kunnen helpen: ‘Een overeenkomst heeft niet alleen de door partijen overeengekomen rechtsgevolgen, maar ook die welke, naar de aard van de overeenkomst, uit de wet, de gewoonte of de eisen van redelijkheid en billijkheid voortvloeien.’ Dat wordt ingekleurd door wat verkopers tijdens het verkooptraject over de diensten hebben gezegd. Bij een voor de betreffende leveranciers grote opdracht kan de klant ook aan de leveranciers vragen om beantwoording van een vragenlijst over de geboden functionaliteit. Dan is het voor de klant van belang dat die antwoorden onderdeel worden van de overeenkomst.

  Juridisch wordt die informatieverstrekking veelal weggepoetst door een ‘entire agreement’-bepaling, die er meestal toe strekt dat de verplichtingen van de leverancier zijn beperkt tot datgene wat met zoveel woorden is opgenomen in de overeenkomst en dat de klant geen recht kan ontlenen aan andere verklaringen die namens de leverancier zijn gedaan. Een dergelijke bepaling moet dus niet licht worden aanvaard, ondanks dat het weglaten voor veel leveranciers onbespreekbaar is.¹⁷x Verkopers stellen de door hen aangeboden diensten vaak mooier voor dan ze zijn, en de juridische afdeling beoogt de leverancier daartegen te beschermen door hun verklaringen weg te schrijven. Uit HR 19 januari 2007, ECLI:NL:HR:2007:AZ3178, NJ 2007/575 (Meyer Europe B.V./Pontmeyer B.V.) blijkt dat opname van een ‘entire agreement’-beding sneller kan leiden tot een tekstuele uitleg, waarbij contractonderhandelingen en handelsgebruiken minder van belang zijn. Maar uit HR 3 april 2013, ECLI:NL:HR:2013:BY8101, NJ 2013/214 (Lundiform/Mexx) blijkt dat ook dan nog het Haviltex-gedachtegoed van toepassing is. Hoe dan ook: als de tekst duidelijk maakt dat tussen partijen andere afspraken dan vastgelegd niet binden, is het zaak zo veel mogelijk van de gemaakte afspraken ook op te nemen. Misschien is de documentatie voldoende duidelijk of zijn betrokkenen voldoende bekend met de softwareoplossing. Anders kan de documentatie wellicht worden aangevuld met enkele specifieke verklaringen over functionaliteit of functioneren,¹⁸x Bijv. de maximale reactiesnelheid van het systeem. of door de antwoorden op een vragenlijst ook onderdeel uit te laten maken van de overeenkomst.

  Ons recht vult de overeenkomst op grond van artikel 6:248 lid 1 BW in beginsel aan met wat de klant in redelijkheid mag verwachten, bijvoorbeeld omdat SaaS die kwaliteit gewoonlijk heeft, of omdat de leverancier de indruk heeft gewekt dat de oplossing geschikt is voor de specifieke context van de klant. Ook daaraan willen de meeste leveranciers zich liever niet binden. Daarom voorzien veel standaardvoorwaarden in het expliciet uitsluiten van impliciete beloftes (‘implied warranties’). De uitsluiting van ‘merchantibility’ (Amerikaans) of ‘satisfactory quality’ (Engels) ziet op de in zijn algemeenheid te verwachten kwaliteit, bijvoorbeeld over hoe snel de oplossing instructies uitvoert. Dit soort aspecten wordt juist vanwege zijn vanzelfsprekendheid lang niet altijd beschreven in de documentatie. Omdat de aangeboden SaaS meestal wel een redelijk kwaliteitsniveau biedt, ook wat betreft de niet in de documentatie benoemde aspecten van de software, zijn SaaS-leveranciers vaak wel bereid de uitsluiting daarvan te laten vallen. De uitsluiting van ‘fitness for a particular purpose’ ziet op de geschiktheid voor de specifieke behoefte of context van de klant. Bepalingen waarmee wordt bevestigd dat de oplossing die geschiktheid heeft, zie ik alleen geaccepteerd worden nadat de leverancier daar betaald onderzoek naar heeft verricht.

• 5. Onderhoud en verdere ontwikkeling

  Dat de SaaS bij aanvang voldoet, is meestal niet voldoende: een doorlopende dienst moet ook blijven voldoen. In de IT-industrie wordt de term ‘onderhoud’ gewoonlijk gebruikt voor herstel van fouten en voor verdere ontwikkeling van de software of dienst.

  Voor het herstel van fouten of het verhelpen van onderbrekingen onderscheiden leveranciers meestal tussen de ‘response time’ en de ‘resolution time’. Het eerste duidt gewoonlijk op de tijd waarbinnen wordt begonnen met het verhelpen van het incident. Het tweede duidt op de tijd die het kost een oplossing voor het probleem te bieden. Omdat vooraf niet met zekerheid is te bepalen hoe snel een probleem zal zijn opgelost, worden die tijden meestal gepresenteerd als doelen. Als die doelen onvoldoende vaak worden gehaald (het daarvoor geformuleerde ‘service level’ wordt niet gehaald), is de leverancier veelal bereid een financiële tegemoetkoming te betalen aan de klant.¹⁹x Een ‘service credit’, gewoonlijk in de vorm van een financiële tegemoetkoming, een enkele keer alleen in de vorm van verlenging van de dienstverlening, soms op voorwaarde dat de klant de onderbreking meldde en de ‘service credit’ tijdig claimt. Deze naar Angelsaksisch recht volstrekt logische aanpak spoort niet helemaal met ons onderscheid tussen inspannings- en resultaatsverbintenis: terwijl de hoofdverplichting is geformuleerd (en waarschijnlijk ook bedoeld) als inspanningsverbintenis, is de boete verschuldigd wanneer het beoogde resultaat niet (vaak genoeg) is gerealiseerd, ook al was er wel voldoende inspanning en is dus naar de Nederlandse systematiek voldaan aan de hoofdverplichting.²⁰x Vgl. art. 6:92 lid 3 BW. Mijn indruk is dat dit in de praktijk geen probleem oplevert doordat de betreffende leverancier in zo’n geval gewoon de ‘service credit’ uitbetaalt. Toch kan het zinvol zijn om de ‘service levels’ te benoemen als resultaatsverplichtingen. Samen met een bepaling dat schadevergoeding kan worden gevorderd naast de ‘service credit’ (of voor zover de schade groter is dan de ‘service credit’),²¹x In afwijking van art. 6:92 lid 2 BW. maakt dat het makkelijker schadevergoeding te vorderen als het echt misgaat.

  Vaak is het de bedoeling van zowel klant als leverancier dat de SaaS verder wordt ontwikkeld. Die ontwikkeling wordt primair bepaald door wat de leverancier denkt dat zijn doelgroep wenst. Door juist dat te ontwikkelen behoudt de leverancier zijn bestaande klanten en maakt hij zijn aanbod aantrekkelijker voor nieuwe klanten. Dat maakt het voor klanten belangrijk een leverancier te kiezen waarvoor zij in de kern van de doelgroep vallen. Wie als franchisegever een oplossing afneemt die gericht is op franchisegevers, wordt waarschijnlijk beter in toekomstige behoeften voorzien dan wanneer een oplossing wordt gekozen die gericht is op het grootwinkelbedrijf. De website, klantenlijst en ‘roadmap’ (planning welke nieuwe functionaliteit wanneer ter beschikking komt) van de leverancier geven daar samen waarschijnlijk een goed inzicht in. De meeste leveranciers willen zich niet vastleggen op hun ‘roadmap’. Daar kunnen goede redenen voor zijn.²²x Zie ook het slot van par. 2. Een leverancier kan ook de vrijheid willen behouden iets beters te doen dan opgenomen in de ‘roadmap’, mocht iets beters worden bedacht. In de praktijk zal de klant het dus moeten doen met de verwachting dat eigenbelang van de leverancier zal leiden tot de juiste ontwikkelingen in de toekomst.

  Allereerst zouden de veranderingen niet moeten leiden tot materiële verslechtering van de functionaliteit. Gezien de wens tot verbetering van de SaaS moet de leverancier het recht hebben de oplossing te wijzigen. Wat de een ervaart als een verbetering kan een ander ervaren als een verslechtering. Een verbetering zou echter niet moeten leiden tot verlies van belangrijke functionaliteit. Vandaar dat de bepalingen die dit regelen gewoonlijk de leverancier ruimte laten te wijzigen voor zover dat niet leidt tot materiële verslechteringen. Als die laatste kwalificatie niet in de standaardvoorwaarden is opgenomen, kan het zinvol zijn deze alsnog op te nemen.²³x Nu is ‘materieel’ natuurlijk geen helder criterium en zou het vanuit dat oogpunt mooi zijn enkele voorbeelden op te nemen ter verduidelijking van dat criterium. Ik ben zelf geneigd de vraag om toevoeging van zo’n bepaling vooral te zien als een vraag naar het beleid van de leverancier: als die daar vlot ‘ja’ op zegt, zal het daar wel goed mee zitten.

  Verder zijn aan de ontwikkeling van de oplossing ook positieve eisen te stellen. Bijvoorbeeld dat het beveiligingsniveau passend moet blijven, ook waar de bedreigingen in de loop van de tijd toenemen, en dat de oplossing moet blijven werken ook als de context waarvoor ze is ontworpen verandert. Denk voor dat laatste bijvoorbeeld aan de situatie dat de SaaS is ontworpen voor gebruik in samenhang met andere software. Dan kan het nodig zijn de verbindingen van de SaaS voor communicatie met die andere software aan te passen als die andere software wordt aangepast. SaaS voor rapportage aan de Belastingdienst of een toezichthouder bijvoorbeeld, zal moeten faciliteren dat de rapportage ook nog correct kan plaatsvinden als de Belastingdienst of die toezichthouder nieuwe eisen stelt.

• 6. Het toegelaten gebruik

  Waar leveranciers meer marge realiseren op additionele verkopen dan op de initiële verkoop, hebben zij er belang bij de verstrekte licentie zo beperkt mogelijk te omschrijven. SaaS-overeenkomsten bevatten dan ook verschillende soorten gebruiksbeperkingen:

  • wie de dienst mag gebruiken;

  • waar de dienst mag worden gebruikt;

  • waarvoor de dienst mag worden gebruikt;

  • bij welk gebruik meer moet worden betaald.

  Licenties worden meestal verstrekt aan de vennootschap die partij is bij de overeenkomst. Waar die onderdeel is van een bedrijf dat als groep van ondernemingen is georganiseerd, is het meestal de bedoeling dat ook groepsmaatschappijen die oplossing kunnen gebruiken. Ook waar evident wordt ingekocht voor een groep, voorzien de door een leverancier verstrekte standaardvoorwaarden daar niet altijd in. Bedenk daarbij dat een groepsdefinitie soms niet alleen moet voorzien in gebruik door vennootschappen die worden gecontroleerd door de licentienemer, maar ook in gebruik door vennootschappen die de betreffende licentienemer controleren en vennootschappen die door die vennootschappen worden gecontroleerd. Als wordt gewerkt met een lijst van groepsmaatschappijen kunnen complicaties ontstaan wanneer een onderdeel wordt opgericht of overgenomen: aan de groep wordt toegevoegd of juist van de groep wordt afgesplitst. Een dynamische (abstract geformuleerde) definitie werkt daardoor beter, bij voorkeur met een bepaling dat een verkocht onderdeel nog gedurende een overgangsperiode (meestal zes tot twaalf maanden) mag worden behandeld als een groepsmaatschappij. Zo krijgt dat afgesplitste onderdeel de tijd een eigen licentie of een alternatief te regelen, waardoor de kans wordt verkleind dat continuïteit moet worden verzekerd tegen de lijstprijs.

  Bij oplossingen die bedoeld zijn ter ondersteuning van de samenwerking met andere partijen zullen die andere partijen de oplossing vaak ook gebruiken. Denk aan systemen voor voorraadbeheer, de verwerking van facturen, begeleiding van bouwprojecten of logistiek. Of bij een pensioenadministratiesysteem aan de deelnemers. Dan mag het gebruiksrecht niet beperkt zijn tot personeel van de licentienemer (en van groepsmaatschappijen). Als gebruik wordt toegestaan aan eenieder die door de licentienemer is geautoriseerd, doet dit probleem zich niet voor. Maar soms is het gebruiksrecht beperkt tot de licentienemer (groepsmaatschappijen) en de daarvoor werkzame personen. Dan valt het gebruik door dergelijke ‘derden’ buiten de licentie. Iets vergelijkbaars kan zich voordoen als de licentie is beperkt tot eigen personeel: dan is gebruik door contractwerkers (zzp’ers) en leveranciers niet toegestaan.

  Licenties worden vaak ook naar doel beperkt. Zo voorzien veel Engelstalige licenties slechts in gebruik voor ‘internal business purposes’. Die bepaling schijnt vooral te zijn bedoeld ter voorkoming van doorverkoop: dat de licentienemer de software of SaaS gebruikt om derden in staat te stellen hun eigen bedrijfsvoering uit te oefenen, waardoor die derden niet hoeven te contracteren met de oorspronkelijke leverancier (en die leverancier potentiële omzet misloopt). Wanneer de software een puur intern proces ondersteunt, de loonadministratie bijvoorbeeld, lijkt die beperking geen enkel probleem. Maar hoe zit dat met een logistiek systeem waarbij het de bedoeling is de logistiek van leveranciers goed op de bedrijfsvoering van de klant te laten aansluiten? Dan dient de software niet alleen de interne bedrijfsvoering van de klant/licentienemer, maar ook de externe relaties van die klant en de bedrijfsvoering van diens leveranciers (die zijn ook gebaat bij een goede logistieke afstemming). In dat soort situaties lijkt het me beter de beperking tot ‘internal’ te schrappen, of te verduidelijken dat communicatie met de omgeving onder die ‘internal business purposes’ valt.

  Een enkele keer beperken de standaardvoorwaarden het geoorloofde gebruik tot specifiek benoemde locaties of landen. Soms is dat nog een overblijfsel van de tijd dat licenties werden verleend voor specifieke (lokale) installaties. Dan laat zo’n beperking zich gemakkelijk schrappen. Soms is de oplossing slechts geschikt voor gebruik in specifieke landen. Ook dan is het zinvol om na te kijken of de formulering daar wel goed op is afgestemd. Waar werknemers ook vanuit het buitenland willen kunnen inloggen, zou dat niet nodeloos moeten worden verboden. Een enkele keer blijkt het een bewuste reflectie te zijn van een licentiemodel waarbij extra moet worden betaald voor gebruik in meer landen.

  Daarnaast zijn er gebruiksbeperkingen die er openlijker op zijn gericht de klant meer te laten betalen als de klant meer wil gebruiken. Dit komt tot uitdrukking in de vergoedingssystematiek.

• 7. De vergoedingssystematiek

  Leveranciers ontwikkelen licentiemodellen waarmee zij zo goed mogelijk beprijzen hoe zij waarde bijdragen aan de gebruikers van hun SaaS.²⁴x Hoe nauwkeuriger ze de gevraagde vergoeding kunnen afstemmen op de daarmee te realiseren waarde, hoe groter het deel van die toegevoegde waarde dat zij kunnen opeisen. Er zijn grofweg vier manieren waarop dit kan worden gedaan (soorten licentie-‘metrics’):

  1. naar aantal gebruikers;

  2. naar het deel van de software dat wordt gebruikt;

  3. naar de (mogelijke) intensiteit van het gebruik;

  4. naar de omvang van de bedrijvigheid die met het gebruik wordt ondersteund.

  Gewoonlijk wordt de betreffende licentieomvang overeengekomen voor de gehele initiële duur van de overeenkomst (vaak drie jaar) en kan de klant wel bijkopen, maar niet verminderen.²⁵x Waarover par. 2 hiervoor.

  Ieder van deze manieren kent eigen uitdagingen. Wie als gebruiker telt, kan op verschillende wijzen worden gedefinieerd: door wie toegangsrechten heeft (‘authorised users’), door wie instructies kan geven (dat kan ook indirect zijn, via andere software, doordat die andere software informatie/instructies doorgeeft aan de relevante software), door verbindingen of automaten (robots) wel of niet ook mee te tellen, of door alleen het aantal (menselijke) gebruikers te tellen dat tegelijk gebruikmaakt van de oplossing (‘concurrent users’). Bij wijze van voorbeeld: een elektronische weegschaal op de groenteafdeling kan zijn gekoppeld aan een databestand voor de prijzen van de dag. Als het gaat om geautoriseerde gebruikers van dat databestand, tellen de mensen die groente komen wegen waarschijnlijk niet mee en de weegschalen ook niet. Maar als het gaat om wie instructies kan geven, tellen de winkelbezoekers die groente wegen waarschijnlijk wel mee (hun gebruik van de weegschaal leidt dan immers tot gebruik van het databestand). De weegschalen tellen wel mee als automaten of verbindingen, maar niet als menselijke gebruikers. En het maakt enorm uit of we tellen wie in de loop van de tijd van de weegschaal gebruikmaakt, of wie er tegelijk van de weegschaal gebruikmaakt.

  Het staat partijen (in de praktijk: de leverancier) vrij het relevante gebruik naar eigen inzicht te definiëren. Zo kent SAP voor ‘on premise’-licenties de volgende definitie: ‘“se” means to activate the processing capabilities of the Software, load, execute, access, employ the Software, or display information resulting from such capabilities’.²⁶x www.sap.com/about/trust-center/agreements/partner-edge/end-user-agreements.html. Dat laten zien van resultaten maakt het enorm ruim: ook het door een afnemer aan een collega laten zien van een met SAP gecreëerde factuur zou gebruik van de software zijn. Dit soort bepalingen is veelal niet aanpasbaar, maar kan vaak wel worden verduidelijkt, zodat de strekking feitelijk wordt beperkt.

  Door functionaliteit in modules aan te bieden kan de leverancier onderscheid maken tussen klanten die veel en klanten die weinig functionaliteit gebruiken: de klanten die meer gebruiken ontlenen daar waarschijnlijk meer waarde aan en zijn dus bereid meer te betalen. Dat leidt tot een situatie waarbij per module wordt betaald. Vergelijkbaar is een model waarbij onderscheid wordt gemaakt tussen verschillende soorten gebruikers, waarbij het ene type meer of andere functionaliteit mag gebruiken dan het andere. Als die modules (of functionaliteit) alleen kunnen worden gebruikt wanneer ze expliciet toegankelijk zijn gemaakt, weet de klant waar hij aan toe is. Soms echter heeft de leverancier alles toegankelijk gemaakt en moet de klant erop toezien dat gebruikers zich aan de contractuele beperkingen houden. Dat is onbegonnen werk. Een contractuele bepaling die dan nog wel eens wil helpen is dat de klant na ontdekking van te ruim gebruik enkele maanden krijgt voor het stoppen van de overschrijdingen en dat hij, als dat lukt, alsnog niet hoeft te betalen voor die overschrijdingen.

  De intensiteit van gebruik kan op tal van manieren worden berekend. Bij licenties voor eigen installatie gaat het daarbij meestal om de capaciteit van de servers die worden ingezet voor het hosten van de software. Bij SaaS kan het bijvoorbeeld gaan over de contractueel overeengekomen upload- of downloadsnelheid, of over de beschikbare opslagcapaciteit. Het kan ook gaan om het aantal geadministreerde rekeningen of polissen of producten. Het kan gaan om het aantal keren dat iets is bekeken, het aantal verstuurde sms’jes, het aantal transacties dat is ondersteund, of het aantal facturen. Ook hier is het belangrijk nauwkeurige definities te gebruiken. Telt het aantal opgemaakte facturen (waarbij correcties wel of niet meetellen), het aantal verzonden facturen (creditfacturen wel of niet meegeteld) of het aantal betaalde facturen (of telt het aantal betalingen)?

  Een enkele keer wordt geabstraheerd van de intensiteit waarmee de oplossing wordt gebruikt, en aangesloten op de omvang van het bedrijf dat met de oplossing wordt ondersteund. Dan wordt de licentievergoeding bijvoorbeeld afhankelijk gemaakt van de omzet van het bedrijf, of van het aantal personeelsleden, het aantal fte’s, het aantal winkels of het aantal verkochte vaten olie. Hier kan de definitie van de relevante licentiegerechtigden (groep) veel verschil maken: als er binnen de groep maar één divisie gebruikmaakt van een bepaalde oplossing, is het niet altijd de bedoeling dat ook de andere divisies meetellen voor de bepaling van de licentievergoeding.

  Wanneer het gebruik groter is dan overeengekomen, kan dat op verschillende manieren worden gesanctioneerd. Klassiek is de bepaling dat de leverancier de overeenkomst met onmiddellijke ingang kan opzeggen wanneer de oplossing meer wordt gebruikt dan overeengekomen. Dat zet voor de klant extra druk op de onderhandelingen over de prijs van extra gebruiksrechten wanneer is geconstateerd dat er meer werd gebruikt dan gelicentieerd. Leveranciers zijn in toenemende mate bereid een dergelijke sanctie te vervangen door een verplichting additionele rechten te kopen – gewoonlijk een oplossing in het belang van beide partijen. Daarbij is het vaak mogelijk te bedingen dat die rechten kunnen worden bijgekocht tegen dezelfde prijs als bij de initiële aankoop, of met eenzelfde korting op de lijstprijs (die inmiddels kan zijn verhoogd). Sommige leveranciers zitten hier (naar eigen zeggen) ‘principieel’ in: als de klant pas bijkoopt nadat de leverancier overschrijding heeft geconstateerd, moet de volle lijstprijs worden betaald. Dit is natuurlijk vooral een probleem als de leverancier de oplossing zo heeft ingericht dat de klant het gebruik niet goed kan bijhouden.

  Zoals in paragraaf 2 genoemd, krijgt de klant bij initiële aankopen meestal een aanzienlijke korting op de lijstprijs.²⁷x Zo bood SAP bij invoering van een nieuw licentiemodel meteen 90% korting op haar lijstprijs, zie https://news.sap.com/wp-content/blogs.dir/1/files/DAAP_External_FV_050520.pdf, p. 7. Het is niet vanzelfsprekend dat de leverancier eenzelfde korting biedt bij uitbreiding of verlenging van de dienstverlening.²⁸x Zo suggereert Salesforce dat verlenging plaatsvindt tegen lijstprijzen tenzij voor identieke hoeveelheden en duur wordt verlengd of het orderformulier expliciet anders bepaalt, zie www.salesforce.com/content/dam/web/en_us/www/documents/legal/Salesforce_MSA.pdf, artikel 11.2. Hoewel de meeste leveranciers een tamelijk consistent beleid lijken te volgen bij verlenging (waarbij vergoedingen flink worden verhoogd, maar niet zoveel dat het aantrekkelijker is voor de klant om een alternatief te implementeren), lijkt het me voor klanten verstandig daar afspraken over te maken. Veel leveranciers zijn daartoe bereid.

  Als er verschillende maatstaven zijn op basis waarvan wordt bepaald wat de gebruiksruimte is binnen de licentie en hoeveel moet worden betaald, kan het zinvol zijn te bedingen dat de klant daartussen kan ruilen. Zo kan SaaS ter ondersteuning van het verkoopproces de licentie laten bestaan uit een aantal personen dat wordt geautoriseerd, een aantal landen waarvoor een website wordt onderhouden en een aantal unieke producten dat wordt verkocht (SKU’s²⁹x Stock keeping units: unieke producten in een productassortiment.). Als die aantallen vastliggen en er blijkt minder personeel nodig voor het verkopen van een kleiner assortiment in meer landen, zal de klant in beginsel gebruikers en SKU’s over hebben en landen moeten bijkopen. Als een ruilmogelijkheid is bedongen, kan de klant gebruikers en SKU’s inruilen tegen landen (gewoonlijk op basis van hun respectieve originele aankoopprijs of hun respectieve lijstprijs). Dat kan de klant een aanzienlijke besparing opleveren. Zoiets later regelen is vaak moeilijk.

• 8. Implementatie

  Waar de leverancier aparte overeenkomsten verlangt voor SaaS (met een minimumlooptijd) en voor de implementatie, zal de klant zich moeten afvragen hoe groot de kans is dat de implementatie mislukt en hoeveel de klant dan aan de SaaS heeft. Als er ook gekwalificeerde alternatieve implementatiepartners zijn, zou zo’n constructie door de klant kunnen worden geaccepteerd. Zijn die er niet, dan kan de klant vertrouwen op het leerstuk van de verbonden overeenkomsten,³⁰x A.H. Lamers, Verbonden overeenkomsten in het handelsrecht, Zutphen: Uitgeverij Paris 2018. met het risico dat een rechter zal oordelen dat partijen een dergelijke verbondenheid juist niet hebben beoogd, of zoeken naar een commerciële oplossing. Zo kan worden afgesproken dat de leverancier eerst door middel van een pilot laat zien dat het meest risicovolle deel van de implementatie mogelijk is. Ook kan worden gedacht aan een aansprakelijkheid onder de implementatieovereenkomst die toelaat dat de klant de kosten van de SaaS terugvordert als de implementatie mislukt. Als dat niet werkt, kan nog worden gedacht aan een in omvang beperkte SaaS-overeenkomst met een optie tot uitbreiding wanneer de implementatie is geslaagd.

  Waar de leverancier klantspecifieke diensten verricht, is normaal evident sprake van een bijzondere zorgplicht.³¹x Zie bijv. P.G. van der Putt & C.A.M van de Bunt, Bijzondere zorgplichten van IT-leveranciers, Computerrecht 2018/160, p. 193-200. Bij Angelsaksisch geïnspireerde overeenkomsten van opdracht in de IT-sector bestaat de neiging die zorgplicht weg te schrijven. Dan wordt de klant sterk afhankelijk van de concurrentiële druk zoals ervaren door de leverancier³²x Die is groter naarmate het voor klanten makkelijker is over te stappen naar een andere leverancier en naarmate de leverancier het belangrijker vindt marktaandeel te winnen. en van de kwaliteit van de expliciet gemaakte afspraken. Denk daarbij aan afspraken over functionaliteit (zie daarover paragraaf 4), afspraken over reactietijden van de applicatie (hoe snel instructies door de software worden verwerkt) en afspraken over beschikbaarheid.

• 9. Beschikbaarheid

  Een cruciaal verschil tussen SaaS en in de eigen omgeving draaiende software is dat de klant bij SaaS voor de beschikbaarheid van de oplossing afhankelijk is van de leverancier. Als de leverancier de beschikbaarheid expres of per ongeluk onderbreekt, heeft dat direct tot gevolg dat de klant er niet mee kan werken. Dat is lang niet altijd problematisch. Zo kan een klant waarschijnlijk best een dag zonder software voor het administreren en uitbetalen van lonen, het doen van belastingaangiftes of de administratie van pensioenen, voordat dat een probleem veroorzaakt. Bij software voor de aansturing van de productie kan dat heel anders liggen. De aan de beschikbaarheid van de SaaS te stellen eisen zijn dus afhankelijk van de functie van de software.

  Nog meer dan bij het oplossen van incidenten zien de meeste leveranciers de ‘service levels’ voor beschikbaarheid als resultaatsverbintenissen. Het is zinvol dat te verduidelijken en in aanvulling op de eventuele ‘service credits’ te voorzien in schadevergoeding.³³x Zie par. 3 hiervoor. Gewoonlijk wordt beschikbaarheid door de leverancier gemeten (ook omdat die niet verantwoordelijk is voor het internet wat meestal tussen zijn metingen en die van de klant zit) en gerapporteerd per maand. Als over een langere periode wordt gemeten, staat eenzelfde percentage beschikbaarheid een langduriger onderbreking toe.³⁴x Een uur per maand is drie uur per kwartaal.

• 10. Remedies

  Het uitgangspunt in de meeste standaardvoorwaarden voor SaaS is dat als er een gebrek is, de leverancier dat gebrek zal herstellen of nog eens zal leveren zonder gebrek. Bij continue dienstverlening werkt dat natuurlijk niet: de inmiddels ontstane gevolgen van het gebrek worden niet ongedaan gemaakt doordat het gebrek wordt verholpen.³⁵x Of wat cru gezegd: als ik door niet-functionerende remmen tegen een boom ben gereden, helpt het repareren van de remmen niet veel meer. Dat verklaart waarom daarvoor ‘service credits’ worden beloofd. Veel leveranciers zouden het daar graag bij houden en stellen daarom een ‘exclusive remedy’-bepaling voor: dat de klant verder geen rechten heeft ter zake van het betreffende gebrek. Dat zou betekenen dat de klant geen recht heeft op schadevergoeding en geen recht op (gedeeltelijke) ontbinding. Dat kan acceptabel zijn voor relatief korte onderbrekingen van de beschikbaarheid, snel herstelde gebreken en een mogelijkheid terug te vallen op een vorige versie (als de nieuwe versie niet goed blijkt te werken). Dan kan de klant de schade beperkt houden. Maar als de SaaS een cruciale functie vervult, zal het ontbreken van verhaal onbevredigend zijn. Als de ‘exclusive remedy’-bepaling dan niet kan worden geschrapt, zou een compromis kunnen worden gevonden door de periode dat het gebrek voortduurt aan te merken als een niet-beschikbaarheid en zo mee te laten wegen voor de bepaling of er ‘service credits’ zijn verschuldigd. Bij beveiligingsincidenten is ook dat geen oplossing – daarvoor zou herstel geen ‘exclusive remedy’ moeten zijn (en is dat waarschijnlijk ook niet bedoeld).

  Voor zover de klant dan toch schadevergoeding zou kunnen vorderen wegens een toerekenbare tekortkoming aan de zijde van de leverancier (artikel 6:74 BW), willen de leveranciers de schadeplichtigheid veelal verregaand beperken. Zo zijn er leveranciers die standaard aansprakelijkheid uitsluiten voor het verlies van data, zelfs waar zij apart worden betaald voor een back-updienst (het regelmatig opslaan van de data opdat die niet verloren gaan). Bijna standaard wordt voorgesteld schade voor onderbreking van de bedrijfsvoering, verlies aan omzet, verlies van winst en dergelijke uit te sluiten, steeds vaker zelfs de kosten van een vervangende oplossing. Dit soort uitzonderingen is vaak onderhandelbaar.

  Bijzondere aandacht verdienen de uitsluitingen voor ‘indirect, special, incidental, consequential, exemplary or punitive damages’. Naar ik begrijp heeft een deel van deze termen naar Engels recht en het recht van sommige Amerikaanse staten niet altijd eenzelfde specifieke betekenis. Zo lijken de Engelsen geen specifieke betekenis toe te kennen aan ‘special’ en ‘incidental’³⁶x Een degelijk onderzoek hiernaar heb ik niet gedaan, maar een onderzoekje via het internet geeft weinig eenduidige informatie. Zo lijkt ‘special’ soms gelijkgesteld te worden aan ‘consequential’ en soms meer te omvatten. ‘Incidental’ heeft in de VS in het kader van de koop en verkoop van roerende goederen wel een specifieke betekenis. De in het recht van de meeste staten omgezette Universal Commercial Code bepaalt in art. 2-715: ‘Incidental damages resulting from the seller’s breach include expenses reasonably incurred in inspection, receipt, transportation and care and custody of goods rightfully rejected, any commercially reasonable charges, expenses or commissions in connection with effecting cover and any other reasonable expense incident to the delay or other breach.’ Buiten het toepassingsgebied van die UCC lijkt ‘incidental damage’ te gaan om de kosten van het mitigeren van de schade. – het is meestal verrassend eenvoudig die geschrapt te krijgen (bijvoorbeeld naar aanleiding van de vraag daar even definities voor aan te leveren omdat ze naar Nederlands recht geen duidelijke betekenis hebben). Bij ‘exemplary’ of ‘punitive damages’ gaat het om een toewijzing van een vergoeding die hoger is dan de geleden schade omdat het relevante gedrag zó onoorbaar is, dat het ermee verkregen voordeel moet worden afgeroomd, of dat zelfs een bestraffing is gerechtvaardigd, bijvoorbeeld door het met het gedrag beoogde voordeel financieel te maken en aan de eiser te laten vergoeden.³⁷x Zie bijv. Axa Insurance UK Plc/Financial Claims Solutions Ltd, [2018] EWCA Civ 1330.

  De begrippen ‘indirect’ en ‘consequential’ lijken naar Engels recht dezelfde vaste betekenis te hebben.³⁸x Zie Hadley/Baxendale, [1854] EWHC Exch J70 Courts of Exchequer; Vic­toria Laundry (Windsor) Ltd/Newman Industries Ltd, [1949] 2 KB 528; Koufos/C Czarnikow Ltd (The Heron II), [1969] 1 AC 350; en bijv. https://cms.law/en/int/expert-guides/cms-guide-to-consequential-loss-clauses-in-the-energy-sector/overview, waar wel wordt gewaarschuwd voor de mogelijkheid dat die interpretatie gaat veranderen. Daarbij wordt ‘direct damage’ omschreven als ‘the amount of injury which would arise generally, and in the great multitude of cases not affected by any special circumstances, from such breach of contract’.³⁹x Hadley/Baxendale, [1854] EWHC Exch J70 Courts of Exchequer. ‘Indirect or consequential damage’ is naar Engels recht dan de andere schade die (slechts) voorzienbaar en toerekenbaar is met bekendheid met de speciale omstandigheden van de ander. Dat is een veel beperkter begrip dan ons begrip ‘gevolgschade’.⁴⁰x Zie bijv. GB Gas Holdings Ltd/Accenture (UK) Ltd, [2010] EWHC 2928 (Comm), waarover bijv. www.pinsentmasons.com/out-law/guides/gb-gas-holdings-limited-v-accenture-uk-limited-and-others-. Veel van wat naar Nederlands recht ‘gevolgschade’ is, is naar Engels recht dus ‘direct damage’. In de praktijk blijken Angelsaksische juristen die uitsluiting van ‘indirect or consequential damage’ niet los te willen laten, ook niet wanneer Nederlands recht van toepassing is. Omdat die termen naar Nederlands recht geen vaste betekenis hebben en er nogal wat mensen zijn die denken dat ‘consequential damage’ moet worden vertaald als ‘gevolgschade’, raad ik bij handhaving van de Engelse termen in een contract naar Nederlands recht aan te verduidelijken dat de Engelse betekenis is bedoeld. bijvoorbeeld met een definitie van ‘direct damage’ als hiervoor gegeven of als ‘losses that may fairly and reasonably be considered to arise “naturally”, i.e. according to the usual course of things from the breach of contract’.

  De aansprakelijkheid die na de hiervoor beschreven beperkingen overblijft wordt meestal ook nog beperkt met een financiële aansprakelijkheidslimiet. Meestal wordt die voorgesteld (in totaal over de looptijd van de overeenkomst) als gemaximeerd op wat in de voorgaande zes of twaalf maanden is betaald voor de betreffende dienst. Zo’n beperking kent verschillende uitdagingen. Allereerst is het zaak erop te letten dat de aansprakelijkheidslimiet aansluit op de vergoedingen voor het totaal aan diensten. Vanwege de betalingstermijn is het beter die aan te laten sluiten op de in rekening gebrachte vergoedingen dan op de betaalde vergoedingen. Omdat SaaS-diensten vaak per jaar vooraf worden betaald, is het zaak op te letten of het aanknopingspunt voor de berekening van het maximum niet tot een raar resultaat leidt. Zo’n wisselend bedrag is te voorkomen door te kiezen voor een veelvoud van de vergoeding per maand of per jaar in plaats van wat er in een bepaalde periode is of moet worden betaald (marktconform is één à twee keer de jaarvergoeding). Leveranciers stellen niet altijd een wederkerig maximum voor, maar accepteren dat gewoonlijk wel.

  Voor de verwerking van persoonsgegevens wordt gewoonlijk een verhoogde aansprakelijkheidslimiet geaccepteerd (meestal drie à vijf keer de jaarvergoeding). De hierna te bespreken vrijwaring voor inbreukclaims is meestal niet onderworpen aan een maximumbedrag.

• 11. Vrijwaring voor inbreuk op andermans IE-rechten

  Bijna altijd biedt de leverancier een beperkte vrijwaring aan voor claims van derden die zijn gebaseerd op inbreuk van de SaaS op intellectuele eigendomsrechten (IE-rechten) van die derden. Net als bij gewone softwarelicenties worden die vrijwaringen geboden ter beperking van de aansprakelijkheid van de leverancier. Uitgangspunt is immers, dat een partij niet iets mag verkopen waarop die geen rechten heeft. Is dat toch gebeurd en wordt de klant daarvoor aangesproken, dan kan de klant de leverancier in vrijwaring roepen. De geboden contractuele vrijwaring is geschreven ter vervanging van dat vrijwaringsrecht, beperkt de aansprakelijkheid van de leverancier gewoonlijk tot de betalingsverplichting jegens de rechthebbende (en eventuele juridische kosten), maar sluit andere schadevergoeding gewoonlijk uit (zoals schade door het niet mogen gebruiken van de SaaS en de kosten van het moeten regelen van een vervangende oplossing).⁴¹x Zie voor onderhandelingstips bijv. www.taylorwessing.com/synapse/ti-ip-indemnities-in-commercial-agreements.html en https://blog.galkinlaw.com/weblaw-scout-blog/guide-to-negotiating-an-ip-indemnity.

• 12. Looptijd en einde

  Voor een langere initiële looptijd hoeft meestal per jaar minder te worden betaald. Een automatische verlenging of optie om te verlengen is zinvol, omdat dat in beginsel impliceert dat tegen dezelfde prijzen kan worden verlengd. Vaak stellen leveranciers een indexatie of minimumverhoging voor bij verlenging. Dat soort bepalingen is gewoonlijk goed onderhandelbaar.

  Met name waar het de klant veel tijd kost de betreffende SaaS te vervangen door een andere, is het goed te voorzien in een verlengingsmogelijkheid voor de klant, en voor de leverancier in een opzegtermijn die langer is dan de periode benodigd voor die vervanging. Anders loopt de klant het risico zonder oplossing te blijven zitten of extra te moeten betalen voor verlenging van de oplossing waaruit wordt vertrokken.

  De meeste leveranciers bieden tegenwoordig gestandaardiseerde formats aan om eventueel door de leverancier voor de klant gehouden data te exporteren. Als dat niet standaard is aangeboden, is het zinvol daarnaar te vragen. Uiteindelijk moet de klant natuurlijk over de eigen gegevens kunnen beschikken en wel in een bruikbaar format.

• 13. Slot

  Door leveranciers opgestelde standaardvoorwaarden voor SaaS bieden talloze aanknopingspunten voor onderhandelingen. Omdat het geduld van leveranciers (zelfs als het over hun eigen voorwaarden gaat) niet oneindig is en ook de klant zijn schaarse tijd moet verdelen, moet telkens weer worden afgewogen waarover in de specifieke context moet worden onderhandeld en wat (met pijn in het hart) toch maar moet worden geaccepteerd. Dat wordt in belangrijke mate bepaald door het gebruik dat de klant verwacht van de SaaS te maken en het bedrijfsmodel van de leverancier. Bij jonge leveranciers is borging van de functionaliteit belangrijk, omdat daar een reëel risico bestaat dat door innovatie functionaliteit verdwijnt. Als de SaaS moet functioneren in een omgeving die snel verandert, is de kwaliteit van het onderhoud belangrijker dan wanneer de SaaS een vrij statische behoefte vervult. Het toegelaten gebruik moet altijd minimaal het initieel beoogde gebruik dekken en dat is meer een kwestie van opletten dan van lastige onderhandelingen. Bij leveranciers die veel verschillende producten hebben of veel maatstaven ter bepaling van de vergoedingen is het belangrijk te bedingen dat daartussen kan worden geruild. Bij kritieke toepassingen (waar al snel veel schade ontstaat bij niet-beschikbaarheid) is het belangrijk dat de beschikbaarheid goed is geborgd, liefst ook met aansprakelijkheid naast ‘service credits’. Naarmate de software moeilijker te vervangen is, is bescherming tegen prijsverhoging bij verlenging van de overeenkomst belangrijker. Succes!

Noten

• 1 Bijv. wanneer de SaaS-leverancier voor de hosting gebruikmaakt van een cloudomgeving van Microsoft, Amazon Web Services of Google.

• 2 Zie bijv. L. Ferreira Pires, Wat is cloud computing?, Computerrecht 2011/63, en www.bmc.com/blogs/saas-vs-paas-vs-iaas-whats-the-difference-and-how-to-choose/.

• 3 Een op de infrastructuur geïnstalleerde softwarelaag waarop vervolgens applicaties kunnen worden geïnstalleerd.

• 4 Namelijk de uitdagingen die hierna worden besproken.

• 5 Bij een overstap van een PaaS- naar een andere PaaS-dienst of van een IaaS- naar een andere IaaS-dienst vindt een verhuizing plaats van applicaties – die moeten voor zo’n verhuizing vaak wel een beetje anders worden geconfigureerd, maar omdat IaaS- en PaaS-diensten juist zijn ingericht om er makkelijk naartoe te verhuizen, zijn de noodzakelijke ingrepen over het algemeen gering (vergelijk: het verplaatsen van kleding van de ene kast naar de andere). Het vervangen van een applicatie vergt meestal dat de nieuwe applicatie weer geheel opnieuw moet worden ingericht voor de gebruiker (vergelijk: het vervangen van een semi-maatpak door een ander semi-maatpak). Dat kost meer tijd en geld en verslechtert daardoor de onderhandelingspositie van de klant ten opzichte van de leverancier.

• 6 Zie voor overeenkomsten die zonder onderhandelingen tot stand komen T.J. de Graaf, Pitfalls in ICT-contracten, Contracteren 2013/3, p. 99-107.

• 7 Bijv. C.M.D.S. Pavillon, Herijking van consumentencontractenrecht: duurzaamheid als nieuw ijkpunt?, in: C.M.D.S. Pavillon & W.H. van Boom, Privaatrechtelijke bescherming herijkt. Preadviezen (Nederlandse Vereniging voor Burgerlijk Recht), Zutphen: Uitgeverij Paris 2021; E. Neppelenbroek, De verstrekking van juridische voorwaarden in het voorportaal van de cloud, Contracteren 2020/4, p. 132-143.

• 8 Bijv. www.eiopa.europa.eu/document-library/guidelines/guidelines-outsourcing-cloud-service-providers.

• 9 Bijv. A. Karimi & J. Toornstra, De nieuwe standaardcontractbepalingen (SCCs) voor de doorgifte van persoonsgegevens naar derde landen: aandachtspunten voor organisaties, Tijdschrift voor Internetrecht 2021/5, p. 197-203; K. Daniëls & P. Kits, Contracteren in de cloud – ken uw risico’s, Contracteren 2015/1, p. 2-16.

• 10 State of New York c.q. England and Wales.

• 11 ‘Gebruik’ is auteursrechtelijk geen relevante term. Bij het gebruik van software (computerinstructies) worden bij elke instructie stukjes van de betreffende software gekopieerd en aan de computer gevoerd, zodat die kan doen wat de bedoeling is. Dat kopiëren van stukjes software vormt het auteursrechtelijk relevante ‘verveelvoudigen’, waarop de auteursrechthebbende het monopolie heeft. Daarvoor is dus diens toestemming nodig. De ‘licentie’ is die toestemming.

• 12 Als de licentie wordt verstrekt aan een vennootschap en haar groepsmaatschappijen mogen het in dat verband ook gebruiken, houdt het gebruiksrecht van zo’n groepsmaatschappij in beginsel op zodra de aandelen daarvan aan een derde zijn geleverd en die dus geen groepsmaatschappij meer is. Als daarbij is afgesproken dat alleen de op een lijst vermelde groepsmaatschappijen het mogen gebruiken, mag een nieuwe groepsmaatschappij het pas gebruiken wanneer zij aan die lijst is toegevoegd.

• 13 Waarover par. 9 hierna.

• 14 Dergelijke opties worden ook wel een ‘price hold’ genoemd.

• 15 Met name wanneer die kan worden toegerekend aan het licentiëren van bestaande software.

• 16 Een poging tot vernietiging wegens niet-beschikbaarheid van een deel van de algemene voorwaarden stuit niet alleen vaak af op art. 6:235 BW, maar heeft ook weinig zin vanwege de constructie dat de dienst ‘as is’ wordt verkocht, met als uitzondering dat wel in hoofdzaak wordt geborgd wat in de documentatie staat. Dan leidt het vernietigen van die documentatie als algemene voorwaarden tot minder rechten.

• 17 Verkopers stellen de door hen aangeboden diensten vaak mooier voor dan ze zijn, en de juridische afdeling beoogt de leverancier daartegen te beschermen door hun verklaringen weg te schrijven. Uit HR 19 januari 2007, ECLI:NL:HR:2007:AZ3178, NJ 2007/575 (Meyer Europe B.V./Pontmeyer B.V.) blijkt dat opname van een ‘entire agreement’-beding sneller kan leiden tot een tekstuele uitleg, waarbij contractonderhandelingen en handelsgebruiken minder van belang zijn. Maar uit HR 3 april 2013, ECLI:NL:HR:2013:BY8101, NJ 2013/214 (Lundiform/Mexx) blijkt dat ook dan nog het Haviltex-gedachtegoed van toepassing is. Hoe dan ook: als de tekst duidelijk maakt dat tussen partijen andere afspraken dan vastgelegd niet binden, is het zaak zo veel mogelijk van de gemaakte afspraken ook op te nemen.

• 18 Bijv. de maximale reactiesnelheid van het systeem.

• 19 Een ‘service credit’, gewoonlijk in de vorm van een financiële tegemoetkoming, een enkele keer alleen in de vorm van verlenging van de dienstverlening, soms op voorwaarde dat de klant de onderbreking meldde en de ‘service credit’ tijdig claimt.

• 20 Vgl. art. 6:92 lid 3 BW.

• 21 In afwijking van art. 6:92 lid 2 BW.

• 22 Zie ook het slot van par. 2.

• 23 Nu is ‘materieel’ natuurlijk geen helder criterium en zou het vanuit dat oogpunt mooi zijn enkele voorbeelden op te nemen ter verduidelijking van dat criterium. Ik ben zelf geneigd de vraag om toevoeging van zo’n bepaling vooral te zien als een vraag naar het beleid van de leverancier: als die daar vlot ‘ja’ op zegt, zal het daar wel goed mee zitten.

• 24 Hoe nauwkeuriger ze de gevraagde vergoeding kunnen afstemmen op de daarmee te realiseren waarde, hoe groter het deel van die toegevoegde waarde dat zij kunnen opeisen.

• 25 Waarover par. 2 hiervoor.

• 26 www.sap.com/about/trust-center/agreements/partner-edge/end-user-agreements.html.

• 27 Zo bood SAP bij invoering van een nieuw licentiemodel meteen 90% korting op haar lijstprijs, zie https://news.sap.com/wp-content/blogs.dir/1/files/DAAP_External_FV_050520.pdf, p. 7.

• 28 Zo suggereert Salesforce dat verlenging plaatsvindt tegen lijstprijzen tenzij voor identieke hoeveelheden en duur wordt verlengd of het orderformulier expliciet anders bepaalt, zie www.salesforce.com/content/dam/web/en_us/www/documents/legal/Salesforce_MSA.pdf, artikel 11.2.

• 29 Stock keeping units: unieke producten in een productassortiment.

• 30 A.H. Lamers, Verbonden overeenkomsten in het handelsrecht, Zutphen: Uitgeverij Paris 2018.

• 31 Zie bijv. P.G. van der Putt & C.A.M van de Bunt, Bijzondere zorgplichten van IT-leveranciers, Computerrecht 2018/160, p. 193-200.

• 32 Die is groter naarmate het voor klanten makkelijker is over te stappen naar een andere leverancier en naarmate de leverancier het belangrijker vindt marktaandeel te winnen.

• 33 Zie par. 3 hiervoor.

• 34 Een uur per maand is drie uur per kwartaal.

• 35 Of wat cru gezegd: als ik door niet-functionerende remmen tegen een boom ben gereden, helpt het repareren van de remmen niet veel meer.

• 36 Een degelijk onderzoek hiernaar heb ik niet gedaan, maar een onderzoekje via het internet geeft weinig eenduidige informatie. Zo lijkt ‘special’ soms gelijkgesteld te worden aan ‘consequential’ en soms meer te omvatten. ‘Incidental’ heeft in de VS in het kader van de koop en verkoop van roerende goederen wel een specifieke betekenis. De in het recht van de meeste staten omgezette Universal Commercial Code bepaalt in art. 2-715: ‘Incidental damages resulting from the seller’s breach include expenses reasonably incurred in inspection, receipt, transportation and care and custody of goods rightfully rejected, any commercially reasonable charges, expenses or commissions in connection with effecting cover and any other reasonable expense incident to the delay or other breach.’ Buiten het toepassingsgebied van die UCC lijkt ‘incidental damage’ te gaan om de kosten van het mitigeren van de schade.

• 37 Zie bijv. Axa Insurance UK Plc/Financial Claims Solutions Ltd, [2018] EWCA Civ 1330.

• 38 Zie Hadley/Baxendale, [1854] EWHC Exch J70 Courts of Exchequer; Vic­toria Laundry (Windsor) Ltd/Newman Industries Ltd, [1949] 2 KB 528; Koufos/C Czarnikow Ltd (The Heron II), [1969] 1 AC 350; en bijv. https://cms.law/en/int/expert-guides/cms-guide-to-consequential-loss-clauses-in-the-energy-sector/overview, waar wel wordt gewaarschuwd voor de mogelijkheid dat die interpretatie gaat veranderen.

• 39 Hadley/Baxendale, [1854] EWHC Exch J70 Courts of Exchequer.

• 40 Zie bijv. GB Gas Holdings Ltd/Accenture (UK) Ltd, [2010] EWHC 2928 (Comm), waarover bijv. www.pinsentmasons.com/out-law/guides/gb-gas-holdings-limited-v-accenture-uk-limited-and-others-. Veel van wat naar Nederlands recht ‘gevolgschade’ is, is naar Engels recht dus ‘direct damage’.

• 41 Zie voor onderhandelingstips bijv. www.taylorwessing.com/synapse/ti-ip-indemnities-in-commercial-agreements.html en https://blog.galkinlaw.com/weblaw-scout-blog/guide-to-negotiating-an-ip-indemnity.