Bij elke contractuele relatie tussen softwareontwikkelaars en -afnemers zijn duidelijke afspraken cruciaal. Toch kan het voorkomen dat de ene partij meent dat haar wederpartij bepaalde verplichtingen niet of niet op tijd nakomt en dat hierdoor schade ontstaat. Belangrijke vragen hierbij zijn: “Op welke manier kan ik mijn schade op de wederpartij verhalen? Moet ik haar nog een herstelmogelijkheid bieden?” In onze blogreeks over wanprestatie en verzuim hebben we uitgebreid stilgestaan bij deze onderwerpen. In deze blog gaan we verder in op deze materie aan de hand van een recente uitspraak.
Even een korte samenvatting: een tekortkoming is als een partij haar afspraken niet nakomt, terwijl dit wel had gemoeten. Als er sprake is van een tekortkoming, kan de andere partij bepaalde juridische stappen nemen (zoals schadevergoeding of ontbinding), onder de voorwaarde dat de tekortkomende partij in verzuim verkeert. Hiervoor is (uitzonderingen daargelaten) een schriftelijke aanmaning voor nodig, waarin een redelijke hersteltermijn wordt geboden – de ingebrekestelling. Als er dan alsnog niet wordt nagekomen, is er sprake van verzuim en kan er schadevergoeding en/of ontbinding worden gevorderd.
Verzuim is dus een belangrijke drempel voor verdere juridische stappen. Er is echter een belangrijke uitzondering op de hoofdregel dat er sprake moet zijn van verzuim voordat deze stappen genomen kunnen worden. Dat is als nakoming blijvend onmogelijk is: als je wederpartij niet meer kan nakomen, is het bieden van een hersteltermijn volgens de wet niet nodig. Van blijvende onmogelijkheid is ook sprake als nakoming op een bepaald moment moet gebeuren en er daarna geen belang meer bij is (levering van een trouwjurk na de bruiloft) of als van de schuldeiser redelijkerwijs niet gevergd kan worden dat hij alsnog op correcte nakoming wacht.
Kan er bij IT-projecten überhaupt sprake zijn van blijvende onmogelijkheid van nakoming?
Klinkt simpel genoeg, maar dit is in de IT-praktijk een stuk lastiger. Implementatietrajecten duren meestal lang genoeg zodat een leverancier theoretisch gezien altijd wel de mogelijkheid heeft om alsnog na te komen. En wanneer kan je van een afnemer niet meer vergen dat hij wacht op die langverwachte functionaliteit als het traject toch al meerdere maanden inneemt? Daarnaast kan de code vaak wel zo aangepast worden dat alsnog aan de afspraken wordt voldaan. Kan er bij IT-projecten überhaupt sprake zijn van blijvende onmogelijkheid van nakoming? Het volgende praktijkvoorbeeld gaat hierop in.
Niet-bruikbare broncode als blijvende onmogelijkheid?
Het praktijkvoorbeeld gaat over een softwareontwikkelingstraject: een bestaande applicatie moest herschreven worden in een andere programmeertaal. Een professionele partij is deze opdracht aangegaan en zou high quality software opleveren. De leverancier stond dus in voor de kwaliteit van de software, die moest bestaan uit verschillende lagen en gemakkelijk aan te passen, uit te breiden en te onderhouden moest zijn.
Al na oplevering van de eerste versie bleek dat de samenwerking niet vlekkeloos verliep. Uiteindelijk kwam het tot een geschil, waarin onder andere de vraag speelde of de afnemer de overeenkomst mocht ontbinden zonder dat sprake was van verzuim. De afnemer stelde dat de leverancier door het produceren van een broncode van slechte kwaliteit tekort was gekomen. Hoewel nakoming in theorie op den duur nog wel mogelijk was, kon volgens de afnemer van een deugdelijke prestatie geen sprake meer zijn. De broncode zou namelijk volledig opnieuw opgebouwd moeten worden en de software zou daardoor pas na jaren in de afgesproken vorm geleverd kunnen worden. Nakoming zou daarom zinloos zijn of, met andere woorden: nakoming zou blijvend onmogelijk zijn.
Het Gerechtshof Den Haag, waar de zaak uiteindelijk werd behandeld na een lang juridisch voortraject, was het niet helemaal eens met de stelling van de afnemer. Het is inderdaad mogelijk dat de afnemer geen belang meer heeft bij de prestatie van de leverancier, zoals de bruid na de trouwerij ook geen belang meer heeft bij haar te laat geleverde trouwjurk. Daardoor zou nakoming blijvend onmogelijk zijn. Maar, zo zegt de rechter, dan moet er wel sprake zijn van “een min of meer duidelijk aan te wijzen peilmoment […] vanaf welk moment bij de prestatie geen belang meer bestond” (vergelijkbaar met de trouwdatum in ons voorbeeld met de trouwjurk).
Omdat de afnemer tijdens de rechtszaak niet een duidelijk peilmoment wist aan te wijzen, kon het hof niet aannemen dat van blijvende onmogelijkheid sprake is. De afnemer gaf namelijk wisselende signalen af. Aan de ene kant had hij meerdere keren per mail aangegeven dat hij door wilde met de leverancier, terwijl hij aan de andere kant tijdens de rechtszaak en in zijn vorderingen stelde dat de opgeleverde software onbruikbaar is en dat klanten definitief afhaakten door de slechte kwaliteit van de software.
Geen ingebrekestelling niet zonder risico’s
Voor softwareontwikkelaars en -afnemers maakt dit voorbeeld uit de rechtspraak duidelijk dat het leveren of geleverd krijgen van zeer slechte broncode een uitzondering op de standaardverzuimregels kan opleveren. Als de opgeleverde broncode zo slecht is dat een complete re-build nodig is, kan de softwareleverancier zonder aanmaning in verzuim verkeren. De voorwaarde is wel dat er een duidelijk aanwijsbaar peilmoment is waarop de software opgeleverd had moeten zijn. Maak daarom met elkaar heldere afspraken hierover zodat je onduidelijkheid achteraf voorkomt.
Het voorbeeld laat verder overduidelijk zien dat het achterwege laten van een ingebrekestelling niet zonder risico’s is; automatisch verzuim wordt niet zomaar aangenomen. Je kan er dus niet van uit gaan dat jouw wederpartij zonder aanmaning in verzuim verkeert en dat je vervolgens de overeenkomst kan ontbinden. Ook laat het duidelijk zien dat je daad bij woord moet voegen als je van mening bent dat nakoming onmogelijk is: als je steeds maar akkoord gaat met gebrekkige prestaties of nader uitstel, geef je je wederpartij telkens weer de ruimte voor nakoming.
De IT-Jurist geeft advies aan bedrijven en helpt bij het opstellen van contracten of een ingebrekestelling
Ga je binnenkort voor een partij software (laten) ontwikkelen of implementeren en wil je duidelijke afspraken maken over wat er geleverd moet worden? Twijfel je over de inhoud van je acceptatie- of escalatieprocedure? Of heb je te maken met een wederpartij die zijn afspraken niet nakomt?
Wij kunnen helpen met het beoordelen van conceptovereenkomsten en bestaande afspraken, het opstellen van duidelijke contracten of het schrijven van een ingebrekestelling. Heb je interesse in advies over deze materie of wil je meer weten over onze werkwijze? Neem dan gerust contact op.