Licențe Open Source — MIT, GPL, Apache și Conformare

Licențele open source sunt contracte prin care titularul dreptului de autor asupra unui program îți permite să îl folosești, modifici și redistribui sub anumite condiții. Cele permisive (MIT, Apache 2.0) cer doar păstrarea atribuirii, iar cele copyleft (GPL, AGPL) impun distribuirea codului sursă al operelor derivate. În dreptul român, nerespectarea condițiilor licenței este o încălcare a dreptului de autor, nu o simplă problemă contractuală (CJUE, C-666/18).

Pe scurt

Licențele open source (MIT, Apache 2.0, GPL, LGPL, AGPL etc.) sunt contracte prin care titularul dreptului de autor asupra unui program pentru calculator îți permite să îl folosești, să îl modifici și să îl redistribui — dar fiecare licență impune condiții, de la simpla păstrare a notei de copyright până la obligația de a publica întreg codul sursă al produsului tău. În dreptul român, software-ul e protejat prin Legea nr. 8/1996, iar o „licență" este tehnic o cesiune a dreptului de utilizare; nerespectarea condițiilor nu e o simplă problemă contractuală, ci o încălcare a dreptului de autor (CJUE, C-666/18). Conformarea corectă înseamnă să știi în ce categorie intră fiecare componentă — permisivă ori copyleft — și să respecți obligațiile de atribuire, de marcare a modificărilor și, la copyleft, de punere la dispoziție a sursei.

Cadrul legal

Software-ul este protejat prin dreptul de autor

În România și în întreaga Uniune Europeană, programele pentru calculator sunt protejate prin dreptul de autor, nu prin brevet, fiind asimilate operelor literare. Cadrul de bază este Legea nr. 8/1996 privind dreptul de autor și drepturile conexe, care în Capitolul dedicat programelor pentru calculator (art. 73-82) reglementează sfera protecției și drepturile titularului.

Art. 7 lit. a) din Legea 8/1996 — Constituie obiect al dreptului de autor operele originale de creație intelectuală [...], precum și programele pentru calculator.

Art. 73 din Legea 8/1996 — Protecția programelor pentru calculator include orice expresie a unui program [...], exprimate în orice fel de limbaj, fie în cod-sursă sau cod-obiect [...]. Ideile, procedeele, metodele de funcționare, conceptele matematice și principiile care stau la baza oricărui element dintr-un program [...] nu sunt protejate.

Sursa: Legea nr. 8/1996, Art. 73 (accesat 2026-08-07)

Consecința practică: dreptul de autor protejează codul (expresia), nu ideea sau algoritmul. Poți reimplementa funcționalitatea unei biblioteci open source scriind cod propriu, dar nu poți copia codul acesteia fără să respecți licența sub care este oferit.

Ce este, juridic, o „licență" în dreptul român

Drepturile patrimoniale exclusive ale titularului sunt enumerate de art. 74: dreptul de a autoriza reproducerea, adaptarea/transformarea, distribuirea și închirierea programului. O licență open source este mecanismul prin care titularul autorizează în avans aceste acte, în anumite condiții, față de oricine.

⚠️ Precizare terminologică (doctrină) — Sub influența practicii americane se folosește impropriu termenul „licență" pentru software. În dreptul român, în cazul programelor pentru calculator, este vorba de fapt despre o cesiune (de regulă neexclusivă) a dreptului de utilizare — unul dintre drepturile patrimoniale reglementate de Legea 8/1996 (art. 39-43 privind cesiunea). Software-ul este licențiat, nu vândut.

Această calificare are consecințe: licența este un contract (guvernat de Codul Civil), iar condițiile ei (atribuire, copyleft, restricții) sunt obligații pe care licențiatul le acceptă prin utilizarea codului. Totuși, așa cum a stabilit CJUE, încălcarea condițiilor privind drepturile de autor nu rămâne un simplu litigiu contractual, ci activează și regimul de protecție a proprietății intelectuale (vezi secțiunea Practică și opinii).

Cesiune formală sau autorizare publică? (forma scrisă vs. acceptare tacită)

Apare o tensiune reală: art. 42 din Legea 8/1996 cere, pentru cesiune, forma scrisă și mențiuni obligatorii — drepturile transmise, modalitățile de utilizare, durata, întinderea și remunerația (iar art. 40 permite limitarea cesiunii la anumite drepturi, teritoriu sau durată). O licență MIT/GPL este însă acceptată tacit, prin simpla utilizare, fără semnătură și, de regulă, cu titlu gratuit. Cum se împacă cele două?

• Interpretarea dominantă în doctrină este că o licență open source nu este o cesiune formală în sensul art. 42, ci o autorizare (licență) neexclusivă acordată printr-o ofertă publică adresată unui număr nedeterminat de persoane. Contractul se formează valabil prin acceptare prin executare (începerea utilizării), conform regulilor generale de formare a contractului din Codul civil (Legea nr. 287/2009), art. 1186-1196. Gratuitatea și lipsa semnăturii nu îl invalidează.
• Consecința asupra validității: cerințele de formă/remunerație de la art. 42 sunt gândite pentru transferul drepturilor patrimoniale între părți identificate; ele nu golesc de efecte o autorizare gratuită și publică. Autorul rămâne titular și doar permite anumite acte.
• Consecința asupra opozabilității: autorizația se opune terților prin publicarea licenței odată cu codul (textul licenței însoțește distribuția). Nu există o formalitate de înregistrare a acestei autorizări.

⚠️ Notă: instanțele române nu s-au pronunțat încă direct pe validitatea unei licențe OSS gratuite ca „cesiune". Calificarea de mai sus (autorizare publică, iar nu cesiune formală) reflectă opinia majoritară a doctrinei și logica CJUE C-666/18. A se reține însă concluzia practică: încălcarea condițiilor licenței este tratată ca încălcare a dreptului de autor, nu ca simplă neexecutare contractuală.

Cine deține drepturile: contribuția salariatului (art. 75)

O întrebare-cheie de conformare: cine poate licenția valabil sub MIT/GPL codul scris de un salariat care contribuie la un proiect open source?

Art. 75 din Legea 8/1996 — „În lipsa unei clauze contrare, drepturile patrimoniale de autor asupra programelor pentru calculator, create de unul sau de mai mulți angajați în exercitarea atribuțiilor de serviciu ori după instrucțiunile celui care angajează, aparțin acestuia din urmă" (angajatorului).

Sursa: Legea nr. 8/1996, Art. 75 (accesat 2026-08-07)

Prin urmare, dacă nu există o convenție contrară, angajatorul deține drepturile patrimoniale asupra codului scris de salariat în exercitarea atribuțiilor. Un angajat care licențiază unilateral sub MIT/GPL cod ce aparține angajatorului nu are calitatea de a-l licenția — iar publicarea poate fi o contrafacere față de angajator. Mecanismele care securizează lanțul de drepturi:

• Politica internă de open source — autorizează expres contribuțiile salariaților și stabilește ce proiecte/licențe sunt permise.
• Contributor License Agreement (CLA) — contribuitorul (sau angajatorul său) acordă proiectului drepturile necesare relicențierii/redistribuirii; clarifică titularitatea.
• Developer Certificate of Origin (DCO) — declarația (prin Signed-off-by) că cel care contribuie are dreptul să transmită codul sub licența proiectului.

CLA/DCO nu înlocuiesc, acolo unde e cerută, o cesiune scrisă între salariat și angajator; ele sunt instrumente de trasabilitate care previn integrarea unui cod „viciat" la origine.

Cod vs. active non-cod: modele AI, seturi de date, Creative Commons

„Open source" nu vizează doar cod. Modelele AI cu „open weights" (ex. Llama), licențele OpenRAIL cu restricții de utilizare, seturile de date și activele non-cod sub Creative Commons ridică un regim juridic diferit:

• Multe dintre aceste licențe nu respectă Open Source Definition — conțin restricții de domeniu sau de utilizare (ex. „no military use", „non-commercial"). Ele sunt „open" în sens larg, dar tehnic source-available / open-weights, nu open source în sensul OSI.
• Seturile de date și bazele de date beneficiază în dreptul român de un drept sui-generis al fabricantului bazei de date — art. 141 și urm. din Legea 8/1996: cine a făcut o investiție substanțială în obținerea, verificarea sau prezentarea conținutului poate interzice extragerea și reutilizarea unei părți substanțiale, independent de dreptul de autor asupra elementelor individuale. Așadar un dataset poate fi protejat chiar dacă elementele sale nu sunt originale.
• De ce diferă de cod: codul beneficiază de dreptul de autor asupra unei creații originale (art. 7, 73); baza de date poate fi protejată prin dreptul sui-generis chiar fără originalitate, pe criteriul investiției. Un model AI combină, de regulă, mai multe straturi (cod + ponderi + date de antrenare), fiecare cu propriul regim, iar clauzele OpenRAIL adaugă restricții contractuale de utilizare peste dreptul de autor.

Surse: Legea nr. 8/1996, Art. 141 și urm. (drept sui-generis) · OpenRAIL / Open Source Definition (OSI) (accesat 2026-08-07)

Cadrul european

Legea 8/1996 transpune Directiva 2009/24/CE privind protecția juridică a programelor pentru calculator, care armonizează protecția software în toate statele membre.

Art. 1 alin. (2) din Directiva 2009/24/CE — Protecția se aplică oricărei forme de exprimare a unui program [...]. Ideile și principiile care se află la baza [...] nu sunt protejate de dreptul de autor.

Sursa: Directiva 2009/24/CE (accesat 2026-08-07)

La acest cadru clasic s-a adăugat recent o dimensiune de securitate cibernetică: Regulamentul (UE) 2024/2847 — Cyber Resilience Act (CRA), în vigoare din 11 decembrie 2024, introduce obligații pentru produsele cu elemente digitale și un regim special, mai ușor, pentru „administratorii de software open source" (detaliat în Aspecte practice).

Ce înseamnă „open source" în sens strict

Termenul nu înseamnă doar „cod vizibil". O licență este considerată open source dacă respectă Open Source Definition a Open Source Initiative (OSI) — 10 criterii care includ: redistribuire liberă, acces la codul sursă, permiterea operelor derivate, fără discriminare între persoane, grupuri sau domenii de utilizare (inclusiv comercial). O licență „no commercial use" nu este open source, ci doar „source-available". OSI menține lista licențelor aprobate, iar proiectul SPDX standardizează identificatorii lor (MIT, Apache-2.0, GPL-3.0-or-later etc.), folosiți în inventarele de conformare.

Surse: Open Source Definition (OSI) · SPDX License List (accesat 2026-08-07)

Explicație detaliată

Toate licențele open source pornesc de la aceeași logică: titularul dreptului de autor acordă permisiuni (să folosești, să copiezi, să modifici, să distribui) în schimbul respectării unor condiții. Diferența dintre licențe stă în cât de exigente sunt aceste condiții. Din acest punct de vedere, licențele se împart în trei mari categorii.

1. Licențe permisive (MIT, BSD, Apache 2.0)

Impun minimul de obligații: în esență, păstrarea notei de copyright și a textului licenței. Permit includerea codului chiar și în produse comerciale proprietare, fără obligația de a publica propriul cod sursă. Sunt preferate pentru adoptare maximă.

• MIT — cea mai simplă și răspândită. Poți face aproape orice (folosi, copia, modifica, sublicenția, vinde), cu o singură condiție: să incluzi nota de copyright și textul licenței în toate copiile sau porțiunile substanțiale. Software-ul e oferit „ca atare", fără garanție.

• BSD (2-clause / 3-clause) — foarte asemănătoare cu MIT. Varianta cu 3 clauze adaugă interdicția de a folosi numele autorilor pentru a promova produse derivate fără acord (clauza „no endorsement").

• Apache License 2.0 — permisivă, dar mai elaborată decât MIT, cu două elemente esențiale în plus:

  • Grant expres de brevet (secțiunea 3): fiecare contribuitor îți acordă o licență de brevet asupra invențiilor pe care le implementează în contribuția sa. În plus, o clauză de retorsiune: dacă dai în judecată pe cineva pentru încălcare de brevet legată de software, îți pierzi licențele de brevet acordate. MIT/BSD nu conțin un astfel de grant explicit, ceea ce lasă un risc de brevet.
  • Obligații de notificare (secțiunea 4): păstrarea fișierului NOTICE, indicarea modificărilor („carry prominent notices stating that You changed the files") și transmiterea unei copii a licenței.

2. Copyleft slab / la nivel de fișier (LGPL, MPL, EPL)

Poziție intermediară: obligă păstrarea „deschisă" a componentei open source și a modificărilor aduse ei, dar nu contaminează restul aplicației tale.

• LGPL (GNU Lesser GPL) — gândită pentru biblioteci. Poți folosi o bibliotecă LGPL într-un program proprietar cu condiția ca utilizatorul final să poată înlocui sau actualiza acea bibliotecă (de regulă prin linking dinamic) și să ai acces la modificările aduse bibliotecii însăși. Codul propriei tale aplicații rămâne al tău.

• MPL 2.0 (Mozilla) și EPL (Eclipse) — copyleft la nivel de fișier: modificările aduse fișierelor acoperite de licență trebuie oferite sub aceeași licență, dar fișierele noi, proprietare, pot fi combinate cu ele.

3. Copyleft tare / „viral" (GPL, AGPL)

Cele mai exigente. Principiul copyleft: dacă distribui o operă derivată dintr-un cod copyleft, întregul rezultat trebuie oferit sub aceeași licență, cu codul sursă corespunzător pus la dispoziție. De aici eticheta (informală) de licență „virală".

• GPL v2 și v3 (GNU General Public License) — dacă incluzi cod GPL într-un program și îl distribui, ești obligat să distribui întregul program derivat tot sub GPL și să oferi codul sursă. GPL v3 adaugă față de v2:

  • un grant expres de brevet din partea contribuitorilor;
  • clauze anti-„tivoization" (nu poți folosi restricții hardware ca să împiedici rularea versiunilor modificate);
  • mecanisme de compatibilitate cu alte licențe (inclusiv Apache 2.0) și clauze de „cure" a încălcărilor.
  • GPL cere, de asemenea, ca versiunile modificate să fie marcate ca modificate, pentru ca problemele lor să nu fie atribuite eronat autorilor originali.

• AGPL v3 (GNU Affero GPL) — închide „portița SaaS". La GPL clasică, obligația de a oferi sursa apare doar la distribuire; dacă rulezi codul doar pe serverul tău (SaaS), fără să distribui binarul, nu ești obligat să publici nimic. AGPL extinde obligația și la utilizarea prin rețea: dacă oferi funcționalitatea unui program AGPL utilizatorilor printr-un serviciu online, trebuie să le pui la dispoziție codul sursă corespunzător.

Mecanismul „viral" și noțiunea de operă derivată

Efectul copyleft se declanșează atunci când creezi o operă derivată și o distribui. Ce înseamnă „operă derivată" în cazul software-ului (linking static vs. dinamic, apel prin API, proces separat) este o chestiune nuanțată și disputată, dar reperele practice sunt:

• Simpla utilizare internă, fără distribuire, nu declanșează obligația copyleft la GPL clasică (dar o declanșează la AGPL, pentru servicii în rețea).
• Combinarea în același executabil (linking static) a codului tău cu cod GPL creează, în interpretarea Free Software Foundation, o operă derivată supusă GPL.
• Agregarea pe același suport a unor programe independente care doar comunică între ele (ex. prin linie de comandă) nu transformă totul în operă derivată.

Obligația copyleft în concret: „codul sursă corespunzător"

Obligația copyleft nu se rezumă la „a publica sursa". Ce trebuie livrat efectiv și cum:

• Ce înseamnă „corresponding source" (GPL): nu doar fișierele .c/.py, ci tot ce e necesar pentru a genera, instala și rula versiunea distribuită — scripturile de build, fișierele de configurare, definițiile interfețelor și, la GPLv3, cheile/scripturile de instalare (Installation Information) pentru „User Products". Nu include compilatorul/toolchain-ul standard disponibil public (System Libraries), dar include instrucțiunile necesare pentru reconstruirea binarului distribuit.
• Cum se livrează: (a) sursa împreună cu binarul; (b) o ofertă scrisă de a furniza sursa — la GPLv2 secțiunea 3(b) valabilă cel puțin 3 ani și adresată oricărui terț; la GPLv3 secțiunea 6 ofertă valabilă minimum 3 ani (sau cât oferi piese de schimb/suport); (c) pentru distribuirea prin rețea, acces la sursă de pe același server sau echivalent.
• Clauza de „cure" (GPLv3 secțiunea 8): la GPLv2 orice încălcare termină automat licența. GPLv3 introduce o remediere: dacă e prima încălcare și o repari în 30 de zile de la notificare, licența este reactivată; dreptul se restabilește și „provizoriu" dacă titularul nu te notifică în 60 de zile. Aceasta reduce riscul unei pierderi definitive a drepturilor pentru o neconformitate remediabilă.

Riscul practic pentru un distribuitor din România care oferă doar binarul, fără o cale funcțională la sursă: încalcă condiția copyleft, iar autorizația de utilizare cade. Potrivit CJUE C-666/18, aceasta nu e o simplă neexecutare contractuală, ci o încălcare a dreptului de autor (contrafacere), cu întregul arsenal al Directivei 2004/48/CE — încetarea distribuției, măsuri asigurătorii, daune. La GPLv2 terminarea e automată; la GPLv3 mai există fereastra de remediere.

Surse: GPL v3, secț. 1, 6, 8 · GPL v2, secț. 3 (accesat 2026-08-08)

Compatibilitatea între licențe

Când combini componente cu licențe diferite, ele trebuie să fie compatibile. Regula de aur: compatibilitatea copyleft este, de regulă, într-un singur sens — poți integra cod permisiv (MIT, BSD, Apache 2.0) într-un proiect GPL, dar nu poți integra cod GPL într-un proiect distribuit sub MIT și să păstrezi termenii MIT: rezultatul devine GPL. Combinații frecvent problematice:

• Apache 2.0 + GPLv2 — incompatibile (clauzele de brevet și de „retorsiune" din Apache 2.0 nu se împacă cu GPLv2); Apache 2.0 + GPLv3 sunt compatibile.
• Cod proprietar + GPL/AGPL distribuit — incompatibil: nu poți păstra codul închis dacă distribui o operă derivată.

Ghid rapid de alegere a licenței

• Vrei adoptare maximă, inclusiv de companii, fără să impui obligații → MIT sau Apache 2.0 (Apache dacă vrei protecție de brevet explicită).
• Vrei ca toate derivatele să rămână open source → GPL v3.
• Vrei să acoperi și utilizarea ca SaaS → AGPL v3.
• Publici o bibliotecă ce poate fi folosită și în software proprietar → LGPL (sau MPL 2.0).
• Ești o instituție publică din UE și vrei o licență oficială, multilingvă → EUPL 1.2.

Surse (texte de licență): MIT · Apache 2.0 · GPL v3 · AGPL v3 · LGPL v3 (accesat 2026-08-07)

Aspecte practice

Conformarea cu licențele open source nu este o formalitate: proiectele software moderne conțin, în medie, sute de dependențe open source, iar o singură componentă copyleft „ascunsă" într-un produs comercial poate crea o expunere juridică majoră. Iată ce contează în practică.

Construiește și menține un inventar (SBOM)

Nu poți respecta licențe pe care nu le cunoști. Primul pas este un SBOM (Software Bill of Materials) — lista completă a componentelor și a licențelor lor:

• Folosește identificatori SPDX standard pentru fiecare componentă și un format de inventar recunoscut (SPDX sau CycloneDX).
• Automatizează scanarea cu unelte dedicate (ex. ScanCode, sau soluții comerciale de tip license compliance), integrate în pipeline-ul CI/CD, astfel încât fiecare dependență nouă să fie evaluată înainte de a intra în produs.
• Un SBOM devine tot mai mult și o cerință de reglementare (vezi mai jos, CRA), nu doar o bună practică.

Respectă obligațiile fiecărei categorii

• Permisive (MIT/BSD/Apache 2.0): păstrează nota de copyright și textul licenței în distribuția ta (de regulă un fișier THIRD-PARTY-NOTICES / „licenses"). La Apache 2.0, păstrează și fișierul NOTICE și marchează fișierele modificate.
• Copyleft (GPL/LGPL/AGPL): dacă distribui produsul, pregătește-te să oferi codul sursă corespunzător (inclusiv scripturile de build) și să distribui întregul derivat sub aceeași licență. La AGPL, obligația apare și dacă oferi doar acces prin rețea/SaaS.
• Marchează modificările la componentele copyleft, ca să nu atribui autorilor originali erorile introduse de tine.

Greșeli frecvente de evitat

• Presupunerea „e gratis, deci pot face orice". Gratuit ≠ fără condiții. Chiar și MIT impune păstrarea atribuirii; lipsa ei este contrafacere.
• „Efectul viral" neintenționat. Integrarea unei componente GPL/AGPL într-un produs proprietar distribuit poate obliga la deschiderea întregului cod. Verifică licențele înainte de a alege o dependență, nu la lansare.
• Efectul de blocare (lock-in). Odată ce ai integrat masiv cod copyleft, migrarea ulterioară către o soluție proprietară poate fi imposibilă fără rescriere.
• Combinații incompatibile (ex. Apache 2.0 + GPLv2), care fac produsul nedistribuibil legal.
• Ignorarea grantului/retorsiunii de brevet (Apache 2.0, GPLv3) în strategia de PI a firmei.

Due diligence în achiziții și investiții (M&A)

La achiziția unei companii de software sau la o rundă de finanțare, auditul de conformare open source este standard. Componente copyleft nedeclarate, atribuiri lipsă sau licențe incompatibile pot reduce evaluarea, pot bloca tranzacția sau pot genera obligații de remediere post-tranzacție. Ține „casa în ordine" (SBOM actualizat, politici interne clare) din timp.

Politică internă de utilizare a open source

Firmele mature adoptă o politică OSS: o listă de licențe permise (de obicei permisive), necesitând-aprobare (copyleft slab) și interzise/atent evaluate (AGPL în produse proprietare), plus un proces de aprobare pentru dependențe noi. Aceasta transformă conformarea dintr-o verificare de ultim moment într-un control continuu.

Noua dimensiune: Cyber Resilience Act (CRA)

Regulamentul (UE) 2024/2847 (CRA) — în vigoare din 11.12.2024, cu aplicare integrală de la 11.12.2027 (raportarea vulnerabilităților de la 11.09.2026) — impune cerințe de securitate cibernetică produselor cu elemente digitale introduse pe piața UE. Pentru open source, CRA introduce o categorie nouă și un regim mai ușor:

• Contribuitorii individuali și dezvoltarea open source pur necomercială rămân, în principiu, în afara obligațiilor de producător.
• „Administratorul de software open source" (open-source software steward) — o entitate juridică ce susține în mod sistematic proiecte FOSS fără a le monetiza direct — are obligații mai reduse (art. 24): o politică de securitate cibernetică documentată, cooperarea cu autoritățile de supraveghere a pieței și cooperarea la raportarea/remedierea vulnerabilităților.
• Dacă monetizezi open source (suport plătit, SaaS, produs comercial construit pe el), se pot aplica obligațiile complete de producător pentru latura comercială.

⚠️ CRA este o reglementare nouă, iar ghidurile de aplicare ale Comisiei Europene sunt încă în curs de finalizare (primele proiecte din 2026). Concluziile privind încadrarea (steward vs. producător) ar trebui reevaluate după publicarea ghidurilor finale.

Sursa: Regulamentul (UE) 2024/2847 (CRA) (accesat 2026-08-07)

Răspunderea pentru produse și AI Act (dincolo de CRA)

Pe lângă CRA, două reglementări recente completează harta riscurilor:

• Noua Directivă privind răspunderea pentru produse defecte — Directiva (UE) 2024/2853 (PLD) include expres software-ul în noțiunea de „produs". Art. 2 exceptează însă software-ul liber și open source dezvoltat sau furnizat în afara unei activități comerciale. Termen de transpunere: 9 decembrie 2026 (până atunci, în România se aplică Legea nr. 240/2004). Concluzie: un dezvoltator OSS necomercial are expunere redusă; cel care monetizează (produs, suport plătit, SaaS) intră în regimul de răspundere.
• AI Act — Regulamentul (UE) 2024/1689, art. 2 alin. (12) exceptează sistemele și modelele AI oferite sub licențe libere și open source — cu excepția celor interzise, a celor high-risk și a modelelor GPAI cu risc sistemic, care rămân reglementate. Exceptarea „open source" din AI Act nu suprapune exact regimul „steward" din CRA: un model AI open source poate fi scutit de o parte din obligațiile AI Act, dar componenta software rămâne sub CRA dacă e introdusă pe piață ca produs cu elemente digitale.

Surse: Directiva (UE) 2024/2853 (PLD), art. 2 · Regulamentul (UE) 2024/1689 (AI Act), art. 2 (accesat 2026-08-08)

Componenta administrativă în România (RNPC/ORDA)

Pentru producătorii de software care comercializează în România există și Registrul Național al Programelor pentru Calculator (RNPC), administrat de ORDA (Oficiul Român pentru Drepturile de Autor), în temeiul OG nr. 25/2006 privind întărirea capacității administrative a ORDA (art. 2). Nu este o condiție de existență a dreptului de autor (protecția e automată), dar înscrierea poate servi ca probă și este relevantă pentru comercianții specializați.

Sursa: OG nr. 25/2006 (republicată), Art. 2 — cadrul RNPC (accesat 2026-08-07)

Mărci: ce NU acordă licența (numele și sigla proiectului)

Licențele open source acordă drepturi de autor și, uneori, de brevet, dar exclud de regulă expres mărcile. De exemplu, Apache 2.0, secțiunea 6 nu acordă niciun drept asupra denumirii, siglelor sau mărcilor licențiatorului. Consecințe practice:

• Poți folosi codul, dar nu poți folosi liber numele și logo-ul proiectului pentru a-ți promova produsul derivat. Un fork trebuie, de regulă, să se re-branduiască.
• „Powered by X" / indicarea compatibilității sunt posibile doar în limitele utilizării nominative/descriptive loiale — art. 14 din Regulamentul (UE) 2017/1001 (marca UE) și Legea nr. 84/1998 (mărci naționale) limitează efectele mărcii, dar cer respectarea practicilor comerciale loiale (fără a sugera o afiliere/aprobare inexistentă).

Surse: Apache 2.0, secț. 6 · Reg. (UE) 2017/1001, art. 14 (accesat 2026-08-08)

Componente open source în produse pentru consumatori (B2C)

Clauza standard „as is" / fără garanție (disclaimer of warranty) din MIT/GPL/Apache nu este opozabilă consumatorului final în România. Ea leagă integratorul-licențiat față de autorul componentei, dar nu se propagă la consumator:

• Legea nr. 193/2000 (clauze abuzive) prezumă abuzivă o clauză care exclude/limitează răspunderea legală față de consumator.
• OUG nr. 140/2021 (transpune Dir. (UE) 2019/771) instituie garanția legală de conformitate: vânzătorul/comerciantul răspunde față de consumator și nu poate opune „as is"-ul din amonte.
• Suplimentar, CRA și noua PLD adaugă obligații de securitate și un regim de răspundere pentru produse.

Cine răspunde? Comerciantul care încorporează componente open source într-un produs livrat consumatorului rămâne răspunzător față de acesta (conformitate, siguranță, produse defecte), indiferent că a folosit componente „gratuite, fără garanție".

Surse: Legea nr. 193/2000 · OUG nr. 140/2021 (garanția de conformitate) (accesat 2026-08-08)

Litigii cu element de extraneitate: ce lege, ce instanță

Multe licențe (MIT, GPL) nu conțin clauză de lege aplicabilă sau de for. În fața instanțelor din România regulile UE tranșează totuși problema:

• Legea aplicabilă: fiindcă CJUE C-666/18 califică încălcarea licenței ca încălcare a dreptului de autor, se aplică Roma II (Reg. 864/2007), art. 8 — legea țării pentru care se solicită protecția (lex loci protectionis): pentru o utilizare în România, legea română. Pe latura pur contractuală, Roma I (Reg. 593/2008) stabilește legea în lipsa alegerii.
• Instanța competentă: Bruxelles I bis (Reg. 1215/2012) — pârâtul poate fi acționat la domiciliul său (art. 4) sau, în materie delictuală, la locul faptei prejudiciabile (art. 7 pct. 2). Un utilizator din România poate fi deci acționat în România.
• Enforcement în practică: un titular străin — ori un colectiv de contribuitori — poate pune în executare licența în România. Provocarea reală nu e competența, ci calitatea procesuală (dovada titularității asupra porțiunilor de cod) și coordonarea între mulți contribuitori; de aici rolul CLA/agregatorilor de drepturi (ex. FSF) care centralizează dreptul de a acționa.

Surse: Roma II (Reg. 864/2007), art. 8 · Bruxelles I bis (Reg. 1215/2012), art. 7 (accesat 2026-08-08)

Întrebări frecvente

Pot folosi gratuit software open source într-un produs comercial? Da, dar depinde de licență. Cele permisive (MIT, BSD, Apache 2.0) permit includerea chiar și în produse comerciale proprietare, cu condiția să păstrezi atribuirea (și, la Apache, fișierul NOTICE). Cele copyleft tare (GPL, AGPL) obligă distribuirea întregului produs derivat sub aceeași licență, cu codul sursă — ceea ce e incompatibil cu un model proprietar închis.

Dacă modific 10% dintr-un program GPL, trebuie să public tot codul meu? Da, dacă distribui programul modificat: orice operă derivată dintr-un cod GPL trebuie oferită tot sub GPL, cu sursa corespunzătoare. Dacă îl folosești doar intern, fără distribuire, nu ești obligat să publici (excepție: AGPL, care extinde obligația și la utilizarea ca SaaS).

Ce se întâmplă dacă nu păstrez nota de copyright dintr-o licență MIT? Încalci singura condiție a licenței. Fără respectarea condiției, autorizația de utilizare cade, iar folosirea codului devine o încălcare a dreptului de autor (contrafacere), nu o simplă neexecutare contractuală (CJUE, C-666/18).

Care e diferența dintre MIT și Apache 2.0 dacă ambele sunt permisive? Apache 2.0 adaugă un grant expres de brevet (și o clauză care îți retrage acest grant dacă inițiezi un litigiu de brevet), obligația de a păstra fișierul NOTICE și de a marca modificările. MIT nu conține clauze de brevet, ceea ce lasă un risc suplimentar în proiectele cu miză de brevete.

Ce înseamnă că o licență este „virală"? Este eticheta informală pentru copyleft: obligația ca operele derivate distribuite să poarte aceeași licență și să vină cu codul sursă. „Contaminarea" apare doar la crearea unei opere derivate și la distribuire — nu la simpla utilizare alăturată a unor programe independente.

Pot combina cod cu licențe diferite? Doar dacă sunt compatibile. Poți integra cod permisiv într-un proiect GPL, dar nu invers. Atenție la combinații incompatibile clasice, precum Apache 2.0 cu GPLv2 (Apache 2.0 e compatibil doar cu GPLv3).

Cum aleg licența pentru propriul proiect open source? Pentru adoptare maximă: MIT sau Apache 2.0; ca derivatele să rămână deschise: GPL v3; pentru a acoperi și SaaS: AGPL v3; pentru o bibliotecă folosită și în software proprietar: LGPL; instituție publică UE: EUPL 1.2.

Poate un angajat să publice sub MIT/GPL cod scris la serviciu? De regulă nu, fără acordul angajatorului. Conform art. 75 din Legea 8/1996, drepturile patrimoniale asupra programelor create de salariat în exercitarea atribuțiilor aparțin angajatorului, dacă nu există clauză contrară. O publicare neautorizată poate fi contrafacere; de aceea firmele folosesc politici interne, CLA și DCO.

Clauza „fără garanție" din licență mă protejează față de consumator? Nu. Disclaimer-ul „as is" leagă integratorul față de autorul componentei, dar nu este opozabil consumatorului. Comerciantul care livrează produsul răspunde față de consumator pe temeiul garanției legale de conformitate (OUG 140/2021) și al regulilor privind clauzele abuzive (Legea 193/2000).

Pot folosi numele și logo-ul unui proiect open source pentru produsul meu? Nu automat. Licențele (ex. Apache 2.0, secț. 6) nu acordă drepturi de marcă. Un fork trebuie de regulă redenumit; „powered by X" e permis doar în limitele utilizării nominative loiale (art. 14, Reg. UE 2017/1001; Legea 84/1998).

Ce lege și ce instanță se aplică dacă titularul e străin? Chiar fără clauză în licență: pentru încălcarea dreptului de autor se aplică legea română dacă utilizarea are loc în România (Roma II, art. 8), iar utilizatorul din România poate fi acționat în România (Bruxelles I bis, art. 4 și 7 pct. 2).

Practică și opinii

Nerespectarea licenței open source = încălcare a dreptului de autor (CJUE)

Cea mai importantă clarificare jurisprudențială pentru conformare vine de la Curtea de Justiție a UE.

⚠️ CJUE, cauza C-666/18, IT Development SAS c. Free Mobile SAS (Hotărârea din 18 decembrie 2019) — Un licențiat modificase codul sursă al unui software cu încălcarea clauzei contractuale care interzicea modificările. Curtea a decis că încălcarea unei clauze dintr-un contract de licență software referitoare la drepturile de proprietate intelectuală intră în sfera „încălcării drepturilor de proprietate intelectuală" în sensul Directivei 2004/48/CE (coroborată cu Directiva 2009/24/CE). Prin urmare, titularul beneficiază de garanțiile și mijloacele de reparație prevăzute de Directiva 2004/48 (încetarea încălcării, daune), indiferent de regimul de răspundere (contractual sau delictual) din dreptul național.

Sursa: CJUE, C-666/18 (accesat 2026-08-07)

De ce contează pentru open source: dacă folosești o componentă MIT fără atribuire, distribui un derivat GPL fără să oferi sursa, sau rulezi un serviciu pe cod AGPL fără a publica codul, nu ești doar „în neregulă contractual" — încalci dreptul de autor al titularului, cu toate consecințele mai grave care decurg (măsuri asigurătorii, daune, riscul unei acțiuni în contrafacere).

Enforcement-ul copyleft funcționează în instanță

Deși în România nu există (încă) jurisprudență publicată semnificativă pe încălcări ale GPL, licențele copyleft au fost aplicate cu succes în alte state membre — în special în Germania, prin acțiuni ale dezvoltatorilor (proiectul gpl-violations.org / Harald Welte), care au obținut măsuri împotriva unor producători de echipamente ce distribuiau firmware bazat pe cod GPL fără a oferi sursa. Aceste cazuri au confirmat că GPL este o licență validă și executabilă, iar titularii drepturilor au calitate procesuală activă.

Epuizarea dreptului și limitele revânzării

⚠️ CJUE, cauza C-128/11, UsedSoft GmbH c. Oracle (Hotărârea din 3 iulie 2012) — Dreptul de distribuție asupra unei copii de software se epuizează la prima vânzare, inclusiv pentru copii descărcate online, când licența este perpetuă; o astfel de copie „second-hand" poate fi revândută. În schimb, licențele pe abonament/SaaS sunt personale și, de regulă, netransferabile.

Sursa: CJUE, C-128/11 (accesat 2026-08-07)

Opinie de sinteză

⚠️ Notă de practică — Distincția esențială pentru orice firmă de software rămâne permisiv vs. copyleft. Riscul juridic real nu apare din utilizarea open source în sine, ci din necunoașterea licențelor din propriul produs: o singură componentă AGPL integrată neatent într-un serviciu comercial poate obliga la publicarea codului sau la reproiectare. Recomandarea constantă a practicienilor este identică cu logica de conformare din secțiunea Aspecte practice: inventar (SBOM) actualizat, politică internă de licențe și verificarea dependențelor înainte de integrare, nu la audit. Pentru situații concrete de integrare comercială, consultă un specialist în proprietate intelectuală.

Referințe

Legislație — România

1. Legea nr. 8/1996 privind dreptul de autor și drepturile conexe (republicată), Art. 7, 39-43, 42 (forma cesiunii), 73-78, 75 (program creat de salariat), 141 și urm. (drept sui-generis al fabricantului bazei de date) — protecția programelor, cesiunea/„licența", titularitatea și bazele de date. legislatie.just.ro
2. OG nr. 25/2006 (republicată) privind întărirea capacității administrative a ORDA, Art. 2 — Registrul Național al Programelor pentru Calculator (RNPC). legislatie.just.ro
3. Codul Civil (Legea nr. 287/2009), Art. 1186-1196 — formarea contractului (ofertă către persoane nedeterminate, acceptare prin executare), aplicabil licenței ca act juridic.
4. Legea nr. 193/2000 privind clauzele abuzive în contractele încheiate cu consumatorii. legislatie.just.ro
5. OUG nr. 140/2021 privind garanția legală de conformitate (transpune Dir. (UE) 2019/771).
6. Legea nr. 240/2004 privind răspunderea producătorilor pentru produsele cu defecte.
7. Legea nr. 84/1998 privind mărcile și indicațiile geografice (republicată).

Legislație — Uniunea Europeană

8. Directiva 2009/24/CE privind protecția juridică a programelor pentru calculator. eur-lex.europa.eu
9. Directiva 2004/48/CE privind respectarea drepturilor de proprietate intelectuală. eur-lex.europa.eu
10. Regulamentul (UE) 2024/2847 — Cyber Resilience Act, Art. 24 (administratorul de software open source). eur-lex.europa.eu
11. Directiva (UE) 2024/2853 privind răspunderea pentru produsele cu defecte (noua PLD; include software-ul), Art. 2. eur-lex.europa.eu
12. Regulamentul (UE) 2024/1689 (AI Act), Art. 2 alin. (12) — exceptarea sistemelor AI open source. eur-lex.europa.eu
13. Regulamentul (CE) 593/2008 (Roma I) și Regulamentul (CE) 864/2007 (Roma II), Art. 8 (lex loci protectionis) — legea aplicabilă. Roma II
14. Regulamentul (UE) 1215/2012 (Bruxelles I bis), Art. 4 și 7 pct. 2 — competența jurisdicțională. eur-lex.europa.eu
15. Regulamentul (UE) 2017/1001 privind marca Uniunii Europene, Art. 14 — limitarea efectelor mărcii. eur-lex.europa.eu

Jurisprudență CJUE

16. CJUE, C-666/18, IT Development SAS c. Free Mobile SAS (18.12.2019) — încălcarea licenței = încălcare a drepturilor de proprietate intelectuală. curia.europa.eu
17. CJUE, C-128/11, UsedSoft GmbH c. Oracle (03.07.2012) — epuizarea dreptului de distribuție și revânzarea licențelor perpetue. curia.europa.eu

Texte de licență și standarde (surse primare ale obligațiilor)

18. MIT License — opensource.org/license/mit
19. Apache License 2.0 (secț. 3 brevet, secț. 6 mărci) — apache.org/licenses/LICENSE-2.0
20. GNU GPL v3 (secț. 1, 6, 8) — gnu.org/licenses/gpl-3.0.html · GPL v2 (secț. 3) — gnu.org/licenses/old-licenses/gpl-2.0.html
21. GNU AGPL v3 — gnu.org/licenses/agpl-3.0.html
22. GNU LGPL v3 — gnu.org/licenses/lgpl-3.0.html
23. Open Source Definition (OSI) — opensource.org/osd
24. SPDX License List — spdx.org/licenses
25. EUPL 1.2 (European Union Public Licence) — eur-lex.europa.eu

Articole conexe

• Drepturile de autor și software (licențe, open source)
• Protecția mărcilor și a brevetelor