Hvad er ansvar for manglende overensstemmelse i kontrakter om system- og softwareudvikling? Forklaring af ændringspunkter

Hvad skal man juridisk gøre, hvis der er en fejl i det system, man har bestilt, efter levering?

Hvis betjeningen er svær, behandlingshastigheden er langsom, eller den bestilte funktion ikke er inkluderet… Som bestiller af systemet, vil du stille leverandøren, der har udviklet systemet, til ansvar for “kontraktuel non-konformitet”.

“Kontraktuel non-konformitet” blev nyt oprettet i stedet for “garanti for mangler”, som blev afskaffet med ændringen af den civile lov i 2017 (Gregoriansk kalenderår). Derfor er det nødvendigt at være opmærksom på, hvordan denne ændring påvirker system- og softwareudvikling.

Problemer opstår ofte efter levering. For at undgå sådanne problemer vil vi forklare indholdet af “kontraktuel non-konformitet” og virkningen af ændringen.

Ændringer i civilretten vedrørende ansvar for kontraktuel uoverensstemmelse

Den ‘Lov om ændring af visse dele af civilretten’ blev offentliggjort den 2. juni 2017 (Heisei 29) og trådte i kraft den 1. april 2020.

I civilretten er de mest grundlæggende regler om kontrakter og lignende fastlagt i det, der kaldes ‘obligationsretten’.

Obligationsretten har næsten ikke været revideret siden den blev indført i 1896 (Meiji 29), hvilket er omkring 120 år siden.

Denne revision er et stort skridt fremad for at tilpasse loven til det moderne samfund.

De specifikke ændringer er mange, men blandt dem er indførelsen af konceptet ‘ansvar for kontraktuel uoverensstemmelse’ en af de vigtigste ændringer.

Som et resultat af dette er det, der tidligere blev kaldt ‘garanti for mangler’, nu blevet erstattet med ‘ansvar for kontraktuel uoverensstemmelse’.

Hvad er kontraktuel ikke-overensstemmelse?

“Kontraktuel ikke-overensstemmelse” refererer til en situation, hvor de funktioner, kvalitet, ydeevne eller tilstand, der oprindeligt skulle være til stede i henhold til parternes aftale eller kontraktens formål og karakter, ikke er til stede.

Denne “kontraktuelle ikke-overensstemmelse” blev introduceret som en erstatning for den traditionelle “mangel” som følge af ændringer i den japanske civillov (Minpō).

I system- og softwareudvikling gælder “kontraktuel ikke-overensstemmelse”, hvis det færdige system ikke stemmer overens med de foruddefinerede specifikationer, eller hvis systemet eller softwaren ikke har de funktioner eller ydeevne, der normalt forventes i lyset af dets karakter.

Ved vurdering af, om der er “kontraktuel ikke-overensstemmelse”, lægges der vægt på parternes aftale og kontraktens formål og karakter.

Derfor er det vigtigt at dokumentere formålet med system- eller softwareudvikling og ordrehistorikken for at klargøre, hvilke ønsker og forventninger bestilleren havde.

Tilfælde hvor softwarefejl osv. svarer til “kontraktuel ikke-overensstemmelse”

Når softwaren forårsager problemer og reparationen er forsinket

Først og fremmest kan der opstå situationer, hvor der opstår en ikke ubetydelig fejl i softwaren, og det er ikke muligt at håndtere det hurtigt, såsom at skulle gå tilbage til designfasen for at rette det.

For eksempel, der er en retssag, hvor det blev anerkendt, at det svarer til den nuværende “kontraktuelle ikke-overensstemmelse” eller “mangel”, i et tilfælde hvor der opstod problemer, såsom at søgeprocessen for det indførte lageropslagssystem tog mere end 30 minutter, og det var nødvendigt at oprette en separat håndskrevet lagerbog for at håndtere kundehenvendelser (Tokyo District Court, 22. april 2002 (Heisei 14)).

Når fejl opstår løbende

Derudover kan der være tilfælde, hvor selvom hver enkelt fejl er mindre og ikke tager lang tid at rette, fejl opstår gentagne gange, og det tager lang tid at rette alle fejl og få det til at fungere korrekt.

For eksempel, hvis der opstår gentagne fejl i det indførte lageropslagssystem, og det er uklart, hvor mange fejl der vil opstå i fremtiden, og hvor lang tid det vil tage at rette dem, og det er ikke muligt at udføre normale forretningsaktiviteter ved hjælp af systemet, kan det siges at være en “kontraktuel ikke-overensstemmelse”.

Tilfælde, hvor softwarefejl osv. ikke betragtes som “kontraktuel ikke-overensstemmelse”

Hvis det er rettet uden forsinkelse eller hvis alternative foranstaltninger er truffet

I retspraksis er det blevet afgjort, at selvom en bruger påpeger en fejl som en bug, hvis det er rettet uden forsinkelse, eller hvis der er truffet alternative foranstaltninger, som brugeren anser for rimelige efter drøftelse, betragtes det ikke som en “mangel” (Tokyo District Court, 18. februar 1997 (Heisei 9)).

I system- og softwareudvikling er det umuligt at programmere således, at der ikke opstår nogen bugs, og det er uundgåeligt, at visse fejl vil opstå.

Derfor, selvom der er en fejl, hvis foranstaltninger som at rette det uden forsinkelse er truffet, bør det ikke betragtes som en “mangel”.

Dette kan også tænkes at være tilfældet under den nuværende “kontraktuel ikke-overensstemmelse”.

Det, der danner grundlag for bedømmelsen af “uden forsinkelse” osv., er beviser som mødereferater, der blev oprettet i løbet af systemudviklingsprocessen.

Detaljer om vigtigheden af disse er forklaret i artiklen nedenfor.

https://monolith.law/corporate/the-minutes-in-system-development[ja]

Hvis en bestemt person ikke let kunne forstå betjeningsmetoden

Med hensyn til brugervenlighed og brugervenlighed er det i høj grad subjektivt, så det vil blive vurderet som “kontraktuel ikke-overensstemmelse”, hvis det er ubrugeligt for den gennemsnitlige bruger.

Det kan ikke siges, at det er “kontraktuel ikke-overensstemmelse”, bare fordi en bestemt person ikke let kunne forstå betjeningsmetoden.

Hvis en fejl opstår på grund af noget uden for leverandørens arbejde

Hvis en fejl opstår på grund af årsager, der ikke har noget at gøre med udviklingsarbejdet hos leverandøren, der udvikler systemet eller softwaren, kan det ikke siges, at der er en “kontraktuel ikke-overensstemmelse” i selve systemet eller softwaren.

For eksempel, hvis en fejl opstår på grund af problemer med hardware, som leverandøren ikke er ansvarlig for at indkøbe, vil det ikke blive vurderet som “kontraktuel ikke-overensstemmelse”.

[Tilføjelse] Hvis en fejl opstår på grund af brugerens instruktioner

Hvis en fejl opstår i det færdige system eller software på grund af brugerens forkerte instruktioner, vil leverandøren i princippet ikke være ansvarlig for kontraktuel ikke-overensstemmelse, selvom systemet osv. anerkendes som at have en “kontraktuel ikke-overensstemmelse”.

For eksempel, hvis en fejl opstår i softwaren, der er udviklet baseret på specifikationer, der er aftalt på baggrund af forkerte oplysninger, der er givet om forhold, som kun brugeren kender til, vil leverandøren ikke have noget ansvar.

Bag denne bedømmelse ligger tanken om, at brugeren, der er bestilleren af softwareudviklingen, også har en “forpligtelse til at samarbejde”. For detaljer, se artiklen nedenfor.

https://monolith.law/corporate/user-obligatory-cooporation[ja]

Emner, som bygherrer/købere kan kræve baseret på ansvar for kontraktuel ikke-overensstemmelse

Her vil vi forklare indholdet af ansvar for kontraktuel ikke-overensstemmelse i forbindelse med system- og softwareudvikling, med hensyntagen til ændringer som følge af revisioner.

Krav om reparation

Hvis en fejl vurderes som en kontraktuel ikke-overensstemmelse, kan bygherren anmode om reparation af fejlen.

Før revisionen var det ikke muligt at anmode om reparation, hvis den fejl, der var problemet, ikke var væsentlig, og reparationen krævede overdreven omkostninger. Denne begrænsning er blevet fjernet med revisionen.

Imidlertid, selv efter revisionen, hvis “kontraktuel ikke-overensstemmelse ikke er væsentlig, og reparation kræver overdreven omkostninger”, kan det være, at en anmodning om reparation ikke anerkendes, da reparation er umulig.

Krav om erstatning

Hvis et system eller software med fejl forhindrer normal drift eller kræver ekstra omkostninger, kan bygherren anmode om erstatning.

Før revisionen var det muligt at anmode om erstatning uanset om der var fejl eller ej, medmindre der var en særlig aftale.

Men med revisionen, hvis der er en undtagelse for udførelsen (en årsag, der ikke kan tilskrives skyldneren), er det ikke længere muligt at anmode om erstatning.

Derfor, hvis leverandøren kan bevise undtagelsen, pådrager de sig ikke erstatningsansvar.

Ophævelse af kontrakten

Udviklingskontrakten kan ophæves på grund af kontraktuel ikke-overensstemmelse i systemet eller softwaren.

I en allerede nævnt retssag blev kontrakten anerkendt som ophævet, fordi der var fejl, såsom at søgeprocessen i lageropslagssystemet tog mere end 30 minutter, og behandlingstiden var for lang, og terminalen selv kunne ikke bruges, og det var nødvendigt at opgive fortsat brug af det implementerede system (Tokyo District Court, 22. april 2002 (Heisei 14)).

Før revisionen var det kun muligt at ophæve kontrakten, hvis fejlen gjorde det umuligt at “opnå det formål, kontrakten blev indgået for”. Men denne begrænsning er blevet fjernet med revisionen.

Imidlertid, selv under den reviderede lov, skal det bemærkes, at ophævelse ikke anerkendes, hvis graden af kontraktuel ikke-overensstemmelse er “mindre”.

Krav om reduktion af honorar

Retten til at anmode om en reduktion af honoraret blev nyt oprettet med revisionen.

Hvis der er en fejl i systemet, og bygherren har anmodet om reparation, men reparationen ikke er udført efter en rimelig periode, kan bygherren anmode om en reduktion af honoraret.

Periode for ansvar

• Krav om reparation
• Krav om erstatning
• Ophævelse af kontrakten
• Krav om reduktion af honorar

Der er en begrænset periode, hvor disse rettigheder kan udøves.

Specifikt kan rettighederne kun udøves, hvis bygherren har informeret leverandøren om, at der er en kontraktuel ikke-overensstemmelse i systemet eller softwaren “inden for et år efter at have fået kendskab til det”.

Før revisionen var perioden for udøvelse af rettigheder begrænset til “inden for et år efter overdragelsen” af systemet eller softwaren. Derfor kan det siges, at perioden for udøvelse af rettigheder er blevet længere med revisionen.

Desuden, ud over denne tidsbegrænsning, gælder bestemmelserne om forældelse også for de ovennævnte rettigheder, der anerkendes på grundlag af ansvar for kontraktuel ikke-overensstemmelse.

Derfor, for eksempel, hvis du først opdager eksistensen af en fejl 11 år efter at have modtaget systemet eller softwaren, vil rettighederne, såsom retten til at anmode om erstatning, være “forældet” efter en periode på “ti år”, uanset om du informerer om kontraktuel ikke-overensstemmelse “inden for et år efter at have fået kendskab til det”.

Afvisning af betaling af honorar

Bygherren kan nægte at betale det fulde honorar, indtil udvikleren har udført reparation eller erstatning.

Punkter for kontraktbestemmelser under hensyntagen til kontraktuel ikke-overensstemmelse

Bestemmelserne om kontraktuel ikke-overensstemmelse er valgfri, og parterne kan ved særlige aftaler begrænse indholdet af ansvaret eller forkorte perioden for udøvelse af rettigheder.

Her vil vi forklare kontraktbestemmelser, der skal tages i betragtning i forhold til kontraktuel ikke-overensstemmelse i system- og softwareudvikling.

Punkt 1: Begivenheder og omfang, der er genstand for kontraktuel ikke-overensstemmelse

Hvis der er utilfredshed med systemet eller softwaren, vil ordregiveren sandsynligvis ønske at forfølge leverandøren for kontraktuel ikke-overensstemmelse.

Men som leverandør kan det ikke accepteres, at man bliver forfulgt for kontraktuel ikke-overensstemmelse, bare fordi man ikke kan lide noget, der ikke er mere end en specifikation.

Desuden kan leverandøren potentielt hæve sit tilbud betydeligt for at forberede sig på uretfærdig forfølgelse af kontraktuel ikke-overensstemmelse, hvilket også er ugunstigt for ordregiveren.

Derfor er det vigtigt at klart angive begivenheder og omfang, der er genstand for kontraktuel ikke-overensstemmelse, ved for eksempel at angive på skrift, hvilket formål ordregiveren har, og hvilke funktioner det ønskede system skal have, og ved at sikre, at dette afspejles korrekt i specifikationerne.

Det kan også overvejes at gøre det klart, at selvom der er nogle ulemper i specifikationerne, vil det ikke være en kontraktuel ikke-overensstemmelse, hvis systemet eller softwaren leveres som angivet i specifikationerne.

Med denne bestemmelse kan man forhindre, at man bliver forfulgt for kontraktuel ikke-overensstemmelse på grund af ordregiverens præferencer, selvom man har udviklet i overensstemmelse med specifikationerne.

Punkt 2: Klarlægning af garantiperioden

Perioden for udøvelse af rettigheder i forbindelse med kontraktuel ikke-overensstemmelse beregnes ikke fra “leveringstidspunktet” for produktet, men fra “tidspunktet for opdagelse” af kontraktuel ikke-overensstemmelse.

Desuden, selvom en anden udløbsperiode gælder, er denne periode maksimalt “ti år” og strækker sig over en lang periode.

For leverandøren kan det være en stor byrde at skulle garantere gratis i “ti år” afhængigt af omstændighederne, og dette skal nødvendigvis medregnes i tilbudsfasen.

For ordregiveren kan det derimod være mere fordelagtigt i forhold til omkostninger osv. at indstille garantiperioden fleksibelt i overensstemmelse med brugsperioden for systemet eller softwaren.

Derfor kan det overvejes at indstille garantiperioden fleksibelt i overensstemmelse med indholdet af systemet osv.

Punkt 3: Håndtering i tilfælde af kontraktuel ikke-overensstemmelse

Hvis der opstår kontraktuel ikke-overensstemmelse, kan parterne ved aftale begrænse de rettigheder, der kan udøves, til en del af de rettigheder, der er anerkendt i civilretten, såsom krav om erstatning for skader eller ophævelse.

Som ordregiver er det nødvendigt at forstå korrekt, hvilke begrænsninger der er pålagt i kontrakten.

Opsummering: Konsulter en advokat ved udarbejdelse af kontrakter, der inkluderer “ansvar for kontraktuel ikke-overensstemmelse”

Ændringer i den japanske civillov har haft stor indflydelse på lovgivningen omkring system- og softwareudvikling.

Hvis der opstår fejl i det leverede system, er det ikke altid klart, om dette udgør en “kontraktuel ikke-overensstemmelse”, og hvilket ansvar der kan pålægges.

Desuden er det afgørende at have en grundig diskussion mellem bestilleren og leverandøren i udviklingskontraktens fase for at forhindre konflikter på forhånd.

Hvis du har bekymringer om udarbejdelsen af kontrakten, skal du endelig konsultere en specialiseret advokat.