Cine deține codul aplicației tale, legal

Începem cu partea pe care majoritatea firmelor o află prea târziu:

Faptul că ai plătit pentru o aplicație nu înseamnă, în dreptul român, că îi deții drepturile.

Nu e o subtilitate de avocat. E regula implicită din Legea 8/1996 privind dreptul de autor, iar dacă în contractul tău nu scrie altceva, ea se aplică automat — indiferent cât ai plătit.

Articolul ăsta explică ce spune legea, ce trebuie să conțină un contract ca să fii chiar proprietar, și cum verifici în cinci minute în ce situație ești acum.

Nu suntem avocați și textul de mai jos nu e consultanță juridică. E ce am învățat preluând proiecte de la alți furnizori, plus textul legii, pe care îl poți citi singur. Pentru un contract concret, întreabă un avocat.

Ce spune legea, pe scurt

Sunt două situații complet diferite, iar oamenii le confundă.

Software scris de angajații tăi. Drepturile patrimoniale îți aparțin ție, angajatorul, dacă programul a fost creat în exercitarea atribuțiilor de serviciu sau după instrucțiunile tale. E regula implicită, și funcționează în favoarea ta fără să faci nimic.

Software comandat unui furnizor extern. Aici se inversează. În cazul unui contract de comandă, în lipsa unei clauze contrare, drepturile patrimoniale rămân autorului — adică firmei care a scris codul, nu ție, care ai plătit.

Recitește propoziția de mai sus. Este cea mai importantă din articol. Fără o clauză explicită de cesiune, ai plătit dreptul de a folosi aplicația, nu proprietatea asupra ei.

Ce trebuie să conțină contractul

Legea nu se mulțumește cu o propoziție vagă de tipul „codul aparține beneficiarului". Contractul de cesiune trebuie să prevadă explicit:

care drepturi patrimoniale se transmit
modurile de utilizare — reproducere, distribuire, modificare, comunicare publică
durata cesiunii
întinderea ei — teritoriul
remunerația cuvenită titularului

Dacă lipsesc, cesiunea poate fi contestată. Iar formularea contează: „exclusivă" înseamnă că nici furnizorul nu mai poate folosi codul; fără acest cuvânt, poate să-l revândă altcuiva.

Cere ca perioada să fie nelimitată și teritoriul mondial. O cesiune pe cinci ani sau doar pentru România sună inofensiv la semnare și devine o problemă exact când aplicația a ajuns să conteze.

Verificarea de cinci minute

Deschide contractul pe care îl ai și caută:

Cuvântul „cesiune" sau „transmitere a drepturilor patrimoniale". Dacă nu apare deloc, aproape sigur nu ești proprietar.
Cuvântul „exclusiv". Fără el, furnizorul poate vinde aceeași soluție concurenței tale.
Durata și teritoriul. Caută „nelimitat" și „mondial". Orice altceva e o limitare pe care ai acceptat-o.
Dreptul de a modifica. Fără el, poți folosi aplicația dar nu o poți dezvolta cu altcineva.
Ce se întâmplă la încetarea contractului. Dacă nu scrie nimic, va fi o negociere exact în momentul în care ai cel mai puțin timp de negociat.

Dacă niciunul dintre punctele astea nu apare, nu înseamnă că furnizorul e de rea-credință. Multe contracte de dezvoltare din România sunt scrise pe grabă, iar problema apare abia peste ani. Dar înseamnă că poziția ta legală e mai slabă decât credeai.

Proprietatea pe hârtie nu e de ajuns

Am preluat proiecte unde clientul avea o clauză impecabilă și tot nu putea face nimic cu aplicația lui. Proprietatea juridică fără acces practic e o hârtie.

Verifică și lista asta, care nu ține de contract ci de realitate:

Unde stă codul? Trebuie să fie într-un repository pe care îl controlezi tu — cont de firmă la GitHub, GitLab sau altundeva — cu furnizorul invitat ca membru. Dacă e pe contul furnizorului și tu ai doar acces, poți fi scos oricând.

Cine deține conturile? Domeniul, găzduirea, contul de cloud, conturile Apple Developer și Google Play, serviciile de plată. Toate ar trebui deschise pe firma ta. Un furnizor care le ține pe ale lui „ca să fie mai simplu" îți ține de fapt afacerea.

Ai secretele? Chei de API, parole de bază de date, certificate de semnare. Fără ele, altcineva nu poate prelua sistemul chiar dacă are codul.

Există documentație de operare? Cum se publică o versiune nouă, unde stau lucrurile, ce se face când pică ceva. Fără ea, un furnizor nou petrece săptămâni doar ca să înțeleagă ce a moștenit.

Poți construi aplicația de la zero? Testul suprem. Dacă un dezvoltator ia repository-ul pe un calculator curat și nu poate obține o versiune funcțională, nu deții un sistem — deții niște fișiere.

De ce unii furnizori evită subiectul

Ca să înțelegi ce auzi când întrebi.

Un furnizor care păstrează codul și conturile are un client care nu poate pleca. Nu e neapărat rea-intenție; e pur și simplu confortabil, iar confortul nu se pune singur în discuție. Rezultatul e că prețurile pot crește, termenele se pot lungi, iar tu nu ai alternativă.

Există și un argument legitim, care merită recunoscut: un furnizor care refoloseste componente proprii între clienți nu poate ceda exclusiv codul acelor componente. E corect — dar atunci trebuie spus explicit care părți sunt ale lui și pe ce licență le folosești, nu ascuns în tăcere.

Formularea corectă sună așa: codul scris pentru tine e al tău, exclusiv și nelimitat; componentele noastre reutilizabile rămân ale noastre, iar tu primești o licență perpetuă, irevocabilă, transferabilă, de a le folosi și modifica. Dacă furnizorul nu poate scrie propoziția asta, întreabă de ce.

Cum lucrăm noi

Ca să știi la ce să te aștepți și ca să poți compara:

Codul stă în repository-ul tău din prima zi, nu la finalul proiectului. Conturile de cloud, magazinele de aplicații și domeniul se deschid pe firma ta, cu noi ca membri. Documentația de operare se livrează cu proiectul. Contractul conține cesiune exclusivă, nelimitată în timp și teritoriu.

Nu e generozitate. E consecința modelului nostru: dacă un client rămâne cu noi doar pentru că nu poate pleca, avem o problemă mai mare decât dacă pleacă.

Întrebări frecvente

Am plătit integral. Nu e evident că e al meu? Nu, și ăsta e exact punctul articolului. Pentru software comandat extern, legea română atribuie implicit drepturile autorului, nu plătitorului. Evidența trebuie scrisă în contract.

Ce fac dacă am deja un contract fără clauză de cesiune? Poți cere un act adițional. Cel mai bun moment e când relația e bună și urmează o etapă nouă — nu când ești deja în conflict. Un furnizor corect nu va refuza.

Furnizorul spune că îmi dă codul „la cerere". E suficient? Nu. Codul livrat la cerere e o promisiune, nu un drept, iar „la cerere" devine complicat exact când relația se strică. Cere acces continuu, din prima zi.

Contează dacă folosește biblioteci open-source? Da, și e normal să folosească. Cere lista licențelor. Majoritatea (MIT, Apache) nu îți impun nimic. Altele, precum AGPL, pot avea consecințe dacă distribui produsul — merită știut înainte, nu după.

Pot cere codul dacă furnizorul a dispărut? Practic, foarte greu. De asta accesul continuu din prima zi contează mai mult decât orice clauză: o firmă radiată nu răspunde la notificări.

Ce faci mai departe

Ia contractul actual și parcurge cele cinci puncte din verificarea de mai sus. Dacă lipsesc, discută cu furnizorul înainte de următoarea etapă de plată — e momentul în care ai cea mai bună poziție.

Dacă pornești un proiect nou, cere oferta cu întrebarea asta pusă direct în cerere. Răspunsul pe care îl primești, de la oricine, îți spune mai multe despre ce fel de relație urmează decât prețul.

Surse și precizări

Legea nr. 8/1996 privind dreptul de autor și drepturile conexe — textul oficial, pe Portalul Legislativ. Relevante sunt dispozițiile privind programele pentru calculator (drepturile aparțin angajatorului pentru software creat de salariați în exercitarea atribuțiilor), cele privind contractul de comandă (în lipsa unei clauze contrare, drepturile rămân autorului) și cele privind cesiunea drepturilor patrimoniale (care impun precizarea drepturilor transmise, a modurilor de utilizare, a duratei, a întinderii și a remunerației).

Precizare: nu suntem avocați, iar articolul nu constituie consultanță juridică. Interpretarea unui contract concret depinde de formulările lui exacte. Verificările practice — repository, conturi, secrete, documentație — vin din experiența noastră de preluare a unor proiecte de la alți furnizori, nu dintr-o sursă externă.