1. Inleiding

 

De meeste contracten verdwijnen na ondertekening in de schuif om daarna nooit meer boven water te komen. Waarom zijn ze dan nodig? Wel, zie ze als een vorm van verzekering. Zolang de samenwerking tussen partijen vlot verloopt, is er geen reden om contractuele bepalingen af te dwingen. De uitvoering van de overeenkomst verloopt naar wens en beide partijen zijn dan ook maar al te graag flexibel. Strafbedingen voor overschrijding van leveringstermijnen worden dan zelden uitgevoerd. Het is pas wanneer de samenwerking mank loopt dat contractuele afspraken (de spreekwoordelijke kleine lettertjes) plots belangrijk worden. En dan kunnen uw belangen in het contract maar beter goed zijn verwoord. Een overeenkomst strekt partijen immers tot wet (art. 1134 BW).

 

Een andere reden om een formeel contract te sluiten is rechtszekerheid. Partijen werken immers niet toevallig samen. Wanneer ze geen schriftelijke overeenkomst hebben, ligt een mondelinge/stilzwijgende overeenkomst aan de basis van hun samenwerking. Deze kan worden bewezen op basis van geschriften zoals brieven, faxen, e-mails, edm. en zelfs op basis van de wijze waarop de samenwerking in de praktijk verliep. Men kan ( financieel) voor uitermate onaangename verrassingen komen te staan wanneer bv. geconstateerd wordt dat men ongewild een arbeidsrelatie of een concessie van alleenverkoop heeft aangegaan. Voorafgaandelijke bezinning over de aard van de relatie van de samenwerking en goede contractuele afspraken verminderen de kans op dergelijke onaangename verrassingen drastisch.

 

2. Overeenkomsten in het algemeen

 

A. De overeenkomst als rechtshandeling

 

Een overeenkomst is een rechtshandeling tussen twee of meer personen waarbij een partij jegens een andere zich verbindt iets te doen, iets niet te doen (art. 1142-1145 BW) of iets te geven (art. 1136-1141 BW).

 

De meeste overeenkomsten zijn wederkerig. Dit wil zeggen dat beide partijen verplichtingen opnemen jegens de andere partij.

 

Overeenkomsten steunen op de wilsovereenstemming tussen partijen. De wil van de partijen bepaalt de inhoud van de overeenkomst. Overeenkomsten zijn dan ook zelden te nemen of te laten. Ze staan open voor onderhandeling, wat een diligente contractspartij dan ook maar beter kan doen. Wanneer er problemen zouden opduiken met de afspraken, maakt een contractuele clausule vaak een wereld van verschil. Wanneer bv. geen contractuele beperking van aansprakelijkheid is voorzien, is een partij volgens het gemene recht gehouden alle voorzienbare schade te vergoeden (art. 1149 – 1151 BW). En dit kan snel oplopen. Een leverancier die contractueel zijn aansprakelijkheid correct heeft beperkt, is slechts aansprakelijk tot het overeengekomen bedrag, bv. de waarde van het contract. Daarom is het voor de leverancier nuttig zijn aansprakelijkheid contractueel te beperken. De onderhandelingspositie van sommige partijen is zo sterk dat zij hun standaardvoorwaarden kunnen opleggen. Dit is bv. vaak het geval bij de huur van datatransmissielijnen en overheidsopdrachten. In dergelijk geval heeft de wederpartij enkel de keuze om al dan niet toe te treden. Dergelijke overeenkomst noemt men toetredingscontracten. In geval van twijfel worden zij geïnterpreteerd tegen de opsteller ervan (art. 1162 BW).

 

Soms laat de wet de partijen geen keuzevrijheid en legt zij een bepaalde regelgeving op. In dergelijk geval spreken we van dwingend recht. Dat is bv. het geval voor arbeidsovereenkomsten, waarvoor de belangrijkste bepalingen zijn vastgelegd in de wet op de arbeidsovereenkomsten (Wet betreffende de arbeidsovereenkomsten dd. 3 juli 1978). Vaak echter is de wet niet van dwingende aard, maar geldt zij slechts voor zover partijen niet anders zijn overeengekomen. In dergelijk geval spreken we van aanvullend recht.

 

De overeenkomst ontstaat door de aanvaarding van een aanbod. Dit valt niet noodzakelijk samen met de ondertekening van een schriftelijk document. De aanvaarding kan, zeker tussen handelaars, op diverse wijzen gebeuren, bv. door een handdruk. Het schriftelijk document is wel zeer nuttig voor het bewijs van de overeenkomst. Hij die de uitvoering van een verbintenis vordert, moet het bestaan daarvan immers bewijzen (art. 1315 BW) wat zonder schriftelijk bewijs uiteraard zeer moeilijk is.

 

Geldig aangegane overeenkomsten verbinden partijen wederzijds. Zij strekken partijen tot wet (art. 1134 BW).

 

B. Voorwaarden

 

Om geldig te zijn gesloten, moeten overeenkomsten voldoen aan volgende vier voorwaarden (art. 1108 BW):

 

1. De partijen moeten hun volwaardige toestemming geven:

 

Wanneer een partij niet haar volwaardige toestemming heeft gegeven, is de overeenkomst in principe nietig. Dit kan door een verkeerde voorstelling van zaken  of door beïnvloeding door externe factoren. We spreken dan van een wilsgebrek. De wilsgebreken zijn dwaling, bedrog, geweld en benadeling.

 

2. De partijen moeten bekwaam zijn:

 

Partijen die niet bekwaam zijn tot het stellen van rechtshandelingen kunnen geen geldige overeenkomst sluiten. De belangrijkste groep zijn de minderjarigen (personen jonger dan 18 jaar). Toch dient deze onbekwaamheid te worden genuanceerd. Minderjarigen stellen immers dagdagelijks rechtshandelingen (zoals het kopen van een brood of het openen van een gratis e-mail account). De concrete handeling zal worden beoordeeld op basis van volgende drie vragen:

 

– Heeft de minderjarige reeds onderscheidingsvermogen (een zesjarige zal dit minder snel hebben dan een vijftienjarige)?

 

– Betreft het een dagelijkse handeling of een handeling met verregaande gevolgen?

 

– Werd de minderjarige benadeeld?

 

3. Het voorwerp van de overeenkomst moet bepaalbaar zijn:

 

Het voorwerp van een overeenkomst is bepaalbaar wanneer de overeenkomst voldoende objectieve elementen bevat waardoor het kan worden bepaald zonder bijkomend akkoord tussen de partijen.

 

4. De oorzaak van de overeenkomst moet geoorloofd zijn:

 

De oorzaak is ongeoorloofd wanneer zij door de wet verboden is of wanneer zij strijdig is met de goede zeden of de openbare orde.

 

Wanneer de overeenkomst geacht wordt nietig te zijn, heeft dit tot gevolg dat partijen moeten teruggeplaatst worden in de situatie waarin ze zich bevonden voor het afsluiten van de overeenkomst. In de praktijk zal dit vaak gepaard gaan met het toekennen van een financiële vergoeding.

 

C. De onderhandeling van de overeenkomst

 

Vanaf het ogenblik dat de overeenkomst wordt gesloten, zijn de partijen gebonden door de voorwaarden ervan. Maar ook voorafgaand gedurende de precontractuele fase, rusten er verplichtingen op de partijen. De onderhandelingen dienen immers te goeder trouw te worden gevoerd. Bovendien rust op beide partijen een wederzijdse informatieplicht. De leverancier dient de klant goed te informeren van wat hij kan (en niet kan) leveren en de klant dient de leverancier te informeren betreffende zijn wensen en noden. Voor grotere of meer ingewikkelde projecten, is het nuttig om deze recontractuele informatieplicht te contractualiseren in de preambule of in een bepaling betreffende  de informatieplicht. De bewoording hiervan kan een belangrijke impact hebben op de verplichtingen van de partijen.

 

Schendingen van de precontractuele aansprakelijkheid, worden beteugeld als onrechtmatige daad. De onrechtmatige daad ligt vervat in artikelen 1382 en 1383 BW: “Elke daad van de mens, waardoor aan een abder schade wordt veroorzaakt, verplicht degene door wiens schuld de schade is ontstaan, deze te vergoeden. Ieder is aansprakelijk niet alleen voor de schade welke hij door zijn daad, maar ook voor die welke hij door zijn nalatigheid of door zijn onvoorzichtigheid heeft veroorzaakt.”

 

Voor de toepassing hiervan moeten volgende drie voorwaarden vervuld zijn:

 

– er moet schade zijn;

 

– de schade is het gevolg van een toerekenbare fout;

 

– er is een oorzakelijk verband tussen de fout en de schade.

 

Er is sprake van een fout indien de algemene zorgvuldigheidsnorm is geschonden. Dit wil zeggen dat de veroorzaker van de schade niet heeft gehandeld zoals van een normaal zorgvuldig persoon (een bonus pater familias) mag worden verwacht. De zorgvuldigheidsnorm wordt toegepast op de concrete omstandigheden van het geval. Zo wordt voor leveranciers die specialist zijn in hun materie, een strengere norm toegepast dan voor nietspecialisten.

 

D. Naleving en remedie

 

Zoals hierboven uiteengezet, strekt een overeenkomst partijen tot wet. Contracten dienen te goeder trouw te worden uitgevoerd. Een contractpartij die haar verplichtingen niet naleeft pleegt contractbreuk wanneer aan volgende twee voorwaarden is voldaan: (i) een contractuele verplichting werd niet  uitgevoerd en (ii) de tekortkoming is aan de contractspartij te wijten. Dit laatste zal niet het geval zijn in geval van overmacht (bv. Sony komt haar leveringsplicht niet na wegens een tsunami in Japan) of indien de oorzaak van het niet uitvoeren van de verplichting ligt bij de andere contractspartij (bv. de klant voorziet niet tijdig de benodigde hardware voor de installatie van de software).

 

Een nalatige contractspartij dient te worden aangespoord door middel van een ingebrekestelling waarin de grieven en de mogelijke consequenties duidelijk worden uiteengezet. In deze ingebrekestelling dient de nalatige partij een redelijke termijn te worden toegekend om alsnog te presteren. Enkel wanneer het alsnog presteren niet meer mogelijk is of absoluut geen zin meer heeft, dient niet ingebreke te worden gesteld. Let wel op. Het is aan de rechter om hier achteraf over te oordelen.

 

Wanneer de contractsbreuk bewezen is, heeft de benadeelde partij volgende mogelijkheden:

 

– vordering van de uitvoering in natura (voor zover dit nog mogelijk is);

 

– indien de uitvoering in natura niet mogelijk is of deze de schade niet volledig herstelt, kan schadevergoeding worden gevorderd;

 

– de ontbinding van de overeenkomst kan worden gevorderd;

 

– de eigen verplichtingen kunnen worden gestaakt (bv. de leverancier staakt de leveringen bij niet-betaling door de klant).

 

De schuldeiser heeft niet de keuze om een vervangende schadevergoeding te kiezen boven de uitvoering van de overeenkomst. In principe dienen overeenkomsten uitgevoerd te worden in natura. Dit wil zeggen dat de schuldenaar zijn contractuele verplichtingen dient uit te voeren. Vandaar dat de ingebrekestelling (de ultieme aansporing om alsnog te presteren) zo belangrijk is.

 

Wanneer de uitvoering in natura onmogelijk is of wanneer de schuldeiser daardoor niet volledig is vergoed (bv. in geval van laattijdige uitvoering), kan de rechter hem een vervangende schadevergoeding toekennen. De vervangende schadevergoeding zal worden berekend door de vergelijking van de situatie waarin de schuldeiser zich zou hebben bevonden zo het contract naar behoren zou zijn uitgevoerd, met de situatie waarin de schuldeiser zich nu bevindt ingevolge de niet of slechts gedeeltelijke uitvoering van de verbintenis.Belangrijk te noteren is dat de vergelijking niet wordt gemaakt met de situatie wanneer de overeenkomst niet zou zijn gesloten. De maat van vergelijking is de correcte uitvoering van de overeenkomst.

 

Maar de schuldeiser heeft niet enkel recht op vervangende schadevergoeding: hij heeft recht op vergoeding van zijn volledige schade die voorzienbaar was bij de contractsluiting (art. 1150 BW) en die een onmiddellijk en rechtstreeks gevolg is van de niet-uitvoering van het contract (art. 1151 BW). Dit houdt eveneens alle andere schade in zoals de redelijke kosten die hij heeft moeten maken om de schade te beperken, geleden verliezen, gederfde winsten en dergelijke meer. Schadeposten die door de rechtspraak reeds werden erkend, zijn onder meer materiaalschade aan hardware, schade aan het netwerk, kosten voor noodzakelijke wijzigingen aan hardware, extra arbeidsuren, kosten voor noodprocedures, vergoedingen en strafsancties aan klanten, schade aan reputatie, kosten voor het weder samenstellen van data, …

 

De waarde van de verbintenis waartoe de schuldenaar zich heeft verbonden heeft geen directe invloed op de begroting van de schade. Ook software die ter beschikking wordt gesteld voor een kleine of marginale vergoeding, kan aanleiding geven tot een enorme schadeclaim. Daarom is het steeds aangewezen om contractueel zijn aansprakelijkheid te beperken, ook al is de waarde van het contract gering. De aansprakelijkheid wordt immers gemeten aan de hand van de voorzienbare schade en niet aan de waarde van de overeenkomst of de financiële draagkracht van de partijen.

 

Wat hoger werd uiteengezet is het wettelijke regime. Dit is evenwel niet van dwingende aard. Contractspartijen kunnen hun aansprakelijkheid contractueel beperken. Dit kan op verschillende wijzen gebeuren, bv. door het kwalificeren van de aard van de fout die de aansprakelijkheid veroorzaakt (zoals het beperken van de aansprakelijkheid tot grote en opzettelijke fouten), door het bepalen van een maximale grens van de aansprakelijkheid (bv. tot 100.000 € of tot de waarde van het contract), door het uitsluiten van indirecte schade of gevolgschade en dergelijke meer.Om geldig te zijn dienen aansprakelijkheidsbeperkingen te voldoen aan drie voorwaarden. Indien zij hier niet aan voldoen, riskeren ze nietig en onafdwingbaar te worden bevonden:

 

i. Geen inbreuk op wettelijke bepalingen: Sommige wetten voorzien in een aansprakelijkheid en zijn van dwingend recht. Dit geldt bv. voor gekende verborgen gebreken, productaansprakelijkheid en dergelijke meer.

 

ii. De overeenkomst mag niet zonder voorwerp worden: Beperkingen van aansprakelijkheid mogen de overeenkomst niet zonder voorwerp maken. Dit zou het geval zijn mochten zij betrekking hebben op essentiële verplichtingen onder de overeenkomst en de schuldeiser zonder enige rechten of middelen laten om de nakoming af te dwingen. Een voorbeeld hiervan is de clausule in een contract voor het ontwikkelen van foto’s, welke bepaalt dat de klant in geval van verlies of schade aan het origineel zal worden vergoed met een blanco rolletje.

 

iii. Misleiding of opzettelijke fout: Niemand kan zichzelf exonereren voor bedrog of moedwillige fouten. De moedwillige fout heeft betrekking op het voornemen de handeling te stellen en niet op de gevolgen ervan. Een voorbeeld hiervan is het negeren van een rood licht. De dader reed moedwillig door het stoplicht, doch bedoelde niet de gevolgen van zijn handelen, het aanrijden van een fietser. Een zware fout is geen opzettelijke fout. Men kan zich dan ook rechtsgeldig exonereren voor zware fouten.

 

Voor zover aan de drie bovenstaande voorwaarden is voldaan, zullen exoneratiebedingen in principe afdwingbaar zijn, tenzij de bedinger beschouwd zou kunnen worden als een professionele verkoper. De professionele verkoper wordt immers vermoed het gebrek in de software te kennen, en krachtens artikel 1643 BW hebben contractuele bedingen van niet-vrijwaring voor verborgen gebreken geen uitwerking indien de verkoper op het ogenblik van de verkoop kennis had van het gebrek in de zaak.

 

De professionele verkoper zal dan ook in principe aansprakelijk zijn voor verborgen gebreken, tenzij hij het bewijs kan leveren van onoverwinnelijke onwetendheid. In de praktijk zal dergelijk bewijs moeilijk te leveren zijn. Deze regeling geldt enkel voor verborgen gebreken (bv. een bug die zich pas later manifesteert) en niet voor zichtbare gebreken (bv. een kras op een cd-rom). Zichtbare gebreken worden gedekt door de aanvaarding door de klant. De klant heeft de plicht de goederen te inspecteren alvorens deze te aanvaarden.

 

E. Einde van de overeenkomst

 

Eens beide partijen hun verplichtingen onder de overeenkomst hebben nageleefd, dooft de overeenkomst uit en houdt zij op verdere gevolgen te hebben. Overeenkomsten kunnen ook beëindigen door opzegging. Wanneer de overeenkomst geen opzeggingstermijn voorziet, kan deze worden opgezegd middels een redelijke opzeggingstermijn. Niemand kan immers tot in de eeuwigheid zijn gebonden. Natuurlijk kunnen partijen ook steeds in onderling overleg besluiten een overeenkomst te beëindigen.

 

3. Informaticacontracten

 

A. Algemene contractuele bepalingen

 

Informaticacontracten verschillen op zich niet van andere contracten. Daarom hebben de meeste informaticacontracten als basis dezelfde structuur als gewone contracten:

 

– Tussen wie wordt de overeenkomst gesloten (de partijen)?

 

– Wat is het voorwerp van de overeenkomst (vb. verkoop of levering van diensten)?

 

– Wat zijn de rechten en verplichtingen van de partijen?

 

– Zijn de algemene voorwaarden van één van de partijen van toepassing?

 

– Waar wordt de overeenkomst uitgeoefend/waar wordt geleverd?

 

– Wat is de aanvangsdatum van de overeenkomst?

 

– Wanneer eindigt de overeenkomst en hoe kan zij door de partijen worden opgezegd?

 

– Wat is de prijs?

 

– Hoe verlopen de betalingen?

 

– Dienen de partijen informatie geheim te houden?

 

– …

 

B. Enkele specifieke aspecten van de informaticacontracten

 

Hieronder wordt ingegaan op een aantal belangrijke aandachtspunten die belangrijk zijn in de meeste informaticacontracten. Waar nuttig worden voorbeeldclausules toegevoegd. Het is belangrijk voor ogen te houden dat de voorbeeldclausules niet geschikt zijn voor alle omstandigheden. Zo zal een clausule die zeer goed is voor een leverancier, vaak ronduit slecht zijn vanuit het standpunt van de klant. Daarom dient men uitermate op te letten bij het overnemen van voorbeeldclausules.

 

Het is noodzakelijk gespecialiseerd juridisch advies in te winnen alvorens de voorbeeldclausules uit dit boek toe te passen.

 

1. Voorwerp

 

Wanneer men een overeenkomst opstelt, dient eerst en vooral haar voorwerp goed te worden bepaald. Dit lijkt evident, maar men zou versteld staan hoe vaak hier tegen wordt gezondigd. Het gebeurt regelmatig dat partijen tijdens de uitvoering van de overeenkomst een discussie krijgen over wat er nu juist dient te worden geleverd. Vaak verwacht de klant voor een bepaalde prijs meer te zullen krijgen dan de leverancier -voor die prijs- wenst te leveren.

 

Bij grote informaticaprojecten is het aangewezen dat eerst een studie/analyse wordt gemaakt van het voorwerp van de overeenkomst. Deze kan dan in bijlage worden gevoegd. Veelal zal het uitvoeren van de voorstudie een afzonderlijke opdracht zijn. Wanneer het maken van een dergelijke studie bij de uitvoering van de overeenkomst hoort, dient zulks duidelijk te worden aangegeven (vb. informaticatoepassing: business analyse -> functionele analyse -> technische analyse -> ontwikkeling zelf).

 

In de loop van de overeenkomst kunnen partijen natuurlijk steeds overeenkomen om het voorwerp van de overeenkomst te wijzigen. Vaak wordt hiervoor een specifieke procedure voorzien.

 

Voorbeeldclausule voor een aanneming voor de ontwikkeling van een softwarepakket:

 

“a. Projectspecificaties

 

Op basis van de Projectbeschrijving door de klant (Bijlage A) gaat de leverancier over tot een vooronderzoek en beschrijving van het Project en de aanpak van het Project en stelt de Projectspecificaties op (die worden gevoegd in Bijlage B), welke als basis en referentiepunt zal fungeren voor de verdere levering van de Diensten. De klant bestudeert de door de leverancier opgestelde Projectspecificaties en formuleert haar opmerkingen of keurt deze goed binnen de ___ dagen na ontvangst ervan. Ingeval de klant opmerkingen heeft geformuleerd, zal de leverancier deze binnen de ___ dagen in de Projectspecificaties verwerken. Deze werkwijze wordt herhaald tot partijen akkoord zijn over de Projectspecificaties.

 

Bij gebreke aan tijdige reactie door de klant worden de Projectspecificaties geacht te zijn goedgekeurd.

 

b. Projectuitvoering

 

De leverancier zal, conform de voorwaarden zoals vervat in deze Overeenkomst, het Project, conform de specificaties zoals vervat in Bijlage B opleveren.

 

c. Change Requests

 

Eventuele wijzigingen in de door de klant eerder kenbaar gemaakte behoeftes, en/of veranderingen en/of toevoegingen aan het Project of de Projectspecificaties kunnen zowel door de klant als door de leverancier geïnitieerd worden via een Change Request. Een Change Request dient schriftelijk goedgekeurd te worden door de klant en de leverancier. Change Requests kunnen aanleiding geven tot een aanpassing van de tussen Partijen overeengekomen prijs en het tussen Partijen overeengekomen tijdsschema.

 

De leverancier behoudt zich het recht voor geen Change Requests uit te voeren zolang geen geschreven overeenkomst is bereikt over dergelijke wijzigingen. Indien de klant wijzigingen vraagt en deze door de leverancier worden uitgevoerd zonder vaste prijsafspraak, zullen deze wijzigingen in regie worden uitgevoerd aan de op dat ogenblik gangbare tarieven van de leverancier.

 

De leverancier behoudt zich uitdrukkelijk het recht voor om niet in te gaan op de door de klant kenbaar gemaakte of gevraagde wijzigingen, aanpassingen en/of toevoegingen, indien hij van mening is dat het door de klant gevraagde onrealiseerbaar is en/of een negatief effect heeft op het Project.

 

Studies en werk dat de leverancier onderneemt met het oog op de evaluatie van door de klant gevraagde Change Requests, zullen worden aangerekend aan de dan geldende tarieven van de leverancier.”

 

2. Resultaatsverbintenis vs. inspanningsverbintenis

 

Wanneer een aannemer een verbintenis op zich neemt, is het belangrijk om een onderscheid te maken tussen een inspanningsverbintenis (ook wel middelenverbintenis of best efforts genaamd) en een resultaatsverbintenis ( ook wel uitslagverbintenis genaamd).

 

Bij een resultaatverbintenis verbindt de schuldenaar zich ertoe om een bepaald resultaat te bereiken. Wanneer de schuldenaar dit resultaat niet bereikt, wordt hij geacht aansprakelijk te zijn wegens niet nakoming van zijn verbintenis. Het is aan de schuldenaar om het bewijs te leveren dat de reden van de tekortkoming hem niet kan worden toegerekend. Hij moet dus zelf het tegenbewijs leveren.

 

Bij een inspanningsverbintenis verbindt de schuldenaar er zich louter toe om zich te zullen inspannen een bepaald resultaat te halen. Dit resultaat is evenwel niet gegarandeerd. Wel dient de schuldenaar de inspanningen te leveren die van een normaal bedachtzaam en voorzichtig persoon kunnen worden verwacht. Wanneer het resultaat niet wordt gehaald, volstaat dit op zich niet opdat de schuldenaar aansprakelijk zou zijn. Het is aan de  schuldeiser om het bewijs te leveren dat de schuldenaar niet de inspanningen heeft geleverd die van een redelijke –professionele– partij kunnen worden verwacht.

 

Het spreekt voor zich dat dit onderscheid zeer belangrijk is wanneer een beoogd resultaat niet is gehaald.

 

Hieronder worden twee voorbeelden van clausules gegeven waarbij de leverancier voor de klant een software systeem dient te ontwikkelen op maat:

 

Voorbeeldclausule resultaatsverbintenis:

 

“De leverancier aanvaardt de opdracht om een volledig geïntegreerd softwarepakket aan de klant te leveren, zoals in detail beschreven in de functionele en technische specificaties als Bijlage A (hierna het ” Pakket”). 

 

De leverancier waarborgt de volledige overeenstemming van het Pakket aan de behoeften van de klant, zoals bepaald in de functionele en technische specificaties en/ of andere documenten welke in de loop van het project worden opgesteld. Eventuele functies die niet uitdrukkelijk zijn voorzien, doch vanzelfsprekend binnen het kader van het project vallen, zullen eveneens worden geleverd. De leverancier heeft kennis van de feitelijke omgeving waarin het Pakket zal moeten functioneren en aanvaardt deze omgeving als zodanig, zonder voorbehoud. De leverancier zal de klant raad en assistentie geven bij het Pakket, en waarschuwen voor alle mogelijke risico’s welke verbonden zouden zijn aan het ontwerp of het gebruik van het Pakket.

 

De leverancier verbindt zich om het Pakket te ontwikkelen en te installeren volgens de regels der kunst, en het foutenvrij op te leveren, en eventuele fouten, tekortkomingen of gebreken welke toch nog zouden voorkomen in de programmatie, de instructies, de parametrisatie, de handleidingen, de schema’s of meer in het algemeen in elk element van het Pakket op eigen kosten te verbeteren.”

 

Voorbeeldclausule inspanningsverbintenis:

 

“De leverancier aanvaardt de opdracht om een softwarepakket aan de klant te leveren, zoals globaal beschreven in de functionele en technische specificaties aangehecht als Bijlage A (hierna het “Pakket”).

 

De leverancier werkt bij de uitvoering van het project volgens de regels van de kunst en met gekwalificeerd personeel. Hoewel de leverancier zijn diensten naar best inzicht en vermogen zal presteren en/of leveren, biedt de leverancier, geen enkele garantie met betrekking tot het Pakket, waaronder de garantie dat het Pakket geschikt zal zijn voor een bepaald doel of dat het zal overeenstemmen met de behoeften van de klant.”

 

3. Toepasselijkheid algemene voorwaarden

 

Een clausule waarvan het belang vaak over het hoofd wordt gezien, is de toepasselijkheid van de algemene verkoopsvoorwaarden of aankoopvoorwaarden  van één van de partijen. Wanneer het contract een bepaald element niet voorziet, dan zal toepassing worden gemaakt van de algemene voorwaarden van de partij die deze heeft opgelegd. Aangezien algemene voorwaarden veelal eenzijdig zijn opgesteld in het voordeel van de partij die ze heeft opgesteld, kan dit voor de wederpartij voor vervelende verrassingen zorgen. Daarom voorzien contracten vaak expliciet dat de algemene voorwaarden van de partijen niet van toepassing zijn.

 

Voorbeeldclausule:

 

“De algemene aankoops- of verkoopsvoorwaarden van de partijen zijn niet van toepassing op deze Overeenkomst.”

 

4. Licentie

 

Om een auteursrechtelijk beschermd werk te kunnen gebruiken, dient men te kunnen aantonen op basis waarvan men zijn gebruiksrechten haalt. Kan men geen gebruiksrechten aantonen, dan dient men zich van ieder gebruik te onthouden. Het werk toch gebruiken, vormt immers een auteursrechtelijke inbreuk.

 

Daarom is het van belang dat de gebruiksrechten die de leverancier aan de klant geeft zo goed mogelijk zijn gedefineerd in de licentieovereenkomst. Deze gebruiksrechten kunnen op diverse wijzen worden omgeschreven.

 

Parameters die vaak worden gehanteerd zijn:

 

– Aantal toegestane gebruikers: hierbij is het van belang of het unieke, bij naam genoemde gebruikers (single users), dan wel gelijktijdige gebruikers zijn (concurrent users). In het eerste geval kunnen slechts de benoemde gebruikers de software gebruiken; in het tweede geval kan iedereen de software gebruiken, zolang het maximaal toegestane aantal gebruikers op eenzelfde ogenblik niet wordt overschreden.

 

– Infrastructuur: vaak worden de gebruiksrechten gekoppeld aan een bepaald aantal CPU’s of cores of dergelijke meer.

 

– Looptijd: zeer belangrijk is de duur van de licentie te bepalen. Is deze slechts geldig voor een jaar of onbeperkt in tijd?

 

– Territorium: men kan de licenties ook aan een geografisch territorium koppelen. Wanneer men de licentie zo ruim mogelijk wenst te definiëren, bepaalt wereldwijd.

 

– Bedrijfsniveau: vaak verleent men ook licenties op bedrijfsniveau: corporate licenses. Ofwel is dit een groepslicentie met korting voor een bepaald aantal gebruikers, ofwel is dit een licentie die alle intern gebruik door het bedrijf dekt. Wanneer men wil dat de gehele groep van het programma gebruik kan maken, dient men dit expliciet te definiëren.

 

– Exclusiviteit: voor belangrijke projecten bedingt men vaak een exclusieve licentie. De leverancier kan het programma dan niet meer aan derden in licentie geven. Men kan de exclusiviteit ook beperken tot bv. een industriële sector, geografisch gebied en dergelijke meer.

 

– Aanpassingen: wanneer de klant het recht wil hebben de software aan te passen, dient zulks expliciet te worden bedongen.

 

– Sublicenties: wanneer de klant de bedoeling heeft de software te commercialiseren of anderszins met derden te delen, dient zulks expliciet te worden voorzien.

 

– Overdracht: indien de klant de licentie wenst te kunnen overdragen, is het aangewezen dit in de licentie te bepalen. Indien dit niet is gebeurd, kan de klant zich nog op de uitputtingsleer beroepen. Beter is evenwel deze discussie te vermijden en de mogelijkheid tot overdracht expliciet te bepalen.

 

Bovenstaande lijst is geenszins exclusief. Een licentie is geen wettelijk bepaalde term. Partijen kunnen deze zelf invullen.

 

Voorbeeldclausule:

 

“Na betaling van de verschuldigde bedragen verleent de leverancier aan de klant een niet overdraagbare en niet-exclusieve licentie voor het Pakket zoals beschreven in de Bijlage. Deze licentie geldt voor het aantal gebruikers zoals vermeld in de Bijlage, en enkel en alleen met het oog op het gebruik van het Pakket in overeenstemming met het beoogde doel.

 

De klant zal het Pakket in zijn geheel of gedeeltelijk niet gebruiken, afdrukken, kopiëren, aanpassen, vertalen of wijzigen, tenzij zoals uitdrukkelijk voorzien in deze Overeenkomst of zoals is toegestaan onder dwingend recht.

 

Daarenboven heeft de klant geen toelating om het Pakket om te zetten in broncode, te decompileren, te deassembleren, of te analyseren bij “reverse engineering” en iedere poging hiertoe zal beschouwd worden als een inbreuk op deze Overeenkomst, tenzij dergelijke daad uitdrukkelijk is toegestaan bij dwingend recht. Deze laatste uitzondering geldt niet wanneer de benodigde informatie vrij verstrekt wordt door de leverancier.”

 

5. Beperking aansprakelijkheid

 

Zoals boven uiteengezet is de schuldenaar in geval van contractbreuk gehouden alle schade te vergoeden die voorzienbaar was bij de contractsluiting (art. 1150 BW) en die een onmiddellijk en rechtstreeks gevolg is van de nietuitvoering van het contract (art. 1151 BW).

 

Dit wettelijke regime is evenwel niet van dwingende aard. Partijen kunnen anders overeenkomen. Het is voor leveranciers aangewezen om van deze mogelijkheid gebruik te maken en hun aansprakelijkheid in een contract of via hun algemene voorwaarden te beperken.

 

Voorbeeldclausule:

 

“Hoewel de leverancier de Dienst en/of Product naar best inzicht en vermogen zal presteren en/of leveren, biedt de leverancier geen enkele garantie met betrekking tot de geleverde Dienst of Product, waaronder de garantie dat de Dienst of Product geschikt zal zijn voor een bepaald doel.

 

De leverancier is niet aansprakelijk voor schade welke niet rechtstreeks en onmiddellijk het gevolg is van een zware fout of bewezen opzet. De leverancier zal nooit aansprakelijk zijn voor indirecte – of gevolgschade, zoals verlies van inkomen, vorderingen van derden, verlies van gegevens, enz. zelfs indien de leverancier op de hoogte is gebracht van de mogelijkheid van het ontstaan van zulke schade.

 

De aansprakelijkheid van de leverancier met betrekking tot rechtstreekse schade zal beperkt zijn tot herstel in natura door het opnieuw presteren van de te leveren  Diensten en/of het leveren van het Product.

 

Zowel de contractuele als buitencontractuele aansprakelijkheid van de leverancier zal in alle gevallen beperkt zijn tot vijftig procent (50%) van de door haar in het kader van de schadeverwekkende Dienst en/of Product aan de klant gefactureerde en effectief betaald gekregen bedragen.”

 

6. Waarborg intellectuele rechten

 

Wanneer vast komt te staan dat geleverde software inbreuk pleegt op intellectuele rechten van derden (bv. op auteursrechten, databankrechten of patenten), staan zowel de leverancier als de klant voor problemen. De derde kan immers ieder gebruik van de inbreukplegende software laten stopzetten. De leverancier zal de klant hiervoor dienen te vergoeden. Daarom is het voor de leverancier aangewezen met de klant voorafgaandelijk afspraken hieromtrent te maken.

 

Deze afspraken hebben best betrekking op (1) het voeren van een eventueel geschil, (2) de wijziging van de software indien nodig en (3) de vergoeding indien vervanging niet mogelijk is. Een voorbeeldclausule is:

 

“De leverancier garandeert dat hij het recht heeft licenties te verlenen voor het Pakket onder de voorwaarden van deze Overeenkomst en dat hij geen kennis heeft van enige vordering in hoofde van een derde dat het gebruik van het Pakket een inbreuk vormt op enig octrooi- of auteursrecht van een dergelijke derde.

 

Indien met gerechtelijke stappen wordt gedreigd of indien die genomen worden tegen de klant met betrekking tot intellectuele eigendomsrechten, met inbegrip van auteursrechten, databankrechten, octrooirechten of soortgelijke rechten op het Pakket en/of documentatie, verbindt de klant er zich toe de leverancier hiervan onverwijld op de hoogte te brengen en de leverancier de toestemming te geven zich in dergelijke procedure te verdedigen. De leverancier zal de klant vergoeden, verdedigen en vrijwaren voor elke rechterlijke uitspraak, kost of andere aansprakelijkheid voortvloeiende uit enige inbreuk van het Pakket op auteursrechten van derden, uitgezonderd voorzover de leverancier aantoont dat dergelijke inbreuk veroorzaakt wordt door een product of dienst die verschilt van de door de leverancier geleverde producten en diensten.

 

De aansprakelijkheid van de leverancier voor aanspraken door derden inzake intellectuele eigendomsrechten is beperkt tot degene die hierboven is u

 

De leverancier zal ten aanzien van de klant niet aansprakelijk zijn voor schade-eisen wegens inbreuken gebaseerd op het feit dat het Pakket gebruikt is in combinatie met een ander product dat niet inbegrepen is in de door de leverancier geleverde producten, of dat het Pakket door de klant is gewijzigd of gebruikt op een wijze waarvoor het niet ontworpen is.

 

Indien het gebruik van het Pakket, of een relevant deel ervan, lijkt te gaan leiden tot een juridische actie, zal de leverancier op eigen kosten:

 

a) het Pakket, of een relevant deel ervan, vervangen door niet-inbreukmakende software of een niet-inbreukmakend relevant deel ervan, of het Pakket, of een relevant deel ervan, aanpassen teneinde de inbreuk ongedaan te maken, of,

 

b) het inbreukmakend Pakket, of het inbreukmakende relevant deel ervan terugnemen, en de klant het betrokken deel van de vergoeding terugbetalen, verminderd met een discount voor afschrijving begroot op 20% per jaar, of,

 

c) voor de klant het recht bekomen om het inbreukmakend Pakket, of het inbreukmakende relevante deel ervan, te gebruiken.

 

De aansprakelijkheid van de leverancier voor aanspraken door derden inzake intellectuele eigendomsrechten is beperkt tot degene die hierboven is uiteengezet.”

 

7. Gebruik van free and open source software (FOSS)

 

Om de ontwikkelingstijd te versnellen, gebruiken leveranciers vaak FOSS. Toch dient daarmee te worden opgelet. Vaak weet men niet of de code deugdelijk is en of diegene die de code op het internet heeft geplaatst hiertoe wel de rechten heeft. Ook het soort licentie die op de code van toepassing is, kan van belang zijn. Het kan het gebruik ervan door de klant immers sterk beperken.

 

Daarom is het essentieel om goede afspraken te maken betreffende welke code door de leverancier kan worden gebruikt. Er kunnen bv. afspraken worden gemaakt betreffende uit welke online bronnen de leverancier code mag halen en onder welke FOSS licenties.

 

Een ander aandachtspunt is het feit dat FOSS typisch ter beschikking wordt gesteld zonder enige garantie. De partijen dienen af te spreken hoe hiermee wordt omgegaan.

 

Een voorbeeldclausule:

 

“Als de klant dat wenst, zal de leverancier bij de Diensten en/of Producten free software en open source software (FOSS) gebruiken. De klant zal de leverancier expliciete richtlijnen bezorgen met betrekking tot de FOSS-licenties en FOSSbronnen die de klant aanvaardt. De klant erkent uitdrukkelijk de voor- en nadelen van FOSS en FOSS-licenties te kennen, zoals het feit dat FOSS wordt geleverd in de staat waarin deze zich bevindt, zonder enige garantie en vaak met specifieke beperkingen met betrekking tot het gebruik. De leverancier biedt geen enkele garantie of waarborg met betrekking tot FOSS, tenzij uitdrukkelijk anders schriftelijk overeengekomen. De leverancier biedt geen bredere gebruiksrechten op FOSS dan bepaald in de toepasselijke FOSS-licentie.”

 

Het is natuurlijk mogelijk dat de leverancier, al dan niet tegen betaling, juist wel een garantie biedt op de FOSS.

 

8. Verplichtingen van de klant

 

In contracten wordt vaak de nadruk gelegd op de verplichtingen van de leverancier. Wanneer er dan een probleem opduikt, verschuilt de klant zich vaak (al dan niet terecht) achter zijn statuut als leek. De professionele leverancier had dit dan maar moeten voorzien.

 

Daarom is het voor de leverancier aangewezen in het contract stil te blijven staan bij de verplichtingen van de klant inzake informatie, medewerking, ter beschikkingstelling van personeel voor testing, software, hosting en dergelijke meer. Wanneer het welslagen van het project afhangt van een goede medewerking van de klant, is het noodzakelijk dit in het contract te voorzien. Het is natuurlijk van belang dat deze clausule specifiek wordt geschreven op maat van het project.

 

Een voorbeeldclausule:

 

“De klant verbindt zich ertoe om op zeer precieze en duidelijke wijze zijn wensen, noden en vereisten met betrekking tot alle prestaties die de leverancier dient te leveren onder deze Overeenkomst kenbaar te maken aan de leverancier.

 

De klant verbindt zich ertoe om de leverancier uit eigen beweging en binnen redelijke termijn alle beschikbare informatie te verstrekken die nodig is en/of op één of andere wijze kan bijdragen aan de succesvolle verwezenlijking van alle opdrachten die de leverancier in het kader van deze overeenkomst van de klant heeft gekregen.

 

Daarnaast zal de klant op eerste verzoek en binnen redelijke termijn aan de leverancier alle noodzakelijke en/of nuttig informatie verstrekken die door de leverancier gevraagd wordt en die de leverancier nodig heeft om hem toe te laten zijn opdrachten naar behoren uit te voeren.

 

De klant begrijpt het grote belang van en garandeert de adequaatheid en nauwkeurigheid van alle gegevens, instructies en informatie die door de klant in het kader van deze Overeenkomst aan de leverancier worden verschaft.

 

De klant verbindt er zich tevens toe om alle redelijke voorzieningen die de leverancier nodig heeft om de in deze Overeenkomst voorziene prestaties te leveren ter beschikking te stellen, waaronder, doch niet beperkt tot, de uitrusting en software als beschreven in de bijlage. De klant blijft op elk moment verantwoordelijk voor de correcte werking en beschikbaarheid van deze uitrusting en software.”

 

9. Aanvaarding

 

De klant heeft de verplichting om de geleverde goederen of diensten te aanvaarden. Maar aangezien de levering van informaticadiensten vaak gradueel gebeurt, is het aangewezen hieromtrent afspraken te maken. De aanvaarding heeft juridisch gezien immers belangrijke gevolgen. De aanvaarding impliceert dat de klant vaststelt dat:

 

– de geleverde goederen en diensten conform zijn aan de afspraken;

 

– het geleverde geen zichtbare gebreken vertoont (zichtbare gebreken zijn die gebreken die de klant tijdens een aandachtig onderzoek van het geleverde zou kunnen/moeten opmerken);

 

– de kwaliteit en kwantiteit van het geleverde overeenstemmen met de afspraken.

 

De aanvaarding heeft ook betrekking op de andere verplichtingen van de leverancier: de levering gebeurde op tijd, op de afgesproken plaats edm. Na de aanvaarding gaat het risico betreffende het geleverde over op de klant en heeft de klant de verplichting om te betalen. De leverancier draagt na de aanvaarding enkel nog de verantwoordelijkheid betreffende verborgen gebreken.

 

De (defintieve aanvaarding dient te worden onderscheiden van de voorlopige aanvaarding. Bij de voorlopige aanvaarding wordt slechts vastgesteld dat de werken voltooid zijn. Een voorlopige oplevering impliceert geenszins een goedkeuring of aanvaarding van het geleverde.

 

De aanvaarding kan gebeuren in fasen. Ieder projectonderdeel kan afzonderlijk worden aanvaard.

 

Voorbeeldclausule (uitgebreide variant):

 

“Per onderdeel of module zal een voorlopige deeloplevering plaatsvinden zoals bepaald in de bijlage. De installatie zal geschieden volgens de specificaties in de bijlage.

 

Elke voorlopige deeloplevering wordt voorafgegaan door een test. De testcriteria zullen in gezamenlijk overleg worden opgesteld en schriftelijk worden vastgelegd ten laatste twee weken voor het begin van de test. De voorlopige deeloplevering houdt in geen enkele betekenis enige aanvaarding door de klant van het onderdeel of de module in.

 

Op de in de bijlage vermelde data dient het betreffende onderdeel of module de test te hebben doorstaan en te werken overeenkomstig deze overeenkomst. Eventuele worden door de leverancier hersteld binnen de vijf werkdagen na de voorlopige deeloplevering. 

 

Binnen de twee weken na de laatste voorlopige deeloplevering zal een test van het volledige systeem plaatsvinden welke als voornaamste doel heeft de integratie van alle onderdelen en modules te testen. Indien het systeem deze test doorstaat, zal het systeem door de klant zo snel als mogelijk in gebruik worden genomen. Indien het systeem gedurende een redelijke termijn foutloos heeft gefunctioneerd gedurende deze ingebruikname, zal overgegaan worden tot voorlopige aanvaarding. Indien de testen voor een deeloplevering of voor de voorlopige aanvaarding niet succesvol worden doorlopen, zal de leverancier de gebreken bijwerken, en in overleg met de klant een nieuwe test organiseren. De datum waarop de laatste test succesvol is voltooid, dient als datum van voorlopige deeloplevering.

 

De voorlopige deelopleveringen en de voorlopige aanvaarding van het systeem zullen slechts plaatsvinden na volledige uitvoering der voorziene werken en na afgifte van de bijhorende documentatie.

 

Na de voorlopige aanvaarding zal het systeem in operationeel gebruik worden genomen en in werking worden getest gedurende een volledige werkingscyclus van ___ maanden. Ingeval het systeem gedurende deze periode beantwoord heeft aan de functies en technische specificaties zoals overeengekomen, zal op het einde van deze periode de definitieve oplevering geschieden. Indien het systeem niet beantwoord heeft aan de functies en de technische specificaties, wordt deze periode verlengd met de periode gedurende dewelke het systeem niet voldeed. In ieder geval zal het systeem gedurende een periode van minimaal drie maanden na de correctie van het laatste gebrek correct moeten hebben gefunctioneerd alvorens tot de definitieve aanvaarding kan worden overgegaan.

 

Elke vorm van oplevering of aanvaarding dient schriftelijk te gebeuren in een afzonderlijk daartoe opgesteld document.”

 

Voorbeeldclausule (korte variant):

 

“De levering geschiedt door het presteren van de Dienst en/of het ter beschikking stellen van het Product en de melding van de leverancier dat de Dienst is gepresteerd en/of het Product klaar is voor gebruik. De klant heeft de plicht om na deze melding de correctheid van de geleverde Dienst en/of het Product te verifiëren en zorgvuldig te testen.

 

De klant beschikt over een termijn van zeven kalenderdagen, ingaande vanaf de dag der levering, om aan de leverancier de gehele of gedeeltelijke aanvaarding of de weigering wegens gebreken van de geleverde Dienst/Product bekend te maken. Elke gehele of gedeeltelijke weigering dient door de klant op voldoende wijze in een aangetekend schrijven gemotiveerd te worden. Het ontbreken van enige reactie van de klant binnen de in dit artikel vooropgestelde termijn, houdt de goedkeuring van de geleverde Dienst/Product in en de succesvolle uitvoering van de testen.

 

Verborgen gebreken dienen binnen de vijf dagen na ontdekking aangetekend te worden gemeld. De klant draagt het risico indien de klant in gebreke is gebleven na de levering de nodige testen uit te voeren.”

 

10. Straffen

 

Partijen kunnen strafsancties met forfaitaire schadevergoedingen overeenkomen die de leverancier dient te betalen, indien de leverancier er niet in slaagt tijdig te leveren of indien het geleverde niet voldoet aan de gevraagde specificaties.Dit is het zogenaamde strafbeding ( art.1226 BW ). Om geldig te zijn dient het strafbeding een vergoedend karakter te hebben. In weerwil van zijn naam, mag een strafbeding dus geen straffend karakter hebben.

 

De toetssteen hierbij is of de overeengekomen vergoeding, op het ogenblik van de contractsluiting, een redelijke begroting kon zijn van de schade die voor de klant uit de door het strafbeding geviseerde wanprestatie kon voortvloeien. Een strafbeding dat te hoog ligt, is dus niet geldig en kan door de rechter worden gematigd. Een matiging is ook mogelijk indien de leverancier zijn verplichtingen gedeeltelijk heeft uitgevoerd.

 

11. Waarborg en onderhoud van de software

 

Artikel 6 van de Softwarewet geeft de rechtmatige gebruiker het recht om alle handelingen uit te voeren die noodzakelijk zijn om het computerprogramma te kunnen gebruiken voor het beoogde doel, met inbegrip van het verbeteren van fouten. Dit is een vorm van recht tot het onderhouden van de software. De leverancier heeft evenwel de mogelijkheid om dit onderhoud door de klant in de overeenkomst te verbieden. In dergelijk geval is hij de enige die het onderhoud van de software mag doorvoeren. Een klant die niet oplet, kan verzeild raken in een situatie waar hij tegen zijn wil gebonden is aan een leverancier. Omgekeerd is het mogelijk dat een leverancier het onderhoud en ondersteuning van een programma tegen de zin van de klant na een tijd stopzet. Voor belangrijke pakketten is het aangewezen om bij de aankoop van de software met deze problematiek rekening te houden, en indien nodig van de leverancier de nodige waarborgen voor continuïteit te eisen. Het onderhoud vormt ook een niet te onderschatten kost.

 

Voor het onderhoud van de software zal de leverancier veelal aandringen

 

op een afzonderlijke onderhoudsovereenkomst. Onder deze overeenkomst

 

staat de leverancier -tegen betaling- in voor het verder actief en actueel houden van de software. De klant daarentegen, wenst vaak een bepaalde waarborgperiode gedurende dewelke de leverancier de software kosteloos dient te onderhouden. Of er een dergelijke waarborg dient te worden geboden en de duur en inhoud ervan, maakt deel uit van de onderhandelingen tussen de partijen. Partijen zijn vrij hieromtrent afspraken te maken.

 

Voorbeeldclausule (waarborg):

 

“De leverancier waarborgt dat het systeem volledig zal beantwoorden aan de overeengekomen functies en specificaties, en dat het geschikt zal zijn voor het doel waarvoor het is bestemd. Gedurende de garantieperiode, vastgesteld op twaalf maanden na de definitieve aanvaarding van het systeem, zal de leverancier in elk geval op zijn kosten gehouden zijn tot het herstellen van bugs, fouten en gebreken.

 

De garantie zal niet gelden indien de klant zonder medeweten van de leverancier wijzigingen aan het systeem aanbrengt of laat aanbrengen, tenzij wanneer veroorzaakt door een tekortkoming van de leverancier en tenzij de vastgestelde gebreken niet door de aangebrachte wijzigingen werden veroorzaakt.

 

De garanties en waarborgen in dit artikel worden geboden onafhankelijk van het afsluiten door de klant van een onderhoudsovereenkomst”.

 

Voorbeeldclausule (geen waarborg):

 

“De leverancier zal alleen onderhoud, bijstand en ondersteuning verlenen voor het systeem indien hiervoor een afzonderlijke onderhoudsovereenkomst is afgesloten. Indien geen afzonderlijke onderhoudsovereenkomst wordt afgesloten vanaf de ingebruikname door de klant vervalt elke waarborg en elke aansprakelijkheid van de leverancier met betrekking tot de werking van het systeem”.

 

12. Escrow

 

Een klant die bedrijfszekerheid wenst, wil vaak toegang tot de broncode van de geleverde software applicatie. Mocht de oorspronkelijke leverancier failliet gaan of zijn verbintenissen niet nakomen, dan kan de klant beroep doen op een andere expert voor het onderhoud van zijn applicatie. De leverancier daarentegen, beschouwt de broncode vaak als een bedrijfsgeheim en wil de klant er geen toegang tot verlenen. De oplossing wordt dan gevonden in het in escrow geven van de broncode bij een derde partij. Het is van belang om goed vast te leggen onder welke voorwaarden de klant toegang zal krijgen tot de broncode en welke rechten hij in dergelijk geval op de code zal hebben.

 

Voorbeeldclausule:

 

“Voor de aanvaarding van het systeem zal de leverancier overgaan tot het ondertekenen van een escrow-overeenkomst waarbij de broncode van de meest recente versie van de software die deel uitmaakt en nadien (na wijziging) deel zal uitmaken van het systeem, alle software componenten welke nodig zijn om tot een werkend systeem te komen, alsook alle technische informatie om de klant en/of derden toe te laten het systeem te onderhouden, aan te passen en/ of uit te breiden, in bewaring zullen worden gegeven bij een derde partij op een wijze en onder voorwaarden die van aard zijn om de broncode ter beschikking te stellen van de klant telkenmale de goede bedrijfsvoering en -werking van de klant bedreigd is, ondermeer ingevolge  faillissement, concordaat, inbreuk op de onderhoudsverplichtingen, beëindiging van de onderhoudsovereenkomst en gebrek aan medewerking en informatieverschaffing van de leverancier bij de ontwikkeling van nieuwe modules door de leverancier of door andere leveranciers.

 

De kosten van dergelijke bewaargeving vallen ten laste van de klant. De klant zal het recht hebben om de broncode in zulk geval in de breedst mogelijke zin te gebruiken en aan te (laten) passen met het oog op gebruik in overeenstemming met deze overeenkomst. De klant zal het recht hebben om een derde deskundige de nodige controles te laten uitvoeren teneinde de identiteit tussen de in bewaring gegeven broncode en technische documentatie en de code en technische documentatie zoals werkend als deel van het systeem vast te stellen.”

 

13. Niet-afwerving

 

Eens een softwareprogramma is geschreven, dient het natuurlijk nog verder onderhouden te worden. En wie kan dit beter onderhouden dan de auteur zelf? Het is dan ook verleidelijk voor de klant om het personeel van de leverancier dat voor de ontwikkeling instond, na de oplevering zelf in dienst te nemen. Goed personeel is immers moeilijk te vinden. Daarom is het voor de leverancier aangewezen om een clausule in de overeenkomst op te nemen die dergelijke afwerving verbiedt.

 

Voorbeeldclausule:

 

“Gedurende de duur van de overeenkomst en gedurende een periode van één jaar na afloop daarvan, zal de klant geen gebruik maken van diensten van het personeel en/of de medewerkers van de leverancier, rechtstreeks noch onrechtstreeks, als zelfstandige, als vennoot, als bediende of in om het even welke andere hoedanigheid of wijze, behoudens uitdrukkelijke, schriftelijke en voorafgaandelijke toestemming van de leverancier.

 

In geval van inbreuk op het verbod voorzien in dit artikel, zal de klant aan de leverancier bij wijze van forfaitaire schadevergoeding een bedrag betalen gelijk aan 50.000€, onverminderd het recht van de leverancier om hogere schade te bewijzen.”

 

14. Bevoegde rechtbank en toepasselijk recht

 

Software en informatica kennen geen grenzen, zeker niet wanneer ze online worden aangeboden.

 

Wanneer de partijen geen keuze hebben gemaakt betreffende het toepasselijk recht en de bevoegde rechtbank, dan zal men de oplossing zoeken

 

in de regels van het internationale privaatrecht. Deze oplossing kan er evenwel toe leiden dat u dient te procederen in een ander land en onder een rechtstelsel dat u niet kent.

 

Om dergelijke, vaak dure, verrassingen te vermijden, is het aangewezen in overeenkomsten de bevoegde rechtbank en het toepasselijke recht te voorzien.

 

Let wel op, in kort geding procedures en in gevallen van dwingend recht, kan een rechtbank zich bevoegd verklaren, ook wanneer de overeenkomst een andere rechtbank aanduidt.

 

Voorbeeldclausule:

 

“Deze overeenkomst wordt beheerst door en geïnterpreteerd overeenkomstig het Belgische recht. Alle geschillen betreffende de geldigheid, de uitvoering of de interpretatie van deze overeenkomst, zullen worden beslecht voor de Rechtbanken van Brussel.”

 

4. Enkele contracten nader besproken

 

A. Softwarelicentieovereenkomst.

 

Een licentie is geen wettelijk gedefineerde term.Het is een gebruiksrecht dat door een partij aan een andere partij wordt verleend op een bepaald voorwerp en tegen bepaalde voorwaarden.

 

In de softwarelicentieovereenkomst bepalen de partijen in essentie (1) de uitgebreidheid van het verleende recht (bv. niet-exclusief, binnen Europa, voor een duur van vijf jaren, zonder het recht sub-licenties te verlenen), (2) het voorwerp dat in licentie wordt gegeven (de software waarop de overeenkomst betrekking heeft) en (3) de voorwaarden waaronder de licentie wordt verleend (bv. het betalen van een jaarlijkse vergoeding).

 

De verleende gebruiksrechten kunnen worden gekoppeld aan een bepaald aantal gebruikers (gelijktijdig of niet), aan het aantal werkstations, aan de hoeveelheid uitgewisselde data en dergelijke meer. De partijen genieten een vrijwel totale vrijheid om daaromtrent afspraken te maken.

 

Belangrijk is voor ogen te houden dat een licentiegever niet meer rechten kan verlenen dan hij zelf heeft. Wanneer de licentiegever de houder is van de intellectuele rechten op het programma, is zijn recht om licenties te geven vrijwel onbeperkt. Indien de licentiegever niet zelf houder is van de rechten, maar een licentie betrokken heeft van een derde partij (voor de volledige of een deel van de software), dient de sub-licentie te kaderen binnen de grenzen van de licentie die hijzelf verkregen heeft.

 

Een ander belangrijk element is de regeling van de intellectuele rechten op aanpassingen en wijzigingen aan de software gedurende de  centieovereenkomst. De leverancier zal vaak willen dat deze naar hem komen zodat hij deze aan zijn andere klanten kan aanbieden. De klant wil deze vaak voor zichzelf onder de redenering dat hij er voor heeft betaald.

 

Met code die men vrij op het internet vindt, dient men voorzichtig te zijn. Het is immers niet omdat deze code vrij beschikbaar of toegankelijk is, dat men deze kan gebruiken. Een huis waarvan de deur openstaat, wandelt men ook niet zomaar binnen. Belangrijk is te kijken welke licentie op de code van toepassing is. Indien de code niet van een licentie is voorzien, dient men veiligheidshalve van het gebruik van de code af te zien. Als gebruiker dient men immers te kunnen aantonen op basis waarvan men een werk gebruikt.

 

Free and Open Source Software is software die onder een Free and Open Source licentieovereenkomst beschikbaar is. Wanneer van deze software gebruik wordt gemaakt, dienen de voorwaarden van deze overeenkomsten, zoals naamsvermelding, publicatie licentievoorwaarden, copyleft, edm. wel degelijk te worden nageleefd.

 

B. Softwareontwikkelingsovereenkomst

 

De softwareontwikkelingsovereenkomst is een overeenkomst waarbij een opdrachtgever een uitvoerder gelast met de ontwikkeling van een softwareprogramma. De rechtsleer neemt aan dat het een aannemingsovereenkomst betreft.

 

Hoewel softwareontwikkelingsovereenkomsten in alle vormen en soorten voorkomen, kan men twee grote categorieën onderscheiden: de ontwikkeling van software tegen een vaste prijs (fixed price) of met nacalculatie (time and material). Onder de ‘fixed price’ overeenkomst neemt de aannemer de opdracht aan om een welbepaald programma tegen een welbepaalde vergoeding te ontwikkelen. Hoewel partijen achteraf nog kunnen overeenkomen om de scope te wijzigen en bijkomende ontwikkelingen toe te voegen, al dan niet tegen een meerprijs, is het uiterst belangrijk dat de uitgebreidheid van de te ontwikkelen software duidelijk is bepaald. Onduidelijke afspraken geven aanleiding tot discussies.

 

Een ‘Fixed price’ overeenkomst zal veelal een resultaatsverbintenis betreffen.Dit betekent dat van de opdrachtnemer verwacht wordt dat hij tegen een bepaalde datum een bepaald resultaat aflevert.De ontwikkelaar wordt hier verondersteld een werkend programma af te leveren, hoewel men veelal anvaardt dat in een op maat ontwikkeld softwareprogramma nog enkele bugs of kleine foutjes kunnen voorkomen. Eventueel kan een waarborgperiode gedurende dewelke de leverancier fouten opspoort en verbetert, worden voorzien.

 

Onder de ‘time and material’ overeenkomst levert de opdrachtnemer zijn prestaties en houdt hij een detail bij van de gepresteerde uren en gemaakte kosten. Op basis van deze staten, wordt de opdrachtnemer vergoed.

 

Van ‘time and material’ overeenkomst wordt vaak aangenomen dat het middelenverbintenissen betreft. Een middelenverbintenis houdt in dat de opdrachtnemer zich op professionele wijze inspant om een bepaald programma te ontwikkelen. Indien dit niet lukt, ligt de verantwoordelijkheid daarvoor niet automatisch bij de ontwikkelaar. Dit zal wel het geval zijn indien de ontwikkeling niet professioneel werd aangepakt.

 

Hoewel de bovenstaande indeling het meeste voorkomt, is het perfect mogelijk voor partijen om andere afspraken te maken. Zo kunnen partijen een    ‘fixed price’ overeenkomst afsluiten zonder garantie op resultaat ( een middelenverbintenis) en bij een ‘time and material’ overeenkomst toch een resultaat garanderen (resultaatsverbintenis).

 

C. Algemene voorwaarden

 

Partijen werken niet toevallig samen. Ook wanneer geen papier wordt ondertekend (of op elektronische wijze wordt gecontracteerd), zal een rechter ervan uitgaan dat er een overeenkomst tussen de partijen is tot stand gekomen. De rechter zal de gezamenlijke bedoeling van de partijen dan proberen te achterhalen.

 

Vaak blijkt dat één van de partijen tijdens de onderhandelingsfase (of in de factuur) haar aankoopvoorwaarden of verkoopsvoorwaarden heeft medegedeeld. Tussen handelaars wordt normaal aangenomen dat de wederpartij deze voorwaarden heeft aanvaard indien zij hiervan kennis heeft genomen of had kunnen nemen en deze niet heeft geprotesteerd.Veiligheidshalve is het aangewezen om de voorwaarden te laten ondertekenen. Dan kan er immers geen discussie zijn over het feit dat de wederpartij deze heeft aanvaard.

 

Ook wanneer een contract is afgesloten, kunnen algemene voorwaarden worden toegepast ter aanvulling van het contract. Wanneer het contract een bepaald element niet voorziet, dan nog zal toepassing worden gemaakt van de algemene voorwaarden van de partij die deze heeft opgelegd. Daarom voorzien contracten vaak expliciet dat de algemene voorwaarden van de partijen niet van toepassing zijn.

 

D. Instructions to proceed

 

Het onderhandelen van softwareontwikkelingsovereenkomsten neemt vaak zoveel tijd in beslag dat partijen de werken reeds voor de ondertekening ervan aanvatten. Dit geeft soms aanleiding tot problemen daar het verloop van de werken de onderhandeling van de overeenkomst kan beïnvloeden. Zolang geen overeenkomst is gesloten, is het algemene wettelijke regime van toepassing. Dit heeft voor beide partijen zowel voor- als nadelen. Zo is de aansprakelijkheid van de leverancier zonder contractuele clausule tot het tegendeel, onbeperkt. De leverancier zal conform het wettelijke regime alle voorzienbare schade moeten vergoeden indien de overeenkomst niet correct wordt uitgevoerd. De leverancier zal dan ook graag een overeenkomst afsluiten om zijn aansprakelijkheid te beperken. De klant heeft dan weer het probleem dat de auteursrechten op de software ontstaan in hoofde van de leverancier. Indien de klant de overdracht ervan wilt, dient hij aan te dringen op het sluiten van een overeenkomst waarin zulks is voorzien. Deze twee voorbeelden tonen aan dat beide partijen hun eigen juridische belang hebben tot het sluiten van een overeenkomst.

 

Om de nadelen van deze grijze zone te ondervangen, geeft de klant de leverancier vaak ‘instructions to proceed’ In deze ‘instructions to proceed’ zijn enkele basisafspraken gemaakt die gelden tot de inwerkingtreding van de onderhandelde overeenkomst. Zij voorzien vaak ook hoe partijen de samenwerking zullen stopzetten indien zij er tegen een bepaalde datum niet in slagen om een overeenkomst te onderhandelen. Omgekeerd kan de leverancier  bedingen dat zijn diensten, in afwachting van de door partijen gesloten overeenkomst, worden geleverd onder zijn algemene verkoopsvoorwaarden.

 

E. Onderhoudsovereenkomst

 

Software wordt vaak geleverd met een waarborgperiode. Gedurende deze periode staat de leverancier in voor het opsporen en verbeteren van fouten. Maar ook na deze waarborgperiode kunnen er zich problemen voordoen en dient de software van tijd tot tijd te worden aangepast aan de voortgang van de techniek en de softwareomgeving waarin deze opereert. Dit is het onderhoud van de software en wordt geregeld in een onderhoudsovereenkomst. Ook deze overeenkomst is een aannemingsovereenkomst.

 

In de onderhoudsovereenkomst zetten partijen de modaliteiten uiteen waaronder de leverancier de software verder zal onderhouden. Een dergelijke overeenkomst is vrij complex en kan betrekking hebben op vele soorten diensten. Zo kan de ondersteuning geleverd worden vanop afstand of ter plaatse, kan er al dan niet een permanente helpdesk worden voorzien etc. Vaak legt de leverancier ook het gebruik van een ticket-systeem op voor het rapporteren van problemen en gebreken.

 

Belangrijk is te voorzien wat wel en wat niet in het onderhoud is begrepen. Zo wordt vaak voorzien dat bugfixes en patches in het onderhoud zijn begrepen, terwijl nieuwe releases van het programma dit niet zijn. Ook voor de onderhoudsovereenkomst is het verschil tussen resultaatsverbintenis en middelenverbintenis van uitermate belang. Zo zal in de ene overeenkomst de leverancier een probleem dienen op te lossen binnen de vier uren na melding (resultaat), terwijl in een andere overeenkomst de leverancier de werken slechts dient aan te vatten binnen deze termijn (en geen op lossing wordt gegarandeerd). De verschillende gevolgen van deze clausules zijn evident.

 

Vaak wordt er in de onderhoudsovereenkomst onderscheid gemaakt naargelang de ernst van de gebreken. Een kritiek probleem zal evident sneller dienen te worden aangepakt dan een klein probleem. Louter cosmetische problemen worden veelal pas opgelost in de volgende release van het programma, terwijl kritische functies soms binnen de vier uren dienen te zijn opgelost. Eventueel kunnen aan het niet tijdig reageren op problemen voor de leverancier sancties zijn verbonden. Dergelijke sancties zijn veelal Financieel van aard.

 

F. Service Level Agreement

 

In een Service Level Agreement of kortweg SLA, garandeert de leverancier een bepaald niveau van dienstverlening. Veelal is dit het beschikbaar stellen van een computerprogramma gedurende een gegarandeerde minimum periode, bv. een gegarandeerde uptime van 98 procent berekend over iedere zesmaandelijkse periode. Het is zeer belangrijk om na te gaan hoe de beschikbaarheid wordt gemeten: wordt deze gemeten per server of over alle servers heen; over welke periode (hoe korter, hoe strenger); gedurende welke periodes; voor welke diensten etc. Een gegarandeerde beschikbaarheid van 99,9 procent biedt voor de klant geen automatische garantie op een goede service!

 

Maar een goede SLA gaat veel verder dan het beloven van uptime. Wat is men immers met uptime wanneer de zoekopdrachten tergend traag verlopen en het scherm voortdurend bevriest? Daarom is het belangrijk om voor alle kritische punten afzonderlijke criteria te voorzien. Bv. de maximale responstermijn voor een zoekopdracht is 0,2 seconde, blokkerende storingen mogen maar één keer per maand voorkomen, edm.

 

Ook een SLA kan een resultaatsverbintenis dan wel een middelenverbintens zijn. Het spreekt voor zich dat de leverancier zal proberen een middelenverbintenis te negotiëren en de klant zal aandringen op resultaten. Net zoals bij onderhoudsovereenkomsten kunnen aan het niet halen van de vooropgestelde targets sancties zijn gekoppeld.

 

SLA’s worden vaak in niveaus aangeboden in termen van zilver, goud en diamant. Een diamanten dienstverlening zal sneller zijn en meer waarborgen bieden dan een zilveren doch voor een hogere prijs.

 

Een service level agreement maakt vaak deel uit van andere overeenkomsten zoals onderhoudsovereenkomst, hostingovereenkomst, SAAS, etc. 

 

G. SAAS: Software as a service

 

In geval van ‘software as a service’, ook wel ‘cloud computing’ of ‘software on demand’ genoemd, draait het computerprogramma niet langer bij de klant lokaal, maar op de servers van de leverancier (of diens leverancier). De klant hoeft zelf geen eigen software meer te installeren en te onderhouden. De voordelen voor de klant zijn dus legio. Maar toch zitten er addertjes onder het gras. Wie is eigenaar van welke data? Wat als de software gedurende een periode niet beschikbaar is? Wat als de leverancier failliet gaat? Wat als de klant wil overschakelen naar een andere leverancier? Om er maar enkele te noemen.

 

1. SAAS als dienstverlening

 

SAAS is veel meer dan een licentie nemen op software. Er zit een belangrijk aspect dienstverlening aan vast. De leverancier stelt de software immers niet enkel ter beschikking, maar moet er ook voor zorgen dat de software continu beschikbaar en toegankelijk is, adequaat werkt, dat fouten verbeterd worden, data worden opgeslagen, edm. Over al deze elementen moeten goede afspraken worden gemaakt in een service level agreement. Wanneer er hieromtrent geen afspraken worden gemaakt en de leverancier geen garantie geeft betre ffende uptime, toegankelijkheid, het bewaren van data edm., dan nog dient de leverancier een professionele dienstverlening te bieden. Als leverancier is het belangrijk duidelijk te communiceren over de mogelijkheden en beperkingen van zijn service.

 

2. De data van de klant?

 

Een ander belangrijk onderwerp zijn de data van de klant. De leverancier is technisch in staat om kennis te nemen van alle gegevens van de klant. Hieromtrent moeten goede afspraken tot geheimhouding worden gemaakt, zeker wanneer persoonsgegevens betrokken zijn. In dat laatste geval dient de leverancier te waarborgen de Privacywetgeving te zullen respecteren en te zullen voldoen aan de technische vereisten voor de verwerking en beveiliging van dergelijke gegevens (zie hoofdstuk Verwerking van persoonsgegevens).

 

Maar er stelt zich ook een probleem betreffende de eigendom van data. Deze is immers niet altijd duidelijk. Dat de inhoud van een document dat opgesteld is door een werknemer van de klant eigendom blijft van de klant, is logisch en duidelijk. Maar wat als de SAAS systemen van de leverancier metadata hebben toegevoegd, zoals wie wanneer toegang heeft gehad tot het document, wie wanneer welke wijzigingen heeft aangebracht, naar wie het document is verzonden, gecertificeerde tijdstempel, koppeling aan andere bestanden zoals tijdsregistratie en facturatie, edm. Een leverancier kan deze gegevens alszodanig niet gebruiken, maar hij kan ze wel aanwenden om de klant aan zich te binden. De klant riskeert immers waardevolle informatie te verliezen bij het veranderen van leverancier. Het is belangrijk voor de klant om goede afspraken te maken over welke data zijn eigendom worden en hoe hij zijn data naar een ander systeem migreert bij beëindiging van de dienstverlening.

 

Een ander probleem is de back-up van data. Vaak bepalen de voorwaarden van de SAAS leverancier enkel dat dagelijks een back-up wordt genomen. Maar wat houdt dat juist in? Worden enkel defiles opgeslagen of de gehele databank? Is er controle op de correctheid van de back-up? Kunnen de data teruggezet worden en hoe lang duurt dit? Het is voor de klant belangrijk hier een duidelijk zicht op te hebben. Dit kan enkel wanneer de leverancier een duidelijke en transparante back-up procedure heeft.

 

H. Consultingovereenkomst/dienstverleningsovereenkomst

 

Een consultingovereenkomst of dienstenovereenkomst is een overeenkomst waarbij een dienstverlener (de consultant) advies, bijstand of diensten verleent aan de opdrachtgever. Deze bijstand kan een specifieke opdracht betreffen of betrekking hebben op gespecialiseerde kennis die de opdrachtgever zelf niet in huis heeft. In dergelijk geval heeft de overeenkomst een welomlijnd kader.

 

In de praktijk ziet men evenwel dat de consultingovereenkomst ook wordt aangewend als alternatief voor een arbeidsovereenkomst. In plaats van de consultant vast in dienst te nemen, werkt de consultant als zelfstandig dienstverlener. Hierbij dient te worden opgelet dat de opdrachtgever geen werkgeversgezag uitoefent over de zelfstandig dienstverlener. In dergelijk geval is er sprake van schijnzelfstandigheid. Hiervoor wordt verwezen naar het hoofdstuk personeel en zelfstandige medewerkers.

 

Een bijzonder aandachtspunt dat niet voldoende kan worden benadrukt is de overdracht van auteursrechten. De auteursrechten op de door de consultant gemaakte werken (software en andere werken) gaan niet automatisch over op de opdrachtgever, ook niet wanneer de opdrachtgever de ontwikkeling integraal betaalt. De overdracht van auteursrechten dient specifiek in de overeenkomst te zijn voorzien.

 

I. Terbeschikkingstelling personeel

 

Meer en meer bedrijven opteren ervoor om, in plaats van zelf een informaticastaf aan te werven, beroep te doen op het personeel van een toeleverancier. Deze toeleverancier stelt dan een aantal profielen (al dan niet op afroep) ter beschikking van de klant. Dit wordt pejoratief wel eens “body shopping” genoemd. Er dientin het bijzonder op te worden gelet dat partijen niet verzeild raken in illegale terbeschikkingstelling met voor beide partijen onaangename gevolgen.

 

Terbeschikkingstelling van personeel is, uitzendarbeid en tijdelijke arbeid uitgenomen, onder de Belgische wet betreffende de tijdelijke arbeid, de uitzendarbeid en het ter beschikking stellen van werknemers ten behoeve van gebruikers, principieel verboden:

 

“Verboden is de activiteit […], door een natuurlijke persoon of een rechtspersoon wordt uitgeoefend om door hen in dienst genomen werknemers ter beschikking te stellen van derden die deze werknemers gebruiken en over hen enig gedeelte van het gezag uitoefenen dat normaal aan de werkgever toekomt.”

 

Als we deze definitie lezen merken we dat terbeschikking illigaal is van zodra er werkgeversgezag wordt overgedragen aan een derde. Deze derde wordt vaak de gebruiker (van het personeel) genoemd. Negatief geredeneerd, kan uit het verbod worden afgeleid dat terbeschikkingstelling van personeel waarbij het werkgeversgezag niet door de gebruiker wordt uitgeoefend, wel is toegelaten. Deze afweging dient zorgvuldig te gebeuren. Indien het werkgeversgezag, zelfs maar ten dele, door de gebruiker wordt uitgeoefend, valt men onder het verbod. De clausules van de overeenkomst tussen de werkgever en de gebruiker dienen dan ook zorgvuldig te worden opgesteld. Het is van belang dat de overeenkomst derwijze is geschreven en wordt geïnterpreteerd dat zij:

 

– aantoont dat de partijen geen illegale terbeschikkingstelling beogen;

 

– geen clausules of werkwijzen bevatten die kunnen leiden tot een onbedoelde vorm van illegale terbeschikkingstelling;

 

– de gebruiker voldoende ruimte laten om aan de werknemers instructies te geven ter uitvoering van het overeengekomen werk (zonder werkgeversgezag uit te oefenen).

 

Het goed opstellen van een dergelijke overeenkomst is dan ook niet eenvoudig.

 

Natuurlijk volstaat het opstellen van de juiste overeenkomst niet. Wanneer er een discrepantie bestaat tussen hoe partijen vooropstellen om samen te werken (de afspraken in de overeenkomst) en de realiteit op de werkvloer, zullen de administratieve overheden en de rechters door het contractuele scherm heen kijken. Daarom is het van belang dat de partijen niet alleen hun overeenkomsten zo schrijven dat zij geen illegale terbeschikkingstelling beogen, maar de gemaakte afspraken ook in realiteit naleven. Wanneer de gebruiker op de werkvloer het gezag over werknemers uitoefent, zullen contractuele afspraken de werkgever en gebruiker niet beschermen tegen het dwingende verbod van terbeschikkingstelling van personeel.

 

Dit onderwerp wordt in meer detail behandeld (met voorbeeldclausules) in het hoofdstuk personeel en zelfstandige medewerkers.

 

J. Geheimhoudingsovereenkomst

 

De meest efficiente wijze om informatie te beschermen tussen partijen, is het afsluiten van een vertrouwelijkheidsovereenkomst (of Non-Disclosure Agreement, NDA). In een dergelijke overeenkomst komen partijen overeen om de vertrouwelijke informatie van de wederpartij vertrouwelijk te houden. Vaak nemen de partijen deze verplichting niet alleen zelf op, doch verbinden zij zich ertoe om deze ook op te leggen aan hun personeel en onderaannemers.

 

Belangrijk is voor ogen te houden dat een NDA een contract is tussen welbepaalde partijen en dat partijen die de overeenkomst niet hebben ondertekend niet door de verplichtingen ervan gebonden zijn. Wanneer men op NDA’s vertrouwt om informatie geheim te houden, dient men er dan ook voor te zorgen dat alle betrokken partijen hieronder gevat zijn.

 

De term “vertrouwelijke informatie” is vaag. Partijen doen er dan ook goed aan om te definiëren wat zij hieronder verstaan. In de meeste enge vorm wordt vertrouwelijke informatie beperkt tot die informatie die in de bijlage is gevoegd of die anderszins als vertrouwelijk is gemarkeerd. Het andere extreem is de afspraak waaronder alle informatie als vertrouwelijk wordt beschouwd. Maar natuurlijk zijn er ook tussenwegen mogelijk.

 

Voorbeeldclausule:

 

Eng: ” Vertrouwelijke informatie bestaat uit ieder document dat als vertrouwelijk is gemarkeerd.”

 

Tussenin: ” Vertrouwelijke informatie bestaat uit alle informatie die uit haar aard vertrouwelijk is.” (deze definitie blijft zeer vaag)

 

Ruim: “Vertrouwelijke informatie bestaat uit alle informatie waarvan de partijen in het kader van deze overeenkomst kennis krijgen.”

 

Het is ook mogelijk te bepalen welke informatie men niet als vertrouwelijk beschouwt:

 

“Onder Vertrouwelijke Informatie wordt niet verstaan enig document, materiaal, gegeven of informatie waarvan de ontvangende Partij kan aantonen dat die:

 

a. haar reeds bekend was op het ogenblik van openbaarmaking door de openbaarmakende Partij;

 

b. publiekelijk bekend is of wordt zonder dat dit verwijtbaar aan de ontvangende Partij kan worden toegerekend;

 

c. door de openbaarmakende Partij aan een derde partij werd geopenbaard zonder verplichting tot vertrouwelijkheid;

 

d. onafhankelijk door de ontvangende Partij werd ontwikkeld.”

 

Het is ook mogelijk om te bepalen welke maatregelen partijen dienen te nemen om de vertrouwelijke informatie te beschermen:

 

“Partijen zullen alle redelijke maatregelen nemen om de Vertrouwelijke Informatie van de wederpartij vertrouwelijk te houden en zullen de toegang

 

ertoe beperken tot diegenen van hun personeelsleden, toeleveranciers en agenten die er toegang toe dienen te hebben voor de doeleinden als uiteengezet in deze overeenkomst. Partijen zullen deze personeelsleden, toeleveranciers en agenten informeren van de voorwaarden uit deze Overeenkomst en zullen verantwoordelijk zijn voor de naleving van deze voorwaarden door deze personeelsleden, toeleveranciers en agenten.

 

Eens de Vertrouwelijke Informatie niet langer noodzakelijk is voor de doeleinden als uiteengezet onder deze overeenkomst, zal de ontvangende Partij alle kopijen van de Vertrouwelijke Informatie terug bezorgen aan de openbaar makende Partij, of –indien deze dit verkiest- schriftelijk bevestigen dat zij alle kopijen van de Vertrouwelijke Informatie in haar bezit of controle heeft vernield.”

 

Daar het vaak zeer moeilijk is om de schade te bepalen welke ontstaat wanneer de wederpartij de vertrouwelijkheidsverplichting niet nakomt, wordt er vaak een forfaitaire schadevergoeding voorzien in geval van contractbreuk.

 

Aangezien het hier om contractuele afspraken gaat, zijn er vele varianten mogelijk.

 

K. Escrow-overeenkomst

 

Tussen de klant en leverancier van software doet er zich vaak een spanning voor. Een klant die bedrijfszekerheid wenst, wil toegang tot de broncode van de geleverde software applicatie. Mocht de oorspronkelijke leverancier failliet gaan of zijn verbintenissen niet nakomen, kan de klant dan beroep doen op een andere expert voor het onderhoud van zijn applicatie. De leverancier daarentegen, beschouwt de broncode vaak als een bedrijfsgeheim en wil de klant er geen toegang toe geven.

 

De oplossing wordt dan gevonden in escrow. In geval van escrow wordt de broncode in bewaring gegeven bij een derde vertrouwenspersoon. Deze zal de broncode enkel aan de klant vrijgeven in contractueel welbepaalde gevallen, zoals het faillissement van de leverancier en het staken van de  bedrijfsactiviteiten door de leverancier. De precieze voorwaarden worden bepaald in de escrow-overeenkomst. Op deze wijze wordt er een evenwicht gezocht tussen de belangen van de klant en de leverancier.

 

Een escrow-overeenkomst geeft de klant soms een vals gevoel van veiligheid. Het is immers niet omdat men toegang krijgt tot de broncode, dat men de mogelijkheden heeft om deze te activeren. Daar is vaak gespecialiseerde kennis van het programma voor nodig. Het kan zijn dat escrow enkel zin heeft, wanneer de klant ook gespecialiseerd personeel van de leverancier kan overnemen.

 

L. Dading

 

Een overeenkomst die geen typisch informaticacontract is, maar toch voldoende belangrijk is om te worden besproken, is de dading. De dading is een wederkerige overeenkomst tussen partijen die elkaar wederzijdse toegevingen doen om een geschil te beëindigen of te voorkomen, zonder dat een van de partijen de gegrondheid van de aanspraken van de andere partij daarom erkent. Het is dus het middel bij uitstek om een geschil of een twistpunt dat tot een geschil kan leiden, te beëindigen. De dading dient schriftelijk te worden opgemaakt.

 

Let wel, een dading stelt een de finitief einde aan het geschil dat het voorwerp is van de dading. Achteraf kan hierop niet meer worden teruggekomen. Wanneer de dading door de contractspartij niet correct wordt uitgevoerd, dient men zich tot de rechter te richten om de uitvoering van de dading te eisen en kan men zich niet meer beroepen op de onderliggende gronden. Over de onderliggende gronden van de dading wordt immers niet meer geoordeeld. De dading is geregeld in artikelen 2044 e.v. BW.

 

M. Informaticaverzekeringen

 

Wanneer een verzekeringspolis wordt afgesloten, is het uiterst belangrijk goed te begrijpen voor welke activiteiten dekking wordt verleend en welke activiteiten specifiek van dekking zijn uitgesloten. Standaard verzekeringspolissen sluiten typisch informaticadiensten zoals informaticaconsultancy, hosting en dergelijke meer uit. Ook aansprakelijkheid voor inbreuken op intellectuele rechten wordt standaard uitgesloten.

 

Indien men zich als leverancier of als klant wil indekken voor informaticarisico’s zoals falen van hardware, computerfraude, aansprakelijkheid van leveranciers voor informaticaproducten, hosting, databanken, wedersamenstelling van gegevens, etc. dient men bij de verzekeringsmakelaar naar een specifieke polis te informeren.

 

De meeste polissen bevatten belangrijke uitsluitingen en dienen grondig te worden bestudeerd om na te gaan of zij een voldoende dekking bieden. In geval van informaticaproducten is het ook van belang na te gaan welke internationale dekking de polis biedt. Verzekeraars zijn veelal weigerachtig om ook in de Verenigde Staten dekking te verlenen.