Protecția software-ului și a aplicațiilor mobile: drepturi de autor versus brevete și contracte cu dezvoltatorii

1. Cadru general: cum este protejat software-ul în România și UE

La nivel european, programele pentru calculator (inclusiv aplicațiile mobile) sunt protejate în primul rând prin drept de autor, nu prin brevet, în baza Directivei 2009/24/CE privind protecția juridică a programelor pentru calculator, transpusă în România prin dispozițiile speciale din Legea nr. 8/1996.

Legea dreptului de autor prevede expres că programele pentru calculator fac parte din operele protejate, ca opere de creație intelectuală, alături de opere literare, artistice sau științifice. Protecția se naște automat, prin simplul fapt al realizării operei, fără vreo formalitate de înregistrare, iar dreptul de autor are componentă morală (legată de persoana autorului) și patrimonială (dreptul de a exploata economic opera). Durata drepturilor patrimoniale este, în principiu, viața autorului plus 70 de ani după moarte. (Legea nr. 8/1996, art. 1 și art. 33–35).

În paralel, Legea nr. 64/1991 privind brevetele de invenție stabilește condițiile în care o invenție poate fi protejată prin brevet (noutate, activitate inventivă, aplicabilitate industrială). Programele de calculator „în sine” nu sunt considerate invenții, dar anumite invenții implementate pe calculator pot fi brevetate în anumite condiții, dacă rezolvă o problemă tehnică, produc un efect tehnic și îndeplinesc criteriile clasice ale invențiilor.

Alte instrumente juridice relevante pentru protecția software-ului sunt: mărcile (denumirea aplicației, logo-ul) – protejate prin înregistrare la OSIM sau EUIPO, secretele comerciale (algoritmi, know-how nepublic) – protejate prin confidențialitate, precum și contractele (de dezvoltare, licență, cesiune de drepturi), care stabilesc „cine deține ce” și „cine are voie să folosească ce” în relația dintre fondatori, dezvoltatori, clienți și investitori.

2. Software-ul ca „operă” protejată prin drepturi de autor

2.1. Ce anume este protejat?

Capitolul dedicat programelor pentru calculator din Legea nr. 8/1996 prevede că protecția include orice expresie a unui program, programe de aplicație și sisteme de operare, exprimate în orice limbaj (cod-sursă sau cod-obiect), materialul de concepție pregătitor (de exemplu, specificații tehnice, diagrame) și manualele. (Art. 72–73 din Legea nr. 8/1996).

Important: se protejează forma de exprimare, nu ideile, algoritmii ca atare, principiile matematice sau funcționalitatea în sine. Această distincție apare atât în Legea nr. 8/1996 (care exclude ideile, metodele de funcționare și conceptele matematice de la protecția prin drept de autor), cât și în jurisprudența Curții de Justiție a UE (de exemplu cauza C-406/10 SAS Institute, unde s-a reținut că limbajul de programare și funcționalitatea programului nu sunt, ca atare, protejate de dreptul de autor, ci doar expresia concretă a programului).

În practică, asta înseamnă că două echipe diferite pot implementa independent aceeași idee de aplicație, cu funcționalități similare, fără a încălca dreptul de autor, atâta timp cât nu copiază codul-sursă sau elementele originale de design, arhitectură sau documentație ale celuilalt.

2.2. Când și cum se naște dreptul de autor asupra software-ului?

Legea nr. 8/1996 prevede că opera de creație intelectuală este recunoscută și protejată independent de aducerea la cunoștință publică, chiar neterminată (art. 2 alin. 2). În cazul software-ului, dreptul de autor apare în momentul în care codul (sau materialul pregătitor) trece de la stadiul de idee la o formă concretă (fișiere, repo, documentație) care poate fi identificată ca operă.

Nu este nevoie de niciun fel de depunere la ORDA sau altă instituție pentru ca drepturile de autor să existe. Aceste formalități pot avea rol probatoriu sau suplimentar (de exemplu, registrul ORDA sau înscrierea în Registrul Național al Programelor pentru Calculator), dar dreptul există și fără ele.

2.3. Cine este autorul și cine este titularul drepturilor?

În principiu, autorul este persoana fizică (programatorul) care a creat efectiv codul sau alte componente ale programului. Autorul este, inițial, titular al drepturilor morale și patrimoniale. Totuși, legea introduce o regulă specială pentru programele de calculator realizate de angajați: în lipsa unei clauze contrare, drepturile patrimoniale de autor asupra programelor pentru calculator, create de unul sau mai mulți angajați în exercitarea atribuțiilor de serviciu ori după instrucțiunile angajatorului, aparțin angajatorului (art. 74 din Legea nr. 8/1996).

Cu alte cuvinte, dacă ești programator angajat și dezvolți codul în cadrul jobului, în mod normal compania va fi titularul drepturilor patrimoniale asupra software-ului, dacă nu s-a convenit altfel. În cazul colaboratorilor externi (freelanceri, PFA, SRL), nu se aplică această prezumție; acolo devine esențial contractul, unde trebuie stabilit clar dacă drepturile patrimoniale sunt cesionate clientului sau doar licențiate, pe ce durată, ce teritoriu și cu ce limitări.

3. Drepturile patrimoniale și morale asupra software-ului

3.1. Drepturi patrimoniale

Drepturile patrimoniale de autor conferă titularului monopolul economic asupra operei. Pentru software, drepturile relevante sunt, în principal (art. 13, art. 73 din Legea nr. 8/1996):

• dreptul de reproducere (copierea codului, instalare, stocare, rulare, execuție, afişare, transmitere în rețea);
• dreptul de a realiza opere derivate (adaptări, modificări, versiuni noi, plugin-uri, integrare în alte produse);
• dreptul de distribuire (vânzarea ori altă formă de transmitere a copiilor programului);
• dreptul de închiriere/licențiere (de exemplu model SaaS, licențe on-premise);
• dreptul de comunicare publică (punerea la dispoziție a software-ului online, astfel încât publicul să poată accesa aplicația).

Aceste drepturi pot fi cedate definitiv (cesiune) sau pot fi acordate sub forma unor licențe (exclusive sau neexclusive). De exemplu, o firmă de produs software va dori, de regulă, să fie titularul drepturilor patrimoniale asupra codului și să acorde clienților licențe de utilizare (SaaS sau on-premise). O agenție de dezvoltare custom software va tinde să cedeze drepturile patrimoniale clientului, cel puțin asupra părților specifice proiectului.

3.2. Drepturi morale

Drepturile morale sunt inalienabile (nu pot fi cedate) și includ, printre altele, dreptul autorului de a-i fi recunoscută calitatea, de a decide dacă, cum și când opera este adusă la cunoștință publică și dreptul la respectarea integrității operei (art. 10–11 din Legea nr. 8/1996). Chiar dacă drepturile patrimoniale sunt transferate, autorul (programatorul) rămâne, în principiu, autor în sens moral.

În practică, litigiile în domeniul software vizează preponderent drepturile patrimoniale (cine poate folosi, modifica, revinde codul), dar drepturile morale pot apărea în discuție, mai ales în cazuri de modificări sau reutilizări ale codului fără acordul autorului, care i-ar putea afecta reputația.

4. Drepturi de autor și formalități: ORDA și Registrul Național al Programelor pentru Calculator

4.1. ORDA și registrul pentru software

În România, Oficiul Român pentru Drepturile de Autor (ORDA) administrează Registrul Național al Programelor pentru Calculator. Înregistrarea unui program în acest registru nu este condiție de existență a dreptului de autor, ci are rol probatoriu (dovadă cu privire la existența și conținutul programului la o anumită dată) și, în anumite cazuri, rol de conformare legală pentru firme care introduc software în circuitul comercial.

Potrivit explicațiilor practice (de exemplu, ghiduri pentru înregistrarea software-ului la ORDA și analize privind art. 25 din Ordonanța nr. 25/2006), persoanele fizice sau juridice înscrise în Registrul național al programelor pentru calculator sunt obligate să înscrie programele în registru înainte de introducerea lor în circuitul comercial, cu anumite excepții prevăzute de lege. Acest mecanism vizează în special producătorii de software care își comercializează produsele la scară largă.

Pentru un startup de tehnologie, înregistrarea principalului produs software la ORDA poate fi utilă ca probă în relația cu potențiali investitori sau parteneri și în eventualitatea unui litigiu. Procedura implică depunerea unui dosar cu descrierea programului și elemente de identificare; în schimb, se eliberează un certificat de înregistrare.

4.2. Avantaje și limite ale înregistrării la ORDA

Avantaje:

• creează o prezumție puternică cu privire la data și paternitatea programului în caz de litigiu privind plagiatul sau utilizarea neautorizată;
• este un semnal de profesionalism și organizare pentru clienți și investitori;
• poate fi integrată în strategia de management al proprietății intelectuale a companiei (alături de brevete, mărci, acorduri de confidențialitate).

Limite:

• nu transformă un program altfel neoriginal într-o operă protejată – originalitatea rămâne criteriul juridic;
• nu oferă un „monopol” asupra ideii sau funcționalității – doar asupra expresiei concrete;
• nu înlocuiește necesitatea unor contracte clare cu angajații și colaboratorii.

5. Brevetele pentru invenții implementate pe calculator

5.1. Când poate fi brevetat software-ul?

Legea nr. 64/1991 privind brevetele de invenție prevede că sunt protejate prin brevet invențiile care îndeplinesc cumulativ trei condiții: noutate, activitate inventivă și aplicabilitate industrială (art. 9–12). În același timp, legea și regulamentul de aplicare exclud unele categorii de „creații” de la brevetare, printre care și programele de calculator, „în sine”. OSIM explică, în ghidurile sale, că programele de calculator ca atare nu sunt considerate invenții, dar că o invenție care conține elemente software poate fi brevetabilă dacă produce un efect tehnic și îndeplinește condițiile de brevetabilitate.

De exemplu, OSIM indică în materiale informative că programele de calculator, „în sine”, nu sunt considerate invenții în sensul art. 7 lit. c) din Legea nr. 64/1991 și că, pentru invențiile din domeniul software, trebuie urmărită evidențierea unui efect tehnic clar (de exemplu o metodă de compresie mai eficientă, un algoritm care optimizează consumul de energie al unui dispozitiv, un sistem de control industrial implementat prin software).

În practică, se vorbeste despre „invenții implementate pe calculator” (computer-implemented inventions), pentru care Oficiul European de Brevete și OSIM au ghiduri dedicate. Ideea de bază este că software-ul care doar procesează date de business sau face calcule matematice obișnuite, fără un efect tehnic suplimentar, nu este brevetabil, în timp ce un algoritm care îmbunătățește funcționarea unui dispozitiv tehnic ar putea fi brevetabil.

5.2. Avantajele și dezavantajele brevetelor pentru startup-uri software

Avantaje potențiale:

• conferă un drept exclusiv asupra unei soluții tehnice, nu doar asupra codului concret; concurenții nu pot implementa aceeași invenție, nici cu cod diferit;
• poate crește valoarea companiei în ochii investitorilor (un portofoliu de brevete este adesea văzut ca „moat” competitiv);
• permite licențierea tehnologiei către alte companii, inclusiv prin modele de business de tip „licențiere de tehnologie”;
• oferă o bază juridică solidă pentru acțiuni de contrafacere ori pentru negocieri de cross-licensing.

Dezavantaje și limite:

• costuri ridicate (taxe OSIM, onorarii consilier în proprietate industrială, eventual extindere europeană sau internațională);
• timp de obținere relativ lung (ani de zile până la eliberarea brevetului, deși protecția începe de la data depozitului);
• necesitatea de a divulga public detalii tehnice despre invenție – după publicarea cererii, concurenții află exact cum funcționează soluția;
• nu orice software inovator este brevetabil; o bună parte din aplicațiile mobile și produsele SaaS se bazează pe idei de business și UX, nu pe invenții tehnice în sensul legii brevetelor.

Din aceste motive, pentru majoritatea startup-urilor orientate spre aplicații mobile tipice (marketplace, SaaS de business, aplicații de productivitate etc.), strategia principală rămâne dreptul de autor, completat de mărci și de contracte solide. Brevetele devin relevante mai ales în zone deep tech (inteligență artificială cu componente tehnice inovatoare, optimizare de rețea, compresie de date, securitate hardware/software etc.).

6. Drepturi de autor versus brevete – cum alegi strategia potrivită

6.1. Comparație rapidă

6.2. Exemple de strategie

Exemplul 1 – aplicație mobilă B2C (marketplace, social, lifestyle): de regulă, protecția principală va fi prin drept de autor asupra codului și designului, marcă asupra denumirii și logo-ului, plus contracte bune cu dezvoltatorii și clienții (Termeni și Condiții, licențiere). Brevetul, în astfel de cazuri, este de multe ori nepractic (nu există o invenție tehnică clară sau costul nu se justifică).

Exemplul 2 – algoritm nou de compresie video sau imagine: dacă există o soluție tehnică nouă care permite comprimarea mai eficientă a datelor, merită evaluată brevetabilitatea. Dreptul de autor protejează codul efectiv, dar pentru a împiedica concurenții să reproducă algoritmul cu cod diferit, brevetul poate fi esențial.

Exemplul 3 – sistem de control industrial implementat software: dacă aplicația ta controlează un echipament industrial într-un mod nou și tehnic, tot brevetul poate fi o opțiune, combinat cu dreptul de autor asupra codului și cu secrete comerciale pentru anumite aspecte de know-how care nu sunt dezvăluite în brevet.

7. Contracte cu dezvoltatorii: cine deține codul?

Indiferent câte drepturi îți acordă legea, în practică, totul se joacă în contracte: contractele de muncă, contractele cu freelanceri, contractele cu firme de dezvoltare, acordurile între fondatori. O strategie bună de protecție a software-ului începe cu o întrebare simplă: „Dacă mâine mă cert cu dezvoltatorul, pot continua legal să folosesc, modific și licențiez aplicația?”

7.1. Angajați vs freelanceri vs agenții de software

Angajații programatori: pentru code-ul creat de angajați în exercitarea atribuțiilor de serviciu sau după instrucțiunile angajatorului, Legea nr. 8/1996 instituie prezumția că drepturile patrimoniale aparțin angajatorului (art. 74). Totuși, este recomandabil ca această regulă să fie reflectată explicit în contractul individual de muncă sau în regulamentul intern, pentru a evita disputele, mai ales în contextul lucrului remote sau al proiectelor „din timpul liber”.

Freelanceri și PFA/SRL: în lipsa regulii speciale din art. 74, drepturile de autor rămân, inițial, la persoana care creează programul. Pentru ca antreprenorul sau clientul să devină titularul drepturilor patrimoniale asupra software-ului, este nevoie de o clauză de cesiune (sau de o licență suficient de largă) exprimată clar și în formă scrisă. Articole și ghiduri privind drepturile de autor în raporturile de muncă subliniază riscul ca, fără astfel de clauze, angajatorul / clientul să nu aibă control deplin asupra operei.

Firme de development / agenții: multe agenții folosesc cod reutilizabil (framework intern, librării proprii) și cedează clientului doar drepturile asupra componentelor specifice proiectului. Contractul trebuie să definească ce este „cod general” al agenției, ce este „cod specific” al proiectului, ce licențe se acordă și dacă există limitări (de exemplu, clientul nu poate vinde codul ca SDK separat).

7.2. Clauze esențiale în contractele de dezvoltare software

Într-un contract de dezvoltare software (cu angajat, freelancer sau agenție), ar trebui să apară, cel puțin, următoarele elemente privind proprietatea intelectuală:

• Obiectul contractului: descriere clară a livrabilelor (cod-sursă, cod-obiect, documentație, design UI/UX, manuale, scripturi de deployment etc.).
• Cesiune de drepturi patrimoniale sau licență: se precizează dacă dezvoltatorul cedează drepturile patrimoniale (în întregime sau limitat) sau acordă doar o licență. În cazul cesiunii, este bine să se precizeze că transferul este:
  • pe durată maximă permisă de lege;
  • pentru toate teritoriile (global);
  • pentru toate modalitățile de utilizare actuale și viitoare, cel puțin în măsura rezonabilă pentru scopul business-ului.
• Remunerația: pentru cesiune, este recomandabil ca remunerația pentru drepturile patrimoniale să fie identificabilă (chiar dacă este inclusă în prețul total), tocmai pentru a evita discuții ulterioare privind caracterul oneros al cesiunii.
• Dreptul de a modifica și dezvolta ulterior: se precizează dacă beneficiarul poate modifica codul, îl poate integra în alte produse, poate crea versiuni noi etc., fără a avea nevoie de aprobarea dezvoltatorului.
• Open-source și third-party: se reglementează utilizarea componentelor open-source sau a bibliotecilor terțe (ce licențe se acceptă, cine răspunde dacă există incompatibilități, dacă este permisă integrarea de cod cu licențe restrictive de tip copyleft etc.).
• Confidențialitate și secrete comerciale: se protejează codul, documentația, specificațiile de produs, datele clienților și orice altă informație sensibilă; această protecție este esențială indiferent dacă există sau nu brevete.
• Garanții privind originalitatea: dezvoltatorul garantează că nu a încălcat drepturile unui terț (de exemplu copiind cod din proiecte anterioare sau din repository-uri fără respectarea licențelor) și se obligă să despăgubească beneficiarul dacă apare o astfel de încălcare.
• Returnarea și ștergerea codului: la încetarea colaborării, se stabilește ce se întâmplă cu codul, cu accesul la repo-uri, la infrastructură, token-uri, credențiale etc.

7.3. Clauze specifice pentru invenții și brevete

Dacă există șansa reală ca proiectul să genereze o invenție brevetabilă (de exemplu, o soluție tehnică inovatoare dezvoltată în cadrul companiei), contractele ar trebui să țină cont și de reglementările privind „invențiile de serviciu” (Legea nr. 83/2014 și raportarea la Legea nr. 64/1991). De regulă, este util:

• să se prevadă obligația angajaților sau colaboratorilor de a notifica prompt compania dacă au dezvoltat o invenție legată de activitatea lor;
• să se stipuleze cine are obligația (și dreptul) de a depune cererea de brevet (compania, inventatorul sau amândoi);
• să se stabilească modul de remunerare suplimentară a inventatorului, dacă brevetul este exploatat comercial.

8. Probleme frecvente și greșeli de evitat

8.1. Lipsa oricărui contract scris cu dezvoltatorii

În practică, foarte multe startup-uri pornesc cu un prieten dezvoltator, un freelancer sau o mică agenție, fără contract clar privind proprietatea intelectuală. Din punct de vedere juridic, asta înseamnă că:

• dacă e vorba de un angajat, te bazezi doar pe prezumția legală din art. 74 (drepturile patrimoniale asupra programelor create în exercitarea atribuțiilor de serviciu aparțin angajatorului), dar pot apărea discuții dacă proiectul s-a dezvoltat „în afara programului” sau „în paralel”;
• dacă e vorba de un freelancer sau o firmă, în lipsa unei cesiuni explicite, drepturile patrimoniale rămân, în principiu, la dezvoltator – iar tu ai cel mult o licență tacită și limitată, care poate fi contestată la primul conflict.

Investitorii serioși verifică de regulă lanțul de titlu (chain of title) pentru IP: vor să vadă contractele cu dezvoltatorii, clauzele de cesiune, eventual dovezile de înregistrare (ORDA, OSIM, mărci). Lipsa lor poate bloca sau întârzia o finanțare sau o exit tranzacție.

8.2. Confuzia dintre „drept de utilizare” și „drept de proprietate”

Legea nr. 8/1996 prevede, la art. 75, o prezumție interesantă: în lipsa unei clauze contrare, printr-un contract de utilizare a unui program pentru calculator se prezumă că utilizatorului i se acordă un drept neexclusiv de utilizare și că nu poate transmite altor persoane acest drept. Totodată, cesiunea dreptului de utilizare nu implică și transferul dreptului de autor asupra programului.

În business, asta se traduce astfel: faptul că un client „plătește pentru un software” nu înseamnă automat că devine proprietar pe cod; de cele mai multe ori, primește doar o licență de utilizare, ale cărei limite (număr de utilizatori, teritoriu, tip de utilizare) trebuie clar stabilite în contractul de licență sau în Termenii și Condițiile aplicației.

8.3. Utilizarea necontrolată a codului open-source

Foarte mult software modern se bazează pe componente open-source. Deși acest lucru este perfect legitim, el vine cu condiții: licențele open-source (MIT, Apache 2.0, GPL, LGPL, AGPL etc.) stabilesc ce drepturi ai și ce obligații ai (de exemplu obligația de a publica codul sursă derivat în cazul unor licențe copyleft).

Dacă folosești, în mod necontrolat, componente cu licențe incompatibile cu modelul tău de business (de exemplu, incluzi componente AGPL în serverul aplicației proprietare fără să respecți obligațiile de divulgare a codului), poți compromite posibilitatea de a proteja software-ul ca produs proprietar și poți intra în conflict cu deținătorii drepturilor asupra componentelor open-source.

8.4. Nealinierea între contracte și practică

Chiar și atunci când există contracte, apar frecvent situații în care practica de zi cu zi le contrazice: programatori care lucrează pe proiecte personale pe același repo cu proiectele companiei, reuse de cod între proiecte fără o politică clară, partajarea credențialelor și accesului la repo-uri fără control etc. O strategie de protecție eficientă nu înseamnă doar contracte scrise, ci și proceduri interne și o cultură organizațională în care toată lumea înțelege importanța proprietății intelectuale.

9. Checklist practic pentru antreprenori și programatori

Pentru a transforma toate aceste principii în pași concreți, iată un checklist minimal pentru un startup sau o firmă care dezvoltă aplicații mobile:

1. Mapează IP-ul existent: ce componente software ai (backend, frontend, aplicații mobile, scripturi, infrastructură), cine le-a scris, în ce perioadă și în ce context (job, freelancing, colaborare).
2. Verifică contractele existente: pentru angajați, freelanceri, agenții – există clauze clare de cesiune sau licență? Se referă explicit la programe pentru calculator, pentru toate versiunile și actualizările?
3. Reglementează folosirea open-source: creează o politică internă privind ce licențe sunt acceptabile și cum se documentează utilizarea componentelor open-source (Software Bill of Materials).
4. Ia în calcul înregistrarea software-ului la ORDA: pentru principalele produse, mai ales dacă sunt destinate comercializării pe scară largă sau dacă reprezintă active cheie pentru business.
5. Verifică oportunitatea brevetării: dacă există o componentă tehnică cu adevărat inovatoare, consultă un consilier în proprietate industrială pentru a evalua șansele unui brevet la OSIM / OEB.
6. Protejează brandul aplicației: înregistrează marca (denumire + logo) la OSIM sau EUIPO, mai ales dacă vrei să scalezi în UE.
7. Consolidează documentația: ține evidența versiunilor codului, a autorilor, a commit-urilor și a deciziilor tehnice (arhitectură, design), astfel încât, la nevoie, să poți demonstra paternitatea și originalitatea.
8. Actualizează periodic contractele: pe măsură ce produsul și echipa evoluează, revizuiește contractele de muncă, contractele cu freelanceri și Termenii și Condițiile aplicației, pentru a te alinia cu practicile actuale și cu legislația.

10. FAQ – Întrebări frecvente despre protecția software-ului și a aplicațiilor mobile