Is een deadline in de ICT-branche fataal?

Onderstaand stuk is geschreven als wetenschappelijk essay over een casus van de studentenrechtbank van de Rijksuniversiteit Groningen. Een afsluitend onderdeel van de bachelor Rechtsgeleerdheid.

Inleiding

We leven heden ten dage in een maatschappij welke gedomineerd wordt door een informatiesamenleving. Velen zijn volledig afhankelijk van automatiseringssystemen. De rol van leveranciers hiervan groeit met de dag. De informatiesamenleving ontwikkelt snel en is fragiel. Het is dan ook geen wonder dat er ellenlange contracten worden gesloten om alle gaten te dichten voor een ICT-project. Toch gaat het vaak genoeg fout.1 Maar, gelet op de invloedrijke rol van leveranciers en hoe afhankelijk men tegenwoordig van hen is, zijn veelal de leveranciers het beste beschermd in dergelijke overeenkomsten. Afnemers zijn daarom meestal de dupe van de jonge en onervaren ICT-sector. Maar, wat als er nou geen algemene voorwaarden aanwezig zijn? Hoe zou dan een geschil verlopen? Dit stuk zal aan de hand van een fictieve casus beschouwen wat in zulke gevallen de stand van zaken is.

Fictieve casus

Stel, u wilt een nieuw automatiseringssysteem en huurt hiervoor een entiteit in. In alle haast en onwijsheid vergeten zowel u als de leverancier een contract te sluiten. Er is alleen een papiertje met een summiere omschrijving van de opdracht en een datum voor ingebruikname. Gedurende het project geeft u enkele meerwerken. Helaas vergeet u bij het verstrekken van benodigde gegevens voor de ontwikkeling cruciale data, ondanks enkele aanmaningen van de leverancier. Daarbij verwatert de sturing vanuit uw bedrijf naar de leverancier wegens een interne reorganisatie. Nu, enkele maanden na het verstrijken van de datum van ingebruikname, is het systeem in gebruik. Ondanks dat het systeem bruikbaar is missen er enkele vitale eigenschappen voor een volledig systeem zoals overeengekomen. Na wikken en wegen vindt u de kwaliteit van de leverancier ontoereikend, u heeft echter wel kosten gemaakt en wilt daarom een schadevergoeding. Wat kunt u doen om van de overeenkomst af te komen? En hoe zit het dan met het gemaakte werk, wie is rechthebbende van de broncode? Aan de hand van deze casus zal het stuk enkele rechtsvragen beantwoorden.

Rechtsvragen

Dit document beperkt zich tot enkele kern-rechtsvragen welke doen rijzen uit de fictieve casus:

  • Mag de afnemer eenzijdig ontbinden?
    • Is er sprake van verzuim, en;
    • Is er sprake van schuldeisersverzuim?
  • Wie verkrijgt het intellectueel eigendom?

Eenzijdige ontbinding

Allereerst, de eenzijdige ontbinding. Dit kan indien nakoming door de leverancier tijdelijk of blijvend onmogelijk is, anders is verzuim vereist. Meestal, en in casu, is de nakoming niet tijdelijk of blijvend onmogelijk bij ICT-projecten. Immers, de leverancier kan het systeem nog steeds ontwikkelen. Hierom dient er dan ook sprake te zijn van verzuim. Verzuim is ook vereist voor een eventuele schadevergoeding.

Verzuim

Zoals hierboven beschreven is doorgaans verzuim nodig voor een eenzijdige ontbinding. Voor verzuim is in beginsel een ingebrekestelling vereist. Ook dient de prestatie opeisbaar te zijn. Ingevolge artikel 6:83 Burgerlijk Wetboek (BW)  dient voor opeisbaarheid eerst het afgesproken termijn, niet zijnde een streefdatum, te zijn verstreken.2 Afnemer zou na het verstrijken van de termijn de leverancier in gebreke kunnen stellen, waarna deze in verzuim treedt. Belangrijk om in acht te nemen is dat meerwerken de omvang van een overeenkomst vergroot, dientengevolge hebbende dat de opeisbaarheid aangetast kan worden.3 Daartegenover staat dat de leverancier een informatieplicht heeft, voortvloeiend uit diens zorgplicht, in het geval van meerwerken, met een mogelijke tekortkoming van de leverancier als gevolg.4 Ook de omvang van een overeenkomst kan door nalaten van de informatieplicht worden aangetast. 5 Interessanter is of rechtstreeks verzuim een alternatief biedt. Hiervoor dient een gegeven termijn als fataal gekwalificeerd te worden.

Fatale termijn

Wanneer is er sprake van een fatale termijn? Blijkens 6:93 BW is een opleverdatum een fatale termijn. De rechtspraak nuanceert echter de bepaling. De Hoge Raad oordeelt dat zo’n termijn, óf duidelijk moet zijn overeengekomen dat het een fatale termijn betreft én voldoende is gespecificeerd, óf zo’n termijn ontleent diens fatale karakter op grond van redelijkheid en billijkheid voortvloeiend uit de aard van de overeenkomst met inachtneming van de omstandigheden van het geval.6

Hieruit concluderend dient onderzocht te worden of een termijn duidelijk gekenmerkt is als fataal of dat er zich anderzijds omstandigheden voordoen die een termijn als fataal kan doen kwalificeren.

Termijnen in de ICT-branche

De hoofdregel is helder, een gegeven termijn is fataal.7 Een termijn dient voldoende omschreven te zijn. Niet is vereist om een exacte dag aan te wijzen.8 Hierom zal er veelal geen probleem zijn om aan te nemen dat zo’n fatale termijn aanwezig is. Het is dan aan de leverancier om aannemelijk te maken dat een gegeven termijn niet een fatale strekking heeft.9

Dit gezegd hebbende, in lijn der rechtspraak zal naar waarschijnlijkheid een datum niet als fatale termijn worden gekenmerkt bij leveranciers van informatiesystemen. De automatiseringsbranche geniet van een speciale ‘eigenschap’. Geredeneerd aan de hand van het Haviltex-criterium dient gemaand te worden dat termijnen bij automatiseringsprojecten in beginsel niet fataal zijn.10 Dit ligt inherent aan de aard van zulke projecten. Immers, “feit van algemene bekendheid is dat automatiseringsprojecten kunnen uitlopen, en uitlopen ook vaak plaats vindt“.11 Waarachtig, bij overlegging van een deskundigenverklaring die een termijn als fataal kwalificeert oordeelt de rechter dat hier geen sprake van is.12 Dat dit afgeleid is vanuit het Haviltex-criterium is evident zichtbaar in een uitspraak van het Hof van Amsterdam, welke de rechtsregel van het arrest doet weerchallen.13 Een uitzondering op de hierboven beschreven exceptie is wanneer onmiskenbaar is aangegeven dat het een uiterste datum betreft.14 Kortom, de leverancier van automatiseringssystemen geniet van veel rechtsbescherming.

Zoals net aangegeven is het niet onmogelijk om termijnen in de ICT-branche te laten kwalificeren als fataal. Indien blijkt uit de strekking van de overeenkomst dat oplevering op het gestelde termijn noodzakelijk is voor de afnemer en dit bekend is bij de leverancier, dan spreekt men wél van een fatale termijn.15 Afnemer zal deze noodzakelijkheid moeten bewijzen, na een gemotiveerde betwisting van de leverancier. Een ander gegeven om een fatale termijn vast te stellen is de aanwezigheid van een boetebeding.16 Hierop concluderend is het dus niet onmogelijk voor een afnemer om een termijn fataal te doen aanduiden.

Is het vreemd dat de rechtspraak zo omgaat met termijnen binnen de ICT-branche? Enerzijds wel. Het schaadt de rechtszekerheid van afnemers. Immers, hoe weet de afnemer nu wanneer een afgesproken termijn daadwerkelijk fataal is? Opmerking hierbij verdient dat de rechtspraak het niet altijd, wel in overwegende mate, uitlegt in voordeel van de leverancier. De rechtspraak is nog op zoek.17 Aan de andere kant is het logisch dat de rechtspraak op deze wijze een termijn invult. Gelet op de aard van automatiseringscontracten is de kans klein zulke projecten zullen slagen. Het slagingspercentage schommelt tussen de 60% voor kleine en 2% voor grootschalige automatiseringsprojecten.18 Wel is een trend zichtbaar, de opkomende projectmethode ‘agile’ heeft een hoger slagingspercentage dan de verouderde waterfall-methode. In het licht van beide aspecten zou wegens het maatschappelijke belang de ICT-branche de tijd dienen te krijgen om zich te professionaliseren. Echter, wegens de rechtsbescherming van de maatschappij in het algemeen zou dit niet eindeloos moeten voortduren. Op den duur zou de rechtspraak er dan ook goed aan doen om de aard van automatiseringscontracten uiteindelijk ook voor rekening te laten vallen voor de leverancier. Maar nu nog niet.

Kortom, de leverancier geniet een groot voordeel als het gaat om fatale termijnen. De afnemer staat echter niet machteloos. Indien deze voldoende aannemelijk maakt dat nakoming van de termijn noodzakelijk is of ondubbelzinnig heeft aangegeven dat het een uiterste termijn betreft, kan de afnemer diens gelijk halen. Maar als afnemer dien je rekening te houden met dat er meestal geen sprake is van een fatale termijn en dus verzuim. Echter zou de rechtspraak er zich goed aan doen, gelet op de rechtsbescherming, om uiteindelijk het niet maatschappelijk betamelijk te achten dat termijnen bij automatiseringsovereenkomsten in beginsel niet fataal zijn.

Doormodderdoctrine

Veelal, en zo ook in de fictieve casus, wordt een termijn niet gehandhaafd door de afnemer. Men wil veelal toch het automatiseringssysteem verkrijgen en is hiervoor afhankelijk van de leverancier of een ander kostbaar en langdurig alternatief. De afnemer zal daarom trachten het project weer in goede banen te leiden zodat deze uiteindelijk toch opgeleverd kan worden. Dit wordt ook wel ‘doormodderen’ genoemd.

De termijn zonder consequentie, bijvoorbeeld door geen ingebrekestelling sturen, laten ‘doormodderen’ heeft als gevolg dat de rechtspraak inhoud geeft aan de overeenkomst aan de hand van de daadwerkelijke uitvoeringen. Dit betekent doorgaans dat het verstrijken van een termijn niet zonder meer tot verzuim van de leverancier leidt.19

Hierom kan het voortzetten van een project door de afnemer, zonder hier consequenties aan te bieden, tot gevolg hebben dat een verstreken termijn geen verzuim oplevert en daardoor een eenzijdige ontbinding niet rechtvaardigt.

Schuldeisersverzuim

Mocht er sprake zijn van verzuim wegens overschrijding van een fatale termijn, dan is het van belang te zien of er sprake is van schuldeisersverzuim. Immers, schuldeisersverzuim heft het verzuim van een schuldenaar op. Ook indien een fatale termijn is verstreken.20 Op grond van artikel 6:64 BW ligt het risico bij de schuldeiser.

In de fictieve casus is duidelijk sprake van schuldeisersverzuim. Door niet de noodzakelijke gegevens te overleggen kan de leverancier niet behoorlijk nakomen. De vraag blijft of een reorganisatie zoals geschetst in de casus voldoende is om aan te merken als een belet, nakoming wordt immers niet onmogelijk gemaakt.

Na afloop van schuldeisersverzuim kan het verzuim van de schuldenaar weer intreden. Dit gebeurt uiteraard niet rechtstreeks. Maar wanneer gaat de leverancier wel in verzuim indien daar gronden voor zijn?

Het antwoord op bovenstaande vraag is simpel, maar een specifiek moment aanduiden is lastig. De leverancier treedt weer in verzuim nadat deze tot in redelijkheid tot nakoming in staat is. Dan pas verloopt het schuldeisersverzuim en treedt verzuim van de leverancier in werking.21 Doordat dit pas na ‘redelijke’ tijd is verschilt het per geval. Daarom dient naar de omstandigheden van het geval gekeken te worden. Wanneer zou een normale leverancier de nakoming hebben verricht? Gedurende deze periode, wat vertraging oplevert en dus mogelijk schade met zich meebrengt, kan de afnemer zich niet op vertragingsschade beroepen. Immers, de leverancier is gedurende de periode van schuldeisersverzuim niet in verzuim. Hierom kan schuldeisersverzuim een kostbare fout zijn van de afnemer.

Een afnemer zal zich goed doen door op tijd alle vereiste benodigdheden te verstrekken. Immers, schuldeisersverzuim treedt zo in indien het de leverancier belet na te komen. De afnemer kan zich eenvoudig verschonen, hier gaat echter, veelal ongewenste, tijd overheen. Ook staat het eenzijdige ontbinding in de weg doordat het verzuim van de leverancier opheft.

Intellectueel eigendom

Het auteursrecht is duidelijk over wie rechthebbende is over de broncode. Artikel 10 lid 1 sub 12 jo. Artikel 1 Auteurswet kent de rechten toe aan de maker, de leverancier. De afnemer zal trachten aanspraak te maken middels artikel 6 Auteurswet. Hiervoor gelden echter mate van intensiteit van het leiderschap en toezicht.  Het hebben van zeggenschap is onvoldoende.22 Vereist is dat afnemer zodanig de leverancier inspireert dat de leverancier niet meer van een eigen schepping kan spreken.23 Dit betekent dat de afnemer de creatieve keuzes dient te maken tijdens het programmeren. Dit zal in de praktijk zelden voorkomen, immers, de afnemer huurt de leverancier in omdat zijzelf expertise mist.

Daarom betekent dit dat in beginsel de leverancier het auteursrecht verkrijgt bij afwezigheid van algemene voorwaarden.

Conclusie

Ook zonder algemene voorwaarden staan leveranciers van automatiseringssystemen er juridisch sterk voor. Er kan niet zomaar eenzijdig ontbonden worden door de afnemer, verzuim is vereist. Verlopen termijnen zijn in beginsel niet fataal in de ICT-branche. Dit klinkt vreemd, maar is te rechtvaardigen gelet op de aard van automatiseringsovereenkomsten. Het overgrote deel haalt een afgesproken termijn niet. Maar gelet op de rechtsbescherming zou op den duur de rechtspraak hierop terug moeten komen. Als een termijn wel fataal is dan wordt deze kwalificatie snel opgeheven door voortgang van het project zonder consequenties, doormodderen. In het geval de afnemer een fout maakt waardoor de leverancier niet kan nakomen, dan komt dit voor zijn rekening. Dit zal vertraging opleveren voor de afnemer én komt voor zijn eigen rekening. Gedurende die periode kan de leverancier niet in verzuim raken. Tot slot krijgt standaard de leverancier het auteursrecht over de gemaakte werken.

Kortom, zonder algemene voorwaarden staat een afnemer er misschien nog slechter voor. Het zou een afnemer goed doen duidelijke afspraken te maken. Bijvoorbeeld, maar niet beperkt tot, het ondubbelzinnig aangeven wanneer een termijn fataal is, afspraken maken over meerwerken en vastleggen dat auteursrechten worden overgedragen. Maar al met al, wie gaat er dan ook een groot automatiseringsovereenkomst aan zonder algemene voorwaarden? Ook staat het een eenzijdige ontbinding in de weg doordat er gedurende de periode geen sprake is van verzuim.

Footnotes

  1. In 2004, toen ICT nog een fractie was van nu, is naar schatting vier tot vijf miljard gespendeerd aan mislukte ICT-projecten in Nederland. Zie ook het rapport van de Rekenkamer “Lessen uit ICT-projecten bij de overheid”, 2007.
  2. Rb. Overijssel 4 september 2013, ECLI:NL:RBOVE:2013:2397 (Centric/Wehkamp).
  3. Rb. Utrecht 4 juli 2012, ECLI:NL:RBUTR:2012:BX5826 (I-aspect).
  4. Hof ’s-Hertogenbosch 3 november 2015, ECLI:NL:GHSHE:2015:4428 (TsZ/Alert).
  5. Hof Den Haag 31 maart 2015, ECLI:NL:GHDHA:2015:1113 (Exact/Brandmeester’s).
  6. HR 4 oktober 2002, NJ 2003, 257 (Fraanje/Götte).
  7. Groene Serie Verbintenissenrecht, art. 6:83, aant. 13, bijgewerkt tot 7 oktober 2015.
  8. Groene Serie Verbintenissenrecht, art. 6:83, aant. 14, bijgewerkt tot 7 oktober 2015
  9. Groene Serie Verbintenissenrecht, art. 6:83, aant. 12, bijgewerkt tot 7 oktober 2015.
  10. Hof ’s-Hertogenbosch 3 november 2015, ECLI:NL:GHSHE:2015:4428 (JsZ/Alert).
  11. Rb. Amsterdam 7 april 2004 (Masalco/PinkRoccade).
  12. Hof Amsterdam 9 juli 2013, ECLI:NL:GHAMS:2013:2121 (Tyco/Inter Access).
  13. Hof Amsterdam 21 juli 2015, ECLI:NL:GHAMS:2015:3021, ro 3.7.
  14. Rb. Rotterdam 12 maart 2010 (VVD/Perfecte Database).
  15. Hof ’s-Hertogenbosch 22 januari 2013, ECLI:NL:GHSHE:2013:BY9487 (Decon).
  16. Asser/Hartkamp & Sieburgh 6-I*, 2012/393.
  17. Zie bijv. Hof Amsterdam 21 juli 2015, ECLI:NL:GHAMS:2015:3021 en Rb. Oost-Nederland 6 februari 2013, ECLI:NL:RBONE:2013:BZ1358.
  18. Standish Group, ‘Chaos Report 2015’, 2015.
  19. Rb. Den Haag 24 december 2014, ECLI:NL:RBDHA:2014:16568 (Elips/De Goudse). Rb. Utrecht 8 juli 2009, ECLI:NL:RBUTR:2009:BJ2078, Computerrecht 2009, 228.
  20. HR 15 december 2006, RvdW 2007, 7.
  21. HR 11 juli 2014, ECLI:NL:HR:2014:1643, NJ 2014/361.
  22. Hof Den Haag 10 december 2013, ECLI:NL:GHDHA:2013:5335 (Promodyne).
  23. HR 28 juni 1940, NJ 1941, 110 (Fire over England).
There are no comments published yet.

Reply.