Similaritățile dintre verificarea contractelor și debug-ul explicat de un avocat fost inginer IT

În centrul activității așa-numitului “avocat consilier al companiei” se află verificarea și modificarea contractelor pe care compania le încheie zilnic cu clienții și partenerii de afaceri. Și aceste verificări și modificări pot fi efectuate în mod corespunzător doar de către persoane care sunt familiarizate cu ambele, legea și domeniul de activitate respectiv. Voi explica de ce este acest lucru necesar.

Totuși, explicarea de mai jos poate fi dificil de înțeles pentru cei care nu sunt ingineri sau nu au experiență în programare. Biroul nostru de avocatură, Monolis, este condus de un avocat care a fost anterior inginer IT și are experiență în managementul unei companii. Este poziționat ca un “articol care explică verificarea și modificarea contractelor, adresat managerilor cu experiență în inginerie și programare, de la un birou de avocatură condus de un fost inginer IT și manager de companie”.

Și pe baza acestei poziționări, verificarea și modificarea contractelor sunt operațiuni similare cu așa-numitul “debugging”.

1. Ce este de fapt un “bug”
2. Ce implică operațiunea de “debugging”
3. Cum definește un contract un algoritm
4. Ce implică modificarea unui contract

Începem cu discuții care sunt “evidente” pentru ingineri, dar le voi explica mai jos.

Ce sunt „bug” și „debug”?

Un bug nu înseamnă “defecțiunea PC-ului”

Când auzim termenul de “bug”, unii dintre noi s-ar putea gândi la situații în care, în timp ce lucrăm pe PC, acesta începe să scoată fum și ecranul afișează imagini ciudate. Cu toate acestea, în principiu, un PC nu face decât să “execute ceea ce i se spune”. Acest lucru este valabil și în cazul în care apar bug-uri. Prin urmare, un “bug” este:

• Un fenomen care se produce chiar dacă PC-ul funcționează așa cum i s-a spus
• Pentru utilizator, acest comportament este “neconform cu așteptările”

Acesta este fenomenul.

De ce apar “comportamente neașteptate”

Să luăm ca exemplu bug-ul “trecerii prin ziduri” în jocurile de acțiune de tipul Mario.

Săritura lui Mario este o funcție de gradul doi. Accelerație, viteză, coordonate. Cu toate acestea, în cazul unei funcții de gradul doi, de exemplu, putem diviza X în mod infinit de fin, cum ar fi “Care este Y când X=1.76582?”, dar în cazul jocurilor video, nu putem diviza timpul în mod infinit de fin. Acest lucru se datorează faptului că ecranul se schimbă doar de 30 de ori pe secundă, de exemplu. Prin urmare, într-un fel, Mario “se teleportează” de 30 de ori pe secundă.

În acest context, să ne gândim la situația în care “Mario sare și se lovește de un zid în aer și ricoșează”. Aceasta este situația în care:

1. Mario era în aer în momentul anterior
2. În momentul următor, coordonatele lui Mario sunt în zid

Acesta este cazul.

În astfel de cazuri, putem concluziona că “Mario s-a lovit de un zid în timp ce sărea”. Prin urmare, dacă scriem un program care spune:

Dacă coordonatele lui Mario sunt în zid, atunci se va efectua o procedură de ricoșare (※1)

Putem realiza procedura “Mario sare și se lovește de un zid în aer și ricoșează”.

※1 pare corect dacă este scris așa cum este deasupra. Și, de fapt, această procedură este corectă “sub anumite condiții”.

Însă, dacă ne gândim mai bine, există și situații ca cea de mai jos (※2).

În acest caz, nu există un moment în care “coordonatele lui Mario sunt în zid”, deci nu se va efectua nicio procedură de ricoșare, iar Mario va trece prin zid.

Acesta este un exemplu de “bug”. Chiar dacă un “bug de trecere prin ziduri” apare din aceste motive, nu înseamnă că PC-ul este defect. PC-ul doar efectuează comportamentul așa cum i s-a spus, iar evaluarea acestui comportament ca fiind “neconform cu așteptările” sau “un bug” este făcută de oameni. Și acest “bug” apare pentru că algoritmul nu este adecvat.

Considerarea “dacă apar acțiuni neașteptate”

Cu toate acestea, dacă în procesul de joc va apărea sau nu “trecerea prin ziduri”, așa cum este menționat mai sus, nu este clar doar gândind abstract. Dacă “trecerea prin ziduri” poate avea loc sau nu, depinde de:

• Puterea de săritură a lui Mario (viteza inițială) și dacă există sau nu obiecte care măresc puterea de săritură
• Cât de gros este zidul în cel mai subțire punct

Aceasta depinde de aceste condiții. În funcție de aceste condiții, depinde dacă situația precum ※2 este posibilă sau nu. Dacă ※2 nu este posibil, atunci programul ※1 nu are nicio problemă.

Ce înseamnă „debugging” sau depanare?

Prin urmare, pentru a efectua „debugging”, adică pentru a identifica și a corecta erorile, este necesar să:

1. Înțelegeți algoritmul programului (deși exemplul de mai sus este în limbaj natural, în realitate, programele sunt scrise într-un limbaj propriu, ceea ce face dificilă înțelegerea acestora)
2. Analizați condițiile în care funcționează programul (de exemplu, să investigați puterea de săritură sau grosimea zidurilor)
3. Verificați dacă nu apar comportamente neașteptate

Acesta este procesul necesar.

Ce presupune verificarea unui contract?

Verificarea unui contract este similară cu acest proces. În esență, un contract este un instrument care reglementează drepturile și obligațiile părților, denumite în mod tradițional “partea A” și “partea B”, în funcție de evenimentele care ar putea avea loc în viitor. În acest sens, se poate spune că un contract este un “program care reglementează lumea reală”. De exemplu,

În cazul în care se produce situația ●●, partea A va plăti partii B o despăgubire de 1 milion de yeni.

Un contract care stabilește astfel de reguli definește condițiile și efectele pentru evenimentele care ar putea avea loc în viitor.

Și verificarea acestui “program care reglementează lumea reală” pentru a vedea dacă există probleme și, dacă există, corectarea acestora, este un proces care se aseamănă foarte mult cu “debugging-ul”.

Contractul nu include întregul algoritm

Există un punct extrem de important în ceea ce privește “contractele”, care poate fi dificil de înțeles pentru cei care nu sunt specializați în drept. Acest punct este că un contract reglementează doar o “parte” a algoritmului care guvernează relațiile dintre părțile implicate. Cu alte cuvinte, doar citind contractul, nu puteți înțelege întregul algoritm care guvernează relația dintre dumneavoastră și cealaltă parte.

De exemplu, când cumpărați un CD second-hand de la un magazin, nu încheiați un “contract de vânzare-cumpărare” cu magazinul, dar dacă CD-ul are zgârieturi care îl fac imposibil de redat pe un player, ați dori să vă plângeți magazinului și v-ați aștepta ca acesta să răspundă. Acest lucru nu este doar o chestiune de “serviciu”, ci teoretic:

1. Chiar dacă nu există un contract scris, un contract de vânzare-cumpărare este încheiat
2. Codul civil japonez (Legea civilă japoneză) prevede că vânzătorul are o responsabilitate de garanție pentru defecte în cazul vânzării de bunuri specifice, cum ar fi CD-urile second-hand
3. Prin urmare, algoritmul definit de Codul civil japonez (Legea civilă japoneză) funcționează între magazin și client, iar magazinul are o responsabilitate de garanție pentru defecte

Acesta este raționamentul. Și un “contract” este ceva care suprascrie algoritmul definit de legi precum Codul civil japonez (Legea civilă japoneză). De exemplu, dacă există un contract între magazin și client care stipulează că “magazinul nu va accepta reclamații ulterioare pentru orice defect al CD-ului”, atunci:

1. Un contract de vânzare-cumpărare este încheiat
2. Codul civil japonez (Legea civilă japoneză) prevede că vânzătorul are o responsabilitate de garanție pentru defecte în cazul acestui contract
3. Însă, conform prevederilor contractului, principiul 2 este suprascris și magazinul nu are o responsabilitate de garanție pentru defecte

Acesta este rezultatul.

Contractele suprascriu principiile, cum ar fi Codul Civil

Aceasta este valabil și în cazul contractelor încheiate între companii, cum ar fi dezvoltarea de sisteme. De exemplu, dacă un contract de dezvoltare a sistemului este încheiat între părțile A și B,

1. Prin încheierea acestui contract, este clar că un contract de subcontractare a fost încheiat
2. În cazul unui contract de subcontractare, responsabilitatea pentru garanția defectelor apare în conformitate cu prevederile Codului Civil
3. Dacă există o prevedere privind responsabilitatea pentru garanția defectelor în contract, acea prevedere suprascrie principiul Codului Civil nr. 2. De exemplu, dacă se stabilește o clauză de garanție a defectelor pentru o perioadă mai lungă decât principiul Codului Civil, prevederea pentru acea perioadă este valabilă

Deci, chiar dacă nu există o prevedere specială privind responsabilitatea pentru garanția defectelor în contract, responsabilitatea pentru garanția defectelor va apărea.

Aceasta nu este o discuție limitată la subcontractare sau dezvoltarea de sisteme, ci este o teorie generală privind toate contractele pe care o companie le încheie, cum ar fi transferul de acțiuni, strângerea de fonduri prin datorii (împrumuturi de consum), angajarea, emiterea de acțiuni, etc.

Prin urmare, nu puteți înțelege întregul “algoritm” care reglementează relația dintre partener și compania dvs. doar citind contractul. Pentru a înțelege întregul tablou, trebuie să înțelegeți “algoritmul implicit” stabilit de legi, cum ar fi Codul Civil. Contractul este doar ceva care suprascrie acest “algoritmul implicit”.

Nu putem “debuga” dacă nu putem anticipa evenimentele care ar putea avea loc în viitor

De asemenea, doar înțelegerea unui algoritm nu ne permite să verificăm dacă “nu va avea loc nicio acțiune neașteptată cu acest algoritm”. La fel ca în cazul “bug-urilor” din jocuri, algoritmul este în esență un lucru abstract, și dacă nu putem anticipa ce fel de evenimente vor avea loc în viitor, nu putem verifica dacă “nu va avea loc nicio acțiune neașteptată atunci când aceste evenimente au loc”.

Aceasta este o problemă majoră, în special în cazul produselor noi, cum ar fi aplicațiile și serviciile, sau schemele de afaceri noi. Ce se poate întâmpla în viitor dacă dezvoltăm o afacere cu aceste produse sau scheme? Acest lucru este greu de anticipat dacă nu avem cunoștințe în domeniul respectiv. În plus, în special în cazul contractelor între companii, atât compania parteneră cât și compania noastră acționează sub o anumită raționalitate economică, deci este necesară o abordare teoretică a jocurilor în managementul companiilor pentru a prezice evenimentele viitoare și acțiunile partenerului care le vor provoca.

Decizia dacă este “neconform cu așteptările” se bazează și pe judecata de management

În plus, la fel cum o persoană, nu un PC, decide dacă un eveniment este un “bug”, decizia dacă o anumită consecință a unui contract este “neconformă cu așteptările” nu este doar o problemă de drept pur, ci și o problemă de judecată de management.

De exemplu, există cazuri reale în care algoritmul “conform principiilor Codului Civil Japonez” este inacceptabil pentru o anumită afacere a unei companii. Deși acesta este un exemplu diferit de cele de până acum, Codul Civil Japonez prevede un algoritm implicit care spune că “subcontractarea de către un contractor este o încălcare a contractului”. Cu toate acestea, există cazuri în care “pentru o anumită companie, se presupune că o anumită afacere va folosi în mod natural subcontractanți”. În astfel de cazuri, un contract care nu permite subcontractarea, adică

• nu se menționează nimic despre posibilitatea subcontractării (în acest caz, principiul Codului Civil Japonez se aplică, așa cum s-a menționat mai sus)
• este menționat explicit că subcontractarea este imposibilă

nu ar trebui să fie acceptat, chiar dacă este “conform principiilor Codului Civil Japonez”.

În plus, în management există întotdeauna riscul de a fi ținut responsabil dacă se produce un anumit eveniment. Nu există practic contracte care nu prezintă “riscuri” pentru propria companie. Decizia de a accepta sau nu acest risc este în cele din urmă o judecată de management. Judecata de management este făcută de manageri, nu de avocați consultanți sau alte persoane cu un rol consultativ, dar consultanții ar trebui să furnizeze informațiile necesare și suficiente pentru ca managerii să poată face o judecată de management, cum ar fi

• riscuri care nu necesită a fi menționate de fiecare dată
• riscuri care necesită o decizie majoră pentru companie și care pot necesita o întâlnire sau alte măsuri

și trebuie să le sublinieze în mod corespunzător. Pentru a seta aceste “nuanțe”, avocații care verifică contractele au nevoie, la fel ca în cazul consultanților din alte domenii, de un anumit grad de înțelegere a managementului.

Rezumat

Așa cum am văzut, verificarea și modificarea contractelor implică în mare parte următoarele activități:

1. Înțelegerea modului în care principiile ‘Codului Civil Japonez’ și altele sunt suprascrise de contract și rezultatul acestui proces sub forma unui algoritm
2. Analizarea evenimentelor care ar putea avea loc în viitor sub acest algoritm
3. Verificarea dacă nu apar comportamente neașteptate în acest context

Și fiecare dintre acestea este:

1. O sarcină dificilă pentru cei care nu înțeleg legea
2. O sarcină dificilă pentru cei care nu înțeleg conținutul afacerii reglementate de contract, cum ar fi aplicațiile sau serviciile web, schemele de afaceri etc.
3. O sarcină dificilă pentru cei care nu au o înțelegere adecvată a companiei sau a conținutului afacerii, sau a simțului afacerii

Acesta este motivul.

Verificarea și modificarea contractelor sunt, din aceste motive, foarte “specializate”.

Informații despre crearea și revizuirea contractelor de către biroul nostru juridic

La Biroul Juridic Monolis, ca firmă de avocatură specializată în IT, internet și afaceri, oferim servicii precum crearea și revizuirea diverselor contracte pentru clienții noștri corporativi și companiile-client.

Pentru cei interesați, vă rugăm să consultați detaliile de mai jos.

https://monolith.law/contractcreation[ja]