MONOLITH LAW OFFICE+81-3-6262-3248Hverdage 10:00-18:00 JST [English Only]

MONOLITH LAW MAGAZINE

General Corporate

Tjekpunkter for kontrakter, når systemudvikling udføres på en semi-delegeret måde

General Corporate

Tjekpunkter for kontrakter, når systemudvikling udføres på en semi-delegeret måde

I øjeblikket er brugen af IT i vores lands borgers liv og socioøkonomiske aktiviteter hurtigt stigende, i takt med den dramatiske forbedring af computerens behandlingskapacitet og udbredelsen af internettet. Som følge heraf er den sociale indvirkning af forretnings- og servicenedbrud eller funktionsnedgang forårsaget af informationssystemfejl voksende dag for dag, og forbedring af systemets pålidelighed og sikkerhed er blevet en stor udfordring.

På den anden side, da den kumulative kontrakt om IT-systemudvikling ikke blev forudset ved lovgivningens begyndelse, har det en tendens til at gøre transaktionsindholdet uklart, og visualisering af transaktioner baseret på tæt kommunikation mellem ordregiveren (brugeren) og entreprenøren (leverandøren), og afklaring af rollefordeling og ansvarsforhold er blevet en udfordring.

Desuden, da informationssystemer nu er bygget på en kombination af forskellige elementer, har de begyndt at inkludere risici relateret til kombinationer, der ikke eksisterede før.

For at forbedre pålideligheden og sikkerheden af disse informationssystemer har det japanske Ministerium for Økonomi, Handel og Industri offentliggjort retningslinjer, hvor der i dem er fremlagt en modelkontrakt for systemudvikling, med kommentarer til hver klausul.

I denne artikel vil vi forklare kontrolpunkterne for kontrakter, når du indgår en semi-delegeret kontrakt i IT-systemudviklingsarbejde, ved at citere klausulerne i den modelkontrakt, der er fremlagt af det japanske Ministerium for Økonomi, Handel og Industri.

Systemudvikling er processen med at skabe et virksomhedssystem ved hjælp af IT-teknologi.

Systemudvikling og semi-fiduciære kontrakter

Hvad er en semi-fiduciær kontrakt?

En semi-fiduciær kontrakt er defineret i civilretten ved at anvende bestemmelserne i en fiduciær kontrakt.

Afsnit 10 Fiduciær
Artikel 643 En fiduciær kontrakt opstår, når en part overlader en juridisk handling til den anden part, og denne accepterer det.
Artikel 656 Bestemmelserne i dette afsnit gælder også for ikke-juridiske opgaver.

En semi-fiduciær kontrakt er en kontrakt, hvor formålet er, at en person udfører opgaver på vegne af en anden person. Den person, der accepterer opgaven, har pligt til at udføre arbejdet med den omhu, en god administrator ville udvise (pligten til at udvise god forvaltning). God forvaltningspligt betyder simpelthen at “gøre sit bedste”.

Forskelle fra en kontrakt om udførelse af arbejde

I en semi-fiduciær kontrakt, som nævnt ovenfor, har den person, der accepterer opgaven, pligten til at udvise god forvaltning, men i modsætning til en kontrakt om udførelse af arbejde, har de ikke pligt til at fuldføre arbejdet. Derfor, medmindre der er et klart defineret produkt, har den person, der accepterer opgaven, ikke ansvar for mangler. Dog, da de har pligten til at udvise god forvaltning, kan de i tilfælde af grov forsømmelse eller alvorlig mangel på opmærksomhed være ansvarlige for skadeserstatning på grund af kontraktbrud, eller kontrakten kan blive ophævet.

Som nævnt ovenfor, har en semi-fiduciær kontrakt ikke pligt til at fuldføre arbejdet. På den anden side, i en kontrakt om udførelse af arbejde, har man pligt til at fuldføre arbejdet. Den følgende artikel forklarer, hvad der sker, når en systemudviklingskontrakt indgås på en udførelsesbasis.

https://monolith.law/corporate/checkpoints-for-contracts-of-system-development [ja]

Modelklausuler og kontrolpunkter for semi-delegation

Støtte til kravspecifikationsudarbejdelse

(Implementering af støtte til kravspecifikationsudarbejdelse)
Artikel 〇: Part B skal, efter indgåelse af den individuelle kontrakt specificeret i artikel 〇, levere en service, der støtter Part A i udarbejdelsen af kravspecifikationer baseret på informationssystemkonceptdokumenter, systemplanlægningsdokumenter osv., som Part A har udarbejdet (herefter benævnt “støtte til kravspecifikationsudarbejdelse”).

2. Part B skal, baseret på specialiseret viden og erfaring inden for informationsteknologi, udføre støtteopgaver såsom undersøgelser, analyser, organisering, forslag og rådgivning med den omhu, en god administrator ville udvise, for at sikre, at Part A’s arbejde udføres gnidningsløst og korrekt.

Kravspecifikation er en proces, hvor brugerens kravspecifikationer (funktioner, der skal realiseres i software) samles, og det er en proces, der er stærkt afhængig af brugerens forretningsindhold. Derfor antager denne sektion, at brugeren udfører kravspecifikationsarbejdet, og leverandøren støtter dette i form af en semi-delegeret kontrakt. Men det betyder ikke, at leverandøren ikke har noget ansvar, fordi det er en semi-delegeret kontrakt. Som modtager har de en pligt til at udvise god forvaltning. Hvis denne pligt til god forvaltning forsømmes, og støtten til kravspecifikationsudarbejdelse ikke udføres korrekt, vil de være ansvarlige for kontraktbrud på grund af overtrædelse af pligten til god forvaltning.

(Indgåelse af individuel kontrakt vedrørende støtte til kravspecifikationsudarbejdelse)
Artikel 〇: Part A og Part B skal, efter at have drøftet handelsbetingelserne angivet i artikel 〇, paragraf 〇, indgå en individuel kontrakt vedrørende støtte til kravspecifikationsudarbejdelse.

Rækkevidden af støtte til kravspecifikationsudarbejdelse skal aftales i en individuel kontrakt i overensstemmelse med de betingelser, der er angivet i den foregående artikel.

(Kravspecifikationsmøde)
Artikel 〇: Part A skal afholde et kravspecifikationsmøde (herefter i dette afsnit benævnt “kravspecifikationsmøde”) med den frekvens, der anses for nødvendig for at afklare eller bekræfte de forhold, der er nødvendige for udarbejdelsen af kravspecifikationer, og Part B skal deltage i dette og udføre støtte til kravspecifikationsudarbejdelse.

2. Part B kan også afholde et kravspecifikationsmøde, når det anses for nødvendigt for at udføre støtte til kravspecifikationsudarbejdelse, og Part A skal deltage i dette.

For at udarbejde kravspecifikationer, der definerer forretningskrav og systemfunktionskrav og ikke-funktionskrav, er det nødvendigt med samarbejde mellem brugerens forretningsafdeling og informationssystemafdeling og leverandøren. Da denne proces er semi-delegeret, bestemmer paragraf 1, at brugeren er vært, og leverandøren, der yder støtte, deltager. Afklaring eller bekræftelse af de forhold, der er nødvendige for udarbejdelsen af kravspecifikationer, udføres alle i kravspecifikationsmødet, og både brugeren og leverandøren er bundet af resultaterne af mødet.

Paragraf 2 bestemmer, at leverandøren også kan afholde et kravspecifikationsmøde, når det er nødvendigt for at udføre støtte til kravspecifikationsudarbejdelse.

(Bekræftelse af kravspecifikationer)
Artikel 〇: Når Part A har afsluttet udarbejdelsen af kravspecifikationer, skal Part A og Part B inden for den periode, der er fastsat i den individuelle kontrakt (herefter benævnt “kravspecifikationsinspektionsperiode”), inspicere, om kravspecifikationerne overholder de beslutninger, der er truffet på kravspecifikationsmødet i den foregående artikel, og som bevis for bekræftelse skal begge parters ansvarlige personer underskrive og stemple kravspecifikationerne. Dog, hvis inspektionen viser, at kravspecifikationerne ikke overholder de beslutninger, der er truffet på kravspecifikationsmødet, skal Part A udarbejde en revideret version inden for den aftalte frist efter drøftelser, og Part A og Part B skal igen udføre ovenstående inspektion og bekræftelsesprocedure.

2. Kravspecifikationerne anses for at være bekræftet ved bekræftelse af begge parter i henhold til den foregående paragraf.

3. Hvis det er nødvendigt at ændre betingelserne i den individuelle kontrakt, såsom arbejdsperiode og honorar, på grund af ændringer i paragraf 〇, skal dette gøres i henhold til proceduren i artikel 〇.

Kravspecifikation er en fase, hvor kravene bekræftes efter at have modtaget et groft estimat fra leverandøren og er nødvendige for at udføre systemdesign osv. Hvis kravene er uklare, vil det være svært for leverandøren at give et nøjagtigt estimat, og der kan opstå problemer i den efterfølgende udviklingsfase. Denne artikel fastlægger en procedure, hvor brugeren og leverandøren bekræfter kravspecifikationerne, der er grundlaget for det efterfølgende udviklingsarbejde, og lederne bekræfter dem ved at underskrive og stemple dem. Der kan være tilfælde, hvor det er nødvendigt at rette kravspecifikationerne under inspektionen for at bekræfte kravspecifikationerne, så den foregående paragraf fastlægger proceduren for dette.

Paragraf 2 gør det klart, at kravspecifikationerne bekræftes ved bekræftelse af både brugeren og leverandøren.
Paragraf 3 fastlægger, at hvis det er nødvendigt at ændre betingelserne i den individuelle kontrakt, såsom at øge mængden af leverandørens arbejde mere end oprindeligt forventet eller at forlænge tidsplanen, som følge af rettelserne i paragraf 1, skal de nødvendige ændringer foretages.

(Afslutning og bekræftelse af arbejdet)
Artikel 〇: Part B skal, inden for 〇 dage efter bekræftelse af kravspecifikationerne i den foregående artikel, udarbejde en arbejdsafslutningsrapport og indsende den til Part A.

2. Part A skal inden for den periode, der er fastsat i den individuelle kontrakt (herefter benævnt “kravspecifikationsstøtteafslutningsinspektionsperiode”), bekræfte den pågældende arbejdsafslutningsrapport.

3. Hvis Part A ikke har nogen tvivl om indholdet af den pågældende arbejdsafslutningsrapport, skal Part A underskrive og stemple en arbejdsafslutningsbekræftelsesrapport og give den til Part B for at bekræfte afslutningen af støtten til kravspecifikationsudarbejdelse.

4. Hvis Part A ikke fremsætter indsigelser med en konkret begrundelse skriftligt inden for kravspecifikationsstøtteafslutningsinspektionsperioden, anses Part A for at have bekræftet afslutningen af arbejdet ved udløbet af kravspecifikationsstøtteafslutningsinspektionsperioden.

Da denne proces er semi-delegeret, fastlægger denne artikel en procedure for at bekræfte, om leverandøren har udført støttearbejdet korrekt baseret på pligten til god forvaltning ved hjælp af en arbejdsafslutningsrapport, der registrerer arbejdsindholdet.
Paragraf 1 fastlægger pligten til at indsende en arbejdsafslutningsrapport.
Paragraf 2 gør inspektionsperioden for rapporten klar for at undgå forsinkelser i bekræftelsen.
Paragraf 3 fastlægger, at afslutningen af støtten til kravspecifikationsudarbejdelse bekræftes ved at brugeren underskriver og stempler en arbejdsafslutningsbekræftelsesrapport.
Paragraf 4 fastlægger en formodet afslutningsbekræftelse, hvis brugeren ikke fremsætter indsigelser skriftligt inden for inspektionsperioden. Denne bestemmelse tager højde for, at hvis brugeren af en eller anden grund ikke udfører bekræftelsesproceduren rettidigt, kan det forsinke det efterfølgende arbejde, eller det kan starte det efterfølgende arbejde uden at gøre bekræftelsen klar, hvilket kan gøre ansvarsforholdet mellem brugeren og leverandøren uklart.

Udarbejdelse af eksterne design dokumenter

Kravspecifikationen er en proces, der samler systemkravene (funktionerne, der skal realiseres i softwaren), som brugeren forsøger at bygge, og er stærkt afhængig af brugerens forretningsindhold.

(Implementering af støtte til udarbejdelse af eksterne design dokumenter)
Artikel X: Part B skal, efter indgåelse af den individuelle kontrakt specificeret i artikel X, levere tjenester til at støtte part A i udarbejdelsen af eksterne design dokumenter (herefter kaldet “støtte til udarbejdelse af eksterne design dokumenter”).

2. Part B skal, baseret på specialiseret viden og erfaring inden for informationsteknologi, udføre støtteopgaver såsom undersøgelse, analyse, organisering, forslag og rådgivning med den omhu, en god administrator ville udvise, for at sikre, at part A’s arbejde udføres gnidningsløst og korrekt.

Udarbejdelse af eksterne design dokumenter er en proces, der fastlægger brugen af dele relateret til grænseflader, såsom skærme og rapporter. Eksterne design dokumenter skal i princippet indeholde alle de oplysninger, der gør det muligt for leverandøren at udvikle programmet. Selvom eksterne design dokumenter indeholder detaljeret information om brugen af formularer, er det kun brugeren, der har beføjelse til at ændre kravspecifikationerne, da det er brugeren, der bestemmer forretningsindholdet.
Derfor forudsætter denne artikel, at brugeren har ansvaret for at færdiggøre de eksterne design dokumenter, og at leverandøren støtter færdiggørelsen af de eksterne design dokumenter som modtager i en quasi-delegation kontrakt.
Men selvom det er en quasi-delegation, betyder det ikke, at leverandøren ikke har noget ansvar. Som modtager har leverandøren en pligt til at udvise god forvaltning. Derfor, hvis denne pligt til god forvaltning forsømmes, og støtten til udarbejdelse af de eksterne design dokumenter ikke udføres korrekt, kan leverandøren være ansvarlig for misligholdelse af kontrakten på grund af overtrædelse af pligten til god forvaltning.

(Indgåelse af individuel kontrakt vedrørende støtte til udarbejdelse af eksterne design dokumenter)
Artikel X: Part A og Part B skal, efter at have drøftet handelsbetingelserne angivet i afsnit 1 i artikel 4, fastlægge disse og indgå en individuel kontrakt vedrørende støtte til udarbejdelse af eksterne design dokumenter.

Omfanget af støtte til udarbejdelse af eksterne design dokumenter skal aftales i den individuelle kontrakt.

(Ekstern design overvejelsesmøde)
Artikel X: Part A skal, når det er nødvendigt for at afklare eller bekræfte de forhold, der er nødvendige for udarbejdelsen af de eksterne design dokumenter, afholde et møde om udarbejdelse af de eksterne design dokumenter (herefter i dette afsnit kaldet “eksternt design overvejelsesmøde”) med den frekvens, der anses for nødvendig, og Part B skal deltage i dette og udføre støtte til udarbejdelse af eksterne design dokumenter.

2. Part B kan også, når det anses for nødvendigt for at udføre støtte til udarbejdelse af eksterne design dokumenter, afholde et eksternt design overvejelsesmøde, og Part A skal deltage i dette.

3. Hvis Part A, som følge af overvejelserne i det eksterne design overvejelsesmøde, ønsker at ændre indholdet af kravspecifikationen, og det er nødvendigt at ændre betingelserne i den individuelle kontrakt, såsom arbejdsperioden og honoraret, skal dette ske i overensstemmelse med proceduren i artikel X (ændring af denne kontrakt og den individuelle kontrakt).

For at fastlægge grænsefladerne, såsom skærme og rapporter, i de eksterne design dokumenter, er det nødvendigt med et samarbejde mellem brugeren og leverandøren.
Da denne proces er en quasi-delegation, fastlægger afsnit 1, at brugeren er den primære arrangør, og at leverandøren, der yder støtte, deltager. Alle afklaringer eller bekræftelser af de forhold, der er nødvendige for udarbejdelsen af de eksterne design dokumenter, skal foretages i det eksterne design overvejelsesmøde, og både leverandøren og brugeren er bundet af resultaterne af overvejelserne i mødet.
Afsnit 2 fastlægger, at leverandøren også kan afholde et eksternt design overvejelsesmøde, når det anses for nødvendigt for at udføre støtte til udarbejdelse af eksterne design dokumenter.
Afsnit 3 fastlægger, at hvis brugeren, som følge af overvejelserne i det eksterne design overvejelsesmøde, ønsker at ændre indholdet af kravspecifikationen, og det er nødvendigt at ændre betingelserne i den individuelle kontrakt, såsom arbejdsperioden og honoraret, skal dette ske i overensstemmelse med proceduren for ændring af denne kontrakt og den individuelle kontrakt.

(Bekræftelse af de eksterne design dokumenter)
Artikel X: Når Part A har færdiggjort udarbejdelsen af de eksterne design dokumenter, skal Part A og Part B inden for den periode, der er fastlagt i den individuelle kontrakt (herefter kaldet “inspektionsperioden for de eksterne design dokumenter”), inspicere, om de eksterne design dokumenter er i overensstemmelse med kravspecifikationen, der er bekræftet i henhold til artikel X, og de beslutninger, der er truffet i det eksterne design overvejelsesmøde specificeret i den foregående artikel, og som bevis for denne overensstemmelse skal de ansvarlige for Part A og Part B underskrive og stemple de eksterne design dokumenter. Dog, hvis det ved inspektionen konstateres, at de eksterne design dokumenter ikke er i overensstemmelse med kravspecifikationen, der er bekræftet i henhold til artikel X, og de beslutninger, der er truffet i det eksterne design overvejelsesmøde, skal Part A, efter drøftelser, udarbejde en revideret version inden for en fastsat frist, og Part A og Part B skal igen udføre ovenstående inspektion og bekræftelsesprocedure.

2. De eksterne design dokumenter anses for at være bekræftet ved bekræftelsen af Part A og Part B i henhold til det foregående afsnit.

3. Hvis det er nødvendigt at ændre betingelserne i den individuelle kontrakt, såsom arbejdsperioden og honoraret, som følge af revisionen i afsnit 1, skal dette ske i overensstemmelse med proceduren i artikel X (ændring af denne kontrakt og den individuelle kontrakt).

Denne artikel fastlægger proceduren for, at brugeren og leverandøren bekræfter de eksterne design dokumenter, som brugeren har udarbejdet, og at de ansvarlige for begge parter underskriver og stempler dokumenterne for at bekræfte dem.
Da det kan være nødvendigt at foretage ændringer i de eksterne design dokumenter ved inspektionen for at bekræfte dem, fastlægger afsnit 1, meningen med denne procedure.

Afsnit 2 fastlægger klart, at de eksterne design dokumenter bekræftes ved bekræftelsen af både brugeren og leverandøren.
Afsnit 3 fastlægger, at hvis det er nødvendigt at ændre betingelserne i den individuelle kontrakt, såsom arbejdsperioden og honoraret, som følge af revisionen i afsnit 1, skal dette ske i overensstemmelse med proceduren for ændring af denne kontrakt og den individuelle kontrakt.

(Afslutning og bekræftelse af arbejdet)
Artikel X: Part B skal, inden for X dage efter bekræftelsen af de eksterne design dokumenter specificeret i den foregående artikel, udarbejde en rapport om afslutningen af arbejdet og indsende den til Part A.

2. Part A skal, inden for den periode, der er fastlagt i den individuelle kontrakt (herefter kaldet “inspektionsperioden for afslutningen af støtte til udarbejdelse af eksterne design dokumenter”), bekræfte indholdet af den nævnte rapport om afslutningen af arbejdet.

3. Hvis Part A ikke har nogen indvendinger mod indholdet af den nævnte rapport om afslutningen af arbejdet, skal Part A underskrive og stemple en bekræftelse af afslutningen af arbejdet og overdrage den til Part B for at bekræfte afslutningen af støtte til udarbejdelse af eksterne design dokumenter.

4. Hvis Part A ikke fremsætter nogen indvendinger med en konkret begrundelse skriftligt inden for inspektionsperioden for afslutningen af støtte til udarbejdelse af eksterne design dokumenter, anses Part A for at have bekræftet afslutningen af arbejdet ved udløbet af inspektionsperioden for afslutningen af støtte til udarbejdelse af eksterne design dokumenter.

Da denne proces er en quasi-delegation, fastlægger denne artikel en procedure for at bekræfte, om leverandøren har udført støttearbejdet korrekt i henhold til pligten til god forvaltning, ved hjælp af en rapport om afslutningen af arbejdet, der registrerer arbejdsindholdet.
Afsnit 2 fastlægger en inspektionsperiode for at undgå forsinkelser i bekræftelsen af rapporten.
Afsnit 3 fastlægger, at afslutningen af støtte til udarbejdelse af eksterne design dokumenter bekræftes ved at brugeren underskriver og stempler en bekræftelse af afslutningen af arbejdet.
Afsnit 4 fastlægger en formodet bekræftelse af afslutningen, hvis brugeren ikke fremsætter nogen indvendinger skriftligt inden for inspektionsperioden for afslutningen af støtte til udarbejdelse af eksterne design dokumenter. Denne bestemmelse tager højde for det faktum, at hvis brugeren af en eller anden grund ikke udfører bekræftelsesproceduren rettidigt, kan det forsinke det efterfølgende arbejde, eller det kan starte det efterfølgende arbejde uden at have klart bekræftet, om det er afsluttet, hvilket kan gøre ansvarsforholdet mellem brugeren og leverandøren uklart.

Softwareudviklingsopgaver

Efter bestemmelserne for systemets eksterne designproces, som er grundlæggende design, følger bestemmelserne for systemets interne designproces, som er detaljeret design. I systemets interne designproces er det normalt, at det, der skal udvikles, og specifikationerne er defineret i arbejdet op til dette punkt. I den modelkontrakt, som det japanske Ministerium for Økonomi, Handel og Industri (METI) har, er det defineret som en kontrakttype. Detaljerne er forklaret i artiklen nedenfor.

https://monolith.law/corporate/checkpoints-for-contracts-of-system-development [ja]

Forberedelse og overgangsstøtte til software drift

(Implementering af forberedelse og overgangsstøtte til software drift)
Paragraf 〇: Part B skal, efter indgåelse af den individuelle kontrakt specificeret i paragraf 〇, udføre nødvendig støtte (herefter kaldet “forberedelse og overgangsstøtte til software drift”) for Part A i forbindelse med systemtest, implementerings- og acceptstøtte samt driftstest, som Part A udfører for at drive den pågældende software i praksis.

2. Part B skal, baseret på specialiseret viden og erfaring inden for informationsteknologi, udføre støttearbejdet med den omhu, en god administrator ville udvise, for at sikre, at Part A’s arbejde udføres gnidningsløst og effektivt.

I det følgende vil vi definere bestemmelserne for udførelse af forberedelse og overgangsstøtte til software drift på en semi-delegeret basis. I systemaccept- og implementeringsstøttefasen er det almindeligt, at brugeren tager initiativet, så i den modelkontrakt, der er udarbejdet af det japanske Ministerium for Økonomi, Handel og Industri, er det defineret som en semi-delegeret form, hvor brugeren tager initiativet, og leverandøren støtter dette. Paragraf 2 fastlægger, at leverandøren, som den delegerede part, har en pligt til at udvise god forvaltning.

(Afslutning og bekræftelse af arbejdet)
Paragraf 32: Part B skal, inden for ○ dage efter afslutningen af forberedelse og overgangsstøtte til software drift, udarbejde en arbejdsafslutningsrapport og indsende den til Part A.

2. Part A skal, inden for den periode, der er fastlagt i den individuelle kontrakt (herefter kaldet “inspektionsperiode for afslutning af forberedelse og overgangsstøtte til software drift”), gennemføre en inspektion af den pågældende arbejdsafslutningsrapport.

3. Hvis Part A ikke har nogen tvivl om indholdet af den pågældende arbejdsafslutningsrapport, skal Part A bekræfte afslutningen af forberedelse og overgangsstøtte til software drift ved at underskrive og stemple en arbejdsafslutningsbekræftelsesrapport og overdrage den til Part B.

4. Hvis Part A ikke fremsætter indsigelser med en specifik begrundelse skriftligt inden for inspektionsperioden for afslutning af forberedelse og overgangsstøtte til software drift, vil afslutningen af arbejdet blive betragtet som bekræftet ved udløbet af inspektionsperioden.

I denne paragraf fastlægger vi proceduren for at bekræfte, om leverandøren har udført forberedelse og overgangsstøtte til software drift korrekt på en semi-delegeret basis, baseret på en pligt til god forvaltning.
Paragraf 2 fastlægger, at leverandøren skal indsende en arbejdsafslutningsrapport til brugeren inden for en bestemt periode efter afslutningen af arbejdet.
Paragraf 3 fastlægger, at brugeren skal gennemføre en inspektion af arbejdsafslutningsrapporten efter at have fastlagt inspektionsperioden.
Paragraf 4 fastlægger en formodet bekræftelse i tilfælde af, at brugeren forsømmer at bekræfte afslutningen af arbejdet i henhold til de to foregående paragraffer.

Afgørelse af kontraktens karakter

For at bestemme karakteren af en kontrakt, skal man se på kontrakten som helhed og overveje, om dens formål er at “levere et færdigt produkt” eller om det er for leverandøren at “udføre arbejdet på en rimelig måde”. En generel retningslinje er, om indholdet af det produkt, der skal fuldføres, er blevet bestemt i nogen grad, og om projektet er blevet fremmet i den retning.
For detaljer om, hvilke aspekter man skal fokusere på, se den følgende artikel.

Managing Attorney: Toki Kawase

The Editor in Chief: Managing Attorney: Toki Kawase

An expert in IT-related legal affairs in Japan who established MONOLITH LAW OFFICE and serves as its managing attorney. Formerly an IT engineer, he has been involved in the management of IT companies. Served as legal counsel to more than 100 companies, ranging from top-tier organizations to seed-stage Startups.

Tilbage til toppen