MONOLITH LAW OFFICE+81-3-6262-3248Zilele săptămânii 10:00-18:00 JST[English Only]

MONOLITH LAW MAGAZINE

IT

Ce este răspunderea pentru neconformitatea contractului în dezvoltarea de sisteme și software? Explicăm punctele de revizuire

IT

Ce este răspunderea pentru neconformitatea contractului în dezvoltarea de sisteme și software? Explicăm punctele de revizuire

Ce ar trebui să facem din punct de vedere juridic dacă există o eroare în sistemul comandat după livrare?

Metoda de operare este dificilă, viteza de procesare este lentă, funcția comandată nu este disponibilă… În fața acestor probleme ale sistemului, ca comandant, veți pune întrebarea “responsabilitatea pentru neconformitatea contractului” către furnizorul care a dezvoltat sistemul.

“Responsabilitatea pentru neconformitatea contractului” a fost nou introdusă în locul “responsabilității pentru garanția defectelor”, care a fost abolită prin revizuirea Codului Civil din 2017 (Anul 2017 al calendarului gregorian). Prin urmare, este necesar să acordăm atenție la modul în care această revizuire afectează dezvoltarea de sisteme și software.

Problemele care apar adesea după livrare. Pentru a evita aceste probleme, vom explica conținutul “responsabilității pentru neconformitatea contractului” și impactul revizuirii.

Modificările aduse Codului Civil privind răspunderea pentru neconformitatea contractului

Imagine cu un judecător

Legea care modifică anumite părți ale Codului Civil Japonez a fost promulgată pe 2 iunie 2017 (Heisei 29, 2017 în calendarul gregorian) și a intrat în vigoare la 1 aprilie 2020.

Partea Codului Civil care stabilește regulile de bază privind contractele și alte obligații este cunoscută sub numele de “Legea obligațiilor”.

Legea obligațiilor nu a fost revizuită semnificativ de la stabilirea sa în 1896 (Meiji 29, 1896 în calendarul gregorian), adică de aproape 120 de ani.

Prin urmare, această revizuire a fost realizată pentru a se adapta la societatea actuală.

Modificările specifice sunt diverse, dar printre acestea, introducerea conceptului de “răspundere pentru neconformitatea contractului” este unul dintre principalele puncte de revizuire.

Ca urmare, ceea ce era cunoscut sub numele de “răspundere pentru garanția viciilor” a fost înlocuit cu “răspundere pentru neconformitatea contractului”.

Ce înseamnă neconformitatea contractului

Oameni confuzi care primesc software neconform cu contractul

“Neconformitatea contractului” se referă la situația în care funcțiile, calitatea, performanța sau starea care ar trebui să fie prezente în conformitate cu acordul părților sau cu natura și scopul contractului nu sunt asigurate.

Acest termen de “neconformitate a contractului” a fost introdus în locul termenului tradițional de “defect” ca urmare a modificării Codului Civil.

În cazul dezvoltării de sisteme sau software, “neconformitatea contractului” se referă la situații în care sistemul finalizat nu corespunde specificațiilor stabilite anterior sau când sistemul sau software-ul nu are funcțiile sau performanța care ar trebui să fie prezente în mod normal, în funcție de natura acestora.

La evaluarea dacă există sau nu “neconformitate a contractului”, se acordă o importanță deosebită acordului părților, scopului și naturii contractului.

Prin urmare, este important să se păstreze în scris scopul dezvoltării sistemului sau software-ului și istoricul comenzilor, pentru a clarifica ce fel de cerințe sau imagini avea comandantul.

Cazuri în care defecțiunile software corespund cu “neconformitatea contractului”

Imaginea neconformității

Când software-ul prezintă probleme și repararea acestuia este întârziată

În primul rând, putem considera cazul în care software-ul prezintă defecțiuni semnificative, care nu pot fi remediate rapid, necesitând o revizuire care se întoarce până la etapa de proiectare.

De exemplu, există un caz judecat în care s-a recunoscut că problemele, cum ar fi faptul că procesul de căutare al sistemului de interogare a stocului introdus durează mai mult de 30 de minute, corespund cu “defectul” actual al “neconformității contractuale”, și că a fost necesar să se răspundă la întrebările clienților prin crearea unui registru de stoc scris de mână (Hotărârea Tribunalului Districtual Tokyo, 22 aprilie 2002 (Anul 14 al erei Heisei)).

Când defecțiunile apar succesiv

De asemenea, putem considera cazul în care, chiar dacă fiecare defecțiune este minoră și nu necesită mult timp pentru a fi remediată, defecțiunile apar de mai multe ori, iar remedierea tuturor defecțiunilor și funcționarea normală a acestora necesită mult timp.

De exemplu, dacă sistemul de interogare a stocului introdus prezintă defecțiuni repetate și nu este clar cât de multe defecțiuni vor apărea în viitor și cât timp va dura remedierea acestora, și dacă nu se poate efectua activitatea obișnuită folosind sistemul, putem spune că este “neconformitate contractuală”.

Cazuri în care defecțiunile software-ului nu corespund cu ‘neconformitatea contractului’

Persoane care consultă legea

Când defectele sunt remediate fără întârziere sau când sunt luate măsuri alternative

În jurisprudență, chiar dacă utilizatorii semnalează bug-uri sau alte defecțiuni, dacă acestea sunt remediate fără întârziere sau dacă se iau măsuri alternative considerate rezonabile în urma consultărilor cu utilizatorii, acestea nu sunt considerate ‘defecte’ (Hotărârea Tribunalului Districtual Tokyo, 18 februarie 1997 (Heisei 9)).

În dezvoltarea de sisteme și software, este imposibil să se programeze astfel încât să nu apară deloc bug-uri, iar apariția unor defecțiuni este inevitabilă.

Prin urmare, chiar dacă există defecțiuni, dacă se iau măsuri precum remedierea fără întârziere, acestea nu ar trebui considerate ‘defecte’.

Aceeași abordare poate fi considerată și în cadrul ‘neconformității contractuale’ actuale.

De notat că baza pentru a determina ‘fără întârziere’ și altele asemenea este evidența, cum ar fi procesele-verbale create în cursul dezvoltării sistemului.

Detalii despre importanța acestora sunt explicate în articolul de mai jos.

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

Când un anumit individ nu a putut înțelege ușor modul de operare

În ceea ce privește operabilitatea și ușurința de utilizare, acestea sunt în mare parte subiective, astfel încât se consideră că ‘neconformitatea contractului’ se aplică atunci când nu poate fi utilizat de către un utilizator mediu.

Doar faptul că un anumit individ nu a putut înțelege ușor modul de operare nu înseamnă că se încadrează în ‘neconformitatea contractului’.

Când defecțiunile apar din cauze care nu sunt legate de munca furnizorului

Dacă defecțiunile apar din cauze care nu au legătură cu activitățile de dezvoltare ale furnizorului care dezvoltă sistemul sau software-ul, nu se poate spune că acest sistem sau software are ‘neconformitate contractuală’.

De exemplu, dacă defecțiunile apar din cauza problemelor cu hardware-ul, pentru care furnizorul nu este responsabil pentru achiziție, nu se consideră că există ‘neconformitate contractuală’.

[Supliment] Când defecțiunile apar din cauza instrucțiunilor utilizatorului

Dacă defecțiunile apar în sistemul sau software-ul finalizat din cauza instrucțiunilor greșite ale utilizatorului, chiar dacă se recunoaște că există ‘neconformitate contractuală’ în sistem etc., în principiu, furnizorul nu își asumă responsabilitatea pentru neconformitatea contractuală.

De exemplu, dacă în timpul dezvoltării unui sistem de afaceri, utilizatorul a oferit o explicație greșită despre o situație pe care doar el o cunoaște, și din cauza acestei informații greșite, defecțiuni apar în software-ul dezvoltat pe baza specificațiilor convenite, furnizorul nu are nicio responsabilitate.

Se poate presupune că în spatele acestei decizii se află ideea că, în dezvoltarea software-ului, partea care comandă, adică utilizatorul, are și o ‘obligație de cooperare’. Pentru detalii, vă rugăm să consultați articolul de mai jos.

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

Aspecte pe care beneficiarul / cumpărătorul le poate solicita pe baza răspunderii pentru neconformitatea contractului

Persoane verificând documente

Aici vom explica conținutul răspunderii pentru neconformitatea contractului în ceea ce privește dezvoltarea de sisteme și software, luând în considerare și modificările aduse prin revizuire.

Solicitarea de remediere

În cazul în care un defect este evaluat ca fiind o neconformitate a contractului, beneficiarul poate solicita remedierea defectului.

Înainte de modificare, nu se putea solicita remedierea dacă defectul în cauză nu era semnificativ și dacă remedierea ar fi necesitat costuri excesive. Această limitare a fost eliminată prin modificare.

În orice caz, chiar și după modificare, dacă “neconformitatea contractului nu este semnificativă și remedierea necesită costuri excesive”, există posibilitatea ca remedierea să nu fie posibilă și, prin urmare, solicitarea de remediere să nu fie recunoscută.

Solicitarea de despăgubire

Dacă un sistem sau software defectuos face imposibilă desfășurarea normală a activității sau necesită cheltuieli suplimentare, beneficiarul poate solicita despăgubiri.

Înainte de modificare, se putea solicita despăgubire indiferent de existența neglijenței, cu excepția cazului în care exista o clauză specială.

Însă, prin modificare, dacă există o cauză de exonerare (o cauză care nu poate fi atribuită debitorului) pentru executant, nu se mai poate solicita despăgubire.

Prin urmare, dacă furnizorul poate dovedi existența unei cauze de exonerare, nu va fi responsabil pentru despăgubire.

Rezilierea contractului

Contractul de dezvoltare poate fi reziliat pe baza neconformității contractului pentru sistem sau software.

Într-un caz de judecată pe care l-am prezentat deja, s-a constatat că există un defect care face ca procesarea căutării în sistemul de interogare a stocurilor să dureze mai mult de 30 de minute, ceea ce face ca timpul de procesare să fie prea lung și cauzează și alte probleme, cum ar fi imposibilitatea utilizării terminalului în sine. Din acest motiv, a fost necesar să se renunțe la utilizarea continuă a sistemului introdus și s-a recunoscut rezilierea contractului (Hotărârea Tribunalului Districtual Tokyo, 22 aprilie 2002 (anul 14 al erei Heisei, 2002 în calendarul gregorian)).

Înainte de modificare, contractul putea fi reziliat numai dacă “obiectivul contractului nu putea fi atins” din cauza defectului. Cu toate acestea, această limitare a fost eliminată prin modificare.

În orice caz, chiar și sub legea modificată, este important de reținut că dacă gradul de neconformitate a contractului este “minor”, rezilierea nu va fi recunoscută.

Solicitarea de reducere a remunerației

Dreptul de a solicita o reducere a remunerației a fost introdus prin modificare.

În cazul în care există un defect în sistem și beneficiarul a solicitat remedierea acestuia, dar remedierea nu a fost efectuată chiar și după o perioadă rezonabilă de timp, beneficiarul poate solicita o reducere a remunerației.

Perioada de responsabilitate

  • Solicitarea de remediere
  • Solicitarea de despăgubire
  • Rezilierea contractului
  • Solicitarea de reducere a remunerației

Există o perioadă limitată în care aceste drepturi pot fi exercitate.

Concret, drepturile pot fi exercitate numai dacă beneficiarul a notificat furnizorul “în termen de un an de la data la care a aflat” despre existența unei neconformități a contractului în sistem sau software.

Înainte de modificare, perioada în care drepturile puteau fi exercitate era limitată la “un an de la data livrării” a sistemului sau software-ului. Prin urmare, se poate spune că perioada în care drepturile pot fi exercitate s-a prelungit prin modificare.

În plus, aceste limite de timp sunt separate de faptul că drepturile recunoscute pe baza răspunderii pentru neconformitatea contractului sunt, de asemenea, supuse prevederilor privind prescripția extinctivă.

Prin urmare, de exemplu, dacă aflați pentru prima dată despre existența unui defect la 11 ani după ce ați primit livrarea sistemului sau software-ului, drepturile, cum ar fi dreptul de a solicita despăgubiri, vor fi “prescrise” după o perioadă de prescripție extinctivă de “zece ani”, indiferent dacă ați notificat furnizorul despre neconformitatea contractului “în termen de un an de la data la care ați aflat”.

Refuzul de a plăti remunerația

Beneficiarul poate refuza să plătească întreaga remunerație până când dezvoltatorul efectuează remedierea sau despăgubirea.

Puncte de luat în considerare pentru clauzele contractuale în caz de neconformitate contractuală

Persoane care încheie un contract și se strâng de mână

Reglementarea răspunderii pentru neconformitatea contractuală este o clauză opțională, iar prin acord special între părți, conținutul răspunderii poate fi limitat sau perioada de exercitare a drepturilor poate fi redusă.

Prin urmare, aici vom explica clauzele contractuale care trebuie luate în considerare în relație cu răspunderea pentru neconformitatea contractuală în dezvoltarea de sisteme și software.

Punctul 1: Evenimentele și domeniul care constituie neconformitate contractuală

În cazul în care există nemulțumiri cu privire la sistem sau software, clientul va dori probabil să urmărească răspunderea furnizorului pentru neconformitatea contractuală.

Însă, din perspectiva furnizorului, nu este acceptabil să fie urmărit pentru răspunderea pentru neconformitatea contractuală doar pentru că clientul nu este mulțumit de o simplă specificație.

În plus, furnizorul poate crește semnificativ estimarea pentru a se pregăti pentru urmărirea nejustificată a răspunderii pentru neconformitatea contractuală, ceea ce poate fi dezavantajos pentru client.

Prin urmare, este important să se reflecte în mod clar în documente sau în specificații scopul și funcțiile pe care clientul dorește să le aibă sistemul pe care intenționează să-l introducă, pentru a clarifica evenimentele și domeniul care constituie neconformitatea contractuală.

De asemenea, se poate lua în considerare clarificarea faptului că, chiar dacă există o anumită neconformitate în specificații, nu constituie o neconformitate contractuală dacă sistemul sau software-ul livrat este conform cu ceea ce este stipulat în specificații.

Această clauză poate preveni urmărirea răspunderii pentru neconformitatea contractuală din cauza preferințelor clientului, chiar dacă dezvoltarea a fost realizată conform specificațiilor.

Punctul 2: Clarificarea perioadei de garanție

Perioada de exercitare a drepturilor pentru răspunderea pentru neconformitatea contractuală nu începe “la momentul livrării” produsului, ci “de la momentul la care se cunoaște” neconformitatea contractuală.

În plus, chiar dacă se aplică un termen de prescripție separat, această perioadă este de “zece ani” la maximum, ceea ce este o perioadă lungă de timp.

Pentru furnizor, este o sarcină mare să ofere o garanție gratuită pentru o perioadă lungă de “zece ani” în unele cazuri, și trebuie să adauge acest cost la etapa de estimare.

Pe de altă parte, pentru client, poate fi mai profitabil din punct de vedere al costurilor să stabilească o perioadă de garanție flexibilă în funcție de durata de utilizare a sistemului sau software-ului.

Prin urmare, se poate lua în considerare stabilirea unei perioade de garanție flexibile în funcție de conținutul sistemului.

Punctul 3: Răspunsul în cazul în care apare o neconformitate contractuală

În cazul în care apare o neconformitate contractuală, se poate limita la o parte din drepturile recunoscute de legea civilă, cum ar fi cererea de despăgubire sau rezilierea, prin acordul între părți.

Ca client, este necesar să înțelegeți corect ce fel de limitări sunt stabilite în contract.

Concluzie: Consultați un avocat pentru redactarea contractelor care includ “Răspunderea pentru neconformitatea contractului”

Imagine

Modificările aduse Codului Civil au avut un impact semnificativ asupra aspectelor legale ale dezvoltării de sisteme și software.

În cazul în care sistemul livrat prezintă defecțiuni, nu se poate spune cu certitudine dacă aceasta constituie o “neconformitate a contractului” și ce responsabilități pot fi atribuite.

De asemenea, pentru a preveni disputele înainte de a apărea, este esențial să se desfășoare discuții ample între client și furnizor în etapa de contractare a dezvoltării.

Dacă aveți nelămuriri cu privire la redactarea contractelor, vă rugăm să consultați un avocat specializat.

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.

Category: IT

Tag:

?napoi la ?nceput