Automatiseringscontracten

Automatiseringscontracten

Automatiseringscontracten Handreiking voor IT-auditors december 2006

mr. M.B. Voulon mr. dr. A.W. Duthler

Grafische vormgeving: Bert Arts BNO

NOREA de beroepsorganisatie van IT-auditors Bezoekadres A.J. Ernststraat 55 1083 GR Amsterdam Postadres Postbus 7984 1008 AD Amsterdam [email protected] www.norea.nl tel +31 (0)20 3010380 fax +31 (0)20 3010302 Deze uitgave is ontwikkeld in samenwerking met: Duthler Associates IT recht adviseurs Frankenslag 137 2582 HH ’s-Gravenhage www.duthler.nl tel +31 (0)70 3922209 fax +31 (0)70 3922276 © 2006 Duthler Associates ISBN: 90 13 03692 9 Uitgegeven door: Uitgeverij Kluwer Deventer – 2006 www.kluwer.nl Deze uitgave wordt uitgegeven onder de Creative Commons licentie Naamsvermelding-GeenAfgeleideWerken-NietCommercieel 2.0 Nederland (http://creativecommons.org/licenses/by-nc-nd/2.0/nl/deed.nl). De volledige tekst van deze licentie is te vinden op http://creativecommons.org/licenses/by-nc-nd/2.0/nl/legalcode.

VOORWOORD

Voor u ligt de Handreiking Automatiseringscontracten. Na de uitgave ‘IT-Recht, Quick reference voor IT-auditors’ is dit de tweede juridische handreiking voor ITauditors. Met deze publicaties wordt beoogd de IT-auditor verder wegwijs te maken in de wereld van het IT-recht. Deze publicatie is tot stand gebracht in het kader van het productplan vaktechnische ontwikkeling onder auspiciën van de NOREA Vaktechnische Commissie. Ten tijde van deze publicatie wordt gewerkt aan een hernieuwde vaktechnische classificatie van NOREA publicaties. Door de Vaktechnische Commissie is aan het bestuur geadviseerd om deze uitgave vaktechnisch dusdanig te positioneren dat elke Register EDP-Auditor (RE) wordt geacht kennis te nemen en zich rekenschap te geven van de inhoud, die aldus deel uitmaakt van de expertise waarop zijn of haar oordeelsvorming is gebaseerd. Immers, elke RE zal in zijn beroepspraktijk te maken krijgen met aspecten van automatiseringscontracten of overeenkomsten waarin iets is vastgelegd over de aard en het niveau van dienstverlening dat met de inzet van informatietechnologie wordt beoogd. Ook is het denkbaar dat de dienstverlening door de IT-auditor zelf het onderwerp is van een contract. Voor dat doel is door het NOREAbestuur reeds in 1998 een ‘Model Algemene Voorwaarden voor dienstverlening door de IT-auditor (RE)’ gepubliceerd. De uiteenzetting over het gebruik van Algemene Voorwaarden in deze handleiding (hoofdstuk 5) kan daarop als een nuttige aanvulling worden beschouwd. Daarnaast bevat deze Handreiking Automatiseringscontracten praktische achtergrondinformatie over de aard en inhoud van automatiseringscontracten, contractuele aspecten inzake de aanschaf van hard- en software, outsourcing en offshoring en ten slotte verhandelingen over aansprakelijkheid en (beslechting van) geschillen. De handreiking is geschreven door juristen voor de doelgroep van IT-auditors en beperkt zich op hoofdlijnen tot de voor deze doelgroep relevante informatie. Het NOREA-bestuur hoopt met deze informatie haar leden van dienst te zijn. Deze uitgave is wederom tot stand gebracht in samenwerking met Duthler Associates en Uitgeverij Kluwer. Dank gaat uit aan eenieder die betrokken is geweest bij de totstandkoming van deze uitgave, in het bijzonder de samenstellers mr. M.B. Voulon en mr.mr. A.W. Duthler. Het bestuur van de NOREA.

V

INHOUDSOPGAVE

Voorwoord / V 1.

Inleiding / 1

1.1. 1.2.

Introductie / 1 Leeswijzer / 1

2.

Introductie in automatiseringscontracten / 3

2.1. 2.2. 2.3. 2.4. 2.5. 2.6. 2.7. 2.8.

Inleiding / 3 Wat is een contract? / 3 Wat is een automatiseringscontract? / 3 Wat is een goed automatiseringscontract? / 4 Soorten automatiseringscontracten / 5 Wat zijn algemene voorwaarden? / 5 Modelvoorwaarden: FENIT & BiZa / 5 De algemene voorwaarden van de overheid: ARVODI / 6

3.

Het sluiten van automatiseringscontracten / 7

3.1. 3.2. 3.3. 3.4. 3.5.

Inleiding / 7 Belang van de onderhandelingsfase / 7 Het afbreken van onderhandelingen in de precontractuele fase / 7 Letter of intent / 8 Aanbestedingstrajecten / 8

4.

Soorten automatiseringscontracten / 11

4.1. 4.2. 4.2.1. 4.3. 4.3.1. 4.3.2. 4.4. 4.4.1. 4.4.2.

Inleiding / 11 De inhoud van een automatiseringscontract / 11 Resultaatsverbintenis of inspanningsverbintenis? / 12 Aanschaf van hardware / 12 Omschrijving / 12 Aandachtspunten / 13 Aanschaf van software (standaardprogrammatuur) / 15 Omschrijving / 15 Aandachtspunten / 16

VII

Inhoudsopgave

4.4.3. 4.4.4.

4.5. 4.5.1. 4.5.2. 4.6. 4.6.1. 4.6.2. 4.6.3. 4.6.4. 4.6.5. 4.6.6.

De (software)ontwikkelingsovereenkomst / 19 Open source-software / 21 Inleiding / 21 Soorten licenties / 22 De Nederlandse overheid en open source / 23 Open source-software en het automatiseringscontract / 23 Onderhoudsovereenkomsten / 24 Omschrijving / 24 Aandachtspunten / 24 Outsourcing en offshoring / 26 Inleiding / 26 Het outsourcingtraject / 26 Juridische structuur van de outsourcingovereenkomst / 27 De outsourcingovereenkomst / 28 Lessons learned / 31 Offshoring / 32

5.

Het gebruik van algemene voorwaarden / 35

5.1. 5.2.

Inleiding / 35 Ambigu karakter van de wettelijke regeling van algemene voorwaarden / 35 Hoofdlijnen van de wettelijke regeling / 36 De zwarte en de grijze lijst / 37 Praktische aandachtspunten bij het gebruik van algemene voorwaarden / 39

5.3. 5.4. 5.5.

6.

Aansprakelijkheid / 43

6.1. 6.2. 6.3. 6.4. 6.5.

Inleiding / 43 Aansprakelijkheid op grond van wanprestatie / 44 Aansprakelijkheid op grond van onrechtmatige daad / 44 Soorten schade / 44 Beheersing van aansprakelijkheidsrisico’s / 45

7.

Geschillen / 49

7.1. 7.2. 7.3.

Inleiding / 49 De gang naar de rechter / 49 Alternatieve geschillenbeslechting: de Stichting Geschillenoplossing Organisatie en Automatisering (SGOA) / 50

Literatuur / 53

VIII

HOOFDSTUK 1

Inleiding

1.1.

Introductie

IT-auditing is de specialisatie die zich bezighoudt met de beoordeling van danwel advisering over de kwaliteit van geautomatiseerde informatievoorziening. De ITauditor zal daarom geregeld te maken hebben met trajecten waarin bijvoorbeeld een automatiseringssysteem wordt geïmplementeerd of wordt aangepast, of waarin hard- of software wordt aangeschaft, of waarin mankracht wordt ingehuurd. In deze situaties zal ook sprake zijn van een juridische inbedding: de betrokken partijen zullen hun afspraken vastleggen in een automatiseringscontract. In een automatiseringscontract worden diverse afspraken neergelegd, bijvoorbeeld met betrekking tot de vraag wie verantwoordelijk is voor bepaalde taken, wat de voltooiingscriteria zijn voor bepaalde werkzaamheden, wie aansprakelijk is voor welke risico’s en hoe wordt omgegaan met intellectuele eigendomsrechten. Deze uitgave bevat praktische handreikingen voor de IT-auditor die betrokken is bij een automatiseringstraject om tijdig twistpunten en risico’s bij het maken van bindende afspraken te onderkennen. Er wordt geen kennis op juridisch gebied of op het gebied van IT-auditing voorondersteld. Voor de juridische fijnproevers worden in de voetnoten verdere verwijzingen gegeven naar wetgeving en literatuur. Dit boekje is ontwikkeld op initiatief van NOREA, de beroepsorganisatie van gekwalificeerde IT-auditors in Nederland. Het is samengesteld door het toonaangevende adviesbureau op het gebied van het IT-recht, Duthler Associates. 1.2.

Leeswijzer

Het volgende hoofdstuk bevat een introductie in een aantal basisbegrippen omtrent automatiseringscontracten en geeft aan wanneer er sprake is van een goed automatiseringscontract. In hoofdstuk 3 worden algemene opmerkingen gemaakt over de wijze waarop een automatiseringscontract tot stand komt. Hoofdstuk 4 behandelt vier soorten automatiseringscontracten en biedt per soort contract praktische aandachtspunten waarmee rekening gehouden dient te worden. In hoofdstuk 5 wordt ingegaan op het gebruik van algemene voorwaarden (de ‘kleine lettertjes’) bij het aangaan van een automatiseringsovereenkomst. In hoofdstuk 6 wordt ingegaan op de aansprakelijkheidsrisico’s die de partijen bij een automatiseringscontract kunnen lopen en hoe zij deze risico’s kunnen beheersen. Hoofdstuk 7 behandelt kort de wijzen waarop met geschillen kan worden omgegaan.

1

HOOFDSTUK 2

Introductie in automatiseringscontracten 2.1.

Inleiding

Voor een goed begrip van de later meer gedetailleerd te behandelen soorten automatiseringscontracten, is het van belang eerst een paar algemene opmerkingen te maken. Daarom wordt in dit hoofdstuk eerst uiteengezet: – wat er onder ‘contract’ moet worden verstaan; – wat er kenmerkend is voor een automatiseringscontract; – wanneer er sprake is van een goed automatiseringscontract; en – wat de rol is van algemene voorwaarden en standaardvoorwaarden. 2.2.

Wat is een contract?

Het is allereerst van belang vast te stellen wat er onder contract wordt verstaan. Een contract is een bindende afspraak tussen twee of meer partijen.1 De afspraak is bindend in die zin dat zij juridisch afdwingbaar is.2 De termen contract en overeenkomst zijn overigens synoniemen, zij hebben dezelfde betekenis. Een contract hoeft niet per se op papier te staan: het kan vormvrij tot stand komen.3 Een mondelinge afspraak of een afspraak via e-mail is net zo bindend als een schriftelijke afspraak. Het is uiteraard wel aan te bevelen om ervoor te zorgen dat eenmaal gemaakte afspraken kunnen worden bewezen, eventueel in een juridische procedure.4 Het is dus raadzaam om afspraken op papier of het equivalent daarvan te zetten. Zo kunnen afspraken duidelijk worden omschreven en kunnen zij er later op worden nageslagen. Een contract zal daarom vaak schriftelijk worden vastgelegd. 2.3.

Wat is een automatiseringscontract?

Onder een automatiseringscontract wordt verstaan een contract met informatietechnologie-producten en/of -diensten als voorwerp. Hieronder vallen niet alleen contracten met betrekking tot hardware en software, maar ook overeenkomsten voor computerdienstverlening, zoals telecommunicatiediensten.5 Vaak zullen bij

1. 2. 3. 4. 5.

Art. 3:33, 3:35 en 6:213 lid 1 BW. Art. 3:296 lid 1 BW. Art. 3:37 lid 1 BW. Vgl. de bewijskracht van de akte, art. 156-160 Rv. Stuurman 1997, blz. 74.

3

Introductie in automatiseringscontracten

een automatiseringscontract twee partijen betrokken zijn: de leverancier en de afnemer. Het automatiseringscontract kenmerkt zich door het volgende: – De complexiteit van het voorwerp; • Voor het opstellen van een goed automatiseringscontract is kennis van ICT onontbeerlijk. – Onevenwichtigheid; • Er kan soms sprake zijn van een contract waarin de belangen van de ene partij beter worden behartigd dan die van de andere partij. Deze situatie doet zich voor wanneer één van beide partijen zijn contractsvoorwaarden onder het motto ‘slikken of stikken’ kan aanbieden, bijvoorbeeld wanneer de leverancier een grote internationale onderneming is. – Onvolledigheid; • Bij een automatiseringstraject doen zich vaak situaties voor, waar het contract niet in voorziet of niet kan voorzien omdat ze onvoorspelbaar zijn. – Het gemengd karakter; • Het automatiseringscontract bevat vaak verschillende juridische onderwerpen. – De invloed van buitenlands recht. • Vanwege de invloed van Amerikaanse ICT-leveranciers worden er soms contractsbepalingen gebruikt die een vrijwel letterlijke vertaling zijn van bepalingen die naar Amerikaans recht zijn opgesteld. Dit kan tot gevolg hebben dat aan deze bepalingen in een juridische procedure door de Nederlandse rechter niet de gewenste juridische betekenis wordt toegekend.6 Typerend voor het automatiseringscontract is dat er niet alleen juridische kennis, maar ook kennis van informatietechnologie vereist is om er op een verantwoorde wijze mee om te gaan. 2.4.

Wat is een goed automatiseringscontract?

Een goed automatiseringscontract bestaat niet alleen uit de juiste bewoordingen op papier, maar maakt integraal onderdeel uit van een automatiseringsproject. Het is dan ook niet aan te raden om ‘voor de vorm’ een contract op te (laten) stellen en dit vervolgens ongebruikt in een la te leggen totdat er een geschil ontstaat. Een goed contract zorgt er juist voor dat er geen onenigheid over de uitleg van de verplichtingen van partijen ontstaat. Idealiter heeft een automatiseringscontract ook de rol van een ‘spoorboekje’ bij het automatiseringsproject. Niet alles is echter van tevoren precies af te bakenen en te omschrijven, ook is niet alles te voorspellen. Een goed contract bevat dan ook procedure-afspraken voor die situaties waarin het contract niet voorziet. Dit betekent ook dat alleen het opstellen van een automatiseringscontract geen garantie biedt voor het voorkomen van juridische problemen. Een contract moet ook

6.

4

Stuurman 1997, blz. 78-79.


worden nageleefd. Indien de uitvoering van een automatiseringsproject los staat van de inhoud van het contract, dan kan dat juist een oorzaak worden voor geschillen. Kortom, het opstellen van een automatiseringscontract is meer dan een actiepunt dat kan worden afgevinkt bij het uitvoeren van een automatiseringsproject. Het contract dient het automatiseringsproject juist weer te geven en juridisch in te kaderen. De activiteiten die na het opstellen van het contract worden ondernomen, zijn vaak in hoofdlijnen weergegeven in het contract. De kwaliteit van een contract kan verder worden beoordeeld aan de hand van drie criteria: duidelijkheid, volledigheid en evenwichtigheid. Met duidelijkheid wordt bedoeld dat de rechten en plichten van beide partijen zonder veel moeite uit het contract en/of de bijlagen zijn af te leiden. Hiervoor is een goede systematiek noodzakelijk. Met volledigheid wordt bedoeld dat er geen ‘gaten’ vallen in het contract. Dat risico bestaat met name bij gemengde contracten waarin verschillende juridisch te onderscheiden onderwerpen in een en hetzelfde contract worden geregeld. Met evenwichtigheid wordt bedoeld dat de risico’s van een project in een contract op een evenwichtige wijze over de betrokken partijen zijn verdeeld. Eenzijdige contracten, waarin alle risico’s bij één partij worden gelegd, nodigen uit om niet te worden nageleefd. Indien problemen ontstaan noodt zoiets niet tot het actief zoeken naar een oplossing. Belangrijke risico’s zijn het uitlopen van het project in tijd en kosten, schade door fouten van de leverancier of door gebreken in het systeem, het wegvallen van het onderhoud, aanspraken van derden als gevolg van schending van intellectuele eigendomsrechten, enzovoort.7 2.5.

Soorten automatiseringscontracten

Automatiseringscontracten zijn er in vele soorten en maten. Hieronder worden enkele voorbeelden gegeven. Vier categorieën van automatiseringscontracten worden hierna in hoofdstuk 4 nader uitgewerkt. Ruwweg zijn er de volgende categorieën van automatiseringscontracten: – De overeenkomst inzake de aanschaf van hardware; – De overeenkomst inzake de aanschaf van software; – De ontwikkelingsovereenkomst; – De onderhouds- en beheerovereenkomst; – De overeenkomst betreffende het transport van gegevens; – De overeenkomst inzake automatiseringsadvies; – De overeenkomst inzake detachering van personeel; – Computeruitwijk en broncode-depot (escrow); – Distributiecontracten; – De outsourcing- en/of offshoring-overeenkomst.

7.

Zie ook Duthler 1995.

5


2.6.

Wat zijn algemene voorwaarden?

Bij een automatiseringstraject worden de afspraken met betrekking tot dat traject neergelegd in één specifieke overeenkomst. Het komt daarnaast echter ook vaak voor dat de leverancier en de afnemer zogenaamde algemene voorwaarden hanteren. Dat zijn contractuele voorwaarden die zijn opgesteld met het voornemen om ze bij meerdere verschillende automatiseringstrajecten te gebruiken.8 Algemene voorwaarden worden vaak door een partij van toepassing verklaard door op briefpapier of op een offerte of offerte-aanvraag een zinsnede als ‘op onze overeenkomsten zijn onze algemene voorwaarden van toepassing’ op te nemen. Deze manier van verwijzen is overigens niet altijd zonder meer juridisch geldig. In hoofdstuk 5 wordt nader ingegaan op het gebruik van algemene voorwaarden. Wanneer er algemene voorwaarden worden gebruikt, dan is er meestal sprake van (tenminste) twee documenten: een document waarin het automatiseringscontract is vastgelegd, en een document waarin de algemene voorwaarden van één van beide partijen zijn opgenomen. 2.7.

Modelvoorwaarden: FENIT & BiZa

In de praktijk wordt veel gebruikgemaakt van modelcontracten. Modelcontracten bevatten voorbeelden van bepalingen die kunnen worden gebruikt in een automatiseringscontract of in algemene voorwaarden. Twee bekende soorten modelcontracten zijn de FENIT-voorwaarden en de BiZa-contracten. De FENIT-voorwaarden bevatten bepalingen die gunstiger zijn voor de leverancier, de BiZa-contracten bevatten bepalingen die gunstiger zijn voor de afnemer. In het vervolg van deze uitgave zullen af en toe FENIT- of BiZa-voorwaarden ter illustratie worden aangehaald. 2.8.

De algemene voorwaarden van de overheid: ARVODI

De rijksoverheid hanteert bij het aangaan van overeenkomsten vaak de zogenaamde ARVODI-voorwaarden. Dit zijn algemene voorwaarden die de overheid kan gebruiken bij het verstrekken van opdrachten tot het verrichten van diensten. ARVODI staat dan ook voor Algemene Rijksvoorwaarden voor het verstrekken van opdrachten tot het verrichten van Diensten. Bij de ARVODI-voorwaarden hoort een model dienstverleningsovereekomst. In principe dienen de ARVODI-voorwaarden te worden gebruikt in combinatie met een op een specifieke opdracht toegespitste dienstverleningsovereenkomst. De ARVODI-voorwaarden zijn bedoeld voor organisatieadviesdiensten en andere dienstverleningsovereenkomsten. Ingeval van automatiseringscontracten waarbij geen sprake is van dienstverlening (bijvoorbeeld enkel de aanschaf van hardware), zal de overheid daarom eerder gebruikmaken van de BiZacontracten.9

8. 9.

6

Vgl. art. 6:231 sub a BW. Interdepartementale Werkgroep Contracten, nieuwsbrief nr. 1, mei 2005.

HOOFDSTUK 3

Het sluiten van automatiseringscontracten 3.1.

Inleiding

Een contract, en dus ook een automatiseringscontract, komt tot stand door een aanbod van de ene partij dat wordt aanvaard door de andere partij.1 In de praktijk zal er uiteraard eerst meer of minder uitgebreid worden onderhandeld voordat er een overeenkomst tot stand komt. De periode voorafgaand aan de totstandkoming is de zogenaamde precontractuele fase. Deze precontractuele fase kan soms ook juridische consequenties hebben. 3.2.

Belang van de onderhandelingsfase

Het komt regelmatig voor dat in de onderhandelingsfase te laat aan juridische onderwerpen wordt gedacht. Het gaat dan met name om de vraag welke partij de intellectuele eigendomsrechten op computerprogrammatuur zal verkrijgen, om aansprakelijkheidskwesties en om eventuele garanties. Bij complexe automatiseringsprojecten kunnen partijen afspreken om te onderzoeken wat de opdrachtgever precies wenst te realiseren en wat haalbaar is voor de opdrachtnemer.2 3.3.

Het afbreken van onderhandelingen in de precontractuele fase

Onderhandelingen hoeven niet altijd tot een overeenkomst te leiden, zij kunnen worden afgebroken. Door het afbreken van onderhandelingen kan één van de partijen, of wellicht beiden, schade lijden. Die partij loopt het gewin dat de partij uit de overeenkomst zou hebben verkregen, immers mis: er is sprake van gederfde winst. Daarnaast kan er sprake zijn van gederfde winst omdat in de onderhandelingsperiode andere commerciële kansen niet zijn benut: de tijd die wordt besteed aan onderhandelingen kan niet aan iets anders worden besteed. Ook kunnen in de onderhandelingsfase kosten zijn gemaakt (offertekosten e.d.), die nu niet kunnen worden terugverdiend. In de precontractuele fase geldt als uitgangspunt dat elk van de betrokken partijen de onderhandelingen kan afbreken, tenzij dit onaanvaardbaar is. Het afbreken van de onderhandelingen door de ene partij is onaanvaardbaar wanneer de andere par-

1. 2.

Art. 6:217 lid 1 BW. Stuurman 1997, blz. 79-81.

7

Het afsluiten van automatiseringscontracten

tij er terecht op mocht vertrouwen dat er wél een overeenkomst tot stand zou komen, of er zich andere omstandigheden voordoen waardoor er sprake is van onaanvaardbaar afbreken. De rechter is overigens terughoudend in het aannemen van aansprakelijkheid in de precontractuele fase.3 3.4.

Letter of intent

Partijen kunnen op voorhand afspraken maken over de wijze waarop onderhandeld zal worden door middel van een letter of intent. Een letter of intent bevat de regels voor de onderhandelingsfase. Belangrijke onderwerpen die in zo’n document kunnen worden opgenomen zijn de verplichting tot geheimhouding, de gevolgen van het afbreken van de onderhandelingen (en de uitsluiting van de aansprakelijkheid daarvoor), de wijze waarop definitieve gebondenheid aan een uiteindelijk contract ontstaat en een onderhandelingstermijn. De partijen kunnen ervoor kiezen om zich niet juridisch te binden aan een letter of intent. Zij kunnen bijvoorbeeld de volgende clausule opnemen: ‘De ondergetekenden verklaren uitdrukkelijk dat deze overeenkomst is aangegaan als een nietbindende afspraak en dat bij overtreding en/of niet-naleving ervan geen gerechtelijke stappen jegens elkaar zullen worden ondernomen om de naleving af te dwingen.’4 3.5.

Aanbestedingstrajecten

Wanneer de overheid voornemens is ICT-producten en/of diensten af te nemen, dan kan het voorkomen dat de overheid verplicht is een Europees aanbestedingstraject te volgen. Een overheidsorgaan, er wordt dan gesproken van een aanbestedende dienst, is hiertoe verplicht wanneer de waarde van een opdracht boven een bepaald bedrag uitkomt (het zogenaamde drempelbedrag). Op het moment van schrijven gelden de volgende drempelbedragen:5

Werken Diensten Leveringen

3.

4. 5.

8

Centrale overheid

Decentrale overheid

€ 5 278 000 € 137 000 € 137 000

€ 5 278 000 € 211 000 € 211 000

HR 12 augustus 2005, NJ 2005, 467 (CBB/JPO), r.o. 3.6 en 3.7. Hiermee zijn waarschijnlijk de drie fasen, zoals bekend uit HR 18 juni 1982, NJ 1983, 723 (Plas-Valburg), teruggebracht tot twee fasen. Een minder onereuze benadering is overigens dat één van beide partijen, om precontractuele aansprakelijkheid te ontkomen, voorzichtig de onderhandelingen ‘stukmaakt’ door subtiel de standpunten van beide partijen verder van elkaar verwijderd te laten geraken. Duthler 1995, blz. 23-24; Stuurman 1997, blz. 79-80. Art. 7 Besluit aanbestedingsregels voor overheidsopdrachten juncto art. 7 Richtlijn 2004/18/EG zoals gewijzigd door Verordening (EG) 2083/2005.

Het afsluiten van automatiseringscontracten

De aanbestedingsregels maken het moeilijker om tijdens onderhandelingen de vraag van de afnemer en het aanbod van de leverancier precies op elkaar af te stemmen. De afnemer zal in een aanbestedingstraject van tevoren moeten omschrijven wat hij precies wil. Hij zal vervolgens op transparante en niet-discriminatoire wijze moeten bepalen welke leveranciers in aanmerking komen voor de opdracht (door middel van selectiecriteria) en aan welke leverancier hij uiteindelijk de opdracht toekent (door middel van gunningscriteria). De afnemer kan verschillende aanbestedingsprocedures gebruiken. Het aanbestedingsrecht kent onder meer de volgende procedures. – De openbare procedure; • Bij deze procedure kunnen alle belangstellende leveranciers na publicatie van de aankondiging een offerte indienen. – De niet-openbare procedure; • In dit geval kunnen na de aankondiging belangstellende leveranciers zich melden. De afnemer maakt vervolgens een selectie van degenen die een offerte mogen indienen. – De procedure van gunning door onderhandelingen, met of zonder aankondiging van de overheidsopdracht; • Deze procedure mag slechts in specifieke gevallen worden gevolgd. – De concurrentie-gerichte dialoog. • Deze procedure houdt in dat ingeval van bijzonder complexe overheidsopdrachten de afnemer een dialoog aangaat over alle aspecten van de betreffende opdracht. Ook deze procedure mag slechts in specifieke gevallen worden gevolgd. In ieder geval maken de openbare en de niet-openbare procedure automatiseringscontracten onderdeel uit van de aanbestedingsdocumenten. Vaak zijn ze onderdeel van de Request for Proposal en kan de inschrijver ze of aanvaarden of niet-aanvaarden. Het al of niet-aanvaarden van het contract vormt meestal één van de gunningscriteria. Door het contract niet te aanvaarden verkleint de inschrijver zijn kansen op gunning.

9

HOOFDSTUK 4

Soorten automatiseringscontracten 4.1.

Inleiding

In dit hoofdstuk worden verschillende soorten overeenkomsten behandeld. In de praktijk kan een automatiseringscontract echter elementen van verschillende soorten overeenkomsten bevatten. Een uitgebreid automatiseringscontract kan bijvoorbeeld zien op de aanschaf van hardware, van software en op het onderhoud van de aangeschafte producten. Automatiseringscontracten zullen vaak zo’n gemengd karakter hebben. In de volgende paragrafen zullen de verschillende automatiseringscontracten worden benoemd. Per contract zal een aantal aandachtspunten op een rij worden gezet. Eerst worden echter enkele algemene opmerkingen gemaakt over de inhoud van een automatiseringscontract. 4.2.

De inhoud van een automatiseringscontract

Een automatiseringscontract bestaat vaak, afhankelijk van het soort contract, uit tenminste de volgende onderdelen: – Overwegingen; • In de overwegingen wordt aangegeven wat de beweegredenen zijn van leverancier en afnemer. Zorgvuldig geformuleerde overwegingen kunnen van groot belang zijn bij het uitleggen van de betekenis van de bepalingen van een contract, mocht daar in een later stadium onenigheid over ontstaan. – Definities; • Uiteraard is het van belang de in het contract gebruikte termen zo zorgvuldig mogelijk te definiëren. – Object; • Het object van de overeenkomst behelst de vraag wat er wordt gekocht, (in)gehuurd, geleasd, overgedragen, ontwikkeld, enz. Het object is het onderwerp van de overeenkomst. – Verschuldigde bedragen en betaling; • In dit onderdeel wordt aangegeven welk bedrag de afnemer aan de leverancier verschuldigd wordt en op welke wijze dient te worden betaald. – Garanties; • Het is raadzaam de omvang van de garanties en de duur ervan zorgvuldig vast te leggen. Om latere discussies voor zover mogelijk te voorkomen, verdient het aanbeveling uit te schrijven welke gebreken onder de garantie vallen. – Aansprakelijkheid. • De leverancier zal zijn aansprakelijkheid voor eventuele schade zoveel moge-

11


lijk willen uitsluiten. Aan dit onderwerp is een apart hoofdstuk gewijd: hoofdstuk 6.1 De onderdelen zullen in de hierna volgende paragrafen per soort automatiseringscontract nader worden ingevuld. 4.2.1.

Resultaatsverbintenis of inspanningsverbintenis?

Bij de invulling van een automatiseringscontract ontstaat regelmatig de discussie of partijen een resultaatsverbintenis of een inspanningsverbintenis op zich nemen. Een leverancier zal geregeld alleen de verplichting op zich willen nemen een bepaalde inspanning te leveren, zonder dat er een concreet resultaat wordt toegezegd. De afnemer zal in een contract juist graag de leverancier willen verplichten een bepaald resultaat af te leveren. Een voorbeeld van een overeenkomst waarbij eerder sprake zal zijn van een inspanningsverbintenis, is de overeenkomst inzake onderhoud of inzake het uitbrengen van automatiseringsadvies. Ingeval van bijvoorbeeld het leveren van hardware of software kan eerder sprake zijn van een resultaatsverbintenis.2 Een resultaatsverplichting kan ook betrekking hebben op een termijn waarbinnen een bepaald product dient te worden opgeleverd. De – leveranciergezinde – FENITvoorwaarden bepalen hierover overigens dat een leverancier ‘zich naar behoren zal inspannen’ om een termijn in acht te nemen, dit is duidelijk een inspanningsverbintenis: Alle door leverancier genoemde of overeengekomen (leverings)termijnen zijn naar beste weten opgesteld op grond van de gegevens die bij het aangaan van de overeenkomst aan de leverancier bekend waren. Leverancier spant zich er naar behoren voor in overeengekomen (leverings)termijnen zoveel mogelijk in acht te nemen. De enkele overschrijding van een genoemde of overeengekomen (leverings)termijn brengt leverancier niet in verzuim. (…)3 Overigens is slechts het opnemen van een formulering in de trant van ‘opdrachtnemer verplicht zich enkel tot het uitvoeren van inspanningsverbintenissen’ onvoldoende. De verplichting zal dan inhoudelijk ook daadwerkelijk als inspanningsverbintenis moeten kunnen worden aangemerkt. 4.3.

Aanschaf van hardware

4.3.1.

Omschrijving

Voor de aanschaf van hardware (computer-, rand- en/of communicatieapparatuur) zijn verschillende juridische constructies mogelijk. Meestal is sprake van één van de volgende overeenkomsten:

1. 2. 3.

12

Vgl. de diverse contracten in ICT Modelcontracten, Deventer: Kluwer en Blok e.a. 2004. Blok e.a. 2004, blz. 42-44. Art. 8 lid 1 FENIT-voorwaarden.


– een koopovereenkomst; – een huurovereenkomst; – een leaseovereenkomst.4 Ingeval van een koopovereenkomst betaalt de afnemer een bedrag aan de leverancier en verkrijgt daarvoor de eigendom van de hardware.5 Bij een huurovereenkomst blijft de leverancier eigenaar van de hardware, maar mag de afnemer hardware gebruiken in ruil voor een tegenprestatie6 (een geldsom). De leaseovereenkomst is ontstaan als vorm van (geld)lening, gekoppeld aan het gebruik van een bepaalde zaak: de leverancier (‘lessor’) koopt hardware in en stelt dat tegen een bepaald bedrag ter beschikking aan de afnemer (‘lessee’). Met deze constructie hoeft de afnemer niet in één keer de volledige koopprijs voor zijn rekening te nemen. Er wordt verder een onderscheid gemaakt tussen: – financiële lease; en – operationele lease. Bij de financiële lease blijft de leverancier formeel eigenaar van de te leveren hardware, maar draagt de afnemer de verdere zorg ervoor. Soms wordt dit ook wel het scheiden van de juridische en de economische eigendom genoemd. De afnemer zal zelf zorg moeten dragen voor bijvoorbeeld onderhoud en verzekering van de hardware. Bij operationele lease staat de leverancier wél (voor een deel) in voor de zorg voor de hardware. De leverancier draagt dan bijvoorbeeld de zorg voor het onderhoud. 4.3.2.

Aandachtspunten

Eén van de aandachtspunten bij de aanschaf van hardware is de keuze voor de juridische constructie: wordt er gebruik gemaakt van koop, huur of lease? Vaak wordt hardware niet ‘los’ aangeschaft, maar wordt een volledig computersysteem aangeschaft, dus hardware inclusief software en eventueel ook aanvullende dienstverlening inzake opleidingen en onderhoud. Er wordt dan wel gesproken van een systeemovereenkomst, een systeemintegratieovereenkomst of een turn key-overeenkomst, afhankelijk van de precieze voorwaarden van het contract. Deze overeenkomsten hebben een gemengd karakter. Zij kunnen naast voorwaarden inzake de aanschaf van hardware ook bestaan uit voorwaarden inzake de aanschaf van software en inzake onderhoud en beheer.7 Voor die onderdelen kan te rade worden gegaan bij de volgende paragrafen waarin die contracten worden behandeld. Bij het vaststellen van de inhoud van het contract gelden de volgende aandachtspunten: – Overwegingen; • Het kan van belang zijn op te nemen waarom de keuze op bepaalde apparatuur is gevallen en wat de gronden zijn voor die keuze. Een keuze voor een

4. 5. 6. 7.

Blok e.a. 2004, blz. 65-69. Art. 7:1 BW. Art. 7:201 BW. Blok e.a. 2004, blz. 65; Stuurman 1997, blz. 75-76.

13


–

–

–

–

–

–

8.

14

bepaald systeem kan bijvoorbeeld de uitdrukkelijke wens zijn van de afnemer, of juist zijn gebaseerd op een advies van de leverancier. Definities; • Termen als ‘Hardware’, ‘Apparatuur’ of ‘Installatie’ dienen nauwkeurig te worden gedefinieerd. Er kan in een definitie ook worden verwezen naar een bijlage bij het contract, bijvoorbeeld met de zinsnede ‘In Bijlage 1 wordt een specificatie gegeven van de Apparatuur, het aantal ervan, het type en het model’. Belangrijke termen zijn voorts ‘Aflevering’, ‘Acceptatie’ en ‘Gebrek’. Object; • Het object kan worden omschreven bij de definities en in bijlagen bij het contract. Indien mogelijk dienen de specificaties zo nauwkeurig mogelijk te worden gegeven, bijvoorbeeld de samenstelling van onderdelen, eigenschappen als snelheid, capaciteit, betrouwbaarheid en prestaties, bijvoorbeeld de mate van beschikbaarheid. Systeemprogrammatuur; • Met de levering van hardware wordt vaak ook systeemsoftware meegeleverd. De afnemer zal hiervoor over een gebruiksrecht moeten beschikken. In feite ziet dit onderdeel van het contract op de aanschaf van software, zie hiervoor de volgende paragraaf. Huur, koop of lease? • In het contract dient de keuze voor huur, koop of lease te worden aangegeven. Er kan expliciet worden genoemd voor welke constructie is gekozen. Bovendien dient te worden geregeld bij welke partij de eigendom van de over te dragen hardware rust. Ingeval van koop verkrijgt de afnemer de eigendom. Ingeval van huur of lease rust de eigendom bij de leverancier. Het kan ook zo worden afgesproken dat de eigendom in eerste instantie bij de leverancier rust en dat de afnemer pas na verloop van tijd eigenaar wordt. Er kan dan sprake zijn van een zogenaamde huurkoop-overeenkomst:8 bij huurkoop gaat de eigendom pas over zodra een gehele koopsom is betaald. Het komt geregeld voor dat partijen afspreken de apparatuur te markeren als eigendom van de leverancier indien de eigendom bij de leverancier rust. Aflevering en installatie; • De plaats en de wijze van aflevering kunnen worden omschreven. Er kunnen afspraken worden gemaakt over het tijdschema aan de hand waarvan aflevering en installatie geschiedt. Ook kan worden bepaald of de hardware en de systeemsoftware al dan niet in gedeelten worden afgeleverd en/of geïnstalleerd. Acceptatie; • Eén van de belangrijkste onderdelen van de overeenkomst inzake de aanschaf van hardware betreft de acceptatie. Van belang is af te spreken: – Of er een acceptatietest zal plaatsvinden, en zo ja, wat de acceptatietest behelst. Er kan worden onderscheiden in de twee fasen: de bedrijfstest en vervolgens de acceptatietest. Bij de bedrijfstest stelt de leverancier vast dat het door hem geleverde product voldoet aan de afgesproken specificaties.

Art. 7A:1576h-1576x BW.


Bij de acceptatietest stelt de afnemer, eventueel gezamenlijk met de leverancier en/of een externe deskundige, vast of het geleverde voldoet aan de afgesproken specificaties. Het afhankelijk maken van een deel van de betaling van het slagen van de acceptatietest, kan een extra stimulans zijn voor de leverancier.9 – Wanneer de acceptatie plaatsvindt. Vindt dit plaats bij aflevering, bij installatie, of later? – Door wie de acceptatie wordt vastgesteld: door de leverancier, de afnemer of door een externe deskundige? – Garanties; • Over de precieze omvang van eventuele garanties kan uitgebreid worden onderhandeld. Vaak wordt als minimum tenminste de garantie gegeven fabricagefouten te herstellen. Naar keuze van partijen kunnen ruimere garanties worden afgesproken. Het verdient aanbeveling garanties zo concreet mogelijk te formuleren. – Aansprakelijkheid. • Zoals bij alle automatiseringscontracten kan de regeling omtrent aansprakelijkheid één van de belangrijkste onderwerpen worden tijdens onderhandelingen. In de onderhandelingen kan een balans worden gezocht tussen aansprakelijkheid, garanties, de koopprijs en de eventuele verzekerbaarheid van bepaalde risico’s. Zie voor een verdere behandeling van aansprakelijkheidsclausules hoofdstuk 6.10 4.4.

Aanschaf van software (standaardprogrammatuur)

4.4.1.

Omschrijving

Wat koop je als je software koopt? Voor een goed begrip van het automatiseringscontract inzake de aanschaf van software, is het van belang voor ogen te houden dat software wordt geregeld door de Auteurswet: software is auteursrechtelijk beschermd. Het auteursrecht op een bepaald programma komt toe aan de maker van die software. Dat betekent dat een afnemer van software niet alleen over een exemplaar van de betreffende software dient te beschikken, maar dat hij ook over een geldig gebruiksrecht dient te beschikken om gebruik te mogen maken van de software. Uit het voorafgaande volgt dat bij de aanschaf van software er meestal sprake is van een licentie- of gebruiksrecht-overeenkomst: de afnemer schaft het recht aan om de software te mogen gebruiken.11 Het antwoord op de vraag is dus: je ‘koopt’ een gebruiksrecht, je ‘koopt’ meestal niet het eigendomsrecht.12 In een automatise-

9. 10. 11. 12.

Blok e.a. 2004, blz. 32-33. Blok e.a. 2004, blz. 65-69; ICT Modelcontracten, C.1.1. Art. 46i en 45j Auteurswet 1912. Zie voor de juridische achtergronden en verdere verwijzingen E.D.C. Neppelenbroek, ‘Software: De auteur, de verkrijger en derde’, AMI 2006/4, blz. 109-118. De term ‘eigendomsrecht’ wordt in dit verband overigens juridisch niet juist gebruikt. Juridisch wordt er gedoeld op het auteursrecht op de software. In de praktijk wordt echter vaak gesproken van de ‘eigendom’ van software.

15


ringscontract inzake de aanschaf van software wordt onder meer de omvang van het gebruiksrecht afgesproken. Het gaat er dan bijvoorbeeld om hoeveel mensen gebruik mogen maken van de software, op hoeveel computers mag de software worden geïnstalleerd, enzovoort. In hoofdstuk 2 van dit boekje is genoemd dat automatiseringscontracten vaak eenzijdig zijn. De belangen van één partij worden in het contract dan beter behartigd dan die van de andere partij. Dat is vaak bij de aanschaf van software het geval. Softwareproducenten bieden hun software inclusief gebruiksvoorwaarden op een take it or leave it-basis aan. In het vervolg van deze paragraaf (4.4) wordt slechts aandacht besteed aan de aanschaf van standaardprogrammatuur: het ontwikkelen van maatwerkprogrammatuur komt hierna aan de orde bij de behandeling van de ontwikkelingsovereenkomst in paragraaf 4.4.3. Wat ook niet aan de orde komt, is de verkoop van ‘consumentensoftware’. 4.4.2.

Aandachtspunten13

De kern van een automatiseringscontract inzake de aanschaf van software bestaat uit het verstrekken van een gebruiksrecht door de leverancier aan de afnemer. Over de omvang van het gebruiksrecht kunnen gedetailleerde afspraken worden gemaakt. Bij het maken van deze afspraken dient rekening te worden gehouden met de volgende ‘minimum-rechten’ van de afnemer. Deze rechten kunnen niet worden ‘weggecontracteerd’: – De afnemer heeft het recht voor het beoogde gebruik van het programma het programma te laden, in beeld te brengen (uit te voeren) en het recht fouten in de programmatuur te verbeteren. Deze handelingen kunnen niet bij overeenkomst worden verboden;14 – De afnemer heeft het recht een reservekopie te maken, indien dat voor het beoogde gebruik noodzakelijk is;15 – De afnemer heeft het recht de software te bestuderen en te testen;16 – De afnemer heeft onder voorwaarden het recht de software te decompileren ten behoeve van reverse engineering, indien dat voor het beoogde gebruik noodzakelijk is.17 Uit deze minimumrechten blijkt dat een belangrijke rol is weggelegd voor de term beoogd gebruik: de afnemer kan zich beroepen op de bovenstaande minimumrechten, maar meestal slechts indien dat voor het beoogd gebruik van de software noodzakelijk is.

13. 14. 15. 16. 17.

16

Blok e.a. 2004, blz. 71-78; ICT Modelcontracten, D.1.2. Art. 46j Auteurswet 1912. Art. 46k Auteurswet 1912. Art. 46l Auteurswet 1912; Zie echter Van Lingen 2002, blz. 62. Art. 46m Auteurswet 1912.


Het is voorts van belang er rekening mee te houden dat er drie partijen betrokken kunnen zijn bij de aanschaf van software: – de producent van de software, die ook auteursrechthebbende is; – de afnemer; en – de wederverkoper. Deze levert de software aan de afnemer, maar is geen auteursrechthebbende. De invulling van het contract is onder meer afhankelijk van de partijen die in een voorkomend geval betrokken zijn bij de aanschaf van software. Men doet er dus goed aan duidelijk voor ogen te houden met welke partij een overeenkomst wordt aangegaan. Net zoals bij de aanschaf van hardware, kan ook hier worden gekozen uit drie juridische constructies: koop, huur of lease. Bij het vaststellen van de inhoud van het contract gelden de volgende aandachtspunten: – Overwegingen; • In de overwegingen kunnen de beweegredenen van de partijen worden aangegeven. Hiermee kunnen de overwegingen van groot belang zijn om zo het begrip beoogd gebruik in te vullen. – Definities; • In de contractsbepaling betreffende de definities kunnen de volgende termen worden opgenomen: – ‘Programmatuur’ dient nauwkeurig te worden omschreven. De naam van de programmatuur, het versienummer en eventuele specificaties kunnen worden genoemd. In de definitie kan ook worden verwezen naar een bijlage bij het contract, ‘de Programmatuur: de programmatuur zoals omschreven in Bijlage 1’. De bijlage bevat dan een beschrijving van de bedoelde software; – ‘Apparatuur’. Indien het gebruik van de software wordt beperkt tot bepaalde apparatuur, is het handig deze apparatuur te definiëren; – ‘Documentatie’; vaak wordt er documentatie meegeleverd; Verder zijn van belang de termen ‘Implementatie’, ‘Conversie’, ‘Acceptatie’, ‘Acceptatietest’, en ‘Gebrek’. – Object; • De omschrijving van het object van het automatiseringscontract is onder meer afhankelijk van de partijen die erbij betrokken zijn. Hierboven is al aangegeven dat er drie partijen betrokken kunnen zijn bij de aanschaf van software: de afnemer, de producent en de wederverkoper. De formulering van het object van het contract is afhankelijk van de vraag welke partijen in het voorliggende geval betrokken zijn. Er kunnen twee situaties worden onderscheiden: – De afnemer verkrijgt de software van de producent. In deze situatie dient in het contract te worden opgenomen dat de producent aan de afnemer een gebruiksrecht verschaft. De omvang van het gebruiksrecht dient dan te worden omschreven. Aan de orde kan komen: • Hoeveel personen mogen tegelijkertijd gebruikmaken van de software?

17


• Mag de afnemer ook andere dingen doen dan de software gebruiken? Mag hij bijvoorbeeld de software wijzigen? • Op welke systemen mag de afnemer de software gebruiken? Vaak wordt een beperking opgenomen met betrekking tot het aantal systemen waarop de afnemer de software mag gebruiken. In een bepaling wordt dan bijvoorbeeld het gebruik beperkt tot één CPU (Central Processing Unit), de single CPU-licence, of wordt een aantal CPU’s gespecificeerd;18 • Mag de afnemer het gebruiksrecht overdragen aan een ander? • Verkrijgt de afnemer een exclusief gebruiksrecht of een niet-exclusief gebruiksrecht? • Wordt het gebruiksrecht verleent voor een bepaalde duur? – De afnemer verkrijgt de software van een wederverkoper. De wederverkoper is echter niet de auteursrechthebbende van de software en kan dus niet zonder meer de afnemer een gebruiksrecht verschaffen. De afnemer kan op twee manieren een gebruiksrecht verkrijgen: • De wederverkoper beschikt over een volmacht waardoor hij bevoegd is namens de producent een gebruiksrecht te verschaffen aan de afnemer. In dit geval kan de afnemer met de wederverkoper de reikwijdte van het gebruiksrecht afspreken; • Het betreft de aanschaf van off the shelf-software waarbij middels de verpakking of de installatieprocedure de gebruiksvoorwaarden aan de afnemer worden getoond en waarmee hij akkoord dient te gaan voordat hij gebruik kan maken van de software (een shrink-wrap- respectievelijk click-wrap-licentie). De gebruiksvoorwaarden bevatten dan een beschrijving van het gebruiksrecht dat aan de afnemer wordt toegekend. – ‘Koop’, lease of huur? • Net zoals bij de aanschaf van hardware, zijn er verschillende juridische constructies mogelijk voor de aanschaf van software. Ook hier kan worden gekozen voor ‘koop’,19 lease of huur. – Levering; • Het contract dient te bepalen op welke wijze de software wordt geleverd. Het is van belang of de afnemer de programmatuur als broncode of als objectcode wil afnemen.

18.

19.

18

Een discussiepunt dat hier kan ontstaan is de vraag hoe een systeem met een multicore processor of met meerdere processoren dient te worden geteld. Softwareproducenten hebben hier verschillende visies op. Ter illustratie kan worden gewezen op het licentiebeleid van Microsoft en Oracle. Microsoft heeft als beleid dat één processor geldt als één processor, ongeacht of de processor één of meer cores heeft, zie [http://www.microsoft.com/licensing/highlights/multicore.mspx]. Oracle hanteert onder meer een wegingsfactor van .75 per core, zie [http://www.oracle.com/corporate/pricing/sig.pdf]. De juridische kwalificatie van de aanschaf van software is tot op zekere hoogte een grijs gebied. De term koop wordt daarom in dit verband tussen aanhalingstekens geplaatst. Het juridische begrip koop heeft namelijk een specifieke betekenis waarvan het de vraag is of het van toepassing is op de aanschaf van software, zie onder meer E.D.C. Neppelenbroek, ‘Software: De auteur, de verkrijger en derden’, AMI 2006/4, blz. 109-118.


– Garanties; • Als garantie kan worden opgenomen dat de software binnen een bepaalde periode volgens bepaalde specificaties functioneert. Mocht de afnemer na afloop van de garantieperiode aanspraak willen maken op ondersteuning, dan dient daarvoor een onderhoudsovereenkomst te worden gesloten. Het is ook mogelijk in het contract inzake de aanschaf van software een regeling op te nemen over door de leverancier te verrichten onderhoud. – Aansprakelijkheid. • Zoals bij alle automatiseringscontracten kan de regeling omtrent de aansprakelijkheid een belangrijk discussiepunt worden. In hoofdstuk 6 wordt de beperking van aansprakelijkheid in het algemeen behandeld. 4.4.3.

De (software)ontwikkelingsovereenkomst20

Hierboven is uitgegaan van de aanschaf van standaard programmatuur. Het komt uiteraard echter ook voor dat een afnemer op maat gemaakte software laat ontwikkelen. Er wordt dan gesproken van een (software)ontwikkelingsovereenkomst.21 Juridisch is de ontwikkelingsovereenkomst vaak te kwalificeren als een zogenaamde overeenkomst van opdracht. De wet verstaat hieronder de overeenkomst waarbij de opdrachtnemer voor de opdrachtgever werkzaamheden verricht.22 Wanneer de ontwikkelingsovereenkomst als overeenkomst van opdracht is te kwalificeren, dan moeten de afnemer en de leverancier ermee rekening houden dat er dan bepaalde wettelijke verplichtingen gelden. De wet legt bijvoorbeeld de leverancier de plicht op als een ‘goed opdrachtnemer’ te handelen.23 De precieze betekenis daarvan is niet meteen op voorhand duidelijk. Verder is de opdrachtnemer verplicht om gevolg te geven aan ‘tijdig verleende en verantwoorde aanwijzingen omtrent de uitvoering van de opdracht’.24 Ook moet de opdrachtnemer de opdrachtgever op de hoogte houden van zijn werkzaamheden ‘en hem onverwijld in kennis stellen van de voltooiing van de opdracht, indien de opdrachtgever daarvan onkundig is’.25 Zo zijn er meer wettelijke verplichtingen bij de overeenkomst van opdracht. De wettelijke verplichtingen kunnen echter voor een groot deel niet van toepassing worden verklaard in de overeenkomst. De overeenkomst dient dan uiteraard een daartoe strekkende bepaling te bevatten. In de praktijk wordt echter nog al eens over het hoofd gezien dat de wettelijke verplichtingen gelden, waardoor wordt nagelaten zo’n bepaling op te nemen.

20. 21. 22.

23. 24. 25.

Blok e.a. 2004, blz. 83-89; ICT Modelcontracten, E.1.1, E.1.3k. Overigens kan een ontwikkelingsovereenkomst ook zien op de ontwikkeling van bijvoorbeeld een communicatie-infrastructuur. Het moet gaan om werkzaamheden die uit iets anders bestaan dan het tot stand brengen van een werk van stoffelijke aard, het bewaren van zaken, het uitgeven van werken of het vervoeren of doen vervoeren van personen of zaken, art. 7:400 lid 1 BW. Art. 7:401 BW. Art. 7:402 lid 1 BW. Art. 7:403 lid 1 BW.

19


Verder is het van belang te realiseren dat voor het succesvol laten ontwikkelen van software een heldere communicatie tussen afnemer en leverancier een noodzakelijk vereiste is. Beide partijen moeten duidelijk aangeven wat de verwachtingen zijn die zij over en weer van elkaar hebben. De afnemer zal duidelijk moeten aangeven wat hij precies wil hebben. Voor zover hij daartoe niet in staat is, zal hij de leverancier inzicht dienen te geven in zijn eisen, wensen en doelstellingen. Eventueel dient hij de leverancier aanvullende informatie te verstrekken, zoals inzicht in zijn organisatie. De leverancier zal op zijn beurt duidelijk moeten aangeven wat wel of niet haalbaar is of technisch (on)mogelijk is. Het is dan ook ten sterkste aan te bevelen eerst een gedetailleerd programma van eisen, een definitiestudie en/of een plan van aanpak op te stellen. Bij het opstellen van een ontwikkelingsovereenkomst gelden onder meer de volgende aandachtspunten. – Specificaties; • Welke functionaliteit dient de programmatuur te bezitten? Welke garanties worden afgesproken? – Informatieplicht afnemer versus onderzoeksplicht leverancier; • Van belang is ook of de leverancier wordt verplicht de benodigde informatie te vergaren in verband met de te vervaardigen software (de onderzoeksplicht), of dat de afnemer wordt verplicht aan de leverancier tijdig de juiste informatie te verschaffen (de informatieplicht). Er kan ook een middenweg worden gekozen. De FENIT-voorwaarden zijn op dit punt duidelijk in het voordeel van de leverancier geformuleerd: volgens deze voorwaarden verricht de leverancier zijn werkzaamheden op basis van de door de afnemer te verstrekken gegevens.26 Indien de leverancier onvolkomenheden constateert in de gegevens, kan hij de afgesproken werkzaamheden opschorten totdat de afnemer de onvolkomenheden heeft verholpen.27 Volgens de BiZa-overeenkomst ‘Ontwikkelingsovereenkomst Maatwerkprogrammatuur’ rust daarentegen op de leverancier de plicht zich in voldoende mate op de hoogte te stellen van de doelstellingen van de afnemer met betrekking tot het betreffende automatiseringsproject, de organisatie van de afnemer, de processen waarbij de software zal worden gebruikt en de gegevensstromen die ermee zullen worden verwerkt.28 – Prijs; • Wordt er een vaste prijs afgesproken of wordt een uur- of dag(deel)- tarief berekend? Wordt meerwerk in rekening gebracht? – Termijnen; • Hoe definitief zijn de deadlines die worden vastgesteld? Worden er fatale termijnen afgesproken of slechts streefdata? – Acceptatie; • Met name bij maatwerksoftware is het van belang voor een zorgvuldig accep-

26. 27. 28.

20

Art. 21 lid 1 FENIT-voorwaarden. Art. 21 lid 2 FENIT-voorwaarden. Art. 2 lid 4 BiZa Ontwikkelingsovereenkomst Maatwerkprogrammatuur.


tatietest te zorgen om vast te stellen of de software aan de gewenste specificaties voldoet. – Auteursrecht. • Een punt waar in de praktijk regelmatig geschillen over ontstaan, is de vraag wie de auteursrechthebbende is met betrekking tot de software die is ontwikkeld in het kader van een ontwikkelingsovereenkomst. De vraag aan wie het auteursrecht op de software toekomt in zo’n geval, kan in grote lijnen als volgt worden beantwoord. Het auteursrecht op software komt toe aan de maker van de software.29 In eerste instantie is dat de leverancier, hij maakt immers de software. De afnemer kan echter toch als maker, en dus als rechthebbende gelden, indien de software tot stand is gebracht ‘naar het ontwerp van’ de afnemer en ‘onder diens leiding en toezicht’.30 Hiervan zal echter niet vaak sprake zijn. Het auteursrecht zal in eerste instantie dan ook meestal aan de leverancier toekomen. Indien de afnemer over het auteursrecht op de software wil beschikken, dan zal dat expliciet moeten worden afgesproken in het contract. Het contract dient dan in de schriftelijke vorm en ondertekend te worden opgemaakt.31 4.4.4.

Open source-software

Inleiding Wanneer de afnemer open source-software wil aanschaffen, dan is daarvoor een specifiek contract nodig. Open source-software is in zekere zin zelfs onlosmakelijk verbonden met de bijbehorende contractuele voorwaarden. Het is allereerst van belang aan te geven wat onder open source-software kan worden verstaan. Software kent twee verschijningsvormen: software in de vorm van broncode (source code) en software in de vorm van objectcode. Software wordt geschreven in een voor mensen begrijpelijke programmeertaal: er is dan sprake van broncode. Om de software uitvoerbaar te maken in een computersysteem, wordt de broncode omgezet in objectcode. De broncode is uitvoerbaar door de computer, maar is niet meer begrijpelijk voor een natuurlijk persoon. Het open source-idee brengt onder meer mee dat het ontwikkelaars zo min mogelijk wordt belemmerd om voort te bouwen op het werk van anderen en dat daartoe de broncode van applicaties vrijelijk beschikbaar wordt gesteld. Om nauwkeuriger aan te gegeven wat onder open source wordt verstaan, kan de zogenaamde Open Source Definition (OSD) van het Open Source Initiative (OSI) worden genoemd. De OSD bestaat uit de volgende ‘geboden’:32 1. Er moet sprake zijn van vrije herdistributie; 2. De software dient inclusief de broncode te worden gedistribueerd; 3. De licentie dient toe te staan dat er aanpassingen en afgeleide werken worden

29. 30. 31. 32.

Art. 1 Auteurswet 1912. Art. 6 Auteurswet 1912. De overdracht van auteursrecht geschiedt namelijk bij akte, art. 2 lid 2 Auteurswet 1912. [http://www.opensource.org/docs/definition.php].

21


gemaakt van de oorspronkelijke broncode. Deze moeten bovendien onder dezelfde voorwaarden kunnen worden gedistribueerd; 4. Integriteit van de oorspronkelijke broncode; – Het moet voor de gebruiker van de software duidelijk zijn welke broncode van welke programmeur afkomstig is. Daarnaast dient een programmeur zijn reputatie te kunnen beschermen. Om hieraan tegemoet te komen, stelt de OSD dat de licentie mag bepalen dat de broncode niet verder mag worden gedistribueerd. De licentie moet dan wel bepalen dat verdere distributie van de oorspronkelijke, ongewijzigde broncode wél is toegestaan in combinatie met patchfiles. Met de patchfiles is het vervolgens mogelijk objectcode te creëren waarin wél wijzigingen zijn verwerkt. 5. De licentie mag geen onderscheid maken naar personen of groepen; 6. De licentie mag geen onderscheid maken naar toepassing; – Er mag bijvoorbeeld niet worden bepaald dat de software niet voor commerciële toepassingen mag worden gebruikt. 7. De licentie moet opeenvolgende verkrijgers binden, zonder dat er een aanvullende overeenkomst nodig is; – De achterliggende gedachte is hier dat de broncode vrij beschikbaar moet blijven. Gebruikers mogen bijvoorbeeld niet worden verzocht een geheimhoudingsverklaring (non-disclosure agreement) overeen te komen. 8. De licentie mag niet enkel betrekking hebben op één specifiek product; 9. De licentie mag geen beperkingen opleggen met betrekking tot andere software; 10. De licentie dient techniek-onafhankelijk te zijn. Het belang van bovenstaande OSD is dat licentievoorwaarden aan de OSI kunnen worden voorgelegd. Het OSI gaat dan na of de licentie voldoet aan de OSD. Is dat het geval, dan mag het ‘OSI certified’-keurmerk worden gevoerd.33 Het OSI houdt op zijn website een lijst bij van ‘goedgekeurde’ open source-licenties. Op het moment van schrijven bevat de lijst 58 licenties.34 Soorten licenties Nu er alleen al 58 OSI-licenties bestaan, kan het moeilijk zijn te bepalen met wat voor licenties men precies van doen heeft. In hoofdlijnen kunnen de 58 worden onderverdeeld in drie categorieën: copyleft, beperkt copyleft en non-copyleft.35 1. Copyleft; – Sommige open source-licenties bevatten een copyleft-bepaling. Het doel van een copyleft-bepaling is zoveel mogelijk te garanderen dat de broncode van software voor iedereen beschikbaar is en dat eenieder daar vervolgens aanpassingen en verbeteringen op mag uitvoeren en er afgeleide werken van mag produceren. De verbeteringen, aanpassingen en afgeleide werken dienen vervolgens ook weer onder dezelfde voorwaarden gedistribueerd te worden.

33. 34. 35.

22

[http://www.opensource.org/docs/certification_mark.php]. [http://www.opensource.org/licenses/index.html]. Van Hekesen & Tjong Tjin Tai 2006.


Bovendien mag er geen vergoeding worden gevraagd voor de broncode. Een bekend voorbeeld van een copyleft-licentie is de GNU General Public License (GNU GPL). De copyleft-voorwaarde kan ertoe leiden dat wanneer er softwarecode dat onder de GPL valt, wordt gebruikt bij het programmeren van andere software, dat dan de gehele broncode van dat andere programma ook onder GPL verder verspreid dient te worden. Er wordt wel gesproken van het virale karakter van de GPL. 2. Non-copyleft; – Non-copyleft-licenties staan net zoals copyleft-licenties toe dat de software onbeperkt wordt gebruikt, bewerkt en verder gedistribueerd. Hét grote verschil met copyleft-licenties is echter dat het niet verplicht wordt gesteld om de verkregen broncode vervolgens ook weer onder dezelfde licentievoorwaarden publiekelijk ter beschikking te stellen. Een bekend voorbeeld van een non-copyleft licentie is de BSD-licentie. 3. Beperkt copyleft. – Beperkt copyleft-licenties zijn een tussenvorm van de eerste twee categorieën open source-licenties. Kenmerkend voor deze licenties is dat zij wel een copyleft-bepaling bevatten, maar dat de reikwijdte van deze bepaling beperkter is. Daarnaast ontbreekt het virale effect. Een bekend voorbeeld van een beperkt copyleft-licentie is de MPL van Netscape. De Nederlandse overheid en open source De Nederlandse overheid staat het gebruik van open source-software binnen de overheid voor. Dit blijkt uit de motie Vendrik en uit het OSOSS-programma. In 2002 heeft de Tweede Kamer de motie Vendrik aangenomen. De motie verzocht de regering ‘actief de verspreiding en ontwikkeling van software met een open broncode (open source-software) in de publieke sector te stimuleren en hiervoor concrete en ambitieuze doelstellingen te formuleren’.36 Het OSOSS-programma stimuleert overheidsorganisaties open source-software en open standaarden te gebruiken.37 Open source-software en het automatiseringscontract Hierboven is uiteengezet wat er onder open source-software wordt verstaan. De vraag die nu aan de orde is, luidt: wat betekent een en ander voor de afnemer en de leverancier bij het maken van afspraken in een automatiseringscontract? In de eerste plaats is het van belang een onderscheid te maken tussen het gebruik en de verdere verspreiding van open source-software. Indien een afnemer en een leverancier een contract sluiten inzake de aanschaf van open source-software, dan is dit

36. 37.

Kamerstukken II 2002-03, 28 600 XIII, nr. 30. [http://www.ososs.nl].

23


in feite een ‘normaal’ contract inzake de aanschaf van software. De afnemer doet er uiteraard verstandig aan onderzoek te doen naar de applicatie die hij voornemens is aan te schaffen. Hij kan bijvoorbeeld nagaan of er sprake is van een actieve en/of gerenommeerde gemeenschap (community) van open source-programmeurs die de applicatie heeft ontwikkeld. Daarnaast kan het verstandig zijn om aanvullende afspraken te maken voor wat betreft de Service Levels in het SLA. In het SLA kunnen risico’s worden afgedekt en garanties worden verkregen. Indien er wordt gekozen voor de ontwikkeling van software, dan is het mogelijk dat de nieuw ontwikkelde software alleen onder bepaalde voorwaarden verder mag worden verspreid. Beide partijen dienen hierover duidelijke afspraken te maken en er een passende open source-licentie bij te kiezen.38 4.5.

Onderhoudsovereenkomsten39

4.5.1.

Omschrijving

Na de aanschaf van software heeft de afnemer er baat bij dat de software ongestoord goed blijft functioneren en eventueel wordt doorontwikkeld of regelmatig wordt bijgewerkt, bijvoorbeeld om rekening te houden met veranderende beveiligingsrisico’s. Een afnemer kan hiertoe een overeenkomst aangaan met een leverancier die het onderhoud van de software voor zijn rekening neemt. Er wordt dan gesproken van een onderhoudsovereenkomst. In de praktijk is een onderhoudsovereenkomst vaak onderdeel van de overeenkomst inzake de aanschaf van software: bij de aanschaf worden dan reeds afspraken gemaakt over het onderhoud. 4.5.2.

Aandachtspunten

Bij het opstellen van een onderhoudsovereenkomst gelden onder meer de volgende aandachtspunten. – Definities; • Er dient duidelijk te worden aangegeven wat wordt verstaan onder ‘programmatuur’, ‘storing’, ‘onvolkomenheden’, ‘fout’, en andere begrippen die een centrale rol spelen. – Soorten onderhoud; • In de praktijk worden globaal drie soorten onderhoud onderscheiden: – Preventief onderhoud; • Hieronder wordt verstaan het nemen van maatregelen om te waarborgen dat de software of het systeem volgens de specificaties en zonder gebreken of storingen functioneert. – Correctief onderhoud;

38. 39.

24

Presentatie B. Knubben, ‘Open source, een juridisch verantwoorde keuze!’, OSOSS Symposium, 8 december 2005. Blok e.a. 2004, blz. 99-106.


–

–

–

–

• Het aanpassen van de software of het systeem om onvolkomenheden te verhelpen. – Vernieuwend onderhoud; • Het implementeren van nieuwe versies of nieuwe onderdelen van de software of het systeem. Het is van belang in het contract rekening te houden met onverwachte gevolgen van een nieuwe versie van (een onderdeel van) de software of van het systeem. Komen deze voor risico van de afnemer of van de leverancier? Naast deze drie vormen van onderhoud wordt vaak aandacht besteed aan helpdesk dienstverlening. Uitwijkregeling; • Soms wordt overeengekomen dat ingeval van een ernstige storing van de software of het systeem, bedrijfsactiviteiten vanuit een andere locatie kunnen worden voortgezet. De dienstverlener zal dan op een uitwijklocatie dezelfde software of hetzelfde systeem beschikbaar moeten hebben. Onderhoudstermijnen/reactietijden; • Het verdient aanbeveling om in het contract neer te leggen binnen welke termijn een bepaald probleem is verholpen. Het ligt voor de hand om de lengte van de periode waarbinnen een probleem dient te zijn verholpen, te koppelen aan de ernst van het probleem. De volgende indeling van problemen of onvolkomenheden kan worden gemaakt: – De software/het systeem functioneert helemaal niet meer; – Er is een ernstig verlies aan functionaliteit van de software/het systeem; – Er zijn hinderlijke tekortkomingen aan de software/het systeem, maar er kan nog wel normaal gebruik van worden gemaakt. Afnemer en leverancier kunnen overeenkomen om de afgesproken termijn te handhaven met een systeem van boetes. Intellectuele eigendom; • Net zoals bij de overeenkomst inzake de aanschaf van software is ook hier de intellectuele eigendom een punt van aandacht. Indien de leverancier als onderdeel van het onderhoud nieuwe onderdelen (updates) van de software of het systeem aanlevert, dan kan de vraag ontstaan aan wie het auteursrecht op deze onderdelen toekomt. Het verdient aanbeveling hier duidelijke afspraken over te maken. De praktijk leert dat met name de afnemer voor vervelende verrassingen kan komen te staan wanneer blijkt dat hij niet (meer) bevoegd is om gebruik te maken van (onderdelen van) de software of het systeem. Aansprakelijkheid. • Zoals bij alle automatiseringscontracten kan de regeling omtrent de aansprakelijkheid een belangrijk discussiepunt worden. In hoofdstuk 6 wordt de beperking van aansprakelijkheid in het algemeen behandeld.

25


4.6.

Outsourcing en offshoring

4.6.1.

Inleiding

Onder outsourcing wordt verstaan het overdragen van een bedrijfsactiviteit aan een ander die vervolgens deze activiteit teruglevert als dienst.40 De achterliggende gedachte bij outsourcing is onder meer dat bedrijven zich met hun core business bezig dienen te houden en niet met ondersteunende werkzaamheden. In deze gedachtegang kan een bedrijf zijn IT-afdeling outsourcen aan een gespecialiseerd ITbedrijf. Outsourcing kan ook betrekking hebben op andere bedrijfsonderdelen, in het hierna volgende staat uiteraard de outsourcing van IT-voorzieningen en –werkzaamheden centraal. Met outsourcing wordt ook wel eens bedoeld het verplaatsen van bedrijfsactiviteiten naar lagelonenlanden of tax havens. Het is echter meer zuiver om dit aan te duiden met de term offshoring. Offshoring kan vervolgens geschieden middels outsourcing. Het kan echter ook binnen een onderneming plaatsvinden.41 Outsourcing en offshoring kunnen complexe, langdurige trajecten met zich meebrengen. Met de hiernavolgende behandeling van outsourcing en offshoring kan dan ook niet meer dan een inleidend overzicht worden gegeven. Hierna zal er op worden gewezen dat het tot stand brengen van een outsourcingovereenkomst van beide partijen een meer evenwichtige benadering eist dan bij andere contracten gebruikelijk is. Het onderhandelen met open vizier bekort het onderhandelingstraject en schept duidelijke verwachtingen, welke nodig zijn voor de langdurige relatie die outsourcing met zich meebrengt. In dit verband kan het objectieve oordeel van de IT-auditor voor beide partijen van belang zijn, bijvoorbeeld bij het beoordelen van de beveiligingseisen in het hierna te behandelen Request for Proposals. 4.6.2.

Het outsourcingtraject

In paragraaf 2.4 is er al op gewezen dat een goed automatiseringscontract meer is dan slechts een actiepunt dat kan worden afgevinkt bij een automatiseringsproject. Dat geldt zeker in het geval van een outsourcingproject. Outsourcingprojecten zijn complexe, ingrijpende procedures waarbij het contract duidelijk dient aan te geven wat de verwachtingen zijn die partijen over en weer van elkaar hebben. Het is daarom van belang rekening te houden met alle onderdelen waar een outsourcingsproces uit bestaat. Van begin tot eind kan een outsourcingsproces er als volgt uit zien.42

40. 41. 42.

26

Rapport juridische werkgroep Platform Outsourcing Nederland 2006, blz. 1. Jongen 2005, blz. 197. Rapport juridische werkgroep Platform Outsourcing Nederland 2006, blz. 2-5; Rinzema 2005, blz. 173.


Tijdstip

Omschrijving

Voorbereidingsfase

De afnemer besluit tot outsourcing. De dienstverlening, bedrijfsprocessen, service levels enz. worden in kaart gebracht. Eventueel wordt er reeds advies ingewonnen bij een leverancier. Het is voor de afnemer van belang bij het eerste contact met een leverancier een geheimhoudingsovereenkomst (Non Disclosure Agreement, NDA) aan te gaan. De afnemer kan een offerte aanvragen in de vorm van een Request for Proposals, RFP. Een RFP is een offerteaanvraag met een beschrijving van het project en een opgave van te beantwoorden vragen. Een concept van een outsourcingovereenkomst kan onderdeel uitmaken van de RFP. Soms verzoekt de afnemer voorafgaand aan de RFP eerst om informatie in de vorm van een Request for Information, RFI.

Onderhandelingsfase

De afnemer en de leverancier treden in onderhandeling. Er kan een Letter of Intent (zie paragraaf 3.4) worden opgesteld waarin afspraken gemaakt worden over het verloop van de onderhandelingsfase. In deze fase kunnen conceptversies van een te tekenen contract worden besproken.

Tekenen van het contract

De outsourcingovereenkomst wordt aangegaan.

Transitie

De overgang van activiteiten en eventueel ook personeel van de afnemer naar de leverancier.

Operationele fase

De dienstverlening in de vorm van de teruglevering van de overgedragen dienst vindt plaats.

Beëindigingsfase

De afnemer besluit de uitbestede dienst weer zelf te gaan verrichten of gaat gebruikmaken van de diensten van een andere leverancier.

Bovenstaand tijdsverloop is een vereenvoudigde weergave van het outsourcingproces. Er kunnen aanvullende gebeurtenissen plaatsvinden. Zo vindt na de transitiefase nog wel eens de transformatiefase plaats. Dat houdt in dat het niveau van dienstverlening wordt gewijzigd. 4.6.3.

Juridische structuur van de outsourcingovereenkomst

Het outsourcen van een bedrijfsactiviteit kan op de volgende manieren juridisch worden vormgegeven: – Dienstenovereenkomst; • In de meest eenvoudige vorm kan outsourcing bestaan uit het aangaan van een dienstenovereenkomst. Daarnaast worden er soms bedrijfsactiva als materialen, apparatuur en software overgedragen. – Fusie of overname; • De leverancier kan fuseren met een bedrijfsonderdeel van de afnemer, of dat bedrijfsonderdeel overnemen.

27


Joint venture. • Afnemer en leverancier kunnen op basis van een samenwerkingsovereenkomst de vereiste dienstverlening opzetten. Dit kan geschieden door bijvoorbeeld gezamenlijk een rechtspersoon (bijvoorbeeld een BV) op te richten waarin afnemer en leverancier middelen (hardware, software, personeel) inbrengen. Bij het kiezen van een juridische constructie voor de outsourcing, kan onder meer rekening worden gehouden met de volgende aspecten: – Verschillende jurisdicties; • Er dient rekening te worden gehouden met het rechtsstelsel van andere landen, indien de te outsourcen bedrijfsactiviteit of de uitbesteding daarvan grensoverschrijdend is. – Vennootschapsrechtelijke structuur van de afnemer; • De afnemer kan als onderneming bestaan uit een groep van rechtspersonen. De te outsourcen bedrijfsactiviteit kan een activiteit zijn waar de hele groep gebruik van wenst te maken. De afnemer zal dan willen bewerkstelligen dat de hele groep, en niet slechts één lid van de groep, juridisch aanspraak kan maken op de bedrijfsactiviteit. – Vennootschapsrechtelijke structuur van de leverancier; • Zeker bij grotere IT-leveranciers, kan ook de onderneming van de leverancier bestaan uit een groep van rechtspersonen. Het is van belang af te spreken welk lid van de groep, of de groep als geheel, zich contractueel bindt. – Fiscale aspecten. • Indien de te outsourcen bedrijfsactiviteit internationale trekken vertoont, is het van belang vast te stellen of het voordelig is om ervoor te zorgen dat de bedrijfsactiviteit onderworpen is aan het belastingregime van één van de betrokken landen.43 4.6.4.

De outsourcingovereenkomst

Bij het opstellen van de outsourcingovereenkomst is het van groot belang voor ogen te houden dat de overeenkomst bestaat uit twee onderdelen. In de eerste plaats dient de overgang van de bedrijfsactiviteit te worden geregeld. In de tweede plaats moeten afspraken worden gemaakt over de dienstverlening die na de overgang zal plaatsvinden. Bij de outsourcingovereenkomst gelden de volgende aandachtspunten:44 – Overwegingen; • In de overwegingen kan worden aangegeven wat de beweegredenen van partijen zijn en wat het gezamenlijke doel is. – Overlegstructuur; • Om een outsourcingtraject goed te doen verlopen, is het zeer belangrijk om

43. 44.

28

Khodabaks 2004, blz. 24-27. Blok e.a. 2004, blz. 107-115; Janse de Jonge 2004; Khodabaks 2004; Rapport juridische werkgroep Platform Outsourcing Nederland 2006, blz. 5-12.


een overlegstructuur in te richten. Er kan worden gekozen voor een gelaagde overlegstructuur waarbij zowel op het operationele als op het tactische en strategische niveau wordt afgestemd. Er kan een escalatiepad worden afgesproken zodat eventuele onenigheden snel en efficiënt worden opgelost. – Overgang van activiteiten; • Onder deze contractsbepaling wordt aangegeven welke bedrijfsactiviteiten worden overgedragen aan de leverancier en hoe de activiteiten worden voortgezet door de leverancier. In de praktijk komt het vaak voor dat wordt afgesproken dat de dienstverlening wordt voortgezet zoals hij zich op dat moment voordoet. Er wordt dan gesproken van een dienstverlening op ‘as is’-basis. Pas na verloop van tijd zal de leverancier de dienstverlening kunnen wijzigen of verbeteren. • Ook is het van belang in het contract rekening te houden met ‘hidden services’. De beschrijving in het contract van de bedrijfsactiviteit die dient te worden uitbesteed, is vaak niet volledig. Het komt regelmatig voor dat tijdens het outsourcingtraject pas blijkt dat er diensten zijn waar de afnemer ook behoefte aan heeft, maar die niet zijn omschreven als uit te besteden bedrijfsactiviteit. Een goed contract voorziet in een manier waarop wordt omgegaan met deze ‘hidden services’. In hoofdlijnen zijn de volgende twee benaderingen mogelijk: – De ‘nee, tenzij’-benadering. Bij deze benadering verricht de leverancier alleen extra werkzaamheden nadat beide partijen daarover aanvullende afspraken hebben gemaakt; – De ‘ja, maar’-benadering. Bij deze benadering verplicht de leverancier zich de dienstverlening ‘as is’ uit te voeren, dus inclusief ‘hidden services’. Indien de omvang van de dienstverlening in een te grote mate afwijkt van de afspraken, dan heeft de leverancier recht op een aanvullende vergoeding. – Overgang van zaken en licenties; • Wanneer er met de outsourcing zaken overgaan, bijvoorbeeld bepaalde computerapparatuur, dan dient het contract aan te geven welke zaken aan de leverancier worden verkocht en hoe de levering geschiedt. • Een speciaal aandachtspunt is de overdracht van het gebruiksrecht op software. Om gebruik te kunnen maken van de computerprogrammatuur, indien dit wordt overgedragen, dient de leverancier over een gebruiksrecht te beschikken. Het is echter de vraag of deze gebruiksrechten kunnen worden overgedragen. Het is vaak nodig om een uitgebreide inventarisatie te doen van de gebruiksrechten die men voornemens is over te dragen, alsook van de aanvullende voorwaarden die omtrent deze gebruiksrechten gelden. Er wordt dan gesproken van een due diligenceonderzoek. Er dient dan bijvoorbeeld te worden geïnventariseerd: – over welke gebruiksrechten de afnemer beschikt; – of de software alleen gebruikt mag worden binnen een bepaald concern of op een bepaalde locatie; – of de gebruiksrechten vervangbaar en/of opzegbaar zijn; – wat de hoogte is van betaalde vergoedingen; – enzovoort.

29


– Overgang van personeel; • Er kan voor worden gekozen om personeel van de afnemer onder te brengen bij de leverancier ter uitvoering van de uitbestede bedrijfsactiviteit. Juridisch geschiedt dit vaak op grond van het volgende. De Nederlandse wet heeft onder meer tot doel de werknemer als ‘zwakke partij’ te beschermen. Hierom bepaalt de wet dat ingeval van een ‘overgang van een onderneming’ het personeel in feite ‘overgaat’ naar degene die de onderneming verkrijgt: het personeel ‘volgt’ de bedrijfsactiviteit.45 Deze overgang van personeel vindt automatisch (‘van rechtswege’) plaats. Het personeel komt dan in dienst van de leverancier onder de arbeidsvoorwaarden zoals die golden bij de afnemer. Er zijn verschillende deelaspecten waarmee rekening moet worden gehouden bij deze automatische overgang van personeel. Het gaat onder meer om het volgende: – De betekenis van een concurrentiebeding kan wijzigen. Een concurrentiebeding kan bijvoorbeeld een lijst met relaties bevatten die een werknemer niet als nieuwe werkgever mag benaderen. Deze lijst dient voor zover mogelijk eventueel te worden gewijzigd of aangevuld; – De afnemer is tot één jaar na de overgang naast de leverancier hoofdelijk aansprakelijk voor de verplichtingen uit de arbeidsovereenkomst.46 Hoofdelijke aansprakelijkheid houdt overigens in dat de werknemer zowel jegens de afnemer als jegens de leverancier recht heeft op nakoming van de arbeidsovereenkomst.47 Afnemer en leverancier moeten de verplichting jegens de werknemer verder onderling afhandelen; – Een werkgever kan een arbeidsovereenkomst niet opzeggen wegens de overgang van een onderneming;48 – Indien de overgang van een onderneming een wijziging ten nadele van de werknemer tot gevolg heeft waardoor de arbeidsovereenkomst wordt ontbonden, dan komt de ontbindingsgrond voor rekening van de werkgever.49 Dit heeft gevolgen voor de ontbindingsvergoeding die de werknemer kan ontvangen en voor de vraag of er sprake is van verwijtbare werkloosheid in het kader van een WW-uitkering; – De pensioenrechten van de werknemer gaan niet altijd mee over naar de leverancier. Het verdient aanbeveling hierover advies in te winnen. • Indien de afnemer over een ondernemingsraad beschikt, dient hij advies over het outsourcingbesluit te vragen aan de ondernemingsraad. • Wanneer de afnemer personeel van de leverancier inleent, dan kan de afnemer worden aangesproken tot het betalen van sociale premies en loonbelastingen. Het verdient aanbeveling om goed uit te zoeken welke fiscale verplichtingen precies op beide partijen rusten en om hier vervolgens afspraken over te maken.

45. 46. 47. 48. 49.

30

Art. 7:663 eerste volzin BW; Janse de Jonge 2004. Art. 7:663 tweede volzin BW. Art. 6:7 lid 1 BW. Art. 7:670 lid 8 BW. Art. 7:665 BW.


– Servicelevels. • Hiervoor bij de behandeling van de overgang van activiteiten is al even genoemd dat meteen na de overgang de dienstverlening wordt voortgezet op ‘as is’-niveau. Daarna kan het niveau van de dienstverlening worden aangepast. Het is van belang hierbij rekening te houden met de te verwachten veranderende behoeftes van de afnemer. Afspraken inzake het niveau van de dienstverlening worden vastgelegd in een Service Level Agreement (SLA). De SLA kan als bijlage worden toegevoegd aan de outsourcingovereenkomst. In de SLA wordt gedetailleerd het niveau van dienstverlening afgesproken, het gaat dan bijvoorbeeld om beschikbaarheid, responstijd en frequentie. Er dient een methode te worden afgesproken om dienstverlening op objectieve wijze te meten zodat kan worden nagegaan of de afgesproken servicelevels al dan niet zijn behaald. De ervaring leert dat de leverancier erbij gebaat is zo laat mogelijk in het outsourcingtraject afspraken te maken over de service levels. De kans is dan namelijk kleiner dat het outsourcingtraject geen doorgang zal vinden, terwijl er in de SLA nog wel belangrijke afspraken worden neergelegd. De afnemer is er juist bij gebaat de service levels in een zo vroeg mogelijk stadium af te spreken. 4.6.5.

Lessons learned

In de praktijk doet zich vaak een aantal problemen voor die een succesvolle outsourcing in de weg staan. Deze problemen zijn door de Juridische Werkgroep van het Platform Outsourcing Nederland geïnventariseerd. Het is de moeite waard ze hier integraal weer te geven: – Zonder een goede en gedetailleerde omschrijving van de dienstverlening (middels een service description) biedt het outsourcingcontract onvoldoende zekerheid en bescherming; – Een vage service description is doorgaans in het nadeel van de afnemer. Een dienst die vaag is omschreven, kan op meerdere manieren worden verricht; – Bij voorkeur moet er een jurist worden ingeschakeld voordat het Request for Proposals (RFP) wordt verzonden; – Het opnemen van een conceptcontract in het RFP voorkomt te opportunistisch bieden door sommige leveranciers; – Het opnemen van een conceptcontract in het RFP heeft voor de afnemer het strategische voordeel dat wordt begonnen met een document op maat dat de door hem gewenste positie bevat; – Het conceptcontract moet evenwichtig zijn. Een zeer eenzijdig contract verlengt de onderhandelingsperiode en leidt niet tot een beter resultaat voor de afnemer; – Er moet vroegtijdig worden onderhandeld over de belangrijkste bijlagen. Dit is namelijk een tijdrovende klus. Bovendien is het verstandig in een vroeg stadium overeenstemming te hebben over het Service Level Agreement. Bij het opstellen van de bijlagen moeten tijdig juristen worden betrokken om de onderhandelingen te ondersteunen en om eindredactie te voeren. Dit voorkomt dat partijen langs elkaar heen praten en bevordert de consistentie van het contract en de bijlagen;

31


– De structuur van de contractsdocumenten moet zo eenvoudig zijn als de fiscale eisen toestaan; – Joint ventures zijn slechts zelden nuttig als juridische constructie voor outsourcing. In feite is een joint venture strijdig met de grondgedachte van outsourcing, de afnemer blijft immers betrokken bij de bedrijfsactiviteit die hij wil uitbesteden; – De complexiteit van de onderhandelingen over pensioenen en andere arbeidsvoorwaarden moeten niet worden onderschat. De financiële consequenties moeten tijdig worden geïnventariseerd; – De afnemer moet zich ervan overtuigen dat de leverancier een voldoende winstmarge overhoudt. Leveranciers kunnen in de onderhandelingsfase worden ‘gedwongen’ met een te lage marge genoegen te nemen. Op lange termijn levert dat onvermijdelijk problemen op. Het outsourcingtraject kan daarom niet worden geleid door de afdeling inkoop, tenzij men zich hiervan bewust is; – Outsourcing is niet hetzelfde als een ‘normale’ overname. Zogenaamde harde onderhandelingen die bij een overname nuttig kunnen zijn, werken niet bij outsourcing. Er moet namelijk een productieve lange termijnrelatie worden gekweekt; – De planning van het outsourcingtraject moet realistisch zijn. Het komt vaak voor dat afnemers hun eigen te ambitieuze planning niet halen. Deskundige juristen kunnen hierbij helpen; – Het contract dient flexibel te zijn. Er moet rekening worden gehouden met wijzigingen in het outsourcingtraject: veel outsourcingtrajecten zijn moving targets; – De technische infrastructuur van de leveranciers dient vroegtijdig te worden onderzocht: er dient te worden nagegaan of de infrastructuur van een leverancier ertoe leidt dat er persoonsgegevens naar landen buiten de EU worden doorgegeven; – De belangrijkste onderhandelingsteams moeten zowel uit commerciëlen als juristen bestaan. Afzonderlijke commerciële en juridische onderhandelingsteams werken niet, bovendien verlengt dit het onderhandelingsproces; – Afnemers zijn soms geneigd de service levels die zij zelf halen mooier voor te stellen dan zij daadwerkelijk zijn. Als deze vervolgens niet worden gehaald door de leverancier, ontstaan er problemen; – Afnemers zijn soms geneigd aan teveel service levels credits te koppelen. Beperk dat tot de echt belangrijke service levels; – Do not outsource a problem.50 4.6.6.

Offshoring

Offshoring is het verplaatsen van een bedrijfsactiviteit naar een ander land, meestal een lagelonenland of een tax haven. Wanneer in het kader van een outsourcingtraject sprake is van offshoring, dan dient onder meer met de volgende aandachtspunten rekening te worden gehouden:51

50. 51.

32

Rapport juridische werkgroep Platform Outsourcing Nederland 2006, blz. 13-14. Offshoring binnen een onderneming wordt buiten beschouwing gelaten.


– Regulatoire belemmeringen; • Nationale overheden kennen vaak branche-specifieke regelgeving, er wordt ook wel gesproken van gereguleerde markten, denk bijvoorbeeld aan telecommunicatie, het bankwezen en de zorg. Deze branche-specifieke regelgeving kan belemmeringen opleveren voor grensoverschrijdende dienstverlening. Het gaat bijvoorbeeld om: – Regelgeving van De Nederlandsche Bank op grond waarvan het plaatsen van een server door een bank in een politiek onstabiel land of dictatuur kan rekenen op bezwaar van De Nederlandsche Bank; – De wetgeving inzake het bankgeheim in Luxemburg op grond waarvan gegevens die betrekking hebben op cliënten niet grensoverschrijdend verstrekt mogen worden. – Exportbeperkingen; • Met betrekking tot high tech-producten, zoals sommige elektronica en software, gelden vaak exportbeperkingen. De achterliggende gedachte is dat deze producten ook militaire toepassingen kunnen hebben. Er wordt soms ook wel gesproken van dual use-goederen, dat wil zeggen producten met zowel een civiele als een militaire toepassing. Een bekend voorbeeld is cryptografische software. Douanes beschikken over lange lijsten met producten waarvoor exportbeperkingen gelden, soms zijn die online in te zien. – Doorgifte van persoonsgegevens naar derdelanden. • De lidstaten van de EU hebben hun wetgeving inzake de bescherming van persoonsgegevens op elkaar afgestemd. Op grond van deze wetgeving mogen persoonsgegevens alleen aan een land buiten de EU worden doorgegeven, indien dat land over een ‘passend beschermingsniveau’ beschikt.52 Er zijn nog meer aspecten waarmee in het kader van offshoring rekening moet worden gehouden. Het verdient dan ook aanbeveling om hierover juridisch advies in te winnen.

52.

Jongen 2005.

33

HOOFDSTUK 5

Het gebruik van algemene voorwaarden 5.1.

Inleiding

In hoofdstuk 2 is al even melding gemaakt van algemene voorwaarden. Algemene voorwaarden zijn contractuele voorwaarden die zijn opgesteld met het voornemen ze bij meerdere verschillende automatiseringstrajecten te gebruiken.1 Zij worden vaak door een partij van toepassing verklaard door op briefpapier of op een offerte of offerte-aanvraag een zinsnede als ‘op al onze aanbiedingen en overeenkomsten zijn onze algemene voorwaarden van toepassing’ op te nemen. In dit boekje worden meestal de termen ‘afnemer’ en ‘leverancier’ gebruikt. In dit hoofdstuk wordt daarvan afgeweken. Er wordt uitgegaan van de ‘gebruiker’, dat is degene die de algemene voorwaarden in een overeenkomst gebruikt,2 en de ‘wederpartij’, dat is degene die de toepasselijkheid van de algemene voorwaarden van de gebruiker aanvaardt.3 5.2.

Ambigu karakter van de wettelijke regeling van algemene voorwaarden

Het Burgerlijk Wetboek bevat gedetailleerde regels over het gebruik van algemene voorwaarden. De wetgever hinkt echter op twee gedachten, waardoor de wettelijke regeling voor de praktijk gecompliceerd kan zijn. De twee gedachten houden het volgende in. Aan de ene kant moet een onderneming vrij gemakkelijk zijn algemene voorwaarden van toepassing kunnen verklaren.4 Dit zou namelijk (maatschappelijk gezien) bepaalde voordelen hebben, zoals onder meer het vereenvoudigen van onderhandelingen en het verkleinen van de kans op vergissingen.5 Aan de andere kant zou de wederpartij echter moeten worden beschermd tegen het gebruik van algemene voorwaarden.6 Deze bescherming is nodig omdat er (maatschappelijk

1. 2. 3. 4.

5.

6.

Vgl. art. 6:231 sub a BW. Art. 6:231 sub b BW. Vgl. art. 6:232 sub c BW. Dat de wetgever deze gedachte aanhangt, blijkt uit het feit dat in art. 6:232 BW een uitzondering op de wilsvertrouwensleer is geformuleerd: ook zonder wilsovereenstemming of een gerechtvaardigd vertrouwen daarop kan er sprake zijn van gebondenheid. E.H. Hondius, Standaardvoorwaarden. Rechtsvergelijkende beschouwingen over de standaardisering van kontraktsbedingen en overheidstoezicht (diss. Leiden), Deventer: Kluwer 1978, blz. 276278, 293-294. PG Inv. Boek 6 MvT 1990, blz. 1443.

35

Het gebruik van algemene voorwaarden

gezien) ook nadelen zitten aan het gebruik van algemene voorwaarden. Algemene voorwaarden zullen namelijk veelal eerder in het voordeel van de gebruiker van de algemene voorwaarden dan in het voordeel van de wederpartij worden opgesteld. In de praktijk worden algemene voorwaarden door de wederpartij echter zelden gelezen. De wederpartij kan daarom voor onverwachte verrassingen komen te staan. Hierna worden de hoofdlijnen van de wettelijke regeling geschetst. Omdat de wetgever op de genoemde twee gedachtes hinkt, zal blijken dat in zekere zin met de ene hand wordt weggenomen wat met de andere hand wordt gegeven. 5.3.

Hoofdlijnen van de wettelijke regeling

De wet schrijft in hoofdlijnen het volgende voor. 1. Snelle gebondenheid aan algemene voorwaarden; – De wederpartij is ook gebonden aan de algemene voorwaarden van de gebruiker wanneer hij geen kennis heeft genomen van de inhoud van de voorwaarden.7 2. Maar: zware informatieverplichting voor de gebruiker; – De snelle gebondenheid wordt evenwel bijna tenietgedaan door de zware informatieplicht die op de gebruiker rust: indien de wederpartij niet een redelijke mogelijkheid tot kennisname heeft van de algemene voorwaarden, dan kan hij (een beding uit) de algemene voorwaarden vernietigen.8 Om aan de verplichting een redelijke mogelijkheid tot kennisname te voldoen, dient de gebruiker de algemene voorwaarden ter hand te stellen. Dat betekent dat de gebruiker zijn algemene voorwaarden aan de wederpartij moet overhandigen dan wel toesturen.9 3. En: inhoudelijke toetsing van algemene voorwaarden. – Niet alle bepalingen in algemene voorwaarden zijn toegestaan. Een bepaling in algemene voorwaarden mag niet onredelijk bezwarend zijn voor de wederpartij.10 Het is vaak moeilijk van tevoren vast te stellen of een bepaald beding onredelijk bezwarend is. Meestal is dat in de praktijk pas te bepalen naar aanleiding van een concreet geschil. Er kan toch enig houvast worden gevonden in de zogenaamde zwarte lijst en de grijze lijst.11 De beide lijsten zijn in principe bedoeld voor algemene voorwaarden die tegenover consumenten worden gehanteerd. Ook wanneer ondernemingen onder elkaar contracteren, kunnen de zwarte en de grijze lijst echter een rol spelen, namelijk in de situatie

7. 8. 9.

10. 11.

36

Vgl. art. 6:232 BW. Art. 6:233 sub b BW. Om een en ander eenvoudig te houden, wordt niet het volledige juridische regime uitgeschreven, zie daarvoor art. 6:233 en 6:234 BW, HR 1 oktober 1999, NJ 2000, 207 m.nt. JH (Geurtzen/Kampstaal), HR 6 april 2001 RvdW 2001, 74 (VNP Parkeersystemen/Havrij), HR 6 april 2001, NJ 2002, 385 m.nt. HJS. Art. 6:233 sub a BW. Daarnaast wordt ook wel gesproken van de Haagse lijst en de blauwe lijst, Loos 2001, nr. 188199.


dat een grote onderneming tegenover een kleine, op een consument gelijkende onderneming staat. Er wordt dan gesproken van reflexwerking van de zwarte en grijze lijst. Het gaat dan bijvoorbeeld om: • Kleine stichtingen of verenigingen die als afnemer optreden; • Eenmanszaken die buiten hun eigenlijke bedrijfsuitoefening handelen (bijvoorbeeld een makelaar die een kantoornetwerk laat aanleggen).12 5.4.

De zwarte en de grijze lijst

Volgens de zwarte lijst wordt als onredelijk bezwarend aangemerkt een beding in algemene voorwaarden: a. dat de wederpartij geheel en onvoorwaardelijk het recht ontneemt de door de gebruiker toegezegde prestatie op te eisen; b. dat de aan de wederpartij toekomende [wettelijke] bevoegdheid tot ontbinding (…) uitsluit of beperkt; c. dat een de wederpartij volgens de wet toekomende bevoegdheid tot opschorting van de nakoming uitsluit of beperkt of de gebruiker een verdergaande bevoegdheid tot opschorting verleent dan hem volgens de wet toekomt; d. dat de beoordeling van de vraag of de gebruiker in de nakoming van een of meer van zijn verbintenissen is te kort geschoten aan hem zelf overlaat, of dat de uitoefening van de rechten die de wederpartij ter zake van een zodanige tekortkoming volgens de wet toekomen, afhankelijk stelt van de voorwaarde dat deze eerst een derde in rechte heeft aangesproken; e. krachtens hetwelk de wederpartij aan de gebruiker bij voorbaat toestemming verleent zijn uit de overeenkomst voortvloeiende verplichtingen op een der in (…) [de wet] bedoelde wijzen op een derde te doen overgaan, tenzij de wederpartij te allen tijde de bevoegdheid heeft de overeenkomst te ontbinden, of de gebruiker jegens de wederpartij aansprakelijk is voor de nakoming door de derde, of de overgang plaatsvindt in verband met de overdracht van een onderneming waartoe zowel die verplichtingen als de daartegenover bedongen rechten behoren; f. dat voor het geval uit de overeenkomst voor de gebruiker voortvloeiende rechten op een derde overgaan, ertoe strekt bevoegdheden of verweermiddelen die de wederpartij volgens de wet jegens die derde zou kunnen doen gelden, uit te sluiten of te beperken; g. dat een wettelijke verjarings- of vervaltermijn waarbinnen de wederpartij enig recht moet geldend maken, tot een verjarings- onderscheidenlijk vervaltermijn van minder dan een jaar verkort; h. dat voor het geval bij de uitvoering van de overeenkomst schade aan een derde wordt toegebracht door de gebruiker of door een persoon of zaak waarvoor deze aansprakelijk is, de wederpartij verplicht deze schade hetzij aan de derde te vergoeden, hetzij in haar verhouding tot de gebruiker voor een groter deel te dragen dan waartoe zij volgens de wet verplicht zou zijn; i. dat de gebruiker de bevoegdheid geeft de door hem bedongen prijs binnen drie

12.

Loos 2001, nr. 202-207.

37


maanden na het sluiten van de overeenkomst te verhogen, tenzij de wederpartij bevoegd is in dat geval de overeenkomst te ontbinden; j. dat in geval van een overeenkomst tot het geregeld afleveren van zaken, elektriciteit daaronder begrepen, of tot het geregeld doen van verrichtingen, leidt tot stilzwijgende verlenging of vernieuwing van meer dan een jaar; k. dat de bevoegdheid van de wederpartij om bewijs te leveren uitsluit of beperkt, of dat de uit de wet voortvloeiende verdeling van de bewijslast ten nadele van de wederpartij wijzigt, hetzij doordat het een verklaring van haar bevat omtrent de deugdelijkheid van de haar verschuldigde prestatie, hetzij doordat het haar belast met het bewijs dat een tekortkoming van de gebruiker aan hem kan worden toegerekend; l. dat ten nadele van de wederpartij afwijkt van [de wettelijke regeling inzake het moment van werking van verklaringen], tenzij het betrekking heeft op de vorm van door de wederpartij af te leggen verklaringen of bepaalt dat de gebruiker het hem door de wederpartij opgegeven adres als zodanig mag blijven beschouwen totdat hem een nieuw adres is meegedeeld; m. waarbij een wederpartij die bij het aangaan van de overeenkomst werkelijke woonplaats in een gemeente in Nederland heeft, woonplaats kiest anders dan voor het geval zij te eniger tijd geen bekende werkelijke woonplaats in die gemeente zal hebben, tenzij de overeenkomst betrekking heeft op een registergoed en woonplaats ten kantore van een notaris wordt gekozen; n. dat voorziet in de beslechting van een geschil door een ander dan hetzij de rechter die volgens de wet bevoegd zou zijn, hetzij een of meer arbiters, tenzij het de wederpartij een termijn gunt van tenminste een maand nadat de gebruiker zich schriftelijk jegens haar op het beding heeft beroepen, om voor beslechting van het geschil door de volgens de wet bevoegde rechter te kiezen.13 Volgens de grijze lijst wordt vermoed onredelijk bezwarend te zijn een beding in algemene voorwaarden: a. dat de gebruiker een, gelet op de omstandigheden van het geval, ongebruikelijk lange of onvoldoende bepaalde termijn geeft om op een aanbod of een andere verklaring van de wederpartij te reageren; b. dat de inhoud van de verplichtingen van de gebruiker wezenlijk beperkt ten opzichte van hetgeen de wederpartij, mede gelet op de wettelijke regels die op de overeenkomst betrekking hebben, zonder dat beding redelijkerwijs mocht verwachten; c. dat de gebruiker de bevoegdheid verleent een prestatie te verschaffen die wezenlijk van de toegezegde prestatie afwijkt, tenzij de wederpartij bevoegd is in dat geval de overeenkomst te ontbinden; d. dat de gebruiker van zijn gebondenheid aan de overeenkomst bevrijdt of hem de bevoegdheid daartoe geeft anders dan op in de overeenkomst vermelde gronden welke van dien aard zijn dat deze gebondenheid niet meer van hem kan worden gevergd;

13.

38

Art. 6:236 BW.


e. dat de gebruiker een ongebruikelijk lange of onvoldoende bepaalde termijn voor de nakoming geeft; f. dat de gebruiker of een derde geheel of ten dele bevrijdt van een wettelijke verplichting tot schadevergoeding; g. dat een de wederpartij volgens de wet toekomende bevoegdheid tot verrekening uitsluit of beperkt of de gebruiker een verdergaande bevoegdheid tot verrekening verleent dan hem volgens de wet toekomt; h. dat als sanctie op bepaalde gedragingen van de wederpartij, nalaten daaronder begrepen, verval stelt van haar toekomende rechten of van de bevoegdheid bepaalde verweren te voeren, behoudens voor zover deze gedragingen het verval van die rechten of verweren rechtvaardigen; i. dat voor het geval de overeenkomst wordt beëindigd anders dan op grond van het feit dat de wederpartij in de nakoming van haar verbintenis is tekort geschoten, de wederpartij verplicht een geldsom te betalen, behoudens voor zover het betreft een redelijke vergoeding voor door de gebruiker geleden verlies of gederfde winst; j. dat de wederpartij verplicht tot het sluiten van een overeenkomst met de gebruiker of met een derde, tenzij dit, mede gelet op het verband van die overeenkomst met de in dit artikel bedoelde overeenkomst, redelijkerwijze van de wederpartij kan worden gevergd; k. dat voor een overeenkomst bedoeld als hierboven onder j. een duur bepaalt van meer dan een jaar, tenzij de wederpartij de bevoegdheid heeft de overeenkomst telkens na een jaar op te zeggen; l. dat de wederpartij aan een opzegtermijn bindt die langer is dan drie maanden of langer dan de termijn waarop de gebruiker de overeenkomst kan opzeggen; m. dat voor de geldigheid van een door de wederpartij te verrichten verklaring een strengere vorm dan het vereiste van een onderhandse akte stelt; n. dat bepaalt dat een door de wederpartij verleende volmacht onherroepelijk is of niet eindigt door haar dood of ondercuratelestelling, tenzij de volmacht strekt tot levering van een registergoed.14 5.5.

Praktische aandachtspunten bij het gebruik van algemene voorwaarden

Mede met de bovenstaande juridische achtergronden in het achterhoofd, kunnen de volgende praktische aandachtspunten worden geformuleerd waarmee rekening gehouden dient te worden bij het gebruik van algemene voorwaarden. – Ter hand stellen; Hierboven is aangegeven dat algemene voorwaarden ter hand moeten worden gesteld. Dat betekent dat zij aan de wederpartij moeten worden toegezonden of in handen moeten worden gedrukt. In de praktijk wordt vaak aangenomen dat het ook voldoende is om te verwijzen naar algemene voorwaarden, die dan bijvoorbeeld zijn gedeponeerd bij de Kamer van Koophandel. Veel afnemers en leve-

14.

Art. 6:237 BW.

39


ranciers beseffen (nog) niet dat zo’n verwijzing onvoldoende is. Slechts in uitzonderlijke gevallen waarin terhandstelling echt niet mogelijk is, kan worden volstaan met een verwijzing naar gedeponeerde algemene voorwaarden of het op verzoek toezenden van de algemene voorwaarden.15 – Grote partijen; Grotere contractspartijen (bijvoorbeeld grote ondernemingen of de rijksoverheid) hanteren vaak hun algemene voorwaarden onder het motto ‘take it or leave it’. Dat wil zeggen dat zo’n contractspartij alleen een overeenkomst aangaat indien zijn algemene voorwaarden van toepassing worden verklaard op de overeenkomst, met uitsluiten van de algemene voorwaarden van de ander. Het is aan te bevelen om dan in het contract zelf aangepaste bepalingen op te nemen, waarbij dan tevens moet worden bepaald dat in het geval van strijdigheid de bepalingen van het contract voorrang hebben boven de bepalingen van de algemene voorwaarden. – Wie het eerst komt, het eerst maalt? In de praktijk komt het vaak voor dat beide partijen hun eigen algemene voorwaarden van toepassing verklaren. Een afnemer kan bijvoorbeeld een leverancier verzoeken een offerte uit te brengen. Op het briefpapier van de afnemer kan dan bijvoorbeeld al worden verwezen naar algemene voorwaarden.16 In de offerte van de leverancier worden vervolgens de algemene voorwaarden van de leverancier van toepassing verklaard. Stel dat de afnemer akkoord gaat met de offerte door de offerte te ondertekenen en/of een aparte overeenkomst op te stellen, dan is het de vraag welke algemene voorwaarden van toepassing zijn, die van de afnemer, die van de leverancier, of allebei? De wet bepaalt hierover het volgende. De overeenkomst komt tot stand door de aanvaarding van het aanbod.17 Verwijzen het aanbod en de aanvaarding daarvan naar verschillende algemene voorwaarden, dan komt aan de tweede verwijzing alleen werking toe als daarbij de andere algemene voorwaarden uitdrukkelijk niet van toepassing worden verklaard.18 Ervaring leert dat het soms moeilijk is vast te stellen welke verklaring als een ‘aanbod’ en welke als een ‘aanvaarding’ is te kwalificeren. Daarom is ook niet altijd eenvoudig vast te stellen aan welke verwijzing nou wel of geen werking toekomt. Het verdient daarom aanbeveling om, indien mogelijk en gewenst, de algemene voorwaarden van de ander expliciet van de hand te wijzen. – Onjuiste voorwaarden. Soms stelt een partij zonder juridische ondersteuning zelf zijn algemene voorwaarden op door algemene voorwaarden van anderen als voorbeeld te nemen. Dit kan tot gevolg hebben dat er algemene voorwaarden worden gehanteerd die eigenlijk zien op een andere vorm van dienstverlening of die bestaan uit vertaalde algemene voorwaarden die oorspronkelijk uitgaande van een ander rechtssysteem zijn geschreven (met name Anglo-Amerikaans recht). De op zodanige wijze

15. 16. 17. 18.

40

HR 1 oktober 1999, NJ 2000, 207 m.nt. JH (Geurtzen/Kampstaal). Het is overigens de vraag of hiermee is voldaan aan de vereiste terhandstelling. Art. 6:217 lid 1 BW. Art. 6:225 lid 3 BW. HR 13 juli 2001, NJ 2001, 497 (Hardstaal/Bovry).


opgestelde algemene voorwaarden hebben zelden de juridische werking die ermee wordt beoogd. Het verdient dan ook aanbeveling een jurist in te schakelen om van tevoren, dus niet met één enkele overeenkomst op het oog, een set algemene voorwaarden op te laten stellen.

41

HOOFDSTUK 6

Aansprakelijkheid

6.1.

Inleiding

Een belangrijk onderwerp van automatiseringscontracten, waar vaak veel onderhandelingstijd in gaat zitten, is het onderwerp aansprakelijkheid. De belangrijkste vraag waarover overeenstemming moet worden bereikt, is de vraag naar de verdeling van aansprakelijkheidsrisico’s. Er zijn verschillende soorten aansprakelijkheid, er zijn verschillende soorten gronden van aansprakelijkheid, en er zijn verschillende soorten schade. Op deze soorten, gronden en schades wordt hieronder nader ingegaan. Het is raadzaam erop te letten dat in contracten altijd bepalingen zijn opgenomen die deze drie onderwerpen regelen. Bovendien is het raadzaam bedragen op te nemen die een bovengrens stellen aan de omvang van de schade die moet worden vergoed. Indien in het contract geen bepalingen worden opgenomen over de gronden van aansprakelijkheid, de soort schade en maximumbedragen, is de partij die onzorgvuldig handelt of toerekenbaar tekort schiet in de nakoming van de overeenkomst, voor alle soorten schade (ook de gevolgen vermogensschade) en voor de volle omvang van de schade aansprakelijk. Dit is niet aan te bevelen. Er zijn maar weinig bedrijven die een dergelijke claim aankunnen. Soorten aansprakelijkheid zijn bijvoorbeeld beroeps-, bedrijfsaansprakelijkheid en bestuurdersaansprakelijkheid, producten dienstaansprakelijkheid, interne en externe aansprakelijkheid, en risico- en schuldaansprakelijkheid.1 Belangrijker dan de soorten aansprakelijkheid, zijn de gronden van aansprakelijkheid. Er zijn twee (hoofd)gronden van aansprakelijkheid: – de aansprakelijkheid op grond van het toerekenbaar niet nakomen van afspraken (wanprestatie);2 en – de aansprakelijkheid op grond van een onrechtmatige daad. De eerste hoofdgrond vloeit voort uit contractuele afspraken die partijen onderling hebben gemaakt. De tweede hoofdgrond vloeit voort uit onzorgvuldig handelen. De soorten schade zijn vervolgens in te delen naar directe en indirecte schade, materiële schade en gevolgschade. Het is belangrijk om in het contract de soorten schade duidelijk te definiëren, zodat er zo min mogelijk interpretatieruimte is. Bij de aansprakelijkheid op grond van wanprestatie en aansprakelijkheid op grond van onrechtmatige daad, wordt hieronder iets langer stilgestaan.

1. 2.

Duthler 1995, blz. 63 e.v. Art. 6:74 BW.

43

Aansprakelijkheid

6.2.

Aansprakelijkheid op grond van wanprestatie

Aansprakelijkheid op grond van wanprestatie3, vloeit voort uit het toerekenbaar niet nakomen van afspraken. De vereisten voor deze vorm van aansprakelijkheid zijn: – Tekortkoming; De tekortkoming kan zowel bestaan uit het geheel of gedeeltelijk uitblijven van nakoming, als uit niet-tijdige of niet-behoorlijke nakoming. – Toerekenbaarheid; Elke tekortkoming is toerekenbaar, tenzij de schuldenaar aantoont dat zij hem niet kan worden toegerekend. De bewijslast rust op de schuldenaar. – Schade en causaal verband. Er moet enige vorm van schade zijn of worden geleden en de tekortkoming moet een noodzakelijke voorwaarde zijn voor de schade. De bewijslast van de schade en het causale verband tussen tekortkoming en schade rust op de schuldeiser. 6.3.

Aansprakelijkheid op grond van onrechtmatige daad

Als onrechtmatige daad worden aangemerkt: – een inbreuk op een recht; – een doen of nalaten in strijd met een wettelijke plicht; – een doen of nalaten in strijd met hetgeen volgens ongeschreven recht in het maatschappelijk verkeer betaamt (zorgvuldigheid). Een voorbeeld van een inbreuk op een recht is de schending van het recht op privacy of een inbreuk op intellectuele eigendomsrechten. Een voorbeeld van een doen of nalaten in strijd met een wettelijke plicht is het niet treffen van passende beveiligingsmaatregelen. Van een doen of nalaten in strijd met de maatschappelijke zorgvuldigheid is bijvoorbeeld sprake als een bepaalde actie niet bij wet is voorgeschreven, maar wel verwacht mocht worden van een zorgvuldig handelende dienstverlener. De vereisten voor aansprakelijkheid op grond van onrechtmatige daad zijn onrechtmatigheid, toerekenbaarheid van de daad aan de dader, schade, causaal verband tussen daad en schade en relativiteit.4 6.4.

Soorten schade

Schade bestaat in verschillende soorten en maten. De soorten schade die het meest voorkomen in automatiseringscontracten zijn zaakschade, letselschade, vermogensschade als gevolg van zaakschade of letselschade en zuivere vermogensschade.5 Onder zaakschade wordt wel verstaan de schade veroorzaakt door fysieke beschadiging of vernietiging van een zaak. Van letselschade is sprake in geval van verwonding of overlijden van personen. Van vermogensschade als gevolg van zaak-

3. 4.

5.

44

De wet spreekt van een toerekenbare tekortkoming in de nakoming van een verbintenis. Relativiteit houdt in dat er geen verplichting tot schadevergoeding bestaat, wanneer de geschonden norm niet strekt tot bescherming tegen schade zoals de benadeelde die heeft geleden. Blok e.a. 2004, blz. 57.

Aansprakelijkheid

schade of letselschade is bijvoorbeeld sprake in geval van gederfde inkomsten doordat men arbeidsongeschikt is geworden. Onder zuivere vermogensschade verstaat men doorgaans geleden verliezen en gederfde winst, waarbij niemand gewond is geraakt noch iets kapot is gegaan. In automatiseringscontracten worden ook wel de termen directe en indirecte schade, materiële en immateriële schade, gevolgschade en vermogensschade gebruikt. De indeling in soorten schades is geen strikte indeling. De verschillende soorten overlappen elkaar en worden door elkaar gebruikt. Het is belangrijk om in een contract precies te omschrijven wat onder een bepaalde soort schade wordt verstaan, zodat daar geen misverstanden over kunnen ontstaan. 6.5.

Beheersing van aansprakelijkheidsrisico’s

Hoe beter contractspartijen hun verantwoordelijkheden en verplichtingen ten opzichte van elkaar beschrijven en hun afspraken concreet en eenduidig vastleggen, hoe gemakkelijker risico’s beheerst kunnen worden. Een eerste stap daartoe is dan ook dat verantwoordelijkheden en verplichtingen tussen contractspartijen helder afgebakend worden. Daarnaast wordt de vraag of er sprake is van aansprakelijkheid in de regel beoordeeld naar de mate van zorgvuldigheid die in acht is genomen. Zorgvuldigheid wordt vaak getoetst aan de ‘inspanning van een redelijk handelend vakgenoot’. Uit deze maatstaf kan een aantal verplichtingen voor de opdrachtnemer worden afgeleid: 1. Vakbekwaamheid. Hierbij moet worden gedacht aan de via opleidingen verworven kennis, de hoeveelheid praktische ervaring en aan de ‘state of the art’. De leverancier of dienstverlener zullen de nieuwste ontwikkelingen kritisch moeten beschouwen; 2. Eigen verantwoordelijkheid. Komt een leverancier tot de conclusie dat hij de door de afnemer voorgestane richting niet voor zijn rekening wenst te nemen, dan zal hij dit duidelijk moeten maken aan de afnemer; 3. De informatieplicht. De leverancier moet de afnemer zo volledig mogelijk en op een voor deze begrijpelijke wijze informeren over (de gevolgen van) de automatisering of het automatiseringsproject. 4. De waarschuwingsplicht. De leverancier dient de afnemer te waarschuwen voor de risico’s en bijzonderheden verbonden aan de gekozen ICT-oplossing. 5. Voldoen aan weten regelgeving. Het lijkt voor de hand te liggen, maar het voldoen aan weten regelgeving is niet altijd vanzelfsprekend en is een blijk van zorgvuldigheid. Dat geldt vooral voor die weten regelgeving, die tevens van invloed is op de inrichting van de organisatie en dienstverlening van de leverancier.6

6.

Een voorbeeld daarvan is de Wet bescherming persoonsgegevens (Wbp) of wetgeving rond informatiebeveiliging.

45

Aansprakelijkheid

Het risico om aansprakelijk te worden gesteld kan zo goed mogelijk worden gereduceerd of beheerst door bovengenoemde verplichtingen in acht te nemen. Bovenstaande verplichtingen vormen in feite een nadere invulling van het criterium van de ‘inspanningen van een redelijk handelend vakgenoot’, het criterium op basis waarvan kan worden vastgesteld of er sprake is van beroepsaansprakelijkheid. Het is het criterium waarmee vooral de opdrachtnemer, de dienstverlener, rekening moet houden. Hieronder worden voor alle contractpartijen aanbevelingen op een rij gezet om aansprakelijkheidsrisico’s zo goed mogelijk te kunnen beheersen en schade te voorkomen. Hieronder worden de belangrijkste aanbevelingen gegeven hoe aansprakelijkheidsrisico’s zo goed mogelijk kunnen worden beheerst. 1. Baken eenduidig en zo concreet mogelijk taken, verantwoordelijkheden en verplichtingen af; 2. Door het zo eenduidig en concreet mogelijk afbakenen van taken, verantwoordelijkheden en verplichtingen en dit schriftelijk vast te leggen in contracten, kan in de toekomst uitvoerige discussie worden vermeden op het moment dat er iets misgaat en schade ontstaat. Een goed contract legt de verwachtingen die partijen van elkaar mogen hebben vast, en zorgt daarmee voor voorspelbaarheid; 3. Maak afspraken over procedures. Voor de onderwerpen waarover op voorhand geen helderheid is te verschaffen, maak afspraken over de te volgende procedure op het moment dat die helderheid nodig is; 4. Maak aansprakelijkheidsrisico’s inzichtelijk. Elke partij zal voor zichzelf de aansprakelijkheidsrisico’s inzichtelijk moeten maken; 5. Maak afspraken over een evenwichtige verdeling van aansprakelijkheidsrisico’s. Partijen moeten afspraken met elkaar maken over de verdeling van aansprakelijkheidsrisico’s. Deze verdeling moet terug komen in de af te sluiten contracten. Het is aan te bevelen te zorgen voor een evenwichtige risicoverdeling. Op het moment dat er onevenredig veel risico’s bij een bepaalde partij worden gelegd, is dat geen stimulans voor het zorgvuldig nakomen van verplichtingen door die partij. Een goed contract is ook een evenwichtig contract; 6. Maak afspraken over bewijslastverdeling. Mocht er onverhoopt iets misgaan, en er ontstaat schade, maak afspraken over wie welke bewijzen moet leveren; 7. Zorg voor een helder contract en goede uitvoerbaarheid. Mocht het onverhoopt toch een keer tot een geschil komen, en er volgt een juridische procedure bij een rechter, dan is het van belang dat ook een rechter gemakkelijk uit het contract kan afleiden wat de rechten en plichten van partijen zijn en wat de bedoeling van het contract was. Ook is het van belang dat het contract leidt tot een goede uitvoerbaarheid. Alleen als een contract ook daadwerkelijk en goed uitvoerbaar is, zal het tot nakoming leiden. Op het moment dat er afspraken worden vastgelegd in een contract, die door een partij moeilijk zijn na te komen, dan is de kans groot dat dat tot niet nakoming leidt en mogelijk schade veroorzaakt; 8. Zorg voor aantoonbare naleving van toepasselijke weten regelgeving. Zoals hiervoor is gezegd, vloeit aansprakelijkheid voort uit het toerekenbaar niet-nakomen van afspraken of een onrechtmatige daad. Van dit laatste is sprake op het moment dat in strijd met een wettelijke plicht of onzorgvuldig is gehandeld. Door te zor-

46

Aansprakelijkheid

gen voor het aantoonbaar naleven van toepasselijke weten regelgeving kan aansprakelijkheid wegens het in strijd handelen met een wettelijke plicht worden voorkomen. Leg wel schriftelijk vast welke maatregelen zijn getroffen om aan de wettelijke plichten te voldoen; 9. Speciaal voor leveranciers: zorg verder voor de inrichting van een zorgvuldige dienstverlening. Ook hiervoor geldt dat de inrichting en schriftelijke vastlegging van procedures en maatregelen daarbij heel belangrijk zijn. Zo kan tevens worden aangetoond dat partijen alles in het werk hebben gesteld om zorgvuldig te handelen. Sluit zo nodig een aansprakelijkheidsrisicoverzekering, bij voorkeur een beroepsaansprakelijkheidsverzekering. Er zijn verschillende soorten aansprakelijkheidsverzekeringen, waaronder een bedrijfs- en beroepsaansprakelijkheidsverzekering. Een bedrijfsaansprakelijkheidsverzekering (AVB) verzekert de aansprakelijkheid van de verzekerden voor door derden geleden schade. Deze schade bestaat uit letselof zaakschade, danwel gevolgschade voortvloeiende uit de letselof zaakschade. Een beroepsaansprakelijkheidsverzekering (BAV) verzekert de aansprakelijkheid van de verzekerden voor door derden geleden schade als gevolg van beroepsfouten van verzekerden. Deze schade bestaat uit vermogensschade, niet voortvloeiende uit letselof zaakschade. Onder fout wordt verstaan: vergissingen, onachtzaamheden, nalatigheden, verzuimen, onjuiste adviezen, verkeerde inzichten maar ook ontoereikendheid van de bekwaamheden nodig voor het uitvoeren van de werkzaamheden. De meeste schade die ontstaat zal het gevolg zijn van fouten bij de uitoefening van beroepswerkzaamheden, en zal bestaan uit vermogensschade. Vandaar dat een beroepsaansprakelijkheidsverzekering het meest passend is.

47

HOOFDSTUK 7

Geschillen

7.1.

Inleiding

Het kan voorkomen dat naar aanleiding van een automatiseringstraject een geschil ontstaat tussen de afnemer en de leverancier. Dat kan gebeuren tijdens de implementatie van bijvoorbeeld hardware of software, maar ook na afloop. Een belangrijke oorzaak van geschillen is dat vaak onvoldoende wordt gespecificeerd waaraan de op te leveren producten dienen te voldoen. Als hierover onduidelijkheid bestaat, kunnen de verwachtingen van de afnemer en de leverancier uiteen gaan lopen. Een tweede factor die een belangrijke rol kan spelen bij het ontstaan van geschillen is een gebrekkige communicatie tussen afnemer en leverancier. Niet alleen kunnen daardoor eveneens afwijkende verwachtingen worden gevormd, ook ontstaat daardoor een zekere onwil. De communicatie wordt als het ware steeds ‘stroever’. Een automatiseringstraject kan een langdurend, ingewikkeld project zijn. Bovendien heeft het vaak gevolgen voor de bedrijfsvoering van de afnemer. Een geschil kan daarom het automatiseringstraject verlammen en daarmee ook negatieve gevolgen hebben voor de bedrijfsvoering van de afnemer. Wanneer een geschil escaleert, is het soms raadzaam een professionele geschilbeslechter in te schakelen. Dit kan door een procedure aanhangig te maken bij de rechter. Er zijn echter ook andere wijzen van geschilbeslechting die in een voorkomend geval een betere oplossing kunnen bieden. Het gaat dan met name om de procedures die kunnen worden gevoerd bij de Stichting Geschillenoplossing Organisatie en Automatisering (SGOA).1 Vaak is de keuze voor een bepaalde geschilbeslechter (de rechter of de SGOA) al vastgelegd in het contract of in de algemene voorwaarden van één van beide partijen. 7.2.

De gang naar de rechter

De gang naar de rechter is eigenlijk alleen aan te raden wanneer afnemer en leverancier er echt samen niet meer uitkomen. De procedure voor de rechter kent beperkingen. De procedure is niet gericht op het bereiken van overeenstemming of het overtuigen van de ander. Het geschil heeft voor de rechter vaak het karakter gekre-

1.

Zie [http://www.sgoa.org/].

49

Geschillen

gen van een loopgravenoorlog: geen van beide partijen is nog bereid iets toe te geven. Intussen is er een product opgeleverd dat niet voldoet aan de verwachtingen van de afnemer en waar hij in het kader van zijn bedrijfsvoering niet mee uit de voeten kan. Een procedure voor de rechter brengt zelden met zich mee dat een automatiseringstraject tot een goed einde worden gebracht. Dat hoeft ook niet altijd. Het is namelijk wel de geëigende manier om een ongedaanmaking (ontbinding) van de overeenkomst of een schadevergoeding te eisen. Dit was voor partijen echter uiteraard niet de reden voor het aangaan van een overeenkomst. 7.3.

Alternatieve geschillenbeslechting: de Stichting Geschillenoplossing Organisatie en Automatisering (SGOA)

De SGOA is een onafhankelijke instelling waaraan verschillende deskundigen zijn verbonden aan wie een geschil kan worden voorgelegd. Anders dan bij de rechter, hoeft men zich bij de SGOA niet te laten vertegenwoordigen door een advocaat, al verdient het bij complexe zaken aanbeveling een advocaat of een jurist ter ondersteuning in te schakelen. De SGOA biedt verschillende wijzen van geschilbeslechting. Afhankelijk van onder meer de waarde van het belang dat aan een geschil is verbonden, kan uit verschillende wijzen van geschilbeslechting een keuze worden gemaakt. De SGOA biedt de volgende wijzen van geschilbeslechting: – eADR; eADR (electronic Alternative Dispute Resolution) is een snelle procedure waarin op elektronische wijze, op afstand, wordt gecommuniceerd met een deskundige van de SGOA. – Bindend advies; Bij deze procedure draagt de SGOA een adviseur voor. Indien beide partijen hiermee akkoord gaan, stelt de adviseur in overleg de te voeren procedure vast. Het verloop van een bindend adviesprocedure verschilt daarom per geschil. Een adviseur kan bijvoorbeeld voorstellen een aantal zittingen te houden, maar hij kan ook alles schriftelijk afdoen. – Arbitrage; Arbitrage is de meest formele procedure van de SGOA en doet daarom denken aan een procedure voor de ‘normale’ rechter. Partijen dienen zich bij arbitrage te laten bijstaan door een raadsman. Er zijn drie vormen van arbitrage: de normale arbitrage, spoed arbitrage en kort geding arbitrage. Een bindend vonnis wordt gegeven door drie arbiters. – Mediation. Mediation is niet zozeer gericht op een harde confrontatie tussen twee partijen, maar op het bemiddelen bij een geschil om zo een praktische oplossing mogelijk te maken. In tegenstelling tot de gang naar de rechter en de arbitrage, waarbij strijdende partijen zich veelal ‘ingraven’ en geen duimbreed willen toegeven, wordt bij mediation in zekere zin het geschil niet zozeer strikt juridisch ingestoken. Dit brengt vaak een praktische oplossing dichterbij.

50

Geschillen

De voordelen van een procedure bij de SGOA boven een procedure bij de civiele rechter, zijn dat deze gewoonlijk minder tijd en kosten met zich meebrengt en dat het geschil door deskundigen wordt beoordeeld.

51

LITERATUUR

Van Asbroek & De Coster B. van Asbroek & T. de Coster, ‘Outsourcing en intellectuele eigendom’, Computerrecht 2005/4, blz. 186-189. Blok e.a. 2004 P.H. Blok e.a, ‘Overeenkomsten inzake informatietechnologie’, Den Haag: SDU Uitgevers 2004. Brunt & Westerbrink-Veenendaal 2004 G. Brunt & B. Westerbrink-Veenendaal, ‘(IT) Outsourcing’, Den Haag: Elsevier Juridisch 2004. Duthler 1995 A.W. Duthler, ‘Beheersing van automatiseringsrisico’s. Het belang van (goede) verzekeringscontracten’, Alphen aan den Rijn: Samsom Bedrijfsinformatie 1995. De Graaf 2006 T.J. de Graaf, ‘Exoneraties in (ICT-)contracten tussen professionele partijen’ (diss. Leiden), Den Haag: Kluwer 2006. Hofkens 2005 J. Hofkens, ‘Het lot van het personeel bij IT-outsourcing’, Computerrecht 2005/4, blz. 202-208. ICT Modelcontracten J.M.A. Berkvens e.a., ‘ICT Modelcontracten. Modellen voor de praktijk’, Deventer: Kluwer. Janse de Jonge 2004 J.J.J. Janse de Jonge, ‘Arbeidsrechtelijke aspecten van outsourcing’, in: Brunt & Westerbrink-Veenendaal 2004, blz. 79-104. Jongen 2004 H. Jongen, ‘Inleiding Outsourcing’, in: Brunt & Westerbrink-Veenendaal 2004, blz. 11-22.

53

Literatuur

Jongen 2005 H. Jongen, ‘Offshoring – enkele aandachtspunten’, Computerrecht 2005/4, blz. 197-201 Khodabaks 2004 A. Khodabaks, ‘De outsourcing-overeenkomst’, in: Brunt & Westerbrink-Veenendaal 2004, blz. 23-44. Van der Klaauw-Koops & Stuurman 1997 F.A.M. van der Klaauw-Koops & C. Stuurman, ‘Computercontracten, automatisering en aansprakelijkheid’, in: H. Franken, H.W.K. Kaspersen & A.H. de Wild, Recht en computer, Deventer: Kluwer 1997, blz. 72-121. Koelman 2000 K.J. Koelman, ‘Terug naar de bron: open source en copyleft’, AMI 2000/8, blz. 149155. Van Lingen 2002 N. van Lingen, ‘Auteursrecht in hoofdlijnen’, Groningen: Martinus Nijhoff 2002. Loos 2001 M.B.M. Loos, ‘Algemene voorwaarden. Beschouwingen over het huidige recht en mogelijke toekomstige ontwikkelingen’, Den Haag: Boom Juridische uitgevers 2001. Moerel & Van Reeken 2005 E.M.L. Moerel & B.L.P. van Reeken, ‘Demand management: dé sleutel voor succes op lange termijn’, Computerrecht 2005/4, blz. 181-185. Noorda 2004 C. Noorda, ‘Outsourcing en intellectuele eigendom’, in: Brunt & WesterbrinkVeenendaal 2004, blz. 63-78. Rapport juridische werkgroep Platform Outsourcing Nederland 2006 Juridische aspecten van outsourcing – Rapportage werkgroep juridisch PON, [http://www.platformoutsourcing.nl/werkgroepen/juridische aspecten bij outsourcing.pdf], 9 januari 2006. Rinzema 2005 W.F.R. Rinzema, ‘De juridische kwalificatie van outsourcingovereenkomsten’, Computerrecht 2005/4, blz. 173-176. Thole, Scholten & Seinen 2005 E. Thole, R. Scholten & W. Seinen (red.), ‘Open Source Software: Een verkenning naar de juridische aspecten van open source software’, Den Haag: Elsevier Juridisch 2005.

54

Automatiseringscontracten

Recommend Documents