Licențe de software open source în conformitate cu legislația olandeză și a UE

Aproape fiecare produs software comercial conține componente open source, de obicei sute, alese de dezvoltatori mai degrabă decât de avocați. Aceasta devine o problemă atunci când nimeni nu poate spune ce licențe se aplică, ce necesită acestea și dacă produsul este conform. Acest articol explică cum funcționează licențele open source în conformitate cu legislația olandeză și a UE, unde se află riscul și ce trebuie să se ia în considerare.

Ce este o licență open source, din punct de vedere juridic

O licență open source este o licență de drepturi de autor acordată sub rezerva unor anumite condiții. Nu este o renunțare, o dedicare domeniului public, o abandonare a drepturilor și, în acest sens, funcționează ca orice altă licență software conform legislației olandeze . Autorul își păstrează drepturile de autor în temeiul art. 1 Aw și art. 10 Aw, care protejează programele de calculator ca opere, iar licența permite acte care altfel ar încălca drepturile exclusive în temeiul art. 12 Aw și art. 13 Aw.

Consecința contează mai mult decât definiția. Dacă respectați licența, copierea și distribuirea acesteia sunt legale. Dacă nu respectați licența, permisiunea nu acoperă ceea ce ați făcut: utilizarea dumneavoastră reprezintă o încălcare a drepturilor de autor, nu o încălcare a contractului. Majoritatea licențelor copyleft întăresc acest lucru prin încetarea automată a încălcării - GPLv2 fără nicio perioadă de remediere, în timp ce GPLv3 și AGPLv3 restabilesc drepturile dacă încălcarea este remediată într-un interval de timp definit după notificare.

Instanțele olandeze aplică acest raționament. În Rb. Amsterdam 22 septembrie 2020, ECLI:NL:RBAMS:2020:4717, s-a considerat că un distribuitor care a eliminat textul licenței și notificarea privind drepturile de autor dintr-o bază de cod bifurcată și-a pierdut permisiunea și încălca drepturile de autor. Adăugarea unui volum mare de cod nou nu a creat o lucrare independentă: originalul a rămas prezent în mod recognoscibil, astfel încât obligațiile au călătorit odată cu acesta.

Cele două familii: permisivă și copyleft

Licențele permisive — MIT, licențele BSD, Apache 2.0 — permit utilizarea, modificarea și redistribuirea, inclusiv în cadrul produselor cu sursă închisă, cu condiția să păstrați notificările privind drepturile de autor și textul licenței.

Licențele cu drepturi de autor impun ca, atunci când distribuiți software-ul sau ceva construit pe baza acestuia, să faceți acest lucru sub aceeași licență și să puneți la dispoziție sursa corespunzătoare. Acestea diferă în ceea ce privește acoperirea.

Declanșatorul copyleft și întrebarea de linkare

Obligațiile de copyright afectează distribuția, nu utilizarea. O companie care rulează intern software GPL, oricât de mult modificat ar fi, nu distribuie nimic și nu datorează nimic. „Am distribuit?” este întotdeauna prima întrebare și de aceea containerele, dispozitivele, firmware-ul și SDK-urile contează mai mult decât instrumentele interne.

A doua întrebare este mai dificilă. GPL vorbește despre o „lucrare bazată pe Program”, împrumutând conceptul american de lucrare derivată. Legea olandeză nu are un astfel de termen: analiza trece prin drepturile de reproducere și adaptare, întrebând dacă a fost reprodusă expresia protejată din original.

Cazul practic este crearea de linkuri. Dacă prin conectarea unui modul proprietar la o bibliotecă GPL se creează o singură lucrare supusă dreptului de autor (copyleft) nu a fost niciodată decisă de o instanță olandeză și nu există o autoritate UE obligatorie. Opinia Free Software Foundation, conform căreia linkurile creează o lucrare combinată, este interpretarea administratorului licenței, nu legea, iar punctul de vedere opus este la fel de netestat. Răspunsul preferat al internetului - linkurile dinamice sunt sigure, linkurile statice nu - nu are bază în legislația olandeză privind drepturile de autor, care nu întreabă cum se comportă un compilator. O analiză mai justificabilă întreabă cât de intim sunt combinate componentele: dacă partajează un spațiu de adrese și structuri de date, dacă combinația este livrată ca un singur produs, dacă ar putea funcționa singură, dacă partea proprietară reproduce antete, macrocomenzi sau cod inline din partea copyleft? Aceste întrebări rezolvă de obicei riscul. În cazul în care nu se întâmplă acest lucru, izolați componenta în spatele unei limite de proces, înlocuiți-o sau obțineți o licență comercială.

AGPL și utilizarea rețelei

AGPL există deoarece copyleft-ul este declanșat de distribuție, iar furnizorii SaaS nu distribuie. Clauza sa de rețea impune ca, dacă modificați software-ul și îl puneți la dispoziția utilizatorilor care interacționează cu acesta de la distanță, să le oferiți sursa corespunzătoare a versiunii modificate.

Trei aspecte sunt frecvent omise. Obligația revine utilizatorilor serviciului, ceea ce într-un produs cu înscriere deschisă nu este deloc reconfortant. Este declanșată de modificare, deci o componentă nemodificată nu o activează, dar o versiune modificată poate. Și ridică aceeași întrebare legată de munca combinată ca și GPL pentru restul stivei - motiv pentru care multe companii interzic AGPL în codul de producție.

Compatibilitatea licenței

Compatibilitatea este problema combinării componentelor ale căror licențe impun obligații ce nu pot fi îndeplinite ambele într-o singură distribuție: licențele permisive sunt compatibile cu aproape orice, licențele copyleft doar cu ceea ce permit propriii lor termeni. Cazul standard este Apache 2.0 și GPLv2. Apache Software Foundation și Free Software Foundation sunt de acord că această combinare nu este permisă, deoarece prevederile de reziliere a brevetelor și de despăgubire ale Apache 2.0 sunt restricții suplimentare pe care GPLv2 nu le permite. GPLv3 a fost elaborat pentru a le accepta. Compatibilitatea este, de asemenea, direcțională: codul Apache poate fi absorbit într-un proiect GPLv3, dar nu invers. O componentă GPL în locul greșit poate forța o alegere între relicențiere, reproiectare sau eliminare - mult mai ieftin înainte de lansare decât după.

Obligații de atribuire și notificare

Cele mai frecvente încălcări ale obligațiilor sunt cele mai puțin dramatice: reproducerea notificărilor privind drepturile de autor, a textelor de licență, a declinarilor de responsabilitate și, în cadrul Apache 2.0, a conținutului NOTICE din materialele care însoțesc distribuția. Fiecare familie de licențe le impune, inclusiv MIT și BSD. Acestea sunt încălcate deoarece nimeni nu le deține și sunt cel mai ușor de remediat - de obicei, un fișier de atribuire generat, livrat împreună cu produsul. Cazul olandez de mai sus s-a bazat exact pe această defecțiune.

Acordarea de brevete și represaliile privind brevetele

MIT și BSD nu spun nimic despre brevete, iar dacă o licență de brevet poate fi implicită este încă neclar. Apache 2.0 a adăugat o licență de brevet expresă, fără redevențe, de la fiecare contribuitor, împreună cu o clauză de represalii: dacă se inițiază un litigiu privind brevetele, susținând că lucrarea încalcă drepturile de autor, licența de brevet încetează. GPLv3 conține o subvenție comparabilă și propriile prevederi privind brevetele.

Două implicații pentru companiile cu portofolii de brevete. Dacă inginerii dumneavoastră contribuie la proiecte licențiate Apache sau GPLv3, acordați licențe în baza propriilor brevete. Și dacă revendicați vreodată brevete împotriva unei companii care se bazează pe aceleași componente licențiate Apache pe care le utilizați, represaliile vă pot costa licența pe care vă bazați.

EUPL și sectorul public olandez

Licența Publică a Uniunii Europene versiunea 1.2, aprobată de Comisia Europeană prin decizia de punere în aplicare din mai 2017, este o licență copyleft aprobată de OSI, cu trei caracteristici distinctive.

• Limba. Există în limbile oficiale ale UE, toate versiunile aprobate având aceeași valoare, astfel încât o autoritate olandeză poate încheia contracte în limba olandeză.
• Compatibilitate. O anexă enumeră licențele compatibile — GPLv2 și v3, AGPLv3, LGPL, MPL 2, EPL 1.0, OSL și CeCILL printre acestea — și permite distribuirea sub licența respectivă a unei lucrări derivate care combină codul EUPL cu codul dintr-o licență listată.
• A ajunge. Definiția sa a distribuției acoperă punerea la dispoziție a operei online sau offline. sau oferind acces la funcționalitățile sale esențiale... și articolul 5 din EUPL extinde obligația de copyright la interacțiunea la distanță în care este oferită aceeași funcționalitate. Prin urmare, aceasta se aplică software-ului furnizat ca serviciu, într-un mod în care GPL nu o face.

Un client din sectorul public olandez poate solicita licența EUPL ca o chestiune de politică, mai degrabă decât de statut. Legea privind interoperabilitatea europeană, Regulamentul (UE) 2024/903, îndrumă organismele din sectorul public să acorde prioritate soluțiilor de interoperabilitate fără termeni de licențiere restrictivi, cum ar fi open source, acolo unde este echivalent; la nivel național, principiul open source, tenzij, se bazează pe decizii și linii de politică ale cabinetului, nu pe statut: Wet digitale overheid facilitează infrastructura de identitate digitală, dar nu impune nicio obligație executorie de a publica întregul cod sursă. Citiți documentele de licitație: o cerință EUPL vă obligă la livrare și poate fi incompatibilă cu codul proprietar pe care intenționați să îl reutilizați.

Aplicarea legii în practică

Cine poate da în judecată. Titularul drepturilor - contribuitorii individuali sau fundația sau compania care deține drepturile de autor cesionate. Autoratul fragmentat este frâna practică: un reclamant trebuie să dovedească dreptul de proprietate asupra codului în cauză. Aceasta a respins cel mai cunoscut caz european GPL, în care acțiunea unui dezvoltator de kernel împotriva unui furnizor de virtualizare a eșuat din lipsă de dovezi ale autorului (LG Hamburg 8 iulie 2016, 310 O 89/15; confirmată OLG Hamburg 28 februarie 2019, 5 U 146/16).

Ce stabilește jurisprudența. Instanțele germane au acceptat în repetate rânduri că licențele open source sunt valabile și că încălcarea acestora face distribuirea ilegală, începând cu prima ordonanță GPL (LG München I 19 mai 2004, 21 O 6123/04). Tribunalul Federal de Circuit al SUA a ajuns la aceeași concluzie în cauza Jacobsen v Katzer , 535 F.3d 1373 (Fed. Cir. 2008): termenii licenței sunt condiții privind domeniul de aplicare al acordării, nu simple angajamente, astfel încât încălcarea susține o acțiune în drepturi de autor și o măsură de despăgubire. Litigiile din SUA explorează dacă un beneficiar din aval poate aplica GPL în calitate de beneficiar terț. Aceasta este întrebarea centrală în cauza Software Freedom Conservancy v Vizio, în fața Curții Superioare din California: dacă consumatorii, în calitate de beneficiari terți, pot solicita eliberarea codului sursă în temeiul GPLv2. La 23 decembrie 2025, instanța a decis un punct privind adjudecarea sumară, hotărând că GPLv2 și LGPLv2.1 necesită o sursă care poate fi obținută și prelucrată pentru utilizare în altă parte, mai degrabă decât o sursă care poate fi reinstalată pe dispozitiv cu funcționalitatea sa intactă. Chestiunea beneficiarului terț în sine a fost lăsată pentru procesul de judecată, care a fost amânat de mai multe ori. În orice caz, este o chestiune de drept contractual californian, deci nu are nicio forță obligatorie în Olanda; ceea ce ar schimba este numărul de persoane care pot depune o plângere.

Cum ar aborda o instanță olandeză această problemă. Ca încălcare a drepturilor de autor în temeiul Auteurswet: reclamantul dovedește dreptul de proprietate și reproducerea sau comunicarea; pârâtul invocă licența; reclamantul răspunde că nu au fost îndeplinite condițiile acesteia, astfel încât apărarea eșuează. Căile de atac contractuale în temeiul art. 6:265 BW funcționează în paralel, dar drepturile de autor reprezintă calea cea mai puternică.

Căi de atac. O ordonanță judecătorească în temeiul art. 3:296 BW, de obicei cu o penalitate și disponibilă în cadrul procedurilor sumare; daune-intervenție în temeiul art. 27 Aw și o evidență a profiturilor în temeiul art. 27a Aw; rechemare, predare sau distrugere în temeiul art. 28 Aw; și recuperarea integrală a cheltuielilor de judecată rezonabile și proporționale în temeiul art. 1019h Rv. În cazul în care software-ul a fost distribuit gratuit, pierderea este greu de cuantificat, iar o instanță de apel germană a refuzat să acorde daune, menținând în același timp ordonanța judecătorească (OLG Hamm 13 iunie 2017, 4 U 72/16). Ceea ce afectează rareori sunt daunele: este ordonanța judecătorească, rechemarea, hotărârea privind cheltuielile de judecată și obligația de a publica sursa pe care nu ați intenționat niciodată să o publicați.

Când descoperiți o problemă de conformitate

Descoperirea vine de obicei dintr-un chestionar de securitate al unui client, o scanare în timpul due diligence sau o scrisoare de la un deținător de drepturi. Remedierea se desfășoară apoi după cum urmează. Opriți distribuirea versiunii afectate dacă expunerea este gravă. Stabiliți ce componentă, ce versiune, ce licență, ce produse și versiuni, pe ce perioadă. Determinați ce necesită de fapt licența - adesea un fișier de atribuire mai degrabă decât o versiune a sursei. Pregătiți artefactele: notificări, texte de licență, sursa completă corespunzătoare, inclusiv scripturile de versiune și o ofertă scrisă, acolo unde este utilizată. Expediați o versiune conformă, apoi spuneți deținătorului de drepturi ce ați făcut, în loc să vă certați dacă a trebuit.

Conform GPLv3 și AGPLv3, fereastra de remediere oferă valoare juridică pentru viteză; conform GPLv2 nu există un drept de remediere, motiv pentru care majoritatea aplicării se încheie cu un angajament de conformitate negociat. Rețineți, de asemenea, că privilegiul se aplică sfatului avocatului dumneavoastră, nu unui raport intern de inginerie.

Open source în fuziuni și achiziții și due diligence

Într-o achiziție de software, open source-ul este un flux standard de lucru în ceea ce privește diligența, iar o componentă copyleft nedivulgată în produsul principal este una dintre puținele descoperiri care influențează cu adevărat o tranzacție: dacă produsul nu poate fi distribuit fără a-și publica sursa, cumpărătorul achiziționează un activ diferit de cel stabilit ca preț.

Așteptați-vă la o scanare a bazei de cod, un inventar al componentelor cu licențe și întrebări despre aranjamentele dintre contribuitori și contractori. Rezultatele tipice sunt o despăgubire specifică, o retenție în așteptarea remedierii, o condiție precedentă care necesită eliminarea sau o garanție open source personalizată. Vânzătorii ar trebui să analizeze mai întâi: constatările pe care le dezvăluiți sunt o negociere, constatările pe care le face consilierul cumpărătorului sunt un punct de sprijin. Cumpărătorii nu ar trebui să caute „compania deține proprietatea intelectuală”, ci o declarație că niciun produs nu încorporează open source care să necesite dezvăluirea codului sursă proprietar.

Lista de materiale, scanarea și Legea privind reziliența cibernetică

O listă de materiale software este un inventar al componentelor unui produs, cu versiuni și licențe. Până de curând, fiind pur contractuală, acum este și reglementată.

Legea privind reziliența cibernetică, Regulamentul (UE) 2024/2847, a intrat în vigoare la 10 decembrie 2024 și este introdusă treptat. Aceasta se adaugă Legii olandeze privind securitatea cibernetică , care se adresează organizației și nu produsului. Obligațiile de raportare pentru vulnerabilitățile exploatate activ și incidentele grave din art. 14 CRA se aplică de la 11 septembrie 2026; prevederile privind notificarea organismelor de evaluare a conformității de la 11 iunie 2026; regulamentul în integralitate de la 11 decembrie 2027 (art. 71 CRA). Anexa I la CRA impune producătorilor să identifice și să documenteze componentele produsului, inclusiv prin întocmirea unei liste de materiale software într-un format utilizat în mod obișnuit și lizibil de către mașină, care să acopere cel puțin dependențele de nivel superior. Nu este necesar să fie publicată; autoritățile de supraveghere a pieței o pot solicita.

Software-ul liber și open source furnizat în afara unei activități comerciale nu intră sub incidența ARC. Regulamentul introduce administratorul software-ului open source - o persoană juridică care oferă sprijin susținut dezvoltării de software open source destinat activităților comerciale - cu obligații mai puțin stricte în art. 24 ARC: o politică de securitate cibernetică documentată, cooperarea cu autoritățile de supraveghere a pieței și raportarea. Dacă comercializați software open source sau finanțați un proiect pe care alții îl comercializează, stabiliți ce rol ocupați. Comisia a adoptat primele sale orientări la 27 iulie 2026: orientările Comisiei privind aplicarea Legii privind reziliența cibernetică (ARC), anexate la comunicarea C(2026) 5252, care abordează, printre altele, situațiile în care software-ul liber și open source intră sub incidența domeniului de aplicare. Nu a fost adoptat niciun act de punere în aplicare care să prescrie un format pentru lista de materiale a software-ului, astfel încât standardul propriu al Regulamentului - un format utilizat în mod obișnuit, care poate fi citit automat - rămâne măsura deocamdată.

Analiza compoziției software-ului executată în CI generează inventarul care deservește simultan conformitatea, revizuirea licenței și diligența. Astfel de instrumente ratează codul furnizorului, identifică greșit proiectele cu licență dublă și nu pot citi condițiile unei licențe: tratează rezultatul ca începutul revizuirii, nu ca fiind revizuirea.

Dacă vă publicați propriul cod: CLA-uri și DCO

O companie care publică cod și acceptă contribuții externe trebuie să știe că are drepturile asupra a ceea ce îmbină. Un acord de licență pentru contribuitori este un contract între proiect și contribuitor, care acordă de obicei o licență extinsă pentru drepturi de autor și o licență expresă pentru brevete, cu garanții privind originalitatea și autoritatea. Este ceea ce permite unei companii să își relicențieze ulterior proiectul sau să ofere licențe comerciale alături de una open source. Costul său este reprezentat de fricțiuni.

Certificatul de origine al dezvoltatorului , utilizat de kernelul Linux și de multe alte proiecte, nu este o licență acordată, ci o atestare ușoară, adăugată ca linie de semnare la fiecare commit, care atestă că contribuitorul poate trimite codul sub licența proiectului. Mai puțin împovărător și mai puțin protector: fără licență de brevet, fără re-licențiere.

Dacă licențierea duală sau o licențiere suplimentară viitoare este plauzibilă, utilizați un CLA; dacă proiectul este un bun comun autentic, DCO este de obicei suficient. În orice caz, asigurați-vă că acordurile de angajare și contractuale cesionează drepturile de autor asupra codului scris de angajații dumneavoastră.

O listă de verificare practică a politicilor

• Generați un inventar de componente per produs și lansați-l în fluxul de producție, nu manual.
• Publicați o politică internă: o listă de permise, o listă de interzise și o cale de aprobare pentru orice altceva.
• Definiți în scris ce se consideră distribuție - instalări locale, dispozitive, containere, SDK-uri, aplicații mobile, firmware.
• Trimiteți un fișier de atribuire generat împreună cu fiecare produs.
• Aprobați opțiunile de licență în momentul proiectării, atunci când o componentă este selectată, nu la lansare.
• Decideți dacă contribuțiile la proiecte externe necesită aprobare, având în vedere acordarea de brevete implicate, și alegeți un CLA sau un DCO înainte de prima contribuție externă.
• Aliniați garanțiile, despăgubirile și termenii de escrow privind proprietatea intelectuală cu sursa deschisă existentă efectiv în produs.
• Efectuați revizuirea înainte de un proces de strângere de fonduri sau de vânzare, nu în timpul unuia.

Law & More oferă consultanță companiilor de software și investitorilor acestora Eindhoven și Amsterdam privind conformitatea cu reglementările open source, revizuirea licenței, acordurile cu contribuitorii și fluxul de lucru open source într-o tranzacție.