10 juridische valkuilen bij softwareontwikkeling (en hoe goede contracten geschillen voorkomen)
De overeenkomst voor de ontwikkeling van software
Softwareontwikkeling draait niet alleen om techniek. Veel softwareprojecten lopen niet vast door programmeerfouten, maar doordat opdrachtgever en leverancier achteraf een verschillende uitleg blijken te geven aan afspraken over scope, planning, acceptatie, meerwerk of verantwoordelijkheden.
Dat dergelijke discussies nog altijd regelmatig tot juridische procedures leiden, bleek bijvoorbeeld uit het arrest van het Gerechtshof 's-Hertogenbosch van 17 december 2024 (ECLI:NL:GHSHE:2024:4059). Ook daar stond uiteindelijk vooral de uitleg van de gemaakte afspraken centraal, waaronder de zorgplicht van de leverancier en de afbakening tussen overeengekomen werkzaamheden en meerwerk.
Wanneer een softwareproject onder druk komt te staan, blijken partijen vaak een fundamenteel andere opvatting te hebben over wat precies is afgesproken. De opdrachtgever meent dat bepaalde functionaliteiten onderdeel waren van de opdracht. De leverancier beschouwt deze als aanvullende werkzaamheden. Oftewel, buiten scope. Andere issues: leverancier is van oordeel dat is opgeleverd en door de klant in gebruik genomen. De klant ziet het anders. Of: een bug of bugs worden door de klant als wanprestatie aangemerkt, door de leverancier niet.
Al dit soort verschillen van inzicht kunnen escaleren tot geschillen en ultimo voor komen te liggen in een procedure bij de rechter of bij arbiters. De overeenkomst is leidend. Niet zelden is de kwaliteit van het contract dan minstens zo belangrijk als de kwaliteit van de software.
Juist daarom vormt een goede softwareontwikkelingsovereenkomst het verschil tussen een beheersbaar project en een kostbaar geschil. No silver bullet, maar een goed contract maakt veel verschil.
In dit artikel bespreken wij de tien juridische valkuilen die wij het vaakst zien terugkomen bij softwareontwikkeling en hoe deze contractueel kunnen worden gereguleerd op een wijze waarop die risico’s beheersbaar worden gemaakt.
1. Onduidelijke scope
Vrijwel ieder softwaregeschil begint met dezelfde vraag: wat moest er eigenlijk worden geleverd?
Op papier lijkt het antwoord vaak eenvoudig. In de praktijk blijkt echter regelmatig dat opdrachtgever en leverancier een verschillend beeld hebben van de overeengekomen functionaliteiten. Begrippen als "gebruiksvriendelijk", "compleet dashboardsysteem" of "integratie met het CRM" laten veel ruimte voor interpretatie. Uitleg achteraf komt in de kern neer op de vraag: wat mocht de klant verwachten? Een belangrijke stap om verschil van inzicht te voorkomen is het vastleggen van:
welke functionaliteiten worden ontwikkeld;
welke functionaliteiten uitdrukkelijk niet worden geleverd;
welke aannames gelden;
welke externe systemen betrokken zijn;
welke documentatie onderdeel uitmaakt van de opdracht.
Een duidelijke scope vormt de juridische basis van het gehele project en de toetssteen bij oplevering.
2. Scope creep en ongecontroleerd meerwerk
Softwareprojecten veranderen in de regel tijdens de uitvoering. Nieuwe inzichten ontstaan (aan beide kanten), gebruikers komen met aanvullende wensen en prioriteiten verschuiven.
Het probleem ontstaat wanneer wijzigingen worden uitgevoerd zonder dat de gevolgen voor planning, budget en verantwoordelijkheden voldoende worden onderkend en (contractuele) afspraken daarop worden afgestemd. Gaandeweg kunnen constrains gaan knellen. Onder druk kan dan over het hoofd gezien worden om nadere afspraken te maken en die schriftelijk vast te leggen. Uitlopende planningen, tegenvallende tussenresultaten, vertragingen bij de klant of niet eerder betrokken gebruikers die nieuwe inzichten of (plausibele) wensen aandragen, kunnen het project opzadelen met grote uitdagingen. Juist het signaleren en managen van die veranderingen vergt aandacht.
Hoe voorkom je dit?
Neem een formele wijzigingsprocedure op waarin wordt geregeld:
hoe wijzigingen worden aangevraagd;
hoe de impact wordt beoordeeld;
wanneer sprake is van meerwerk;
welke tarieven gelden;
welke gevolgen ontstaan voor planning en budget.
3. Onrealistische planningen
Veel softwareprojecten beginnen - onder commerciële omstandigheden - met ambitieuze deadlines. Zodra vertraging ontstaat, ligt discussie over de oorzaak of oorzaken op de loer.
Opdrachtgevers wijzen vaak naar de leverancier. Leveranciers zien gewijzigde requirements, ontbrekende input of trage besluitvorming.
Hoe voorkom je dit?
Maak onderscheid tussen:
indicatieve planningen;
streefdata;
mijlpalen;
fatale termijnen.
Daarnaast moet duidelijk zijn welke medewerking van de opdrachtgever wordt verwacht. Wanneer essentiële informatie te laat wordt aangeleverd, moet dat gevolgen kunnen hebben voor de planning.
Een realistische planning is niet alleen een projectmanagementinstrument, maar ook een juridisch risicobeheersingsmiddel.
4. Discussies over acceptatie
Wanneer is software eigenlijk opgeleverd?
Die vraag lijkt eenvoudig, maar vormt in de praktijk een van de meest voorkomende bronnen van discussie.
Veel overeenkomsten bevatten uitgebreide bepalingen over ontwikkeling, maar nauwelijks afspraken over acceptatie. Daardoor blijft onduidelijk wanneer de ontwikkelfase eindigt en wanneer een opdrachtgever het resultaat heeft geaccepteerd.
Belangrijke onderwerpen
acceptatiecriteria;
testprocedures;
testperiodes;
hersteltermijnen;
afkeuringsgronden;
ingebruikname als acceptatie.
Bij veel projecten wordt software al in gebruik genomen terwijl formele acceptatie nog niet heeft plaatsgevonden. Juist dan ontstaan complexe discussies over de juridische status van het project.
Een goede acceptatieprocedure voorkomt dat een project juridisch blijft "zweven".
5. Iedere bug wordt gezien als wanprestatie
Geen applicatie is foutloos. De laatste fout moet nog gevonden worden. Toch gaan opdrachtgevers er soms vanuit dat iedere softwarefout automatisch betekent dat de leverancier tekortschiet. Juridisch ligt dat een stuk genuanceerder en de overeenkomst is daarin simpelweg cruciaal. Voldoet de software aan de verwachtingen die de klant mocht hebben op grond van de overeenkomst. In de rechtspraak is vaker de mogelijkheid van “kinderziektes” aangenomen. Contractueel dient geborgd te zijn de plicht om de leverancier middels ingebrekestelling gelegenheid te bieden tot herstel binnen een redelijke termijn.
6. Onenigheid over intellectueel eigendom
Dit is waarschijnlijk het onderwerp waarover de meeste misverstanden bestaan. Software vindt bescherming onder de Auteurswet en door de wet wordt het auteursrecht toekend aan de maker. Niet de opdrachtgever die opdracht geeft tot ontwikkeling en ook betaling van de gemaakte uren maakt de opdrachtgever niet tot “eigenaar”. In de praktijk wordt dit vaak over het hoofd gezien en het (achteraf) besef dat het anders ligt, kan de verhoudingen flink opschudden.
In de overeenkomst kunnen andere afspraken over de eigendom worden gemaakt. De overdracht van auteursrecht dient geregeld te worden door een akte van overdracht en dit kan feitelijk in de softwareontwikkelingsovereenkomst worden meegenomen. Verstandig is om dit dan meteen goed afgebakend te formuleren (denk aan: de precieze omschrijving van die eigendom, de afbakening ten opzichte van software en componenten van derden en open source software alsmede bij de leverancier achterblijvende gebruiksrechten etc.). Zonder overdracht blijft de eigendom bij de maker.
7. Risico's van open source software
Vrijwel iedere moderne applicatie maakt gebruik van open source componenten.
Dat biedt belangrijke voordelen, maar brengt ook juridische risico's met zich mee.
Niet iedere open source licentie kent dezelfde voorwaarden. Sommige licenties verplichten tot openbaarmaking van broncode, andere bevatten verplichtingen rondom distributie of kennisgeving.
Contractuele aandachtspunten
welke open source componenten worden gebruikt;
wie verantwoordelijk is voor licentiecompliance;
welke garanties worden verstrekt;
hoe beveiligingsproblemen worden afgehandeld;
welke afhankelijkheden van derden bestaan.
Open source software is waardevol, maar vereist bewust beheer.
8. Aansprakelijkheid voor schade
Wanneer software uitvalt, kunnen de financiële gevolgen aanzienlijk zijn voor de klant. Denk aan:
omzetverlies;
stilgevallen bedrijfsprocessen;
dataverlies;
herstelkosten;
claims van klanten;
reputatieschade.
Zonder duidelijke contractuele afspraken kunnen deze risico's onbeheersbaar worden en een groot gevaar vormen voor een leverancier.
Regel daarom expliciet:
maximale aansprakelijkheid;
uitsluiting van gevolgschade;
schadebeperkingsplicht;
verzekerbare risico's;
uitzonderingen op aansprakelijkheidsbeperkingen.
In de praktijk wordt vaak onderscheid gemaakt tussen directe schade, gevolgschade en aanspraken van derden. Een goed geformuleerde aansprakelijkheidsregeling creëert duidelijkheid voor beide partijen en bescherming van de leverancier tegen risico’s die niet opwegen tegen het belang van de opdracht.
9. Onduidelijkheid over onderhoud en support
Oplevering markeert meestal niet het einde van de relatie. Software moet worden onderhouden, beveiligingsupdates moeten worden uitgevoerd en gebruikers verwachten ondersteuning.
Veel conflicten ontstaan doordat partijen verschillende verwachtingen hebben over wat onder onderhoud valt.
Veelvoorkomende vragen
Welke fouten worden kosteloos hersteld?
Binnen welke termijn?
Welke responstijden gelden?
Welke ondersteuning is inbegrepen?
Wat valt buiten de dienstverlening?
Zijn nieuwe functionaliteiten inbegrepen?
Wanneer dit niet vooraf wordt geregeld, ontstaan discussies op het moment dat de software daadwerkelijk in gebruik is.
10. Geen afspraken over exit en continuïteit
Veel partijen denken pas aan een exit wanneer zij afscheid willen nemen van elkaar.
Juist dan blijkt hoe belangrijk deze afspraken zijn.
Een opdrachtgever wil voorkomen dat hij volledig afhankelijk blijft van één leverancier. Een leverancier wil weten welke ondersteuning nog wordt verwacht na beëindiging van de samenwerking.
Denk aan afspraken over:
export van data;
overdracht van documentatie;
kennisoverdracht;
migratieondersteuning;
beheerinformatie;
broncode-escrow.
Goede exit-afspraken zorgen ervoor dat een organisatie kan blijven functioneren wanneer een leverancier wegvalt of wordt vervangen. Contracten die vallen onder de reikwijdte van de Europese Dataverordening (Data Act) dienen te voldoen aan nieuwe eisen voor wat betreft exit-verplichtingen.
Conclusie
De meeste softwaregeschillen ontstaan niet doordat software technisch niet werkt, maar doordat partijen contractueel onvoldoende hebben vastgelegd wat zij van elkaar mochten verwachten.
Onduidelijke afspraken over scope, wijzigingen, planning, acceptatie, intellectueel eigendom, aansprakelijkheid en continuïteit vormen vaak de werkelijke oorzaak van kostbare conflicten.
Een professionele softwareontwikkelingsovereenkomst sorteert voor op de voorkomende risico’s en geschillen. Dat biedt zekerheid en bescherming.
Op zoek naar professionele softwarecontracten?
Een solide contractstructuur bestaat doorgaans uit meerdere documenten, waaronder:
een softwareontwikkelingsovereenkomst;
een Statement of Work (SOW);
algemene voorwaarden;
een onderhoudsovereenkomst;
een Service Level Agreement (SLA);
een verwerkersovereenkomst indien persoonsgegevens worden verwerkt.
Samen vormen deze documenten het juridische fundament onder ontwikkeling, implementatie, beheer en ondersteuning van software.