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

MONOLITH LAW MAGAZINE

IT

Contractul pe care un inginer individual ar trebui să-l pregătească în avans pentru o afacere comună cu o companie

IT

Contractul pe care un inginer individual ar trebui să-l pregătească în avans pentru o afacere comună cu o companie

Biroul nostru, în care un fost inginer IT este avocatul principal, este un birou de avocatură care primește consultări legale nu numai din partea companiilor, dar și din partea inginerilor. Un tip de consultare este: “Ca individ, am fost implicat într-o nouă afacere împreună cu o anumită companie, dar nu pot primi o distribuție adecvată de la companie”. De exemplu, situațiile sunt următoarele:

  1. Ca inginer individual, am fost implicat de la început în dezvoltarea internă a unui nou sistem de către o companie care nu este neapărat puternică în IT
  2. Sistemul respectiv are o performanță bună și vânzările sunt în creștere
  3. Am cerut distribuția acțiunilor și distribuția profiturilor pe baza vânzărilor, dar compania nu a răspuns la aceasta

Vă vom explica ce ar trebui să gândească un inginer individual în astfel de situații, de ce apar astfel de situații și cum le putem preveni.

Conflictele legate de afacerile comune pot fi prevenite dacă există un contract

În primul rând, dacă ar trebui să tragem o concluzie, prevenirea acestor situații este, de fapt, simplă. Răspunsul este simplu

Pentru a fi pregătiți pentru astfel de situații, ar trebui să încheiem în prealabil un “contract de afacere comună” care include următoarele elemente.

Acesta este rezultatul. În contractul de afacere comună, de exemplu, se poate considera includerea următoarelor clauze:

  • Drepturile de autor asupra sistemului respectiv sunt împărțite între tine și companie
  • Un procent de ●% din vânzări sunt distribuite către tine
  • Clauze privind transferul de acțiuni

Acestea trebuie să fie proiectate cu un echilibru optim și să fie încheiate în prealabil.

Însă, în practică, încheierea acestor contracte este adesea amânată, motiv pentru care problemele menționate mai sus sunt mai susceptibile să apară.

  • Când problemele apar, care este situația cu privire la drepturi?
  • Cum ar trebui să proiectăm un contract de afacere comună în prealabil?
  • De ce sunt problemele susceptibile să apară dacă contractul nu a fost încheiat?

Voi explica aceste puncte pe rând în continuare.

Atribuirea codului sursă al programului în afaceri comune

Drepturile de autor ale codului sursă al programului nu sunt întotdeauna atribuite unui inginer individual.

La momentul când problemele de mai sus devin evidente, dreptul maxim pe care un inginer individual îl poate revendica față de companie este dreptul de autor. Codul sursă al programului este un “lucru creat” care este subiectul drepturilor de autor. Și atribuirea drepturilor de autor ale codului sursă urmează regulile:

  1. În principiu, este atribuit celui care a scris codul
  2. Dacă cel care a scris codul este angajat de o companie, etc., sub anumite condiții, devine “creație în cursul muncii” și este atribuit companiei
  3. Dacă există o dispoziție privind atribuirea drepturilor de autor în contract, se va conforma acelei dispoziții

Prin urmare,

  1. În principiu, este atribuit inginerului individual care a scris codul
  2. Inginerul individual nu este un angajat al companiei, deci nu se stabilește o “creație în cursul muncii”
  3. Se va conforma dispoziției de atribuire în contract, dar nu există un “contract”

Se pare că drepturile de autor vor fi atribuite inginerului individual, dar dacă acest conflict ajunge în instanță, instanța nu va face neapărat o astfel de decizie.

De asemenea, dacă vă întrebați dacă un contract privind dezvoltarea de sisteme poate fi încheiat fără un contract, am explicat în detaliu în articolul de mai jos.

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

În absența unui contract, deciziile devin neclare

Deși nu este un proiect de dezvoltare a sistemului, într-un caz în care s-a disputat dreptul de autor asupra designului unui monument instalat într-o stație între designerul individual care a realizat designul și compania care a plasat comanda, Curtea de Apel din Tokyo a recunoscut transferul drepturilor de autor de la designerul individual către companie pe 31 mai 2004 (Heisei 16), pe baza următoarelor:

  • Nu exista un contract
  • Monumentul a fost planificat să fie instalat în stație sub conducerea companiei de la început, și nu s-a anticipat niciun alt scop
  • Compania a plătit o remunerație designerului individual

Prin urmare, în absența unui contract sau a altor documente scrise, dacă a avut loc sau nu transferul drepturilor de autor către partea care a comandat este determinat pe baza diverselor circumstanțe, căutând intenția rațională a comandantului și a comandatului. Cu alte cuvinte, devine o decizie foarte “neclară”, adică nu există o regulă clară. De exemplu, “Cum este plătită remunerația pentru scrierea codului sursă” este, în general, tratată în felul următor în această decizie “neclară”.

  • Dacă plata se face sub formă de taxă lunară → Este considerată o remunerație pentru un serviciu total, inclusiv întreținerea, și în special dacă partea comandată este o persoană fizică, este ușor de evaluat ca un salariu similar, înclinându-se spre afirmarea transferului drepturilor de autor către partea comandantă
  • Dacă se obține o estimare de fiecare dată când se face un upgrade de versiune → Este ușor de evaluat ca o remunerație pentru crearea acelei versiuni, înclinându-se spre negarea transferului drepturilor de autor către partea comandantă

În cazul în care un inginer individual primește o comandă de la o companie sub forma unei “afaceri comune”, remunerația este adesea plătită sub formă de taxă lunară, ceea ce înseamnă că este mai ușor să se afirme transferul drepturilor de autor către companie. În plus, cel puțin din partea inginerului individual, în absența unui document scris, este dificil să se spună că “drepturile de autor sunt clar ale mele”.

Detalii despre atribuirea drepturilor de autor asupra codului sursă sunt explicate în detaliu în articolul de mai jos.

https://monolith.law/corporate/copyright-for-the-program-source-code[ja]

Ce ar trebui să stipuleze un contract privind o afacere comună

Motivul fundamental pentru care se ajunge în astfel de situații este faptul că nu s-a întocmit un contract în prealabil. Chiar dacă vi se spune acest lucru, s-ar putea să vă gândiți instinctiv că “nu este realist să se întocmească un contract în avans”, dar vom discuta acest aspect mai târziu. Mai întâi, vom explica ce ar trebui să conțină un contract adecvat.

Dispoziții privind drepturile de autor

În contract, așa cum este evident din discuția de mai sus, ar trebui să se stabilească dispoziții privind drepturile de autor. Din perspectiva unui inginer individual, cel mai mare risc al lucrului cu o companie într-o afacere comună, cum ar fi dezvoltarea de sisteme, este acela de a fi “tăiat” după ce proiectul devine profitabil.

Adică, chiar dacă, așa cum vom discuta mai târziu, încheiați un contract care prevede că “20% din venituri vor fi plătite inginerului individual”, dacă contractul în sine este încheiat, în final nu veți putea obține profit. Pentru a nu încheia contractul, este important să dețineți “drepturile” de partea dvs., iar cel mai important dintre aceste “drepturi” este dreptul de autor. În ceea ce privește drepturile de autor,

  • Drepturile de autor aparțin inginerului individual
  • Drepturile de autor sunt împărțite între companie și inginerul individual
  • Drepturile de autor aparțin companiei, dar aceasta nu poate exercita sau transfera aceste drepturi fără permisiunea inginerului individual

Dacă se stabilesc astfel de dispoziții, din perspectiva companiei, dacă “taie” inginerul individual, nu va mai putea continua afacerea, astfel încât să se poată preveni a fi “tăiat” în acest fel.

De asemenea, pentru o imagine de ansamblu a sistemului IT și a drepturilor de autor, vă rugăm să consultați articolul de mai jos pentru o explicație detaliată.

https://monolith.law/corporate/internet-technology-system-copyright-problem[ja]

Dispoziții privind contravaloarea

De asemenea, este evident că sunt necesare dispoziții privind contravaloarea. Acest lucru nu se aplică doar în astfel de cazuri, dar când se desfășoară o afacere în comun, partea care nu realizează vânzări este mai avantajată să primească o distribuție bazată pe vânzări, nu pe profit. Adică, de exemplu

  • Compania va plăti inginerului individual un procent din profitul afacerii legate de sistemul respectiv
  • Compania va plăti inginerului individual un procent din vânzările afacerii legate de sistemul respectiv

Ar trebui să se opteze cât mai mult posibil pentru a doua variantă. Inginerul individual nu poate înțelege cu exactitate nici vânzările realizate de companie, nici sumele cheltuielilor, nici dacă aceste cheltuieli sunt cu adevărat “pentru afacere”. Atât obținerea veniturilor, cât și plata cheltuielilor, precum și gestionarea și supravegherea personalului obținut prin aceste cheltuieli, sunt în cele din urmă responsabilitatea companiei. Și în acest context, vânzările sunt probabil cel mai ușor de înțeles. Este avantajos să se stabilească o formă de plată care poate fi calculată simplu doar din ceea ce este ușor de înțeles.

Dispoziții privind transferul de acțiuni

În plus, există și opțiunea de a solicita transferul de acțiuni. Cu toate acestea, nu vom detalia acest aspect în acest articol, dar este dificil în practică pentru un “inginer individual sub contract extern care se ocupă de o afacere comună” să solicite o cantitate mare de acțiuni, cum ar fi zeci de procente. Dacă un străin într-o astfel de poziție deține o cantitate semnificativă de acțiuni, investițiile de la VC sau IPO devin foarte dificile în practică. Ar trebui să se negocieze într-un cadru realist, cum ar fi 5%.

De ce nu sunt create contractele în avans?

În contractele privind afacerile comune, este important să clarificăm relația contractuală între inginerul individual și companie.

Așa cum am menționat, faptul că nu există un contract care include și plățile viitoare pentru un “proiect comun” între un inginer individual și o companie este o situație foarte “defavorabilă” pentru inginerul individual. Este important să creați un contract în avans, dar mulți oameni par să simtă că este dificil să creeze și să încheie un contract în avans.

Acest lucru se datorează, aș putea spune dur, diferenței de conștientizare a “afacerii” între companie și individ. În primul rând, aceste dispute legate de proiectele comune apar de obicei în următoarea ordine cronologică:

  1. Compania și inginerul individual își încredințează dezvoltarea sistemului pentru a lansa o nouă afacere. În acest moment, se ajunge la un acord pentru a plăti o remunerație, cum ar fi “300.000 de yeni pe lună”, pentru viața inginerului individual
  2. Afacerea respectivă devine profitabilă și remunerația menționată mai sus este ușor crescută
  3. Afacerea continuă să crească, generând venituri de zeci de milioane sau chiar miliarde de yeni pentru companie
  4. La acest punct, suma pe care o primește inginerul individual, cum ar fi “500.000 de yeni pe lună”, devine nesemnificativă în comparație cu profitul pe care îl obține compania și, de asemenea, devine ieftină în comparație cu suma pe care o altă companie ar fi primit-o pentru a prelua sistemul
  5. Relația dintre inginerul individual și companie se deteriorează

Din perspectiva inginerului individual, este adevărat că, dacă nu primesc o taxă lunară la etapa 1, vor avea probleme în viața lor de zi cu zi. Și la etapa 4, este adevărat că suma de “500.000 de yeni pe lună” în exemplul de mai sus este nesemnificativă în comparație cu:

  1. Profitul pe care îl obține compania
  2. Suma pe care o altă companie ar fi primit-o dacă ar fi creat sistemul

Însă, a face această comparație simplă este economic incorect. Deoarece:

  1. La etapa 1, compania face o investiție inițială, plătind remunerația inginerului individual și salariul vânzătorului, pentru o afacere a cărei vânzări nu sunt încă cunoscute
  2. Dacă o altă companie ar fi creat sistemul, ar fi trebuit să se stabilească transferul drepturilor de autor, deci nu ar fi fost o discuție despre “distribuirea profiturilor pe baza vânzărilor”

Spunând dur, “dacă ați obținut o plată pentru munca dvs. fără riscuri la un moment în care nu se știa dacă va fi profitabil, nu aveți dreptul de a solicita o distribuire a profiturilor atunci când se dovedește a fi profitabil”. Se crede că multe dintre deciziile instanțelor vor fi, în cele din urmă, aceleași cu această evaluare și concluzie.

Concluzie

La un stadiu în care nu se știe dacă afacerea va avea succes sau nu, alocarea timpului pentru crearea unui contract de afaceri comun sau solicitarea unui avocat și asumarea costurilor poate fi, într-adevăr, un “risc”. Dacă afacerea eșuează în cele din urmă, timpul și costurile devin o “pierdere de cost”.

Însă, structura de bază a unei afaceri este că “cel care își asumă riscul, în cazul în care lucrurile merg bine, obține profitul suplimentar”. Dacă inginerii individuali își asumă costurile, cum ar fi timpul și cheltuielile, la un stadiu în care “nu se știe încă dacă va fi profitabil” și își asumă “riscul” până la limită, atunci, dacă afacerea are succes, pot obține rezultate mai bune decât dacă nu și-ar fi asumat “riscul”.

Contractele privind afacerile comune sunt, în mod inevitabil, de specialitate. Pentru a preveni disputele viitoare și pentru a asigura profiturile care ar trebui obținute, este important să creați și să încheiați un contract care clarifică relațiile contractuale, solicitând un avocat de la un stadiu timpuriu, de exemplu.

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

Biroul nostru juridic, Monolis, având ca punct forte domeniul IT, internet și afaceri, oferă, printre altele, servicii de creare și revizuire a diferitelor contracte pentru companiile noastre client și cele pe care le consiliem.

Pentru detalii, vă rugăm să consultați pagina de mai jos.

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

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