Wat is de aansprakelijkheid voor niet-naleving van contracten in systeem- en softwareontwikkeling? Uitleg over de wijzigingen

Wat moet u juridisch doen als er een fout optreedt na de levering van het systeem dat u heeft besteld?
Het is moeilijk te bedienen, de verwerkingssnelheid is traag, de functie die u heeft besteld is niet beschikbaar… Als besteller van het systeem, zult u de leverancier die de systeemontwikkeling heeft uitgevoerd aansprakelijk stellen voor ‘contractuele non-conformiteit’.
‘Contractuele non-conformiteit’ is nieuw ingesteld ter vervanging van de ‘garantie voor verborgen gebreken’, die in 2017 (Gregoriaanse kalender) is afgeschaft door de wijziging van het Japanse Burgerlijk Wetboek. Daarom is het belangrijk om aandacht te besteden aan hoe deze wijziging van invloed is op systeem- en softwareontwikkeling.
Problemen die vaak optreden na de levering. Om dergelijke problemen te voorkomen, zullen we de inhoud van ‘contractuele non-conformiteit’ en de impact van de wijziging uitleggen.
Wijzigingen in het Burgerlijk Wetboek betreffende contractuele non-conformiteitsaansprakelijkheid

De ‘Wet tot wijziging van een deel van het Burgerlijk Wetboek’ (Japanse Burgerlijk Wetboek), die op 2 juni 2017 (Heisei 29) werd afgekondigd, is op 1 april 2020 in werking getreden.
In het Burgerlijk Wetboek wordt het deel dat de meest fundamentele regels met betrekking tot contracten en dergelijke vaststelt, ‘verbintenissenrecht’ genoemd.
Het verbintenissenrecht was sinds de invoering in 1896 (Meiji 29) bijna 120 jaar lang nauwelijks herzien.
Deze herziening is bedoeld om een grote herziening door te voeren om aan te sluiten bij de huidige samenleving.
De specifieke wijzigingen zijn divers, maar een van de belangrijkste wijzigingen is de introductie van het concept van contractuele non-conformiteitsaansprakelijkheid.
Als gevolg hiervan is wat ‘garantieaansprakelijkheid voor gebreken’ werd genoemd, vervangen door ‘contractuele non-conformiteitsaansprakelijkheid’.
Wat is contractuele non-conformiteit

“Contractuele non-conformiteit” verwijst naar het ontbreken van de functies, kwaliteit, prestaties of staat die er zouden moeten zijn, gezien de overeenkomst of het doel en de aard van het contract tussen de partijen.
Deze “contractuele non-conformiteit” is geïntroduceerd ter vervanging van de traditionele “gebreken” door de herziening van het Japanse Burgerlijk Wetboek (Minpō).
In systeem- en softwareontwikkeling, wordt het beschouwd als “contractuele non-conformiteit” als het voltooide systeem niet overeenkomt met de vooraf vastgestelde specificaties, of als het systeem of de software niet de functies of prestaties heeft die het normaal gesproken zou moeten hebben, gezien de aard ervan.
Bij het beoordelen van de aanwezigheid van “contractuele non-conformiteit”, wordt er veel belang gehecht aan de overeenkomst tussen de partijen en het doel en de aard van het contract.
Daarom is het belangrijk om de doelstellingen en de achtergrond van de bestelling van de systeem- of softwareontwikkeling schriftelijk vast te leggen, om duidelijk te maken welke verwachtingen of beelden de besteller had.
Gevallen waarin softwarefouten en dergelijke overeenkomen met ‘contractuele non-conformiteit’

Als er problemen ontstaan met de software en de reparatie wordt vertraagd
Allereerst kan het voorkomen dat er een niet onbelangrijke fout optreedt in de software, en dat het niet mogelijk is om snel te reageren, zoals het nodig is om terug te gaan naar de ontwerpfase om deze te corrigeren.
Bijvoorbeeld, er is een rechtszaak waarin werd erkend dat er sprake was van een ‘gebrek’ dat overeenkomt met de huidige ‘contractuele non-conformiteit’, in een geval waarin er problemen ontstonden, zoals dat het meer dan 30 minuten duurde om de zoekprocedure van het geïmplementeerde voorraadraadplegingssysteem uit te voeren, en dat het noodzakelijk was om een handgeschreven voorraadboek te maken om te reageren op vragen van klanten (Tokyo District Court, 22 april 2002 (Heisei 14)).
Als fouten geleidelijk aan het licht komen
Daarnaast kan het ook voorkomen dat, hoewel individuele fouten klein zijn en het niet lang duurt om ze te corrigeren, er steeds weer fouten optreden, en het veel tijd kost om alle fouten te corrigeren en de software normaal te laten functioneren.
Bijvoorbeeld, als er steeds weer fouten optreden in het geïmplementeerde voorraadraadplegingssysteem, en het is niet duidelijk hoeveel fouten er in de toekomst zullen optreden en hoe lang het zal duren om ze te corrigeren, en het is niet mogelijk om normale bedrijfsactiviteiten uit te voeren met behulp van het systeem, dan zou men kunnen zeggen dat er sprake is van ‘contractuele non-conformiteit’.
Gevallen waarin softwarefouten etc. niet voldoen aan “contractuele non-conformiteit”

Als het onmiddellijk is gerepareerd of als er alternatieve maatregelen zijn genomen
In rechtszaken wordt geoordeeld dat, zelfs als een gebruiker een bug of andere defecten aanwijst, als het onmiddellijk is gerepareerd of als er redelijke alternatieve maatregelen zijn genomen in overleg met de gebruiker, dit niet als een “gebrek” wordt beschouwd (Tokyo District Court, 18 februari 1997 (Heisei 9)).
In systeem- en softwareontwikkeling is het onmogelijk om te programmeren zonder bugs, en het is onvermijdelijk dat er enige defecten zullen optreden.
Daarom, zelfs als er een defect is, als maatregelen zoals onmiddellijke reparatie worden genomen, zou het niet als een “gebrek” moeten worden beschouwd.
Dit kan ook worden gedacht onder de huidige “contractuele non-conformiteit”.
De basis voor het beoordelen van “onmiddellijk” en dergelijke hier is het bewijs van de notulen en dergelijke die tijdens het systeemontwikkelingsproces zijn gemaakt.
De details van het belang hiervan worden uitgelegd in het volgende artikel.
Als een specifiek individu de bedieningsmethode niet gemakkelijk kon begrijpen
Wat betreft bedienbaarheid en gebruiksgemak, aangezien deze grotendeels subjectief zijn, wordt geoordeeld dat het “contractueel niet-conform” is als het niet geschikt is voor gebruik op basis van de gemiddelde gebruiker.
Alleen het feit dat een specifiek individu de bedieningsmethode niet gemakkelijk kon begrijpen, betekent niet dat het “contractueel niet-conform” is.
Als een defect is opgetreden als gevolg van iets anders dan het werk van de leverancier
Als een defect optreedt als gevolg van een oorzaak die niets te maken heeft met de ontwikkelingswerkzaamheden van de leverancier die het systeem of de software ontwikkelt, kan niet worden gezegd dat dit systeem of deze software “contractueel niet-conform” is.
Bijvoorbeeld, als een defect optreedt als gevolg van een probleem met de hardware waarvoor de leverancier niet verantwoordelijk is voor de inkoop, wordt dit niet beoordeeld als “contractueel niet-conform”.
[Aanvulling] Als een defect is opgetreden als gevolg van instructies van de gebruiker
Als een defect optreedt in het voltooide systeem of de software als gevolg van onjuiste instructies van de gebruiker, zal de leverancier in principe geen verantwoordelijkheid dragen voor contractuele non-conformiteit, zelfs als het systeem en dergelijke worden erkend als “contractueel niet-conform”.
Bijvoorbeeld, bij de ontwikkeling van een bedrijfssysteem, als er een verkeerde uitleg is gegeven over omstandigheden die alleen de gebruiker kent, en een defect optreedt in de software die is ontwikkeld op basis van de specificaties die zijn overeengekomen op basis van deze verkeerde informatie, is de leverancier niet verantwoordelijk.
Achter deze beoordeling zit het idee dat de gebruiker, als opdrachtgever van softwareontwikkeling, ook een “verplichting tot samenwerking” heeft. Zie het volgende artikel voor meer details.
https://monolith.law/corporate/user-obligatory-cooporation[ja]
Zaken die de opdrachtgever/koper kan claimen op basis van aansprakelijkheid voor contractuele non-conformiteit

Hier bespreken we de inhoud van de aansprakelijkheid voor contractuele non-conformiteit in verband met systeem- en softwareontwikkeling, rekening houdend met de wijzigingen door de herziening.
Verzoek tot herstel
Als een defect wordt beoordeeld als contractuele non-conformiteit, kan de opdrachtgever een verzoek tot herstel indienen.
Vóór de wijziging was het niet mogelijk om een verzoek tot herstel in te dienen als het betreffende defect niet significant was en het herstel buitensporige kosten met zich meebracht. Deze beperking is verwijderd door de wijziging.
Echter, ook na de wijziging, als de “contractuele non-conformiteit niet significant is en het herstel buitensporige kosten met zich meebrengt”, kan het zijn dat een verzoek tot herstel niet wordt toegestaan omdat het herstel onmogelijk is.
Verzoek tot schadevergoeding
Als een systeem of software met een defect ervoor zorgt dat normale bedrijfsvoering onmogelijk wordt of extra kosten met zich meebrengt, kan de opdrachtgever een verzoek tot schadevergoeding indienen.
Vóór de wijziging was het mogelijk om een verzoek tot schadevergoeding in te dienen, ongeacht de aanwezigheid van nalatigheid, tenzij er een speciale overeenkomst was.
Echter, door de wijziging, als de uitvoerder een vrijstelling van aansprakelijkheid heeft (een reden die niet aan de schuldenaar kan worden toegeschreven), is het niet langer mogelijk om een verzoek tot schadevergoeding in te dienen.
Daarom, als de leverancier het bestaan van een vrijstelling van aansprakelijkheid kan bewijzen, is hij niet aansprakelijk voor schadevergoeding.
Contractbeëindiging
De ontwikkelingsovereenkomst kan worden beëindigd op grond van contractuele non-conformiteit van het systeem of de software.
In een reeds geïntroduceerd rechtszaak, werd de beëindiging van het contract toegestaan omdat er een defect was dat de verwerkingstijd van het voorraadcontrolesysteem meer dan 30 minuten duurde, de verwerkingstijd te lang was, en er problemen waren zoals het onvermogen om het terminal zelf te gebruiken, waardoor het noodzakelijk was om het gebruik van het geïntroduceerde systeem op te geven (Tokyo District Court, 22 april 2002 (Heisei 14)).
Vóór de wijziging kon het contract alleen worden beëindigd als het “onmogelijk was om het doel van het contract te bereiken” door het defect. Echter, deze beperking is verwijderd door de wijziging.
Echter, zelfs onder de gewijzigde wet, is het belangrijk op te merken dat als de mate van contractuele non-conformiteit “gering” is, de beëindiging niet wordt toegestaan.
Verzoek tot vermindering van de vergoeding
Het recht om een vermindering van de vergoeding te vragen is nieuw ingesteld door de wijziging.
Als er een defect is in het systeem en de opdrachtgever heeft om herstel gevraagd, maar er is geen herstel uitgevoerd ondanks een redelijke periode van tijd, kan de opdrachtgever een verzoek tot vermindering van de vergoeding indienen.
Periode van aansprakelijkheid
- Verzoek tot herstel
- Verzoek tot schadevergoeding
- Contractbeëindiging
- Verzoek tot vermindering van de vergoeding
Er is een beperkte periode waarin deze rechten kunnen worden uitgeoefend.
Specifiek, de rechten kunnen alleen worden uitgeoefend als de opdrachtgever de leverancier binnen een jaar na het ontdekken van de contractuele non-conformiteit in het systeem of de software hiervan op de hoogte heeft gesteld.
Vóór de wijziging was de periode waarin rechten konden worden uitgeoefend beperkt tot “binnen een jaar na de overdracht” van het systeem of de software. Daarom kan worden gezegd dat de periode waarin rechten kunnen worden uitgeoefend langer is geworden door de wijziging.
Daarnaast, los van deze tijdsbeperking, zijn de bovengenoemde rechten die worden erkend op basis van aansprakelijkheid voor contractuele non-conformiteit ook onderworpen aan de bepalingen van de verjaringstermijn.
Daarom, als bijvoorbeeld het bestaan van een defect voor het eerst wordt ontdekt 11 jaar na de ontvangst van het systeem of de software, zijn de rechten zoals het recht op schadevergoeding “tien jaar” verstreken vanwege de verjaringstermijn, ongeacht of de contractuele non-conformiteit “binnen een jaar na ontdekking” is gemeld, en kunnen de rechten niet worden uitgeoefend.
Weigering van betaling van de vergoeding
De opdrachtgever kan de volledige betaling van de vergoeding weigeren totdat de ontwikkelaar het herstel of de schadevergoeding heeft uitgevoerd.
Punten om te overwegen bij contractbepalingen met betrekking tot contractuele non-conformiteit

De bepalingen van contractuele non-conformiteit zijn optioneel en kunnen door speciale overeenkomsten tussen de partijen worden beperkt of de periode voor het uitoefenen van rechten kan worden verkort.
In dit artikel zullen we de contractbepalingen bespreken die aandacht verdienen in relatie tot contractuele non-conformiteit bij systeem- en softwareontwikkeling.
Punt 1: De gebeurtenissen en het bereik die onderwerp zijn van contractuele non-conformiteit
Als er ontevredenheid is over een systeem of software, zal de opdrachtgever waarschijnlijk de leverancier willen aanspreken op contractuele non-conformiteit.
Echter, als leverancier, is het onaanvaardbaar om aansprakelijk te worden gesteld voor contractuele non-conformiteit, zelfs als het slechts om specificaties gaat en de opdrachtgever gewoon niet tevreden is.
Bovendien kan de leverancier de offerte aanzienlijk verhogen ter voorbereiding op ongerechtvaardigde claims van contractuele non-conformiteit, wat nadelig kan zijn voor de opdrachtgever.
Daarom is het belangrijk om schriftelijk aan te geven wat het doel is van de opdrachtgever, welke functies het systeem moet hebben, enz., om de gebeurtenissen en het bereik die onderwerp zijn van contractuele non-conformiteit duidelijk te maken.
Daarnaast kan overwogen worden om duidelijk te maken dat, zelfs als er enige ongemakken zijn in de specificaties, er geen sprake is van contractuele non-conformiteit als het systeem of de software wordt geleverd volgens de specificaties.
Met deze bepaling kan worden voorkomen dat de leverancier aansprakelijk wordt gesteld voor contractuele non-conformiteit, ondanks dat het systeem is ontwikkeld volgens de specificaties, simpelweg vanwege de voorkeuren van de opdrachtgever.
Punt 2: Verduidelijking van de garantieperiode
De periode voor het uitoefenen van rechten op grond van contractuele non-conformiteit begint niet op het moment van “overdracht” van het product, maar vanaf het moment dat de contractuele non-conformiteit “bekend” is.
Bovendien, zelfs als er een aparte verjaringstermijn van toepassing is, is deze periode maximaal “tien jaar” en duurt dus lang.
Voor de leverancier is het een grote last om in sommige gevallen “tien jaar” lang gratis garantie te moeten bieden, en dit moet noodzakelijkerwijs worden opgenomen in de offerte.
Aan de andere kant kan het voor de opdrachtgever voordeliger zijn om de garantieperiode flexibel in te stellen op basis van zaken als de gebruiksduur van het systeem of de software.
Daarom kan het overwogen worden om de garantieperiode flexibel in te stellen op basis van de inhoud van het systeem, enz.
Punt 3: Reactie in geval van contractuele non-conformiteit
Als er sprake is van contractuele non-conformiteit, kunnen de partijen overeenkomen om de uitoefening van rechten die onder het burgerlijk recht zijn toegestaan, zoals schadeclaims en ontbinding, te beperken tot bepaalde zaken.
Als opdrachtgever is het belangrijk om goed te begrijpen welke beperkingen er in het contract zijn opgenomen.
Samenvatting: Raadpleeg een advocaat voor het opstellen van een contract dat ‘niet-nakoming van de overeenkomst’ bevat

Door de herziening van het Burgerlijk Wetboek (Japanse Burgerlijk Wetboek) heeft de wetgeving rond de ontwikkeling van systemen en software grote veranderingen ondergaan.
Als er een defect optreedt in het geleverde systeem, is het niet altijd duidelijk of dit een ‘niet-nakoming van de overeenkomst’ is en welke verantwoordelijkheid kan worden aangesproken.
Bovendien is het essentieel om voldoende overleg te hebben tussen de opdrachtgever en de leverancier tijdens de contractfase om geschillen te voorkomen.
Als u zich zorgen maakt over het opstellen van een contract, aarzel dan niet om een gespecialiseerde advocaat te raadplegen.
Category: IT
Tag: ITSystem Development




















