Czego należy szukać w umowach dotyczących systemów na zlecenie?

Ministerstwo Gospodarki Japonii (Japanese Ministry of Economy, Trade and Industry) przedstawiło modelowe klauzule dla umów o rozwój systemów IT w swoich “Wytycznych dotyczących poprawy niezawodności systemów informacyjnych” (Japanese Guidelines on Improving the Reliability of Information Systems). Wraz z rozpowszechnieniem się Internetu, społeczne skutki awarii systemów informacyjnych, takie jak przerwy w działalności lub usługach lub obniżenie ich funkcjonalności, stają się coraz bardziej poważne. Poprawa niezawodności i bezpieczeństwa systemów jest pilnym zadaniem. Z drugiej strony, umowy o rozwój systemów IT mają tendencję do stawania się niejasne w zakresie treści transakcji. Te klauzule mają na celu zwiększenie przejrzystości tych umów oraz jasne określenie podziału ról i odpowiedzialności. W tym artykule omówimy kluczowe punkty do sprawdzenia w umowie, gdy zawierasz umowę na rozwój systemu IT na zasadach zlecenia, odwołując się do klauzul modelowej umowy Ministerstwa Gospodarki.

Rozwój systemu i umowy o dzieło

Co to jest umowa o dzieło

Umowa o dzieło jest zdefiniowana w prawie cywilnym w następujący sposób:

Artykuł 632
Umowa o dzieło powstaje, gdy jedna ze stron zobowiązuje się do wykonania określonej pracy, a druga strona zobowiązuje się do zapłaty za wynik tej pracy.

W umowie o dzieło, wymogiem jest “zobowiązanie do wykonania pracy”. Na przykład, jeśli celem umowy jest stworzenie określonego systemu do określonego terminu, obowiązkiem dostawcy jest “ukończenie systemu do określonego terminu”. Jeśli nie uda się ukończyć systemu do ustalonego terminu, może to prowadzić do odpowiedzialności za niewykonanie zobowiązania z tytułu opóźnienia w wykonaniu. Jednakże, jeśli po dostarczeniu i ukończeniu systemu w określonym terminie zostaną znalezione jakiekolwiek braki, obowiązek dostawcy został już wykonany, więc niewykonanie zobowiązania nie jest problemem, a kwestia staje się problemem odpowiedzialności za wady. W kontekście rozwoju systemu, kiedy “ukończenie pracy” jest uznawane, jest szczegółowo omówione w poniższym artykule.

https://monolith.law/corporate/completion-of-work-in-system-development[ja]

Różnice w stosunku do umowy zlecenia

W umowie o dzieło, dostawca ma obowiązek ukończenia pracy, więc jeśli dostarczony produkt ma wady, dostawca ponosi odpowiedzialność za te wady. Z drugiej strony, w umowie zlecenia nie ma obowiązku ukończenia pracy, więc nie ma odpowiedzialności za wady, jak w przypadku umowy o dzieło. Jednakże, jeśli w procesie przetwarzania zadań, obowiązek starannego zarządzania jest uznany, może to prowadzić do osobnej odpowiedzialności za niewykonanie zobowiązania, takiej jak odszkodowanie za szkody. Jakie odpowiedzialności mogą być problemem w umowie o rozwój systemu, jest szczegółowo omówione w poniższym artykule.

https://monolith.law/corporate/responsibility-system-development[ja]

Model kontraktu na zlecenie i punkty kontrolne

Wsparcie w tworzeniu definicji wymagań

Definicja wymagań to proces zbierania specyfikacji systemu, który użytkownik zamierza zbudować. W fazie definiowania wymagań, rozważany jest kierunek budowy systemu i decyduje się, jaki system ma zostać zbudowany. Ze względu na fakt, że nie można konkretnie przewidzieć wyników, japońskie Ministerstwo Gospodarki, Handlu i Przemysłu określa ten proces jako quasi-mandate (quasi-zlecenie). Szczegółowe wyjaśnienie znajduje się w poniższym artykule.

https://monolith.law/corporate/system-development-contract-check-quasi-mandate[ja]

Tworzenie dokumentacji zewnętrznego projektu

(Realizacja usługi tworzenia dokumentacji zewnętrznego projektu)
Artykuł ○ Strona B, po zawarciu indywidualnej umowy określonej w artykule ○, przeprowadzi usługę tworzenia dokumentacji zewnętrznego projektu dla oprogramowania na podstawie dokumentacji wymagań ustalonych zgodnie z postanowieniami artykułu ○.

2. Podczas realizacji usługi tworzenia dokumentacji zewnętrznego projektu, Strona B może zażądać od Strony A niezbędnej współpracy, a Strona A zobowiązuje się do odpowiedzi na takie żądanie w odpowiednim czasie.

Tworzenie dokumentacji zewnętrznego projektu to usługa polegająca na określeniu sposobu korzystania z interfejsów, takich jak ekrany i formularze. Dokumentacja zewnętrznego projektu powinna zawierać wszystkie informacje, które umożliwią dostawcy rozwijanie programu na jej podstawie. Dokumentacja zewnętrznego projektu zawiera szczegółowe informacje o wykorzystaniu formatów, ale możliwość zmiany wymagań leży po stronie użytkownika, który decyduje o treści usługi. Jednakże, jeśli dokumentacja wymagań, będąca wynikiem wcześniejszej fazy tworzenia dokumentacji zewnętrznego projektu, jasno definiuje potrzeby użytkownika i treść pracy, którą dostawca ma zakończyć, możliwe jest zawarcie umowy na zasadzie zlecenia, w której dostawca jest głównym podmiotem odpowiedzialnym za tworzenie dokumentacji zewnętrznego projektu.

Pierwszy punkt określa, że dostawca jest głównym podmiotem odpowiedzialnym za realizację usługi, ponieważ jest to usługa na zasadzie zlecenia. Jednakże, nawet w przypadku umowy na zasadzie zlecenia, zewnętrzny projekt ma duży wpływ na ustalenie treści usługi użytkownika, dlatego wymagane jest aktywne zaangażowanie użytkownika. Dlatego drugi punkt jasno określa, że dostawca może zażądać od użytkownika współpracy niezbędnej do rozważenia i ustalenia specyfikacji systemu, a użytkownik zobowiązuje się do odpowiedzi na takie żądanie w odpowiednim czasie, co oznacza, że rozważanie specyfikacji systemu jest wspólnym zadaniem dostawcy i użytkownika.

(Zawarcie indywidualnej umowy dotyczącej usługi tworzenia dokumentacji zewnętrznego projektu)
Artykuł ○ Strony A i B, w odniesieniu do usługi tworzenia dokumentacji zewnętrznego projektu, ustalą warunki transakcji określone w artykule ○, punkcie ○, po przeprowadzeniu negocjacji, a następnie zawrą indywidualną umowę dotyczącą usługi tworzenia dokumentacji zewnętrznego projektu.

Zakres usługi tworzenia dokumentacji zewnętrznego projektu jest ustalany w indywidualnej umowie zgodnie z warunkami transakcji określonymi w poprzednim artykule.

(Spotkanie dotyczące zewnętrznego projektu)
Artykuł ○ Strona B, w celu wyjaśnienia lub potwierdzenia kwestii niezbędnych do tworzenia dokumentacji zewnętrznego projektu, zorganizuje spotkanie dotyczące zewnętrznego projektu (zwane dalej w tym rozdziale “spotkaniem dotyczącym zewnętrznego projektu”) w częstotliwości uznanej za konieczną zgodnie z postanowieniami artykułu ○, a Strona A weźmie udział w tym spotkaniu.

2. Strona A, jeśli uzna to za konieczne do tworzenia dokumentacji zewnętrznego projektu, może zorganizować spotkanie dotyczące zewnętrznego projektu, a Strona B weźmie udział w tym spotkaniu.

3. Jeśli, w wyniku dyskusji podczas spotkania dotyczącego zewnętrznego projektu, Strona A zamierza zmienić treść dokumentacji wymagań i jeśli zmiana ta wymaga zmiany warunków indywidualnej umowy, takich jak okres realizacji i opłata za usługę, procedura ta będzie realizowana zgodnie z postanowieniami artykułu 33 (zmiana treści niniejszej umowy i indywidualnej umowy).

Tworzenie dokumentacji zewnętrznego projektu, która określa interfejsy, takie jak ekrany i formularze, wymaga współpracy między użytkownikiem a dostawcą. Ponieważ ta usługa jest realizowana na zasadzie zlecenia, pierwszy punkt określa, że dostawca jest organizatorem spotkania, a użytkownik bierze udział w tym spotkaniu. Wyjaśnienie lub potwierdzenie kwestii niezbędnych do tworzenia dokumentacji zewnętrznego projektu odbywa się podczas spotkania dotyczącego zewnętrznego projektu, a dostawca i użytkownik są związani wynikami dyskusji podczas tego spotkania.

Drugi punkt określa, że użytkownik może również zorganizować spotkanie dotyczące zewnętrznego projektu, jeśli uzna to za konieczne do realizacji usługi tworzenia dokumentacji zewnętrznego projektu.
Trzeci punkt określa, że jeśli, w wyniku dyskusji, użytkownik zamierza zmienić treść dokumentacji wymagań, a ta zmiana może wpłynąć na warunki indywidualnej umowy, takie jak okres realizacji i opłata za usługę, procedura ta będzie realizowana zgodnie z metodą zmiany treści niniejszej umowy i indywidualnej umowy określoną w innym artykule.

(Dostarczenie dokumentacji zewnętrznego projektu)
Artykuł ○ Strona B dostarczy Stronie A dokumentację zewnętrznego projektu i wniosek o przyjęcie dokumentacji zewnętrznego projektu (wraz z dokumentem dostawy) do daty określonej w indywidualnej umowie.

Ponieważ ta usługa jest realizowana na zasadzie zlecenia, dostawca dostarcza dokumentację zewnętrznego projektu jako wynik pracy.

(Zatwierdzenie i ustalenie dokumentacji zewnętrznego projektu)
Artykuł ○ Strona A, w okresie określonym w indywidualnej umowie (zwany dalej “okresem sprawdzania dokumentacji zewnętrznego projektu”), sprawdzi, czy dokumentacja zewnętrznego projektu jest zgodna z dokumentacją wymagań ustaloną zgodnie z postanowieniami artykułu ○ i decyzjami podjętymi podczas spotkania dotyczącego zewnętrznego projektu określonego w artykule ○, oraz czy nie zawiera błędów logicznych, a następnie zatwierdzi dokumentację zewnętrznego projektu poprzez podpisanie i pieczętowanie dokumentu zatwierdzającego dokumentację zewnętrznego projektu przez osoby odpowiedzialne z obu stron. Jeśli jednak, w wyniku sprawdzenia, okaże się, że dokumentacja zewnętrznego projektu nie jest zgodna z dokumentacją wymagań lub decyzjami podjętymi podczas spotkania dotyczącego zewnętrznego projektu, lub zawiera błędy logiczne, Strona B, po konsultacji, przygotuje poprawioną wersję i przedstawi ją Stronie A, a Strona A ponownie przeprowadzi powyższe sprawdzenie i procedurę zatwierdzania.

2. Jeśli Strona A nie zgłosi sprzeciwu na piśmie z konkretnym uzasadnieniem w okresie sprawdzania dokumentacji zewnętrznego projektu, uważa się, że Strona A zatwierdziła dokumentację zewnętrznego projektu po upływie okresu sprawdzania dokumentacji zewnętrznego projektu.

3. Dokumentacja zewnętrznego projektu jest uważana za ustaloną po zatwierdzeniu przez Stronę A zgodnie z powyższymi dwoma punktami.

Podczas procesu zewnętrznego projektowania ustalane są wymagania niezbędne do przeprowadzenia późniejszych prac nad tworzeniem dokumentacji wewnętrznego projektu, ale jeśli ustalenie wymagań pozostanie niejasne, może to prowadzić do problemów w późniejszym rozwoju. Ten artykuł określa procedurę, w której użytkownik sprawdza dokumentację zewnętrznego projektu, która stanowi podstawę dla późniejszych prac rozwojowych, i ustala ją poprzez zatwierdzenie przez użytkownika.

Pierwszy punkt określa, że użytkownik sprawdza zgodność dokumentacji zewnętrznego projektu z dokumentacją wymagań i wynikami dyskusji podczas spotkania dotyczącego zewnętrznego projektu oraz brak błędów logicznych. Może się zdarzyć, że podczas sprawdzania dokumentacji zewnętrznego projektu do zatwierdzenia stwierdzi się konieczność wprowadzenia poprawek, dlatego ten punkt określa procedurę w takim przypadku.
Drugi punkt jest postanowieniem, które uznaje, że jeśli użytkownik nie zgłosi sprzeciwu w określonym czasie, nawet jeśli nie podpisze i nie pieczętuje dokumentu zatwierdzającego, uważa się, że użytkownik zatwierdził dokumentację zewnętrznego projektu. Wprowadzenie takiego postanowienia ma na celu zapobieganie problemom, które mogą wystąpić później, jeśli niejasne jest, czy użytkownik zatwierdził dokumentację czy nie.

A następnie trzeci punkt określa, że dokumentacja zewnętrznego projektu jest uważana za ustaloną po zatwierdzeniu przez użytkownika.

(Odpowiedzialność za wady)
Artykuł ○ Jeśli po ustaleniu zgodnie z poprzednim artykułem zostanie odkryte, że dokumentacja zewnętrznego projektu nie jest zgodna z dokumentacją wymagań lub decyzjami podjętymi podczas spotkania dotyczącego zewnętrznego projektu, lub zawiera błędy logiczne (zwane dalej w tym artykule “wadami”), Strona A może zażądać od Strony B poprawienia tych wad, a Strona B zobowiązuje się do poprawienia tych wad. Jednakże, Strona B jest odpowiedzialna za poprawienie tych wad tylko wtedy, gdy Strona A zażąda tego w ciągu ○ miesięcy po ustaleniu zgodnie z poprzednim artykułem.

2. Pomimo postanowień poprzedniego punktu, jeśli wada jest drobna i poprawienie dokumentacji zewnętrznego projektu wymagałoby nadmiernych kosztów, Strona B nie jest zobowiązana do poprawienia wady określonej w poprzednim punkcie.

3. Postanowienia punktu 1 nie mają zastosowania, jeśli wada powstała na skutek materiałów dostarczonych przez Stronę A lub instrukcji udzielonych przez Stronę A. Jednakże, jeśli Strona B wiedziała, że te materiały lub instrukcje są niewłaściwe i nie poinformowała o tym, nie stosuje się tego ograniczenia.

Ten artykuł określa odpowiedzialność za wady w dokumentacji zewnętrznego projektu. Okres gwarancji na wady jest ustalany na podstawie rozważenia takich czynników jak skala systemu informacyjnego i wynagrodzenie, i jest ustalany jako okres uznany za odpowiedni w wyniku negocjacji między stronami.

Pierwszy punkt określa niezgodność dokumentacji zewnętrznego projektu z dokumentacją wymagań i wynikami dyskusji podczas spotkania dotyczącego zewnętrznego projektu oraz błędy logiczne jako wady.

Drugi punkt chroni dostawcę, stwierdzając, że jeśli wada jest drobna i poprawienie dokumentacji zewnętrznego projektu wymagałoby nadmiernych kosztów, dostawca nie jest zobowiązany do poprawienia wady, zgodnie z postanowieniami artykułu 634, punkt 1 Kodeksu cywilnego.

Trzeci punkt, zgodnie z postanowieniami artykułu 636 Kodeksu cywilnego, stwierdza, że jeśli wada powstała na skutek instrukcji lub materiałów dostarczonych przez użytkownika, dostawca nie jest odpowiedzialny za poprawienie wady, chyba że dostawca wiedział, że te instrukcje lub materiały są niewłaściwe i nie poinformował o tym.

Warto zauważyć, że odpowiedzialność za wady jest regulacją opcjonalną, co oznacza, że jeśli nie zostanie wprowadzona taka regulacja, kwestia ta będzie rozstrzygana zgodnie z ogólnymi zasadami Kodeksu cywilnego. Odpowiedzialność za wady jest jednym z obszarów, które są silnie wpływane przez nowelizację Kodeksu cywilnego, która wejdzie w życie w kwietniu 2020 roku, dlatego po wejściu w życie nowelizacji Kodeksu cywilnego, sposób traktowania tego obszaru będzie się różnił. Szczegó

Usługi w zakresie rozwoju oprogramowania

(Realizacja usług w zakresie rozwoju oprogramowania)
Artykuł 〇. Wykonawca, po zawarciu indywidualnej umowy określonej w artykule 25, przeprowadzi usługi w zakresie rozwoju oprogramowania, od projektowania wewnętrznego do testów systemowych, na podstawie specyfikacji systemu ustalonej w poprzednich sekcjach jako część niniejszych usług.

2. W trakcie realizacji usług w zakresie rozwoju oprogramowania, wykonawca może zażądać od zleceniodawcy niezbędnej współpracy, a zleceniodawca zobowiązuje się odpowiedzieć na takie żądanie w odpowiednim czasie.

W niniejszym artykule określamy klauzule dotyczące rozwoju oprogramowania realizowanego przez dostawcę na zasadzie umowy o dzieło. W procesie projektowania wewnętrznego systemu, zwykle określa się cel rozwoju i specyfikacje na podstawie prac wykonanych do tej pory, dlatego model umowy Ministerstwa Gospodarki, Handlu i Przemysłu określa to jako umowę o dzieło.

(Zawarcie indywidualnej umowy dotyczącej usług w zakresie rozwoju oprogramowania)
Artykuł 〇. Zleceniodawca i wykonawca ustalą warunki transakcji określone w artykule 〇, punkt 〇, po przeprowadzeniu negocjacji, a następnie zawrą indywidualną umowę dotyczącą usług w zakresie rozwoju oprogramowania.

Zakres usług w zakresie rozwoju oprogramowania jest ustalany w indywidualnej umowie zgodnie z warunkami transakcji określonymi wcześniej.

(Dostarczenie produktów)
Artykuł 〇. Wykonawca dostarczy zleceniodawcy produkty określone w indywidualnej umowie do określonego terminu, wraz z formularzem wniosku o akceptację (również jako dowód dostawy).
2. Zleceniodawca, w przypadku dostawy, przeprowadzi inspekcję zgodnie ze specyfikacją inspekcji określoną w następnym artykule, zgodnie z postanowieniami artykułu 〇 (akceptacja niniejszego oprogramowania).
3. Wykonawca, podczas dostarczania produktów, może zażądać od zleceniodawcy niezbędnej współpracy, a zleceniodawca zobowiązuje się odpowiedzieć na takie żądanie niezwłocznie.
4. Ryzyko utraty, uszkodzenia itp. produktów spoczywa na wykonawcy przed dostarczeniem, a na zleceniodawcy po dostarczeniu.

Ze względu na to, że niniejszy proces jest realizowany na zasadzie umowy o dzieło, oprogramowanie, które zostało ukończone, jest dostarczane jako produkt podlegający inspekcji. Pierwszy punkt określa, że produkty są dostarczane wraz z formularzem wniosku o akceptację (również jako dowód dostawy).

Drugi punkt określa przeprowadzenie inspekcji przez użytkownika.
Trzeci punkt określa obowiązek współpracy użytkownika w przypadku dostarczenia do określonego miejsca dostawy, które może wymagać współpracy użytkownika (np. dostarczenie do biura użytkownika, dostarczenie w stanie gotowym do uruchomienia w rzeczywistym środowisku operacyjnym użytkownika).
Czwarty punkt to klauzula dotycząca ryzyka utraty lub uszkodzenia produktów, która dzieli moment przeniesienia ryzyka na podstawie przeniesienia fizycznej kontroli.

(Akceptacja niniejszego oprogramowania)
Artykuł 〇. W przypadku niniejszego oprogramowania, które jest jednym z produktów dostarczonych, zleceniodawca przeprowadzi inspekcję na podstawie specyfikacji inspekcji określonej w poprzednim artykule w okresie określonym w indywidualnej umowie (zwany dalej “okresem inspekcji”) i sprawdzi, czy specyfikacja systemu i niniejsze oprogramowanie są zgodne.

2. Jeżeli niniejsze oprogramowanie spełnia wymogi inspekcji określone w poprzednim punkcie, zleceniodawca podpisze i pieczętuje certyfikat zgodności i dostarczy go wykonawcy. Ponadto, jeżeli niniejsze oprogramowanie nie spełnia wymogów inspekcji określonych w poprzednim punkcie, zleceniodawca dostarczy wykonawcy pisemne powiadomienie zawierające konkretne powody niezgodności, żądając poprawki lub uzupełnienia, a jeżeli powody niezgodności są uznane za uzasadnione, wykonawca dostarczy poprawione oprogramowanie bezpłatnie w określonym terminie po konsultacjach, a zleceniodawca przeprowadzi ponowną inspekcję w zakresie wymaganym przez poprzedni punkt.

3. Nawet jeżeli certyfikat zgodności nie został dostarczony, jeżeli zleceniodawca nie zgłosi sprzeciwu na piśmie z konkretnym powodem w okresie inspekcji, niniejsze oprogramowanie uważa się za zgodne z inspekcją określoną w niniejszym artykule.

4. Akceptacja niniejszego oprogramowania jest uważana za zakończoną po zakończeniu inspekcji określonej w niniejszym artykule.

Ze względu na to, że niniejszy proces jest realizowany na zasadzie umowy o dzieło, niniejszy artykuł określa procedurę akceptacji dostarczonego oprogramowania.

Pierwszy punkt określa, że zleceniodawca przeprowadzi inspekcję niniejszego oprogramowania na podstawie specyfikacji inspekcji w okresie inspekcji i sprawdzi, czy specyfikacja systemu i niniejsze oprogramowanie są zgodne.
Drugi punkt nakłada na wykonawcę obowiązek dostarczenia poprawionej wersji oprogramowania zleceniodawcy, jeżeli stwierdzi się, że niniejsze oprogramowanie nie jest zgodne ze specyfikacją systemu.
Trzeci punkt ma na celu zapobieganie opóźnieniom w akceptacji spowodowanym przez zleceniodawcę, poprzez ustanowienie przepisu o domniemanej akceptacji.
Czwarty punkt wyraźnie stwierdza, że akceptacja niniejszego oprogramowania jest uważana za zakończoną po zakończeniu inspekcji.

(Odpowiedzialność za wady)
Artykuł 〇. Po zakończeniu inspekcji określonej w poprzednim artykule, jeżeli zostanie odkryta niezgodność (w tym błędy) między produktami a specyfikacją systemu, zleceniodawca może zażądać od wykonawcy poprawy tej wady, a wykonawca jest zobowiązany do jej poprawy. Jednakże, wykonawca jest zobowiązany do poprawy tylko wtedy, gdy zleceniodawca zażąda tego w ciągu ○ miesięcy po zakończeniu akceptacji określonej w poprzednim artykule.
2. Pomimo poprzedniego punktu, jeżeli wada jest drobna i wymaga nadmiernych kosztów naprawy produktu, wykonawca nie jest zobowiązany do naprawy określonej w poprzednim punkcie.
3. Postanowienia punktu 1 nie mają zastosowania, jeżeli wada powstała na skutek materiałów dostarczonych przez zleceniodawcę lub instrukcji udzielonych przez zleceniodawcę. Jednakże, nie dotyczy to sytuacji, gdy wykonawca nie poinformował, mimo że wiedział, że materiały lub instrukcje były niewłaściwe.

Ze względu na to, że niniejszy proces jest realizowany na zasadzie umowy o dzieło, niniejszy artykuł określa odpowiedzialność za wady produktów. Granica między odpowiedzialnością za niewykonanie zobowiązania (praca nie jest ukończona) a odpowiedzialnością za wady (praca jest ukończona) jest trudna do ustalenia w praktyce. Istnieje precedens sądowy (wyrok Sądu Okręgowego w Tokio z dnia 22 kwietnia 2002 roku), który stwierdza, że czy system jest uważany za ukończony, czy nie, powinno być oceniane na podstawie tego, czy prace zostały zakończone do ostatniego etapu przewidzianego w pierwotnej umowie o dzieło. Jeżeli po dostarczeniu i akceptacji oprogramowania, które zostało ukończone do przewidzianego ostatniego etapu, zostanie odkryta wada, zasadą jest, że stosuje się odpowiedzialność za wady.

Pierwszy punkt definiuje “niezgodność ze specyfikacją systemu” jako wadę w usługach rozwoju oprogramowania. W przypadku niedociągnięć funkcjonalnych, które wystąpiły na etapie projektowania zewnętrznego, odpowiedzialność jest określana nie na podstawie niniejszego artykułu, ale na podstawie przepisów dotyczących odpowiedzialności za wady na etapie projektowania zewnętrznego. Okres gwarancji na wady powinien być ustalany przez strony na podstawie rozważenia skali systemu informacyjnego, wynagrodzenia itp.

Drugi punkt zawiera przepis podobny do art. 634 par. 1 Kodeksu cywilnego, który stanowi, że jeżeli wada jest drobna, a naprawa produktu wymaga nadmiernych kosztów, wykonawca nie jest zobowiązany do naprawy bezpłatnie.

Trzeci punkt, podobnie jak art. 636 Kodeksu cywilnego, stanowi, że jeżeli wada wynika z instrukcji lub materiałów dostarczonych przez zleceniodawcę, wykonawca nie jest odpowiedzialny, chyba że wykonawca nie wskazał, że materiały lub instrukcje były niewłaściwe, mimo że o tym wiedział.

Szczegółowe wyjaśnienia dotyczące tego, kiedy wada jest uznawana i jakie są konkretne konsekwencje jej uznania, można znaleźć w poniższym artykule.

https://monolith.law/corporate/defect-warranty-liability[ja]

Wsparcie w przygotowaniu i migracji oprogramowania

Na etapie przyjęcia i wdrożenia systemu, zazwyczaj to użytkownik działa aktywnie. W modelowym kontrakcie Ministerstwa Gospodarki Japonii (Japanese Ministry of Economy, Trade and Industry), użytkownik jest głównym podmiotem, a dostawca wspiera go, co jest określone jako forma pół-zlecenia.

Określanie charakteru umowy

Aby określić charakter umowy, należy spojrzeć na całość umowy i rozważyć, czy jej celem jest “dostarczenie gotowego produktu”, czy też “racjonalne wykonanie zadań” przez dostawcę. Ogólnym wyznacznikiem jest to, czy zawartość produktu do zrealizowania jest do pewnego stopnia konkretna i czy projekt jest prowadzony w tym kierunku. Szczegółowe wyjaśnienia dotyczące tego, na co konkretnie zwracać uwagę, znajdują się w poniższym artykule.