Hva er ansvaret for kontraktsmessig ikke-samsvar i system- og programvareutvikling? Forklaring av endringspunkter

Hva bør du juridisk sett gjøre hvis det er en feil etter levering av systemet du bestilte?

Operasjonen er vanskelig, behandlingshastigheten er treg, funksjonen du bestilte er ikke tilgjengelig… Som bestiller, vil du stille leverandøren som utviklet systemet ansvarlig for “kontraktsmessig ikke-samsvar”.

“Kontraktsmessig ikke-samsvar” ble nylig etablert som en erstatning for “garanti for mangler”, som ble avskaffet med endringene i den japanske sivilloven (2017 i den vestlige kalenderen). Derfor er det nødvendig å være oppmerksom på hvordan denne endringen påvirker system- og programvareutvikling.

Feil som ofte oppstår etter levering. For å unngå slike problemer, vil jeg forklare innholdet i “kontraktsmessig ikke-samsvar” og effekten av endringene.

Endringer i sivilloven om kontraktsmessig uoverensstemmelsesansvar

Den “Loven om endring av deler av sivilloven” (japansk: 民法の一部を改正する法律), som ble kunngjort 2. juni 2017 (Heisei 29), trådte i kraft 1. april 2020.

Den delen av sivilloven som fastsetter de mest grunnleggende reglene for kontrakter og lignende, kalles “Obligasjonsloven” (japansk: 債権法).

Obligasjonsloven hadde nesten ikke blitt revidert siden den ble etablert i 1896 (Meiji 29), over en periode på omtrent 120 år.

Denne revisjonen ble gjennomført for å gjøre en betydelig revisjon for å tilpasse seg det moderne samfunnet.

De spesifikke endringene er mange, men blant dem er etableringen av konseptet med kontraktsmessig uoverensstemmelsesansvar en av de viktigste endringene.

Som et resultat, det som ble kalt “garanti for mangler” (japansk: 瑕疵担保責任) har blitt erstattet med “kontraktsmessig uoverensstemmelsesansvar”.

Hva er kontraktsmangel

“Kontraktsmangel” refererer til når en funksjon, kvalitet, ytelse eller tilstand som skal være til stede i henhold til partenes avtale eller kontraktens hensikt og natur, ikke er til stede.

Dette begrepet “kontraktsmangel” ble introdusert som en erstatning for det tidligere begrepet “feil” som følge av endringer i den japanske sivilloven (Minpō).

I system- og programvareutvikling, vil det være en “kontraktsmangel” hvis det ferdige systemet ikke samsvarer med de forhåndsbestemte spesifikasjonene, eller hvis systemet eller programvaren ikke har funksjonene eller ytelsen som normalt skal være til stede gitt dets natur.

Når man vurderer om det er en “kontraktsmangel”, blir partenes avtale og kontraktens hensikt og natur vektlagt.

Derfor er det viktig å dokumentere formålet med system- eller programvareutviklingen og rekkefølgen av bestillingene, og å klargjøre hvilke ønsker eller forventninger bestilleren hadde.

Tilfeller der programvarefeil osv. tilsvarer “kontraktsmessig ikke-samsvar”

Når programvaren forårsaker problemer og reparasjonen er forsinket

Først og fremst, det kan være tilfeller der det oppstår en alvorlig feil i programvaren, og det er ikke mulig å håndtere det raskt, for eksempel ved å gå tilbake til designfasen for å rette det.

For eksempel, det er en rettsavgjørelse som anerkjenner at det tilsvarer en “mangel” som er “ikke i samsvar med kontrakten” i dag, om et tilfelle der det oppstod problemer som at søkeprosessen i det innførte lagerspørringssystemet tok mer enn 30 minutter, og det var nødvendig å lage en håndskrevet lagerbok for å håndtere kundehenvendelser (Tokyo District Court, 22. april 2002 (Heisei 14)).

Når feil oppstår etter hvert

Videre, selv om hver feil er mindre og det ikke tar lang tid å rette, kan det være tilfeller der feil oppstår igjen og igjen, og det tar lang tid å rette alle feilene og få dem til å fungere normalt.

For eksempel, hvis det oppstår gjentatte feil i det innførte lagerspørringssystemet, og det er uklart hvor mange feil som vil oppstå i fremtiden og hvor lang tid det vil ta å rette dem, og det er ikke mulig å utføre vanlig arbeid ved hjelp av systemet, kan det sies å være “ikke i samsvar med kontrakten”.

Tilfeller der programvarefeil osv. ikke utgjør “kontraktsbrudd”

Når det er rettet opp uten forsinkelse eller når alternative tiltak er iverksatt

I rettspraksis, selv om brukeren har påpekt feil som bugs, hvis de er rettet opp uten forsinkelse, eller hvis alternative tiltak som brukeren anser som rimelige er iverksatt, blir det ikke ansett som en “mangel” (Tokyo District Court, 18. februar 1997 (Heisei 9)).

I system- og programvareutvikling er det umulig å programmere slik at det ikke oppstår noen bugs, og det er uunngåelig at det oppstår visse feil.

Derfor, selv om det er feil, bør det ikke betraktes som en “mangel” hvis tiltak som å rette opp feilen uten forsinkelse er iverksatt.

Dette kan tenkes å være tilfelle også under dagens “kontraktsbrudd”.

Bevis som møtereferater som ble opprettet i løpet av systemutviklingsprosessen er grunnlaget for å bestemme “uten forsinkelse”.

Vi forklarer detaljert om viktigheten av disse i artikkelen nedenfor.

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

Når en bestemt person ikke lett kunne forstå hvordan man opererer

Når det gjelder brukervennlighet, siden det i stor grad er subjektivt, vil det bli vurdert som “kontraktsbrudd” hvis det er uegnet for bruk basert på en generell bruker.

Det kan ikke sies at det er “kontraktsbrudd” bare fordi en bestemt person ikke lett kunne forstå hvordan man opererer.

Når feil oppstår på grunn av noe utenfor leverandørens arbeid

Hvis feil oppstår på grunn av årsaker som ikke har noe med utviklingsarbeidet til leverandøren som utvikler systemet eller programvaren, kan det ikke sies at det er “kontraktsbrudd” i systemet eller programvaren selv.

For eksempel, hvis feil oppstår på grunn av problemer med maskinvaren som leverandøren ikke er ansvarlig for å skaffe, vil det ikke bli vurdert som “kontraktsbrudd”.

[Tillegg] Når feil oppstår på grunn av brukerens instruksjoner

Hvis det oppstår feil i det ferdige systemet eller programvaren på grunn av brukerens feilaktige instruksjoner, vil leverandøren i prinsippet ikke være ansvarlig for kontraktsbrudd, selv om det er anerkjent at det er “kontraktsbrudd” i systemet osv.

For eksempel, hvis det oppstår feil i programvaren utviklet basert på spesifikasjonene som ble avtalt med feilaktig informasjon om forholdene som bare brukeren kjenner til i utviklingen av forretningssystemet, vil leverandøren ikke ha noe ansvar.

Det kan tenkes at bak denne vurderingen ligger tanken om at brukeren, som er bestilleren i programvareutvikling, også har en “samarbeidsplikt”. For mer informasjon, se artikkelen nedenfor.

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

Elementer som byggherrer/kjøpere kan kreve basert på ansvar for kontraktsbrudd

Her vil vi forklare innholdet i ansvar for kontraktsbrudd i forbindelse med system- og programvareutvikling, med hensyn til endringer som følge av revisjoner.

Krav om reparasjon

Hvis en feil vurderes som et kontraktsbrudd, kan byggherren kreve reparasjon av feilen.

Før revisjonen, kunne man ikke kreve reparasjon hvis feilen ikke var alvorlig og reparasjonen ville kreve overdreven kostnad. Denne begrensningen er fjernet med revisjonen.

Imidlertid, selv etter revisjonen, hvis “kontraktsbruddet ikke er alvorlig, og reparasjonen krever overdreven kostnad”, kan det være at krav om reparasjon ikke blir anerkjent fordi reparasjonen er umulig.

Krav om erstatning

Hvis et system eller programvare med feil forhindrer normal drift eller krever ekstra kostnader, kan byggherren kreve erstatning.

Før revisjonen, kunne man kreve erstatning uavhengig av om det var uaktsomhet, med mindre det var en spesiell avtale.

Men med revisjonen, hvis det er en unnskyldningsgrunn (en grunn som ikke kan tilskrives skyldneren) for utføreren, kan man ikke kreve erstatning.

Derfor, hvis leverandøren kan bevise unnskyldningsgrunnen, vil de ikke være ansvarlige for erstatning.

Oppsigelse av kontrakt

Utviklingskontrakten kan bli opphevet på grunn av kontraktsbrudd i systemet eller programvaren.

I en tidligere nevnt rettsavgjørelse, ble kontrakten opphevet fordi det var en feil som forårsaket forstyrrelser som at søkeprosessen i lagerforespørselssystemet tok mer enn 30 minutter, og terminalen selv ikke kunne brukes, og det var nødvendig å gi opp fortsatt bruk av det innførte systemet (Tokyo District Court, 22. april 2002 (Heisei 14)).

Før revisjonen, kunne man bare oppheve kontrakten hvis feilen gjorde det umulig å “oppnå formålet med kontrakten”. Men denne begrensningen er fjernet med revisjonen.

Imidlertid, selv under den reviderte loven, er det viktig å merke seg at oppsigelse ikke vil bli anerkjent hvis graden av kontraktsbrudd er “mindre”.

Krav om reduksjon av honorar

Retten til å kreve reduksjon av honorar ble nylig etablert med revisjonen.

Hvis det er en feil i systemet, og byggherren har bedt om reparasjon, men reparasjonen ikke er utført selv etter en rimelig periode, kan byggherren kreve en reduksjon i honoraret.

Periode for ansvar

• Krav om reparasjon
• Krav om erstatning
• Oppsigelse av kontrakt
• Krav om reduksjon av honorar

Det er en begrenset periode for å utøve disse rettighetene.

Spesifikt, kan du bare utøve rettighetene hvis byggherren har informert leverandøren om at det er et kontraktsbrudd i systemet eller programvaren “innen ett år etter at de ble kjent med det”.

Før revisjonen, var utøvelsesperioden for rettighetene begrenset til “innen ett år etter levering” av systemet eller programvaren. Derfor kan man si at perioden for å kunne utøve rettighetene har blitt lengre med revisjonen.

I tillegg til denne tidsbegrensningen, gjelder også bestemmelsene om foreldelse for de ovennevnte rettighetene som er anerkjent basert på ansvar for kontraktsbrudd.

Derfor, for eksempel, hvis du først blir klar over eksistensen av en feil 11 år etter at du har mottatt systemet eller programvaren, vil rettighetene som krav om erstatning ha utløpt etter “ti år” av foreldelsesperioden, uavhengig av om du har informert om kontraktsbruddet “innen ett år etter at du ble kjent med det”.

Nektelse av betaling av honorar

Byggherren kan nekte å betale hele honoraret til utvikleren inntil reparasjon eller erstatning er utført.

Punkter for kontraktsbestemmelser med tanke på kontraktsmisforhold

Bestemmelsene om kontraktsmisforhold er valgfrie, og partene kan begrense innholdet av ansvaret og forkorte perioden for utøvelse av rettigheter gjennom spesielle avtaler mellom dem.

Her vil vi forklare kontraktsbestemmelser som bør tas i betraktning i forhold til kontraktsmisforhold i system- og programvareutvikling.

Punkt 1: Hendelser og omfang som utgjør kontraktsmisforhold

Hvis det er misnøye med systemet eller programvaren, vil bestilleren sannsynligvis ønske å forfølge leverandørens kontraktsmisforholdsansvar.

Men som leverandør, kan det ikke aksepteres å bli forfulgt for kontraktsmisforholdsansvar bare fordi man ikke liker noe som bare er en spesifikasjon.

I tillegg kan leverandøren potensielt øke estimatet betydelig for å forberede seg på urettferdig forfølgelse av kontraktsmisforholdsansvar, noe som også vil være ugunstig for bestilleren.

Derfor er det viktig å klargjøre hendelser og omfang som utgjør kontraktsmisforhold ved å vise skriftlig hva slags formål bestilleren har, hvilke funksjoner de ønsker at systemet skal ha, og så videre, og å sikre at dette reflekteres i spesifikasjonene.

Det kan også være verdt å klargjøre at selv om det er noen ulemper med spesifikasjonene, vil det ikke utgjøre kontraktsmisforhold hvis systemet eller programvaren leveres i henhold til det som er fastsatt i spesifikasjonene.

Med denne bestemmelsen kan du forhindre at du blir forfulgt for kontraktsmisforholdsansvar på grunn av bestillerens preferanser, til tross for at du har utviklet i henhold til spesifikasjonene.

Punkt 2: Klargjøring av garantiperioden

Perioden for utøvelse av rettigheter for kontraktsmisforholdsansvar beregnes ikke fra “leveringstidspunktet” for produktet, men fra “tidspunktet man ble klar over” kontraktsmisforholdet.

I tillegg, selv om det er en foreldelsesfrist, er denne perioden “ti år” på det meste, og strekker seg over en lang periode.

For leverandøren kan det være en stor byrde å måtte gi en gratis garanti for en så lang periode som “ti år” avhengig av situasjonen, og de vil ikke ha noe annet valg enn å legge dette til i estimatet.

For bestilleren kan det også være mer lønnsomt å fleksibelt sette garantiperioden i henhold til bruksperioden for systemet eller programvaren, med tanke på kostnader og lignende.

Derfor kan det være verdt å vurdere å fleksibelt sette garantiperioden i henhold til innholdet i systemet og lignende.

Punkt 3: Håndtering når kontraktsmisforhold oppstår

Når kontraktsmisforhold oppstår, kan partene begrense hvilke av de rettighetene som er anerkjent i sivilretten, som skadeerstatningskrav og oppsigelse, som kan utøves, gjennom enighet mellom dem.

Som bestiller er det nødvendig å forstå nøyaktig hvilke begrensninger som er satt i kontrakten.

Oppsummering: Konsulter en advokat når du lager en kontrakt som inkluderer “ansvar for kontraktsbrudd”

Endringer i den japanske sivilloven har hatt stor innvirkning på juridiske forhold knyttet til system- og programvareutvikling.

Hvis det oppstår en feil i det leverte systemet, er det ikke alltid klart om dette utgjør et “kontraktsbrudd”, eller hvilket ansvar som kan pålegges.

I tillegg er det avgjørende å ha grundige diskusjoner mellom bestilleren og leverandøren i kontraktsfasen for å forhindre konflikter på forhånd.

Hvis du har bekymringer om å lage en kontrakt, vennligst konsulter en spesialisert advokat.