Vad är ansvaret för icke-överensstämmelse i kontrakt för system- och programvaruutveckling? En förklaring av ändringspunkterna

Vad bör man juridiskt sett göra om det finns ett fel i systemet efter leverans?

Om systemet är svårt att använda, om bearbetningshastigheten är långsam, eller om den beställda funktionen saknas… Som beställare kommer du att ifrågasätta systemutvecklaren, eller leverantören, om deras “ansvar för kontraktsbrott”.

“Ansvaret för kontraktsbrott” infördes som ersättning för “ansvaret för dolda fel”, som avskaffades genom en ändring av den japanska civilrätten (Japanska Civil Code) 2017 (Gregorianska kalendern 2017). Därför är det nödvändigt att vara uppmärksam på hur denna ändring påverkar system- och programvaruutveckling.

Problem som ofta uppstår efter leverans. För att undvika sådana problem kommer vi att förklara innehållet i “ansvaret för kontraktsbrott” och effekterna av ändringen.

Ändringspunkter i civilrätten gällande ansvar för kontraktsbrist

Den “Lag om ändring av vissa delar av civilrätten” (Japanska Civilrätten), som offentliggjordes den 2 juni 2017 (Heisei 29 år, 2017 i västerländsk kalender), trädde i kraft den 1 april 2020.

I civilrätten kallas den del som fastställer de mest grundläggande reglerna för kontrakt och liknande för “obligationsrätt”.

Obligationsrätten hade inte genomgått någon större översyn sedan den infördes 1896 (Meiji 29 år, 1896 i västerländsk kalender), en period på nästan 120 år.

Den här ändringen är ett försök att göra en omfattande översyn för att anpassa lagen till dagens samhälle.

De specifika ändringspunkterna är många, men en av de viktigaste är införandet av ett nytt koncept kallat ansvar för kontraktsbrist.

Som ett resultat av detta har det som tidigare kallades “garanti för defekter” ersatts med “ansvar för kontraktsbrist”.

Vad är kontraktsbrist?

“Kontraktsbrist” innebär att en produkt eller tjänst inte har de funktioner, kvaliteter, prestanda eller tillstånd som den borde ha, med hänsyn till parternas överenskommelse, kontraktets syfte och natur.

Termen “kontraktsbrist” introducerades som en ersättning för den tidigare termen “fel” (kashi) i och med ändringar i den japanska civilrätten (Japanese Civil Code).

I system- och programvaruutveckling, om det färdiga systemet inte överensstämmer med de förutbestämda specifikationerna, eller om systemet eller programvaran inte har de funktioner eller prestanda som det normalt borde ha med hänsyn till dess natur, anses detta vara en “kontraktsbrist”.

När man bedömer om det finns en “kontraktsbrist” eller inte, är parternas överenskommelse, kontraktets syfte och natur av stor betydelse.

Därför är det viktigt att dokumentera syftet med system- eller programvaruutvecklingen och bakgrunden till beställningen, för att klargöra vilka förväntningar och visioner beställaren hade.

Fall där mjukvarufel etc. motsvarar “kontraktsbrist”

När mjukvaran orsakar problem och reparationen dröjer

Först och främst kan vi tänka oss ett fall där ett allvarligt mjukvarufel uppstår, och det är inte möjligt att snabbt åtgärda det, till exempel genom att gå tillbaka till designstadiet för korrigeringar.

Till exempel finns det ett rättsfall där det erkändes att det fanns en “brist” som motsvarar den nuvarande “kontraktsbristen” i ett fall där ett problem uppstod, som att sökprocessen för det införda lagersökningssystemet tog mer än 30 minuter, och det var nödvändigt att skapa en separat handskriven lagerbok för att svara på kundförfrågningar (Tokyo District Court, 22 april 2002 (Heisei 14)).

När fel uppstår successivt

Å andra sidan, även om varje fel är mindre och inte tar tid att korrigera, kan det hända att fel uppstår upprepade gånger, och det tar lång tid att korrigera alla fel och få det att fungera korrekt.

Till exempel, om det upprepade gånger uppstår fel i det införda lagersökningssystemet, och det är oklart hur många fel som kommer att uppstå i framtiden och hur lång tid det kommer att ta att korrigera dem, och det är inte möjligt att utföra normala arbetsuppgifter med systemet, skulle det kunna kallas en “kontraktsbrist”.

Fall då mjukvarufel inte klassificeras som “kontraktsbrott”

När felet har åtgärdats utan dröjsmål eller när alternativa åtgärder har vidtagits

I rättsfall har det bedömts att även om användare påpekar buggar eller andra fel, om dessa åtgärdas utan dröjsmål, eller om alternativa åtgärder som anses rimliga efter samråd med användaren vidtas, anses det inte vara en “brist” (Tokyo District Court, 18 februari 1997 (Heisei 9)).

I system- och mjukvaruutveckling är det omöjligt att programmera så att inga buggar uppstår alls, och det är oundvikligt att vissa fel uppstår.

Därför, även om det finns fel, om åtgärder som att åtgärda dem utan dröjsmål vidtas, bör det inte betraktas som en “brist”.

Detta kan tänkas gälla även under nuvarande “kontraktsbrott”.

Bevis som ligger till grund för bedömningen av “utan dröjsmål” etc. är mötesprotokoll etc. som skapats under systemutvecklingsprocessen.

Vi förklarar detaljerna om vikten av dessa i följande artikel.

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

När en specifik individ inte lätt kan förstå hur man använder det

När det gäller användarvänlighet och användbarhet, eftersom dessa i stor utsträckning beror på subjektiva faktorer, kommer det att bedömas att det är ett “kontraktsbrott” om det inte kan användas av genomsnittliga användare.

Det räcker inte att säga att det är ett “kontraktsbrott” bara för att en specifik individ inte lätt kan förstå hur man använder det.

När ett fel uppstår på grund av något utanför leverantörens arbete

Om ett fel uppstår på grund av orsaker som inte har något att göra med utvecklingsarbetet av en leverantör som utvecklar system och mjukvara, kan man inte säga att det finns ett “kontraktsbrott” i själva systemet eller mjukvaran.

Till exempel, om ett fel uppstår på grund av problem med hårdvara som leverantören inte ansvarar för att skaffa, kommer det inte att bedömas som ett “kontraktsbrott”.

[Tillägg] När ett fel uppstår på grund av användarens instruktioner

Om ett fel uppstår i det färdiga systemet eller mjukvaran på grund av felaktiga instruktioner från användaren, kommer leverantören i princip inte att bära ansvaret för kontraktsbrott, även om det erkänns att det finns ett “kontraktsbrott” i systemet etc.

Till exempel, om ett fel uppstår i mjukvaran som utvecklats baserat på specifikationer som överenskommits på grund av felaktig information om omständigheter som endast användaren känner till vid utvecklingen av ett affärssystem, kommer leverantören inte att ha något ansvar.

Det kan tänkas att bakom denna bedömning ligger tanken att användaren, som är beställaren i mjukvaruutveckling, också har en “skyldighet att samarbeta”. För mer information, se följande artikel.

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

Frågor som byggherrar och köpare kan kräva baserat på ansvar för kontraktsbrist

Här förklarar vi innehållet i ansvar för kontraktsbrist i samband med system- och programvaruutveckling, med hänsyn till ändringar genom revideringar.

Krav på reparation

Om en defekt bedöms som en kontraktsbrist kan det göras en begäran om reparation från beställaren.

Före ändringen kunde man inte begära reparation om defekten inte var betydande och reparationen krävde överdriven kostnad. Denna begränsning har tagits bort genom ändringen.

Även efter ändringen kan det dock vara så att om “kontraktsbristen inte är betydande och reparationen kräver överdriven kostnad”, kan reparationen anses vara omöjlig och begäran om reparation kan inte godkännas.

Krav på skadestånd

Om ett system eller en programvara med defekter gör att normal verksamhet inte kan utföras eller extra kostnader uppstår, kan det göras en begäran om skadestånd från beställaren.

Före ändringen kunde man begära skadestånd oavsett om det fanns försummelse eller inte, så länge det inte fanns något särskilt avtal.

Men genom ändringen, om det finns en ansvarsfrihetsgrund (en orsak som inte kan tillskrivas gäldenären) för den som ska utföra, kan man inte begära skadestånd.

Därför, om leverantören kan bevisa ansvarsfrihetsgrunden, behöver de inte ta ansvar för skadestånd.

Avbrytande av kontrakt

Ett utvecklingskontrakt kan avbrytas på grund av kontraktsbrist i systemet eller programvaran.

I det tidigare nämnda rättsfallet godkändes avbrytandet av kontraktet eftersom det fanns en defekt som gjorde att sökprocessen i lagersystemet tog mer än 30 minuter, vilket gjorde att behandlingstiden blev alltför lång och det uppstod problem som att terminalen inte kunde användas, och man var tvungen att ge upp att fortsätta använda det införda systemet (Tokyo District Court, 22 april 2002 (Heisei 14)).

Före ändringen kunde man avbryta kontraktet endast om man “inte kunde uppnå syftet med kontraktet” på grund av defekten. Men denna begränsning har tagits bort genom ändringen.

Det bör dock noteras att även under den ändrade lagen, om graden av kontraktsbrist är “mindre”, kommer uppsägning inte att godkännas.

Krav på minskning av ersättning

Rätten att begära minskning av ersättning har införts genom ändringen.

Om det finns en defekt i systemet och beställaren har begärt reparation, men reparationen inte har utförts trots att en rimlig tid har gått, kan det göras en begäran om minskning av ersättning från beställaren.

Period för att ta ansvar

• Krav på reparation
• Krav på skadestånd
• Avbrytande av kontrakt
• Krav på minskning av ersättning

Det finns en begränsad period under vilken dessa rättigheter kan utövas.

Specifikt kan rättigheterna utövas endast om beställaren har meddelat leverantören om kontraktsbristen i systemet eller programvaran “inom ett år från det att de blev medvetna om det”.

Före ändringen var rättigheterna begränsade till “inom ett år från leveransen” av systemet eller programvaran. Därför kan man säga att perioden under vilken rättigheterna kan utövas har förlängts genom ändringen.

Utöver denna tidsbegränsning gäller också bestämmelserna om preskription för de ovan nämnda rättigheterna som erkänns på grund av ansvar för kontraktsbrist.

Därför, om man till exempel först blir medveten om existensen av en defekt 11 år efter att man har mottagit systemet eller programvaran, kommer rättigheterna, såsom rätten att begära skadestånd, att ha preskriberats efter “tio år”, oavsett om man meddelar om kontraktsbristen “inom ett år från det att man blev medveten om den” eller inte, och man kan inte utöva rättigheterna.

Vägran att betala ersättning

Beställaren kan vägra att betala hela ersättningen tills utvecklaren har utfört reparationen eller betalat skadestånd.

Punkter att överväga för kontraktsbestämmelser med hänsyn till kontraktsbrist

Bestämmelserna om ansvar för kontraktsbrist är valfria och kan begränsas eller förkortas genom särskilda avtal mellan parterna.

Här kommer vi att förklara kontraktsbestämmelser som bör beaktas i samband med system- och programvaruutveckling med hänsyn till ansvar för kontraktsbrist.

Punkt 1: Händelser och omfattning som utgör kontraktsbrist

Om det finns missnöje med ett system eller en programvara, kan beställaren vilja hålla leverantören ansvarig för kontraktsbrist.

Men som leverantör kan man inte acceptera att bli hållen ansvarig för kontraktsbrist bara för att beställaren inte gillar något, även om det bara är en specifikation.

Dessutom kan leverantören potentiellt höja offerten betydligt för att skydda sig mot orättvisa anspråk på kontraktsbrist, vilket skulle vara till nackdel för beställaren.

Därför är det viktigt att tydligt definiera händelser och omfång som utgör kontraktsbrist genom att till exempel skriftligt ange vilket syfte beställaren har och vilka funktioner de vill att systemet ska ha, och att säkerställa att detta återspeglas i specifikationerna.

Det kan också vara värt att klargöra att om ett system eller en programvara levereras enligt vad som anges i specifikationerna, kommer det inte att anses vara en kontraktsbrist, även om det finns några problem med specifikationerna.

Genom denna bestämmelse kan man förhindra att man hålls ansvarig för kontraktsbrist på grund av beställarens preferenser, trots att man har utvecklat enligt specifikationerna.

Punkt 2: Tydliggörande av garantiperioden

Perioden för att utöva rätten till ansvar för kontraktsbrist räknas inte från “leveranstidpunkten” för produkten, utan från “tidpunkten då kontraktsbristen upptäcktes”.

Även om det finns en separat preskriptionstid, sträcker sig denna period som längst över “tio år”, vilket är en lång tid.

För leverantören kan det vara en stor börda att behöva erbjuda en gratis garanti under en så lång period som “tio år” beroende på omständigheterna, och de kommer att behöva lägga till detta i offerten.

Å andra sidan kan det vara mer fördelaktigt för beställaren att flexibelt ställa in garantiperioden baserat på saker som användningsperioden för systemet eller programvaran.

Därför kan det vara värt att överväga att flexibelt ställa in garantiperioden baserat på innehållet i systemet och liknande.

Punkt 3: Hantering när kontraktsbrist uppstår

När en kontraktsbrist uppstår kan parterna genom gemensamt avtal begränsa vilka rättigheter som kan utövas, såsom skadeståndskrav eller uppsägning, bland de rättigheter som erkänns enligt civilrätten.

Som beställare är det viktigt att förstå vilka begränsningar som finns i kontraktet.

Sammanfattning: Konsultera en advokat när du skapar ett kontrakt som inkluderar “ansvar för kontraktsbrist”

Ändringar i den japanska civilrätten (Minpō) har haft en stor inverkan på juridiska aspekter av system- och programvaruutveckling.

Om det uppstår ett fel i det levererade systemet, är det inte alltid klart om detta utgör en “kontraktsbrist”, eller vilket ansvar som kan ifrågasättas.

Dessutom är det avgörande att ha en grundlig diskussion mellan beställaren och leverantören vid kontraktsskedet för att förebygga tvister i förväg.

Om du har några bekymmer om att skapa ett kontrakt, tveka inte att konsultera en specialistadvokat.