Licencat e softuerit me burim të hapur sipas ligjit holandez dhe të BE-së

Pothuajse çdo produkt softuerik komercial përmban komponentë me burim të hapur, zakonisht qindra, të zgjedhur nga zhvilluesit dhe jo nga avokatët. Kjo bëhet problem kur askush nuk mund të thotë se cilat licenca zbatohen, çfarë kërkojnë ato dhe nëse produkti është në përputhje me ligjin holandez dhe të BE-së, ku qëndron rreziku dhe çfarë duhet të keni parasysh.

Çfarë është një licencë me burim të hapur, në terma ligjorë

Një licencë me burim të hapur është një licencë e të drejtave të autorit që jepet me kushte. Nuk është heqje dorë, nuk është një përkushtim ndaj domenit publik, nuk është një braktisje e të drejtave, dhe në këtë drejtim funksionon si çdo licencë tjetër softueri sipas ligjit holandez . Autori ruan të drejtat e autorit sipas nenit 1 Aw dhe nenit 10 Aw, i cili mbron programet kompjuterike si vepra, dhe licenca lejon veprime që përndryshe do të shkelnin të drejtat ekskluzive sipas nenit 12 Aw dhe nenit 13 Aw.

Pasoja ka më shumë rëndësi sesa përkufizimi. Nëse e zbatoni, kopjimi dhe shpërndarja juaj janë të ligjshme. Nëse nuk e zbatoni, leja nuk mbulon atë që keni bërë: përdorimi juaj është shkelje e të drejtave të autorit, jo shkelje e kontratës. Shumica e licencave të të drejtave të autorit e përforcojnë këtë duke përfunduar automatikisht në rast shkeljeje - GPLv2 pa ndonjë periudhë korrigjimi, ndërsa GPLv3 dhe AGPLv3 rivendosin të drejtat nëse shkelja korrigjohet brenda një afati të përcaktuar pas njoftimit.

Gjykatat holandeze e zbatojnë këtë arsyetim. Në Rb. Amsterdam Më 22 shtator 2020, ECLI:NL:RBAMS:2020:4717, një shpërndarës që hoqi tekstin e licencës dhe njoftimin e të drejtave të autorit nga një bazë kodi e degëzuar u shpall se kishte humbur lejen e tij dhe se po shkelte të drejtat e autorit. Shtimi i një vëllimi të madh kodi të ri nuk krijoi një vepër të pavarur: origjinali mbeti i pranishëm në mënyrë të dallueshme, kështu që detyrimet udhëtuan me të.

Dy familjet: lejuese dhe të drejta kopjimi

Licencat lejuese — MIT, licencat BSD, Apache 2.0 — lejojnë përdorimin, modifikimin dhe rishpërndarjen, duke përfshirë brenda produkteve me burim të mbyllur, me kusht që të ruani njoftimet e të drejtave të autorit dhe tekstin e licencës.

Licencat e të drejtave të autorit kërkojnë që kur shpërndani softuerin ose diçka të ndërtuar mbi të, ta bëni këtë sipas të njëjtës licencë dhe ta vini në dispozicion burimin përkatës. Ato ndryshojnë në shtrirje.

Aktivizuesi i të drejtës së kopjimit dhe pyetja për lidhjen

Detyrimet e të drejtës së autorit ndikojnë në shpërndarje, jo në përdorim. Një kompani që përdor softuer GPL në mënyrë të brendshme, sado të modifikuar që të jetë, nuk shpërndan asgjë dhe nuk ka asnjë detyrim. "A e kemi shpërndarë?" është gjithmonë pyetja e parë, dhe kjo është arsyeja pse kontejnerët, pajisjet, firmware-i dhe SDK-të kanë më shumë rëndësi sesa mjetet e brendshme.

Pyetja e dytë është më e vështirë. GPL flet për një “vepër të bazuar në Program”, duke huazuar konceptin amerikan të një vepre derivate. Ligji holandez nuk ka një term të tillë: analiza kalon nëpër të drejtat e riprodhimit dhe adaptimit, duke pyetur nëse shprehja e mbrojtur nga origjinali është riprodhuar.

Rasti praktik është lidhja. Nëse lidhja e një moduli pronësor me një bibliotekë GPL krijon një vepër që i nënshtrohet të drejtës së autorit, nuk është vendosur kurrë nga një gjykatë holandeze dhe nuk ka asnjë autoritet detyrues të BE-së. Pikëpamja e Fondacionit të Softuerit të Lirë se lidhja krijon një vepër të kombinuar është interpretimi i administratorit të licencës, jo ligji, dhe pikëpamja e kundërt është po aq e patestuar. Përgjigja e preferuar e internetit - lidhja dinamike e sigurt, lidhja statike jo - nuk ka bazë në ligjin holandez të të drejtave të autorit, i cili nuk pyet se si sillet një përpilues. Një analizë më e mbrojtshme pyet se sa ngushtë kombinohen komponentët: a ndajnë ata një hapësirë ​​adresash dhe struktura të dhënash, a dërgohet kombinimi si një produkt i vetëm, a mund të funksionojë vetëm, a riprodhon ana pronësore titujt, makrot ose kodin e brendshëm nga ana e të drejtës së autorit? Këto pyetje zakonisht zgjidhin rrezikun. Kur nuk e bëjnë, izoloni komponentin pas një kufiri procesi, zëvendësojeni atë ose merrni një licencë tregtare.

AGPL dhe përdorimi i rrjetit

AGPL ekziston sepse e drejta e të drejtave të autorit aktivizohet nga shpërndarja dhe ofruesit e SaaS nuk e shpërndajnë. Klauzola e saj e rrjetit kërkon që nëse e modifikoni softuerin dhe e bëni të disponueshëm për përdoruesit që bashkëveprojnë me të nga distanca, t'u ofroni atyre burimin përkatës të versionit tuaj të modifikuar.

Zakonisht nuk merren parasysh tre pika. Ky detyrim vlen për përdoruesit e shërbimit, gjë që në një produkt me regjistrim të hapur nuk është aspak ngushëllim. Ai aktivizohet nga modifikimi, kështu që një komponent i pamodifikuar nuk e angazhon atë, por një version i riparuar mund ta bëjë. Dhe ngre të njëjtën pyetje të punës së kombinuar si GPL për pjesën tjetër të paketës suaj - prandaj shumë kompani e ndalojnë AGPL-në në kodin e prodhimit.

Pajtueshmëria e licencës

Përputhshmëria është problemi i kombinimit të komponentëve, licencat e të cilëve vendosin detyrime që nuk mund të përmbushen të dyja në një shpërndarje: licencat lejuese janë të përputhshme me pothuajse gjithçka, licencat copyleft vetëm me atë që lejojnë kushtet e tyre. Rasti standard është Apache 2.0 dhe GPLv2. Apache Software Foundation dhe Free Software Foundation bien dakord që kombinimi nuk lejohet, sepse dispozitat e ndërprerjes së patentës dhe dëmshpërblimit të Apache 2.0 janë kufizime shtesë që GPLv2 nuk i lejon. GPLv3 u hartua për t'i pranuar ato. Përputhshmëria është gjithashtu drejtuese: Kodi Apache mund të përthithet në një projekt GPLv3, por jo e kundërta. Një komponent GPL në vendin e gabuar mund të detyrojë një zgjedhje midis rilicencimit, riinxhinierisë ose heqjes - shumë më lirë para publikimit sesa pas tij.

Atribuimi dhe detyrimet e njoftimit

Detyrimet që shkelen më shpesh janë më pak dramatiket: riprodhimi i njoftimeve të të drejtave të autorit, teksteve të licencave, mohimeve të përgjegjësisë dhe, sipas Apache 2.0, përmbajtjes NOTICE në materialet që shoqërojnë shpërndarjen. Çdo familje i imponon ato, përfshirë MIT dhe BSD. Ato shkelen sepse askush nuk i zotëron dhe janë më të lehta për t'u rregulluar - zakonisht një skedar atribuimi i gjeneruar i dërguar me produktin. Rasti holandez i mësipërm ndezi pikërisht këtë dështim.

Grantet e patentave dhe hakmarrja për patentat

MIT dhe BSD nuk thonë asgjë për patentat, dhe nëse një licencë patente mund të nënkuptohet është e paqartë. Apache 2.0 shtoi një licencë patente të shprehur, pa pagesë për të drejtat e autorit nga secili kontribues, të shoqëruar me një klauzolë hakmarrjeje: ngrini padi për patentën duke pretenduar se puna shkel të drejtat dhe licenca juaj e patentës përfundon. GPLv3 përmban një grant të krahasueshëm dhe dispozitat e veta për patentat.

Dy implikime për kompanitë me portofole patentash. Nëse inxhinierët tuaj kontribuojnë në projekte të licencuara nga Apache ose GPLv3, ju po jepni licenca sipas patentave tuaja. Dhe nëse ndonjëherë kërkoni patenta kundër një kompanie në varësi të të njëjtave komponentë të licencuar nga Apache që përdorni, hakmarrja mund t'ju kushtojë një licencë në të cilën mbështeteni.

EUPL dhe sektori publik holandez

Versioni 1.2 i Licencës Publike të Bashkimit Evropian, i miratuar nga Komisioni Evropian me vendim zbatues në maj 2017, është një licencë copyleft e miratuar nga OSI me tre karakteristika dalluese.

• Gjuhe. Ekziston në gjuhët zyrtare të BE-së, të gjitha versionet e miratuara kanë vlerë identike, kështu që një autoritet holandez mund të lidhë kontrata në holandisht.
• Përputhshmëria Një shtojcë liston licencat e përputhshme — midis tyre GPLv2 dhe v3, AGPLv3, LGPL, MPL 2, EPL 1.0, OSL dhe CeCILL — dhe lejon që një vepër derivate që kombinon kodin EUPL me kodin sipas një licence të listuar të shpërndahet sipas asaj licence.
• Arrij. Përkufizimi i tij i shpërndarjes mbulon bërjen e veprës të disponueshme në internet ose jashtë internetit. ose duke ofruar akses në funksionalitetet e tij thelbësore, dhe neni 5 i EUPL-së e mbart detyrimin për të drejtën e autorit deri në bashkëveprimin në distancë në të cilin ofrohet i njëjti funksionalitet. Prandaj, ai arrin në softuerin e ofruar si shërbim, në një mënyrë që GPL nuk e bën.

Një klient holandez i sektorit publik mund ta kërkojë EUPL-në si çështje politike dhe jo si statut. Akti i Evropës së Ndërveprueshme, Rregullorja (BE) 2024/903, i udhëzon organet e sektorit publik që t'i japin përparësi zgjidhjeve të ndërveprueshmërisë pa kushte kufizuese licencimi, siç është burimi i hapur, aty ku është ekuivalent; në nivel kombëtar, parimi i burimit të hapur, tenzij mbështetet në vendimet e kabinetit dhe linjat e politikave, jo në statut: mbivendosja dixhitale lehtëson infrastrukturën e identitetit dixhital, por nuk vendos asnjë detyrim të zbatueshëm për të publikuar të gjithë kodin burimor. Lexoni dokumentet e tenderit: një kërkesë EUPL lidhet me produktin tuaj të dorëzueshëm dhe mund të jetë e papajtueshme me kodin pronësor që keni ndërmend ta ripërdorni.

Zbatimi në praktikë

Kush mund të ngrejë padi. ​​Mbajtësi i të drejtave të autorit — kontribues individualë, ose fondacioni ose kompania që mban të drejtën e autorit të caktuar. Autorësia e fragmentuar është freni praktik: një paditës duhet të provojë pronësinë e kodit në fjalë. Kjo rrëzoi rastin më të njohur evropian të GPL, ku pretendimi i një zhvilluesi të kernelit kundër një shitësi të virtualizimit dështoi për shkak të mungesës së provave të autorësisë (LG Hamburg 8 korrik 2016, 310 O 89/15; mbështeti OLG Hamburg 28 shkurt 2019, 5 U 146/16).

Çfarë përcakton jurisprudenca. Gjykatat gjermane kanë pranuar vazhdimisht se licencat me burim të hapur janë të vlefshme dhe se shkelja e bën shpërndarjen të paligjshme, duke filluar me urdhrin e parë të GPL (LG München I 19 Maj 2004, 21 O 6123/04). Gjykata Federale e SHBA-së arriti në të njëjtin përfundim në Jacobsen kundër Katzer , 535 F.3d 1373 (Fed. Cir. 2008): kushtet e licencës janë kushte mbi fushëveprimin e grantit, jo thjesht marrëveshje, kështu që shkelja mbështet një pretendim për të drejtën e autorit dhe një urdhër urdhri. Litigimi në SHBA po shqyrton nëse një marrës i rrjedhës së poshtme mund të zbatojë GPL-në si përfitues i palës së tretë. Kjo është pyetja qendrore në çështjen Software Freedom Conservancy kundër Vizio para Gjykatës së Lartë të Kalifornisë: nëse konsumatorët, si përfitues të palëve të treta, mund të kërkojnë publikimin e kodit burimor sipas GPLv2. Më 23 dhjetor 2025, gjykata vendosi për një pikë mbi gjykimin e shkurtuar, duke mbajtur qëndrimin se GPLv2 dhe LGPLv2.1 kërkojnë burim që mund të merret dhe të ripërpunohet për përdorim diku tjetër, në vend të burimit që mund të riinstalohet në pajisje me funksionalitetin e tij të paprekur. Çështja e përfituesit të palës së tretë në vetvete u la për gjykimin me trup gjykues, i cili është shtyrë më shumë se një herë. Sidoqoftë, është një çështje e së drejtës kontraktuale të Kalifornisë, kështu që nuk detyrohet asgjë në Holandë; ajo që do të ndryshonte është numri i njerëzve që mund të ankohen.

Si do ta trajtonte një gjykatë holandeze. Si shkelje e të drejtës së autorit sipas Auteurswet: paditësi vërteton pronësinë dhe riprodhimin ose komunikimin; i padituri ngre çështjen e licencës; paditësi përgjigjet se kushtet e saj nuk janë përmbushur, kështu që mbrojtja dështon. Mjetet juridike kontraktuale sipas nenit 6:265 BW funksionojnë paralelisht, por e drejta e autorit është rruga më e fortë.

Mjete juridike. Një urdhër gjyqësor sipas nenit 3:296 BW, zakonisht me një gjobë pagese dhe i disponueshëm në procedura të shkurtra; dëmshpërblim sipas nenit 27 Aw dhe një llogari e fitimeve sipas nenit 27a Aw; tërheqje, dorëzim ose shkatërrim sipas nenit 28 Aw; dhe rikuperim i plotë i kostove ligjore të arsyeshme dhe proporcionale sipas nenit 1019h Rv. Kur softueri shpërndahej falas, humbja është e vështirë të përcaktohet sasiore, dhe një gjykatë apeli gjermane refuzoi të caktojë dëmshpërblim, ndërsa mbështeti urdhër-padinë (OLG Hamm 13 qershor 2017, 4 U 72/16). Ajo që kafshon rrallë është dëmshpërblimi: është urdhër-padia, tërheqja, urdhri i kostove dhe detyrimi për të publikuar burimin që nuk keni pasur kurrë ndërmend ta publikoni.

Kur zbuloni një problem me pajtueshmërinë

Zbulimi zakonisht vjen nga një pyetësor sigurie i klientit, një skanim gjatë verifikimit të duhur ose një letër nga një mbajtës i të drejtave të autorit. Më pas, korrigjimi kryhet si më poshtë. Ndërpritni shpërndarjen e versionit të prekur nëse ekspozimi është serioz. Përcaktoni se cilin komponent, cilin version, cilën licencë, cilat produkte dhe lëshime, gjatë cilës periudhë. Përcaktoni se çfarë kërkon në të vërtetë licenca - shpesh një skedar atribuimi në vend të një lëshimi burimor. Përgatitni artefaktet: njoftimet, tekstet e licencës, burimin e plotë përkatës duke përfshirë skriptet e ndërtimit dhe një ofertë me shkrim aty ku është përdorur. Dërgoni një lëshim në përputhje me rregullat, pastaj i tregoni mbajtësit të të drejtave të autorit se çfarë keni bërë në vend që të debatoni nëse ju është dashur ta bëni.

Sipas GPLv3 dhe AGPLv3, dritarja e korrigjimit i jep shpejtësisë vlerë ligjore; sipas GPLv2 nuk ka të drejtë korrigjimi, prandaj shumica e zbatimit përfundojnë me një angazhim të negociuar përputhshmërie. Vini re gjithashtu se privilegji i përket këshillave nga avokati juaj, jo një raporti të brendshëm inxhinierik.

Burimi i hapur në M&A dhe verifikimin e kujdesshëm

Në një blerje softuerësh, burimi i hapur është një rrjedhë pune standarde e kujdesit, dhe një komponent i pazbuluar i të drejtës së autorit në produktin kryesor është një nga gjetjet e pakta që vërtet e shtyn përpara një marrëveshje: nëse produkti nuk mund të shpërndahet pa publikuar burimin e tij, blerësi po blen një aset të ndryshëm nga ai i çmimit.

Prisni një skanim të bazës së kodit, një inventar të komponentëve me licenca dhe pyetje në lidhje me marrëveshjet e kontribuesve dhe kontraktorëve. Rezultatet tipike janë një dëmshpërblim specifik, një mbajtje në pritje të ndreqjes, një kusht paraprak që kërkon heqje ose një garanci e personalizuar me burim të hapur. Shitësit duhet të skanojnë së pari: gjetjet që zbuloni janë një negocim, gjetjet që bën këshilltari i blerësit janë ndikim. Blerësit nuk duhet të kërkojnë "kompania zotëron IP-në e saj", por një deklaratë se asnjë produkt nuk përfshin burim të hapur që kërkon zbulimin e kodit burimor të pronarit.

Lista e materialeve, skanimi dhe Akti i Rezistencës Kibernetike

Një listë materialesh e softuerit është një inventar i komponentëve të një produkti, me versione dhe licenca. Deri vonë, thjesht kontraktuale, tani është edhe rregullatore.

Akti i Rezistencës Kibernetike, Rregullorja (BE) 2024/2847, hyri në fuqi më 10 dhjetor 2024 dhe hyn gradualisht në fuqi. Ai qëndron së bashku me Aktin Holandez të Sigurisë Kibernetike , i cili trajton organizatën dhe jo produktin. Detyrimet e raportimit për dobësitë e shfrytëzuara në mënyrë aktive dhe incidentet e rënda në nenin 14 të CRA-së zbatohen nga 11 shtatori 2026; dispozitat mbi njoftimin e organeve të vlerësimit të konformitetit nga 11 qershori 2026; Rregullorja në tërësi nga 11 dhjetori 2027 (neni 71 i CRA-së). Shtojca I e CRA-së kërkon që prodhuesit të identifikojnë dhe dokumentojnë përbërësit në produkt, duke përfshirë hartimin e një liste materialesh të softuerit në një format të përdorur zakonisht dhe të lexueshëm nga makina, që mbulon të paktën varësitë e nivelit të lartë. Nuk ka nevojë të publikohet; autoritetet e mbikëqyrjes së tregut mund ta kërkojnë atë.

Softueri i lirë dhe me burim të hapur i ofruar jashtë një aktiviteti komercial bie jashtë CRA-së. Rregullorja prezanton administratorin e softuerit me burim të hapur - një person juridik që jep mbështetje të vazhdueshme për zhvillimin e softuerit me burim të hapur të destinuar për aktivitete komerciale - me detyrime më të lehta në nenin 24 CRA: një politikë e dokumentuar e sigurisë kibernetike, bashkëpunim me autoritetet e mbikëqyrjes së tregut dhe raportim. Nëse komercializoni burimin e hapur ose financoni një projekt që të tjerët komercializojnë, përcaktoni se cilin rol mbani. Komisioni miratoi udhëzimin e tij të parë më 27 korrik 2026: udhëzimin e Komisionit mbi zbatimin e Aktit të Rezistencës Kibernetike (CRA), të bashkangjitur në komunikimin C(2026) 5252, i cili trajton ndër të tjera kur softueri i lirë dhe me burim të hapur bie brenda fushëveprimit. Nuk është miratuar asnjë akt zbatues që përcakton një format për listën e materialeve të softuerit, kështu që standardi i vetë Rregullores - një format i përdorur zakonisht, i lexueshëm nga makina - mbetet masa për momentin.

Analiza e përbërjes së softuerit e ekzekutuar në CI gjeneron inventarin që shërben njëkohësisht për pajtueshmërinë, shqyrtimin e licencës dhe kujdesin. Mjete të tilla humbasin kodin e shitësit, identifikojnë gabimisht projektet me licencë të dyfishtë dhe nuk mund të lexojnë kushtet e një licence: trajtoni rezultatin si fillimin e shqyrtimit, jo shqyrtimin.

Nëse publikoni kodin tuaj: CLA-të dhe DCO-ja

Një kompani që publikon kod dhe pranon kontribute të jashtme duhet të dijë se ka të drejtat për atë që bashkon. Një marrëveshje licence kontribuesi është një kontratë midis projektit dhe kontribuesit, që zakonisht jep një licencë të gjerë të të drejtave të autorit dhe një licencë të shprehur patentë, me garanci për origjinalitetin dhe autoritetin. Është ajo që i lejon një kompanie të rilicencojë projektin e saj më vonë, ose të ofrojë licenca komerciale së bashku me një licencë me burim të hapur. Kostoja e saj është fërkimi.

Certifikata e Origjinës së Zhvilluesit , e përdorur nga kerneli i Linux-it dhe shumë projekte të tjera, nuk është një dhënie licence, por një vërtetim i lehtë, i shtuar si një rresht nënshkrimi për çdo angazhim, që kontribuesi mund ta paraqesë kodin sipas licencës së projektit. Më pak e rëndë dhe më pak mbrojtëse: pa licencë patente, pa rilicencim.

Nëse licencimi i dyfishtë ose një rilicencim në të ardhmen është i besueshëm, përdorni një CLA; nëse projekti është një pronë e mirëfilltë e përbashkët, DCO zakonisht është i mjaftueshëm. Sidoqoftë, sigurohuni që marrëveshjet tuaja të punësimit dhe të kontraktorit të caktojnë të drejtat e autorit në kodin që shkruajnë njerëzit tuaj.

Një listë kontrolli praktike për politikat e politikave. Një listë kontrolli praktike për politikat.

• Gjeneroni një inventar komponentësh për çdo produkt dhe publikojeni gjatë procesit të ndërtimit, jo manualisht.
• Publikoni një politikë të brendshme: një listë të lejuarash, një listë të ndaluarash dhe një rrugë miratimi për gjithçka tjetër.
• Përcaktoni me shkrim se çfarë llogaritet si shpërndarje — instalime në vend, pajisje, kontejnerë, SDK, aplikacione celularë, firmware.
• Dërgoni një skedar atribuimi të gjeneruar me çdo produkt.
• Miratoni zgjedhjet e licencës në kohën e projektimit, kur zgjidhet një komponent, jo në momentin e publikimit.
• Vendosni nëse kontributet në projekte të jashtme kanë nevojë për miratim, duke pasur parasysh grantet e patentave të përfshira, dhe zgjidhni një CLA ose një DCO para kontributit të parë të jashtëm.
• Përputhni garancitë, dëmshpërblimet dhe kushtet e garancisë së pronësisë intelektuale me burimin e hapur që është aktualisht në produkt.
• Kryeni shqyrtimin përpara një procesi mbledhjeje fondesh ose shitjeje, jo gjatë tij.

Law & More këshillon kompanitë e softuerëve dhe investitorët e tyre nga Eindhoven Amsterdam mbi pajtueshmërinë me kodin e hapur, shqyrtimin e licencës, marrëveshjet e kontribuesve dhe rrjedhën e punës me kodin e hapur në një transaksion.