Internetrecht door Arnoud Engelfriet

Taiwanese iOS-gebruikers mogen apps 7 dagen testen, las ik bij iPadclub. De Taiwanese wet koop op afstand blijkt ook te gelden voor digitale producten zoals apps voor iPads en Android apparaten. Apple heeft gemeld haar beleid aan te passen, maar Google weigert meer dan 15 minuten retourtermijn te geven en incasseert de boetes vooralsnog.

Bij ons geldt er geen retourrecht voor apps, behalve dan wat je vrijwillig aangeboden krijgt in de algemene voorwaarden. In het Android-geval dus 15 minuten, en bij Apple bij mijn weten helemaal niet. Software wordt wel genoemd in de Wet koop op afstand, maar dan alleen als uitzondering: software mag alleen worden geretourneerd als deze in de originele verzegeling zit. Want die wet komt uit een tijd dat downloaden van software alleen iets voor bebaarde hippies was.

De op stapel staande richtlijn over consumentenrechten moet daar verandering in brengen. De recent goedgekeurde regels kiezen een andere insteek: downloadbare software wordt niet als product gezien en valt dus niet onder de gewone Wet koop afstand. Wel wordt het downloaden van software expliciet als dienst gemarkeerd, en die mag worden geannuleerd binnen 14 dagen (nieuwe regel) mits het downloaden nog niet is begonnen.

Dat lijkt me een iets betere aanpak dan de Taiwanese insteek. Menig app heb je binnen een week wel gezien lijkt me, zeker spelletjes, en de kans op misbruik lijkt me wel erg groot in die situatie. Een app kopen is voor mijn gevoel wat anders dan een boek of een paar sokken. Aan de andere kant, enige mogelijkheid tot uitproberen lijkt me wel een goed idee voor software. Niet voor niets was shareware/trialware lange tijd zeer populair. (Hoewel, wie kócht daadwerkelijk zijn shareware?)

Arnoud

Microsoft moet i4i 300 miljoen dollar betalen voor patentschending, nadat alle bezwaren zijn verworpen, meldde Webwereld vrijdag. Er wordt voor een invasie van patenttrollen gevreesd, omdat de Supreme Court de bewijsregels in patentrechtszaken wel heel pro-patenthouder lijkt te formuleren. Het patent van i4i is geldig, omdat Microsoft geen “helder en overtuigend” bewijs van het tegendeel heeft. Maar i4i hoeft slechts aan te tonen dat het “waarschijnlijk” is dat Microsoft het octrooi schendt om een verbod toegewezen te krijgen.

i4i is een Canadees bedrijf dat software maakt voor documentbeheer. Hun patent (US5,787,449) betreft een techniek om structuur en inhoud van een document apart te kunnen beheren, die gebruik maakt van metacodes in een aparte datastroom. Het patent is uit 1994 en heeft elke aanval weten te overleven. In 2009 werd Microsoft veroordeeld omdat Word inbreuk zou maken met het .DOCX en .DOCM bestandsformaat.

Microsoft had bij de procedure diverse prior art systemen gevonden, maar liep tegen een procedureel probleem aan: de jury(*) kreeg als instructie dat ze alleen het octrooi ongeldig mocht verklaren als de prior art “clear and convincing evidence” bevatte dat de uitvinding al bestond. Dat is een hoge eis, hoger dan de gebruikelijke “preponderance of the evidence”. En die laatste standaard mocht dan weer wél gebruikt worden om te bepalen of Microsoft inbreuk maakte en dus Word van de markt moest halen.

De Supreme Court in haar arrest (pdf) nu dat dit verschil juist is. Dit omdat het USPTO de patentaanvraag heeft onderzocht, en we toch mogen verwachten (hah!) dat deze daarbij zorgvuldig en grondig te werk gaat. Daarom is het terecht om in die situatie een extra hoge eis te stellen aan waar de gedaagde mee komt.

Webwereld vreest dat patenttrollen zich gesterkt zullen voelen door dit arrest. Logisch, de Supreme Court bevestigt hier dat het inderdaad moeilijk is een octrooi aan te vechten. Bovendien kost dat al snel enkele miljoenen Euros. Maar een kenmerk van trollen is dat ze zelden procederen, en liever een relatief laag bedrag eisen om zo snel binnen te lopen. Veel door trollen ingezette octrooien zijn zeer dubieus, maar als je moet kiezen tussen 1 miljoen betalen en 4 miljoen in een rechtszaak steken dan is -zakelijk gezien- de keuze duidelijk.

i4i lijkt me overigens geen patenttrol: zij verkopen eigen producten, en onder trollen worden over het algemeen alleen bedrijven verstaan die octrooien opkopen en licenties gaan eisen zonder zelf iets op de markt te brengen.

(*) In de VS worden octrooirechtszaken door een jury beslist. Daarbij is het gebruikelijk dat alle mensen met technische achtergrond worden uitgesloten van de jury, omdat die bevooroordeeld zouden zijn. Inderdaad betekent dat dat zaken over complexe technologie beslist worden door mensen met per definitie geen verstand daarvan.

Arnoud

Over een week of drie te koop: ons boek Software: Deskundig en praktisch juridisch advies. Met dank aan alle reageerders die onderwerpen aandroegen. (En ik had nog een vraag aan jullie, hieronder.)

Hoofdstuk 1. Software juridisch bekeken
Bescherming van een idee
De geschiedenis van software
De keuze van de juiste bescherming
De grenzen opgezocht
Octrooi op computerprogramma’s
De opkomst van open source
Software als dienst

Hoofdstuk 2. Auteursrecht op software
Eigen intellectuele schepping
Rechten op grond van software-auteursrecht
Backups van software
Reverse engineeren en decompileren
Handhaving en naleving
De rechthebbende op software

Hoofdstuk 3. Softwarelicenties
Het sluiten van licentieovereenkomsten
De bindendheid van licentievoorwaarden
Belangrijke licentievoorwaarden

• Geautoriseerd gebruik en doel
• Betaling of andere tegenprestatie
• Beperkingen van aansprakelijkheid
• Exportrestricties
• Aanpassen van de voorwaarden
• Toegang tot broncode
• Overdraagbaarheid van de licentie
• Duur en opzegging

Hoofdstuk 4. Softwareontwikkeling juridisch bekeken
Overeenkomst van opdracht
Oplevering en aanvaarding
De positie van standaardcomponenten
Onderhoudscontracten
Fouten, bugs en conformiteit
Omgaan met mislukkingen

Hoofdstuk 5. Octrooi op software
Octrooieerbaarheid van software
De procedure om octrooi te krijgen
Europees octrooi
De kosten van een octrooi
Het nut van een octrooi
Wel of geen octrooi?

Hoofdstuk 6. Open source software
Uitgangspunten van open source
Soorten open source
GPL versie 3
Werken met open source
Afgeleide werken
Unieke risico’s, unieke kansen

Hoofdstuk 7. Software in de wolken
Licentieovereenkomsten bij cloud computing
Support en ondersteuning
Het maken van backups
Eigendom van data
Privacy en persoonsgegevens
Softwaredienstverlening en faillissement

Onze ontwerpster Jolie is nu druk bezig met de vormgeving. Een preview:

Het boek gaat 19,95 kosten. Wie voorintekent, betaalt geen verzendkosten. Wie nog leuke promotie-acties weet: ik houd me aanbevolen!

En nu de vraag terug, want zo’n aankondigblog is misschien wat saai. Ik hoor veel over Bitcoin maar ik kan maar moeilijk ontdekken hoe dat nu moet gaan werken. Is er ergens een begrijpelijke uitleg van de techniek? Zodra ik het snap, zal ik bloggen of dit legaal in te zetten is in Nederland

Arnoud

Een lezer vroeg me:

Enkele jaren terug hebben wij een softwarepakket laten maken door een leverancier. Eigenlijk hadden wij daar vanaf het begin geen goed gevoel bij. Alles kostte geld, van een extra feature tot corrigeren van taalfoutjes aan toe.

Een maand geleden kregen we echter een nieuwe aankondiging die voor ons de druppel is: we worden verplicht een servicecontract af te nemen van 1200 euro per jaar, en anders wordt de licentie ingetrokken. We hebben 2 maanden om te beslissen, en in de tussentijd krijgen we bij elke keer opstarten een melding dat dit eraan gaat komen. Kan dat zomaar?

Deze vraag is in het algemeen moeilijk te beantwoorden, omdat het antwoord voor 99% afhangt van het contract. Maar het is denkbaar dat het antwoord “ja, dat kan zomaar” luidt.

Hoofdregel bij software is dat de leverancier alle auteursrechten op de software heeft. Alleen als er schriftelijk (en ondertekend) is gezegd dat de rechten naar de opdrachtgever gaan, heeft de opdrachtgever de rechten. En wanneer de leverancier de rechten heeft, bepaalt hij op welke manier de klant gebruik mag maken van de software. Ja, ook als het maatwerk is.

Het wijzigen van het contract kan alleen als in het contract staat dat de leverancier dat mag doen. Maar vrijwel elk contract bevat zo’n beding, ergens verstopt tussen toepasselijk recht, overmacht en de clausule dat kopjes in het contract niet in de interpretatie van de artikelen mogen worden betrokken (wtf?). Daarmee kan de leverancier dus vrij eenvoudig elke nieuwe licentieconstructie doorvoeren.

Het gaat nogal ver om ineens een servicecontract met hoge extra kosten te introduceren, maar in principe kan het dus wel. Wie zijn softwarelicenties dus niet goed leest, kan tegen dit soort verrassingen aanlopen.

Slimme klanten bedingen dus het eigendom op de software (of kiezen open source) zodat ze dit probleem niet hebben.

Arnoud

Als je afspreekt dat je software alleen mag verspreiden in versleutelde vorm, maar er zit open source in, schend je dan de licentie door toch broncode vrij te geven? Jaja, het lijkt er zowaar op dat we een vonnis hebben over de ‘virale’ werking van open source. Maar dat valt vies tegen: de rechtbank doet geen uitspraak (via) over de bindendheid van de ‘open licenties’ omdat de licentienemer deze er eenvoudig uit had kunnen slopen.

Het bedrijf Purple Pigeon had software (’Eigen Chatbox’, ‘WebAgenda Multi-User’, ‘WebEnquete PRO’, ‘Web to Go Personal’ en ‘Web To Go Professional’) ontwikkeld, en met Quinarx een exclusieve distributieovereenkomst gesloten. Die werd later omgezet in een nieuwe overeenkomst, waarbij afgesproken werd dat de broncode te allen tijde gecodeerd (versleuteld) zou moeten worden met een pakket als SourceCop. Ook moest altijd het copyright van Purple Pigeon worden vermeld.

In 2010 constateerde Purple Pigeon dat de software nog steeds werd verkocht, en ook nog eens met vrij beschikbare broncode en zónder auteursvermelding van PP. Volgens Quinarx was daar geen sprake van, waarop Purple Pigeon naar de rechter stapte en een terughaalactie (recall) eiste plus een schadevergoeding.

Eén van de verweren van Quinarx was dat het programma open source bevatte, en dat het daarom niet zomaar versleuteld verspreid mocht worden. Op zich een terecht verweer: de GPL bijvoorbeeld verbiedt zulke distributie, de broncode moet er echt bij zitten (of op verzoek nageleverd worden). Maar de rechter oordeelt dat je als licentienemer niet zomaar eenzijdig mag besluiten om dan de broncode maar openbaar te maken. Als je zo’n compliance probleem signaleert, moet je de rechthebbende benaderen en ze daarop wijzen.

Terecht, maar jammer dat dit punt niet nader is uitgewerkt. Ik had wel eens willen zien wat de rechter zou zeggen van het verweer dat Quinarx (en ook Purple Pigeon) gewoon gebonden was aan de GPL en daarom wel moest handelen op deze manier.

Arnoud

In januari meldde ik al dat het er aan zat te komen: het boek Software: Deskundig en praktisch juridisch advies. De tekst vordert gestaag, en ik zou dan nu ook graag jullie feedback krijgen op de inhoudsopgave. Nu kan er nog wat bij of af

1. Software juridisch bekeken
   • De prehistorie van software
     • Softwarepools
     • Een markt voor software
     • De keuze van de juiste bescherming
     • Vier modellen
   • De keuze voor auteursrecht
   • De grenzen opgezocht
     • Geen bescherming voor concepten
     • Structuren en processen
     • Bescherming van een idee
   • Octrooi op computerprogramma’s
   • De opkomst van open source
   • Software als dienst
2. Auteursrecht op software
   • Rechten op software
     • kopiëren
     • gebruiken
     • verspreiden
   • Uitzonderingen volgens de wet
     • backups
     • reverse engineering
     • uitputting
   • Handhaving en naleving
     • BSA
     • technische maatregelen (DRM)
     • strafrecht
   • Eigenaar van software
     • werkgever/werknemer
     • freelance/inhuur

3. Softwarelicenties
   • Uitgangspunten bij licenties
   • EULA’s
     • akkoord gaan met (algemeen)
     • shrinkwrap/clickwrap specifiek
     • bindendheid inhoud (consumentenrecht)
   • Licenties en appstores
   • Onderhoudsverplichtingen
   • Escrow van broncode

4. Octrooi op software
   • Octrooieerbaarheid van software
     • Softwareoctrooien in Europa en de VS
     • Softwareoctrooien in de praktijk
   • Procedure om octrooi te krijgen
     • Opstellen van de aanvraag
     • Publicatie van de aanvraag
     • Nieuwheidsonderzoek
     • Beoordeling van de octrooieerbaarheid
     • Europees octrooi
   • Kosten van een octrooi
   • Het nut van een octrooi
     • Exclusiviteit
     • Actief licentiëren
     • Passief gebruik
     • Innovatiebox
   • Wel of geen octrooi?

5. Open source software
   • Uitgangspunten van OSS
   • Soorten open source
     • BSD-achtig
     • Mozilla-achtig
     • GPL-achtig
     • GPL versie 3
   • Linken/combineren met open source
   • Bindendheid/rechtsgeldigheid open source
   • Bedrijfsmodellen bij open source

6. Software as a service
   • Uitgangspunten van SaaS
   • Beschikbaarheid/downtime regelen
   • Aansprakelijkheid/schade bij downtime
   • API’s aanbieden
   • Persoonsgegevens bij SaaS
   • Beschikbaarheid van data in SaaS (export)
   • Escrow en continuïteit van SaaS bij faillissement

We hopen eind mei te kunnen publiceren

Arnoud

Het is ‘onzinnig en schadelijk’ als digitale diensten zoals cloud computing en betaalde downloads en streams in de nieuwe Europese regels voor consumentenbescherming worden opgenomen, las ik bij Webwereld woensdag. De softwarelobbygroep is er fel op tegen dat software en online diensten onder het consumentenrecht geschaard worden, wat het plan is met de in behandeling zijnde Consumentenrechtenrichtlijn.

Het zal wel aan mij liggen, maar de reactie van de BSA vind ik dan weer onzinnig:

Er ontstaan hierdoor namelijk hele rare en mogelijk schadelijke situaties, schetst Francisco Mingorance van de BSA. Zo eist de nieuwe richtlijn dat producten bij het afleveren niet defect zijn. Dit zou softwareleveranciers ontslaan van de plicht om later patches en updates te leveren, ten nadele van de consument.

Dat is natuurlijk niet wat “niet defect mogen zijn” betekent. Wat er nu al in de wet staat - en de ontwerprichtlijn niet verandert - is dat als producten tóch defect zijn, de winkelier die gratis moet herstellen. Of dat voor software geldt, is onduidelijk, hoewel in juni het Gerechtshof Arnhem oordeelde van wel. Lijkt me ook niet meer dan terecht eigenlijk.

Overigens betekent de conformiteitseis niet dat software per se foutvrij moet zijn. Als inherent aan software is dat er enige fouten in zullen zitten, dan hoort dat bij de redelijkerwijs gewekte verwachtingen. En díe bepalen waar je recht op hebt. Zeg maar, je weet dat Windows lek zal zijn maar dat er updates komen, dus meer dan updates bij ontdekte lekken kun je niet verwachten.

Door dit artikel werd ik wel weer geprikkeld om die ontwerprichtlijn eens te gaan lezen. Deze heeft als doel alle consumentenrechtgerelateerde richtlijnen te consolideren én de positie van de consument meteen maar te versterken.

Ik had goede hoop dat men software er ook expliciet onder zou schuiven, maar dat zie ik nergens in de tekst terug. Het enige dat ik over software zie, is de uitzondering op het retourrecht die nog steeds geformuleerd is alsof het 1995 is:

de levering van verzegelde audio- en video-opnamen en computerprogrammatuur waarvan de verzegeling door de consument is verbroken;

Kennelijk zwerft er dus ergens een recentere tekst rond waar wél meer over software in staat. Het persbericht van de EC van januari is informatief maar helpt niet echt. Iemand enig idee waar de geconsolideerde tekst staat?

Update (7 maart): Met dank aan PdL gevonden: het rapport plus het procedure-overzicht. Ik vermoed dat de BSA hierover valt:

Digital content: digital content transmitted to the consumer in a digital format, where the consumer obtains the possibility of use on a permanent basis or in a way similar to the physical possession of a good, should be treated as goods for the application of the Directive which apply to sales contracts. However, a withdrawal right should only apply until the moment the consumer chooses to download the digital content.

Met deze definitie is software (maar ook muziek en films) inderdaad onder de conformiteitseis te scharen. En, minstens zo leuk, je wordt dan eigenaar van je kopietje (en dus niet slechts licentienemer).

Arnoud

Als een offerte belooft dat je “meerdere gebruikers kunt aanmaken”, hoe veel zijn dat er dan? En als je dan achteraf hoort dat je maar met 2 gebruikers tegelijk ingelogd mag zijn, ben je dan bekocht? Een klant die Exact Compact 2003 voor hun hypotheekadviesbureau had aangeschaft, vond van wel en ontbond de licentie op die gronden. Exact was het daar niet mee eens en stapte naar de rechter om betaling van een kleine tienduizend euro aan licentiekosten plus wettelijke rente te eisen. De rechter vonnist dat Exact gelijk lijkt te hebben, en baseert zich op een interne mail van de klant als bewijs (via).

De klant, een hypotheekadviesbureau, had bij Exact een offerte opgevraagd voor een multi-user boekhoudpakket. De verkoper had een maatwerkofferte gestuurd, met daarop deze zinnen:

Naast de voordelen die Exact Compact 2003 Factuur biedt kunt u nu ook met meerdere gebruikers tegelijkertijd in de software werken. In Exact Compact 2003 kunt u hiervoor meerdere gebruikers aanmaken waarvan u kunt aangeven of ze al dan niet toegang tot Exact hebben.
In bijgevoegd orderformulier kunt u zelf aangeven met hoeveel extra gebruikers u tegelijkertijd in de software wilt werken.
Voor plaatsing van de order verzoeken wij u vriendelijk een ondertekende orderbevestiging tesamen met een ondertekende licentie- en onderhoudsregistratiekaart (laatste pagina van het boekje Exact-voorwaarden voor uw licentie en onderhoud) retour te sturen of te faxen naar Exact

De klant had de offerte voor akkoord getekend en geretourneerd, en ook een registratiekaart ingevuld waarop bij “Aantal gebruikers” het aantal “4” ingevuld was. Maar uiteindelijk (na onderhandelen over een korting) bleek dat maar twee gebruikers de software van het pakket gebruik konden maken, wat niet was wat de klant had verwacht. (Ik snap de licentiestructuur van Exact niet, maar dat zal wel aan de uitleg in het vonnis liggen.)

Het bedrijf had in eerste instantie gezegd dat er geen licentieovereenkomst was gesloten, omdat zij een licentie voor 4 gebruikers wilde en die niet had gekregen. Maar dat verwerpt de rechtbank. Het is misschien niet duidelijk wat er precies besteld is, maar dát er iets besteld is, staat vast. De vraag is dus: is geleverd wat er is besteld?

Exact krijgt de bewijslast: omdat zij zegt dat er keurig geleverd is en betaald moet worden, moet zij bewijzen dat het geleverde voldoet aan de wens van de klant. Dat was het geval volgens ExcelExact. Zij had een maatwerkofferte opgesteld op basis van wat de klant had aangegeven, en bij de constructie daarvan had de klant niet gezegd dat vier gebruikers tegelijkertijd de software hadden moeten kunnen gebruiken. De zinnen hierboven waren niet meer dan een standaardfrase. De klant zette daar tegenover dat mondeling herhaaldelijk was aangegeven dat vier mensen tegelijkertijd de software moesten kunnen gebruiken.

De rechtbank neemt de offerte en de registratiekaart als uitgangspunt, en constateert meteen dat deze “geen enkele duidelijkheid” opleveren over wat er nu precies afgesproken is. Maar men vond in het dossier nog een interne mail van de interim-manager van de klant die verslag doet van zijn gesprek met Exact (”lekker commercieel bij Exact…”). En daar schrijft deze:

Ik heb zojuist met Exact contact gehad over het gebruik maken van Exact Compact door 2 gebruikers. Het zou zo moeten zijn dat je dan 4 x het pakket aanschaft (2 x 4 administraties en 2 x voor 2 gebruikers).

De klant had nimmer betwist dat deze mail correct zou zijn. Natuurlijk is dit een interne mail en geen toezegging aan of van Exact, maar de rechtbank gebruikt de mail heel slim: dit is bewijs van hoe de klant dacht dat het contract in elkaar zat. En deze samenvatting is precies zoals Exact het voorspiegelde. Daarmee lijkt Exact dus gelijk te hebben over dat de verkochte licenties voldeden aan de verwachtingen van de klant.

Omdat dit toch wat sneu lijkt, krijgt de klant nog de gelegenheid om tegenbewijs te leveren. Ik ben heel benieuwd waar men mee komt.

Arnoud

Regelmatig krijg ik vragen als de volgende:

Als softwareontwikkelaar/designer/ontwerper van logo’s/teksten/webapplicaties houden wij het auteursrecht op de door ons gemaakte werken. Stel dat een klant deze over zou willen nemen, wat is dan een aannemelijke manier van waardebepaling?

Deze vraag komt neer op “wat kost een auto”. Daar is juridisch geen zinnig woord over te zeggen. Je mag als ontwerper of maker zelf bepalen wat je wil hebben voor het overnemen van het auteursrecht. Je mag zelfs weigeren dit over te dragen.

In sommige branches (met name fotografie en tekstschrijven) wordt als vuistregel wel gehanteerd dat je de rechten overneemt (of afkoopt) tegen drie maal het normale tarief. Maar ik vind dat een beetje rare manier van zakendoen: is dat werkelijk de waarde voor de klant?

Economisch gezien zou de redenering moeten zijn: welke inkomsten zou ik hebben verkregen door dit werk te hergebruiken bij andere klanten? Je mag een gemaakt werk immers niet meer opnieuw inzetten na overdracht auteursrecht. Volgens die redenering zou het auteursrecht op een generieke module dan duurder zijn dan het auteursrecht op een logo dat je specifiek voor één klant maakt. Dat logo kun je niemand anders meer verkopen.

Je kunt bij de overdracht bedingen dat je een licentie terug krijgt voor hergebruik in andere projecten mits die maar niet te veel lijken of hetzelfde doen als het project dat de klant overneemt. En dan zou overdracht van de rechten niet heel veel meerprijs moeten zijn. De klant heeft nu het voordeel dat hij niet bang hoeft te zijn voor jouw faillissement: omdat hij de rechten heeft verkregen, kan de curator zijn licentie niet intrekken of extra betaling eisen.

Arnoud

De op één na ergste openingszin in mijn inbox is toch wel “een tijd geleden zijn wij een IT-project gestart, maar…” Ik weet niet wat het is, maar het lijkt wel of elk IT-project gruwelijk faalt: gemiste deadlines, vele extra rekeningen (liefst terwijl een vaste prijs bedongen was), eindeloos gesoebat over specificaties, maandenlange vertraging bij oplevering en uiteindelijk de helft van de functionaliteit krijgen voor tien maal de prijs. Om dat juridisch op te lossen is geen pretje. Zeker niet omdat de meeste klanten denken “als het lang genoeg geduurd heeft en we nog steeds niets zien, dan trekken we de stekker eruit”. Maar zo werkt het niet.

Het grootste juridische struikelblok is dat opdrachtgevers in een IT-project maar laatste kansen blijven geven. De wet biedt je namelijk pas de gelegenheid een project te staken als de wederpartij “in verzuim” is, en daarvan is pas sprake als hij een fatale deadline heeft gemist of als hij in gebreke is gesteld. Beide opties zijn juridisch tot op alle punten en komma’s uitgeprocedeerd, en het verbaast dan ook niet dat het héél lastig om te bewijzen is dat hiervan sprake is. In een helder artikel (PDF) legt IT-advocaat Polo van der Putt duidelijk uit waar de juridische valkuilen liggen.

Eerst maar eens die “fatale termijn”. Daarmee wordt een deadline bedoeld die écht deadline is, oftewel missen daarvan is jou(w bedrijf) fataal. Essentieel daarbij is dat de wederpartij wist dat het om een fatale termijn ging. Dat de termijn belangrijk was voor jou, is niet belangrijk. Het klassieke voorbeeld van een fatale termijn is de bruidstaart: de bakker moet weten dat die voor de trouwdag wordt besteld, en een dag te laat is echt onaanvaardbaar.

Bij IT-projecten ligt dat iets anders. Daar is uitstel of iets latere levering eigenlijk altijd wel mogelijk. Immers, geen IT-project dat per se op je trouwdag af moet zijn. En werkt de IT-er met een beetje toegesneden algemene voorwaarden, dan is er nooit sprake van een fatale termijn, hoe belangrijk die voor de klant ook is. De voorwaarden definiëren dan simpelweg elke termijn als zijnde niet fataal, ongeacht mededeling van de klant. (Toegegeven, zulke voorwaarden schrijf ik ook.)

Van der Putt signaleert een vonnis waarbij de rechter het droogjes als volgt samenvat waarom IT-deadlines nimmer van niveau trouwdag kunnen zijn:

Dit te meer nu feit van algemene bekendheid is dat automatiseringsprojecten kunnen uitlopen, en uitlopen ook vaak plaats vindt.

Een rechter met IT-clue. Iedereen weet dat IT-projecten altijd uitlopen, dus iedereen moet snappen dat deadlines slechts bedoeld zijn als indicatieve termijnen - “ergens rond 27 mei zou leuk zijn, maar 19 september mag ook hoor”. Van een falende leverancier kom je dus niet af met het argument “u had 27 mei moeten opleveren en dat is niet gebeurd”.

De andere juridische boeg waar je het over kunt gooien is dat er niet correct geleverd wordt. De leverancier schiet tekort, juridisch gezegd. Dat kan een grond zijn om te ontbinden, maar dat bewijzen is moeilijker dan je denkt. Zeker als het gaat om toekomstige tekortkomingen, het “dit komt nooit meer goed”-argument:

Het zal in de praktijk niet eenvoudig zijn om voldoende aannemelijk te maken dat tekort zal worden geschoten. Doorgaans zal het de afnemer aan voldoende expertise en wetenschap ontbreken om aan te kunnen tonen dat correcte nakoming onmogelijk zal zijn. Bovendien zal, zeker bij langlopende projecten waar de leverancier nog een lange termijn heeft om te presteren, altijd wel een gezaghebbende expert gevonden kunnen worden die met kracht van argument kan betogen dat correcte nakoming wel mogelijk is.

Kun je wel bewijzen dat sprake is van een daadwerkelijke tekortkoming, dan is het mogelijk om het project te annuleren. Eis is dan wel dat de IT-er in verzuim is. De wet eist dan als hoofdregel dat hij in gebreke is gesteld. Dat wil zeggen: er is een tekortkoming gesignaleerd, de IT-er heeft een laatste kans gehad om het recht te zetten en ook daarna blijft het tegenvallen. In dat geval mag je als opdrachtgever opzeggen. Maar ook dat is moeilijker dan je denkt. Twee struikelblokken:

1. Er moet een schriftelijke ingebrekestelling zijn verstuurd. Dat is een brief (geen mail) met daarin de toverformule “ik stel u bij deze in gebreke en eis dat u de hierboven gesignaleerde fouten herstelt”.
2. De ingebrekestelling moet een redelijke termijn stellen voor het herstel van de fouten.

Te vaak denken opdrachtgevers dat het genoeg is te constateren dat er gefaald is en dat ze daarmee mogen opzeggen. Dat is dus expliciet niet zo. Evenmin is sprake van een ingebrekestelling als men geen uiterlijke termijn stelt, maar bv. alleen aanbiedt te gaan overleggen om te kijken wat er nog te redden valt.

Of te wel: zachte heelmeesters maken stinkende wonden. Een afnemer die meent dat er sprake is van een tekortkoming doet er verstandig aan om ook een termijn te stellen. Praten kan altijd nog.

Er zijn uitzonderingen op deze regel. Zo is een ingebrekestelling niet nodig wanneer de leverancier heeft gemeld dat hij niets meer gaat doen of als er lange tijd helemaal géén reacties komen op klaagmails. Of als de enige oplossing is om maar helemaal opnieuw te beginnen. Maar ik zou er niet op durven vertrouwen als ik de jurisprudentie erop nalees.

Met deze samenvatting doe ik Polo’s artikel nauwelijks recht, dus lees graag het gehele artikel: (Dreigende) tekortkoming en verzuim van IT-dienstverleners bij IT en Recht.nl.

Waar ik zelf dan nog benieuwd naar ben: waarom laten IT-klanten het altijd zo gierend uit de hand lopen met die projecten? Is het omdat IT moeilijk is en je geen idee hebt wat ze aan het doen zijn? Omdat je (vanwege de auteursrechten op de code) vast zit aan deze leverancier en je dus alle gelden kwijt bent als je opzegt? Of hebben IT-ers betere komtwelgoedpraatjes dan aannemers?

Arnoud
PS: de voor mij ergste openingszin is “u bent mijn laatste hoop”, en ja die krijg ik zo eens per week.