Licencie na softvér s otvoreným zdrojovým kódom podľa holandského práva a práva EÚ

Takmer každý komerčný softvérový produkt obsahuje komponenty s otvoreným zdrojovým kódom, zvyčajne stovky, ktoré si vyberajú vývojári a nie právnici. To sa stáva problémom, keď nikto nevie povedať, ktoré licencie sa vzťahujú, čo vyžadujú a či produkt spĺňa požiadavky. Tento článok vysvetľuje, ako fungujú licencie s otvoreným zdrojovým kódom podľa holandského a európskeho práva, kde spočíva riziko a čo je potrebné mať zavedené.

Čo je licencia s otvoreným zdrojovým kódom z právneho hľadiska

Licencia s otvoreným zdrojovým kódom je licencia na autorské práva udelená za určitých podmienok. Nejde o zrieknutie sa práv, nie o venovanie sa verejnej doméne, ani o vzdanie sa práv, a v tomto ohľade funguje ako akákoľvek iná softvérová licencia podľa holandského práva . Autor si ponecháva autorské práva podľa článku 1 Aw a článku 10 Aw, ktoré chránia počítačové programy ako diela, a licencia povoľuje konanie, ktoré by inak porušovalo výlučné práva podľa článku 12 Aw a článku 13 Aw.

Dôsledok je dôležitejší ako definícia. Dodržte ho a vaše kopírovanie a distribúcia budú zákonné. Ak ho nedodržíte, povolenie sa nevzťahuje na to, čo ste urobili: vaše použitie je porušením autorských práv, nie porušením zmluvy. Väčšina licencií copyleft to posilňuje automatickým ukončením v prípade porušenia – GPLv2 bez akejkoľvek lehoty na nápravu, zatiaľ čo GPLv3 a AGPLv3 obnovujú práva, ak je porušenie odstránené v stanovenej lehote po oznámení.

Holandské súdy uplatňujú toto zdôvodnenie. V prípade Rb. Amsterdam 22. septembra 2020, ECLI:NL:RBAMS:2020:4717, distribútor, ktorý odstránil text licencie a oznámenie o autorských právach z rozvetvenej kódovej základne, bol uznaný za distribútora, ktorý stratil svoje povolenie a porušil autorské práva. Pridanie veľkého objemu nového kódu nevytvorilo nezávislé dielo: originál zostal rozpoznateľne prítomný, takže s ním prešli aj záväzky.

Dve rodiny: permisívna a copyleftová

Permisívne licencie – MIT, licencie BSD, Apache 2.0 – umožňujú používanie, úpravu a redistribúciu, a to aj v rámci produktov s uzavretým zdrojovým kódom, za predpokladu, že zachováte upozornenia na autorské práva a text licencie.

Copyleft licencie vyžadujú, aby ste pri distribúcii softvéru alebo niečoho, čo je na ňom postavené, robili tak pod rovnakou licenciou a sprístupnili zodpovedajúci zdrojový kód. Líšia sa dosahom.

Spúšťač copyleftu a otázka prepojenia

Povinnosti týkajúce sa copyleftu sa týkajú distribúcie, nie používania. Spoločnosť, ktorá interne prevádzkuje softvér s licenciou GPL, nech je akokoľvek silne upravený, nič nedistribuuje a nič nedlhuje. „Distribuovali sme?“ je vždy prvá otázka a preto sú kontajnery, zariadenia, firmvér a SDK dôležitejšie ako interné nástroje.

Druhá otázka je ťažšia. GPL hovorí o „diele založenom na programe“, čím si požičiava americký koncept odvodeného diela. Holandské právo takýto termín nemá: analýza sa zaoberá právami na reprodukciu a adaptáciu a pýta sa, či bol reprodukovaný chránený prejav z originálu.

Praktickým prípadom je prepojenie. Či prepojenie proprietárneho modulu s knižnicou GPL vytvára jedno dielo podliehajúce copyleftu, nikdy nerozhodol holandský súd a neexistuje žiadna záväzná autorita EÚ. Názor Nadácie pre voľný softvér, že prepojenie vytvára kombinované dielo, je interpretáciou správcu licencií, nie zákonom, a opačný názor je rovnako neoverený. Obľúbená odpoveď internetu – dynamické prepojenie je bezpečné, statické prepojenie nie – nemá základ v holandskom autorskom práve, ktoré sa nepýta, ako sa kompilátor správa. Obhájiteľnejšia analýza sa pýta, ako úzko sú komponenty kombinované: zdieľajú adresný priestor a dátové štruktúry, je kombinácia dodávaná ako jeden produkt, môže fungovať samostatne, reprodukuje proprietárna strana hlavičky, makrá alebo vložený kód zo strany copyleftu? Tieto otázky zvyčajne riešia riziko. Ak nie, izolujte komponent za hranicou procesu, nahraďte ho alebo získajte komerčnú licenciu.

AGPL a používanie siete

Licencia AGPL existuje preto, lebo copyleft sa aktivuje distribúciou a poskytovatelia SaaS nedistribuujú. Jej sieťová klauzula vyžaduje, aby ste v prípade úpravy softvéru a jeho sprístupnenia používateľom, ktorí s ním interagujú na diaľku, ponúkli zodpovedajúci zdrojový kód vašej upravenej verzie.

Často sa prehliadajú tri body. Povinnosť sa vzťahuje na používateľov služby, čo v produkte s otvorenou registráciou nie je veľkým komfortom. Spúšťa sa úpravou, takže nemodifikovaný komponent ju neaktivuje, ale opravená zostava áno. A vyvoláva rovnakú otázku kombinovanej práce ako GPL pre zvyšok vášho balíka – a preto mnoho spoločností zakazuje AGPL v produkčnom kóde.

Kompatibilita licencií

Kompatibilita je problém kombinovania komponentov, ktorých licencie ukladajú povinnosti, ktoré nie je možné splniť v jednej distribúcii: permisívne licencie sú kompatibilné takmer so všetkým, copyleft licencie iba s tým, čo umožňujú ich vlastné podmienky. Štandardným prípadom je Apache 2.0 a GPLv2. Nadácia Apache Software Foundation a Nadácia Free Software Foundation sa zhodujú, že kombinácia nie je povolená, pretože ustanovenia o ukončení patentu a odškodnení v Apache 2.0 sú dodatočnými obmedzeniami, ktoré GPLv2 neumožňuje. GPLv3 bola navrhnutá tak, aby ich akceptovala. Kompatibilita je tiež smerová: kód Apache je možné absorbovať do projektu GPLv3, ale nie naopak. Jeden komponent GPL na nesprávnom mieste môže vynútiť výber medzi opätovným udelením licencie, prepracovaním alebo odstránením – oveľa lacnejšie pred vydaním ako po ňom.

Povinnosti týkajúce sa uvedenia zdroja a oznámenia

Najčastejšie porušované povinnosti sú tie najmenej dramatické: reprodukcia oznámení o autorských právach, licenčných textov, vyhlásení o odmietnutí zodpovednosti a v rámci Apache 2.0 aj obsahu NOTICE v materiáloch priložených k distribúcii. Každá rodina ich ukladá, vrátane MIT a BSD. Porušujú sa, pretože ich nikto nevlastní a najľahšie sa dajú opraviť – zvyčajne sa s produktom dodáva vygenerovaný súbor s uvedením zdroja. Holandský prípad uvedený vyššie sa odvíja práve od tohto zlyhania.

Udeľovanie patentov a odvetné opatrenia za patenty

MIT a BSD sa nevyjadrujú k patentom a nie je jasné, či je možné implicitne počítať s patentovou licenciou. Apache 2.0 pridal výslovnú patentovú licenciu bez licenčných poplatkov od každého prispievateľa spolu s klauzulou o odvetných opatreniach: ak začnete súdny spor o patent, v ktorom tvrdíte, že dielo porušuje patent, vaša patentová licencia zanikne. GPLv3 obsahuje porovnateľné udelenie patentu a vlastné patentové ustanovenia.

Dva dôsledky pre spoločnosti s patentovými portfóliami. Ak vaši inžinieri prispievajú k projektom s licenciou Apache alebo GPLv3, udeľujete licencie na základe vlastných patentov. A ak niekedy uplatníte patenty voči spoločnosti, ktorá je závislá od rovnakých komponentov s licenciou Apache, ktoré používate, odvetné opatrenia vás môžu stáť licenciu, na ktorú sa spoliehate.

EUPL a holandský verejný sektor

Verejná licencia Európskej únie verzie 1.2, ktorú schválila Európska komisia vykonávacím rozhodnutím v máji 2017, je licencia copyleft schválená OSI s tromi rozlišovacími znakmi.

• Jazyk. Existuje v úradných jazykoch EÚ, pričom všetky schválené verzie majú rovnakú platnosť, takže holandský orgán môže uzatvárať zmluvy v holandčine.
• Kompatibilita. V dodatku je uvedený zoznam kompatibilných licencií – medzi nimi GPLv2 a v3, AGPLv3, LGPL, MPL 2, EPL 1.0, OSL a CeCILL – a umožňuje namiesto toho distribúciu odvodeného diela kombinujúceho kód EUPL s kódom pod uvedenou licenciou pod touto licenciou.
• Dosah. Jeho definícia distribúcie zahŕňa sprístupnenie diela online alebo offline alebo poskytovanie prístupu k jeho základným funkciáma článok 5 EUPL prenáša povinnosť copyleftu aj na vzdialenú interakciu, v ktorej je ponúkaná tá istá funkcia. Vzťahuje sa teda na softvér dodávaný ako služba spôsobom, akým to GPL nerobí.

Holandský zákazník z verejného sektora môže vyžadovať licenciu EUPL skôr z politického než zo zákona. Zákon o interoperabilite v Európe, nariadenie (EÚ) 2024/903, nariaďuje subjektom verejného sektora, aby uprednostňovali riešenia interoperability bez obmedzujúcich licenčných podmienok, ako je napríklad open source, ak je to ekvivalentné; na vnútroštátnej úrovni sa princíp open source, tenzij, opiera o rozhodnutia vlády a politické línie, nie o zákon: Wet digitale overheid uľahčuje infraštruktúru digitálnej identity, ale neukladá žiadnu vynútiteľnú povinnosť zverejniť všetok zdrojový kód. Prečítajte si dokumenty k súťaži: požiadavka EUPL je záväzná pre váš výstup a môže byť nekompatibilná s proprietárnym kódom, ktorý ste zamýšľali opätovne použiť.

Presadzovanie v praxi

Kto môže žalovať. Držiteľ práv – individuálni prispievatelia alebo nadácia či spoločnosť, ktorá je držiteľom pridelených autorských práv. Fragmentované autorstvo je praktickou brzdou: žalobca musí preukázať vlastníctvo sporného kódu. Tým bol zamietnutý najznámejší európsky prípad licencie GPL, v ktorom bola žaloba vývojára jadra voči dodávateľovi virtualizácie zamietnutá pre nedostatok dôkazu o autorstve (LG Hamburg 8. júla 2016, 310 O 89/15; potvrdené OLG Hamburg 28. februára 2019, 5 U 146/16).

Čo stanovuje judikatúra. Nemecké súdy opakovane akceptovali, že licencie s otvoreným zdrojovým kódom sú platné a že porušenie robí distribúciu nezákonnou, počnúc prvým súdnym príkazom GPL (LG München I 19. mája 2004, 21 O 6123/04). Americký federálny obvodný súd dospel k rovnakému záveru vo veci Jacobsen v Katzer , 535 F.3d 1373 (Fed. Cir. 2008): licenčné podmienky sú podmienky týkajúce sa rozsahu udelenia, nie len zmluvy, takže porušenie podporuje nárok na autorské práva a súdny príkaz. Americký súdny spor skúma, či môže následný príjemca vymáhať GPL ako tretia strana. To je ústredná otázka vo veci Software Freedom Conservancy v Vizio pred Najvyšším súdom v Kalifornii: či spotrebitelia ako tretie strany môžu požadovať uvoľnenie zdrojového kódu podľa GPLv2. Dňa 23. decembra 2025 súd rozhodol o jednom bode skráteného konania a rozhodol, že GPLv2 a LGPLv2.1 vyžadujú zdrojový kód, ktorý je možné získať a prepracovať na použitie inde, a nie zdrojový kód, ktorý je možné preinštalovať do zariadenia s neporušenou funkčnosťou. Samotná otázka týkajúcej sa oprávnenej tretej strany bola ponechaná na súdne konanie, ktoré bolo viackrát odročené. V každom prípade ide o otázku kalifornského zmluvného práva, takže v Holandsku nie je k ničomu záväzná; zmenila by len počet ľudí, ktorí sa môžu sťažovať.

Ako by k tomu pristupoval holandský súd. Ako porušenie autorských práv podľa Auteurswet: žalobca preukáže vlastníctvo a reprodukciu alebo prenos; žalovaný sa odvolá na licenciu; žalobca odpovie, že jeho podmienky neboli splnené, takže obhajoba zlyhá. Zmluvné opravné prostriedky podľa článku 6:265 BW fungujú paralelne, ale autorské právo je silnejšou cestou.

Nápravné prostriedky. Súdny príkaz podľa článku 3:296 BW, zvyčajne s pokutou a dostupný v skrátenom konaní; náhrada škody podľa článku 27 Aw a vyúčtovanie zisku podľa článku 27a Aw; stiahnutie z trhu, odovzdanie alebo zničenie podľa článku 28 Aw; a úplná náhrada primeraných a primeraných nákladov na právne zastúpenie podľa článku 1019h Rv. V prípadoch, keď bol softvér distribuovaný bezplatne, je ťažké vyčísliť stratu a nemecký odvolací súd odmietol priznať náhradu škody, pričom súdny príkaz potvrdil (OLG Hamm 13. júna 2017, 4 U 72/16). Škoda je zriedkakedy závažná: je to súdny príkaz, stiahnutie z trhu, rozhodnutie o trovách konania a nutnosť zverejniť zdroj, ktorý ste nikdy nezamýšľali zverejniť.

Keď zistíte problém s dodržiavaním predpisov

K odhaleniu zvyčajne dochádza prostredníctvom bezpečnostného dotazníka zákazníka, skenovania počas due diligence alebo listu od držiteľa práv. Náprava potom prebieha nasledovne. Zastavenie distribúcie postihnutej zostavy, ak je narušenie vážne. Zistenie, ktorý komponent, ktorá verzia, ktorá licencia, ktoré produkty a vydania a na aké obdobie. Zistenie, čo licencia skutočne vyžaduje – často skôr súbor s uvedením zdroja ako vydanie zdrojového kódu. Pripravenie artefaktov: oznámenia, texty licencií, kompletný zodpovedajúci zdrojový kód vrátane skriptov zostavenia a písomnú ponuku, ak sa použil. Odoslanie vyhovujúcej verzie a potom informovanie držiteľa práv o tom, čo ste urobili, namiesto toho, aby ste sa hádali o tom, či ste museli.

Podľa licencií GPLv3 a AGPLv3 dáva nápravné obdobie právnu hodnotu rýchlosti; podľa licencie GPLv2 neexistuje právo na nápravu, a preto väčšina presadzovania práva končí dohodnutým záväzkom o dodržiavaní predpisov. Upozorňujeme tiež, že výsadné právo sa viaže na poradenstvo od vášho právnika, nie na internú inžiniersku správu.

Open source v oblasti fúzií a akvizícií a due diligence

Pri akvizícii softvéru je open source štandardným pracovným postupom previerky a nezverejnená zložka copyleftu v jadre produktu je jedným z mála zistení, ktoré skutočne posunú obchod: ak produkt nemožno distribuovať bez zverejnenia jeho zdrojového kódu, kupujúci získava iné aktívum, ako je to, za ktoré bola stanovená cena.

Očakávajte skenovanie kódovej bázy, inventár komponentov s licenciami a otázky týkajúce sa dohôd medzi prispievateľmi a dodávateľmi. Typickými výsledkami sú špecifické odškodnenie, uchovávanie do odstránenia, odkladacia podmienka vyžadujúca odstránenie alebo záruka open source na mieru. Predávajúci by mali najskôr skenovať: zistenia, ktoré zverejníte, sú predmetom rokovania, zistenia, ktoré urobí poradca kupujúceho, sú pákou. Kupujúci by nemali hľadať „spoločnosť vlastní jej duševné vlastníctvo“, ale vyhlásenie, že žiadny produkt neobsahuje open source vyžadujúci zverejnenie proprietárneho zdrojového kódu.

Kusovník, skenovanie a zákon o kybernetickej odolnosti

Kusovník softvéru je zoznam komponentov produktu s verziami a licenciami. Donedávna bol čisto zmluvný, teraz je aj regulačný.

Zákon o kybernetickej odolnosti, nariadenie (EÚ) 2024/2847, nadobudol účinnosť 10. decembra 2024 a postupne sa zavádza. Je súčasťou holandského zákona o kybernetickej bezpečnosti , ktorý sa zameriava skôr na organizáciu ako na produkt. Povinnosti hlásenia aktívne zneužívaných zraniteľností a závažných incidentov v článku 14 zákona CRA sa uplatňujú od 11. septembra 2026; ustanovenia o notifikácii orgánov posudzovania zhody od 11. júna 2026; nariadenie v plnom znení od 11. decembra 2027 (článok 71 zákona CRA). Príloha I k zákonu CRA vyžaduje, aby výrobcovia identifikovali a zdokumentovali komponenty produktu, a to aj vypracovaním softvérového zoznamu materiálov v bežne používanom a strojovo čitateľnom formáte, ktorý pokrýva aspoň závislosti najvyššej úrovne. Nemusí sa zverejniť; orgány dohľadu nad trhom si ho môžu vyžiadať.

Bezplatný a otvorený softvér dodávaný mimo komerčnej činnosti nespadá do pôsobnosti CRA. Nariadenie zavádza správcu softvéru s otvoreným zdrojovým kódom – právnickú osobu, ktorá poskytuje trvalú podporu vývoju softvéru s otvoreným zdrojovým kódom určeného na komerčné činnosti – s ľahšími povinnosťami v článku 24 CRA: zdokumentovaná politika kybernetickej bezpečnosti, spolupráca s orgánmi dohľadu nad trhom a podávanie správ. Ak komercializujete otvorený zdrojový kód alebo financujete projekt, ktorý komercializujú iní, uveďte, akú úlohu zastávate. Komisia prijala svoje prvé usmernenie 27. júla 2026: usmernenie Komisie k uplatňovaniu zákona o kybernetickej odolnosti (CRA), ktoré je pripojené k oznámeniu C(2026) 5252 a ktoré sa okrem iného zaoberá tým, kedy bezplatný a otvorený softvér patrí do rozsahu pôsobnosti. Nebol prijatý žiadny vykonávací akt predpisujúci formát zoznamu materiálov softvéru, takže zatiaľ zostáva opatrením vlastný štandard nariadenia – bežne používaný, strojovo čitateľný formát.

Analýza zloženia softvéru spustená v CI generuje inventár, ktorý slúži naraz na kontrolu súladu s predpismi, kontrolu licencií a dôkladnú kontrolu. Takéto nástroje prehliadajú kód od dodávateľa, nesprávne identifikujú projekty s dvojitou licenciou a nedokážu prečítať licenčné podmienky: výstup považujú za začiatok kontroly, nie za samotnú kontrolu.

Ak publikujete svoj vlastný kód: CLA a DCO

Spoločnosť, ktorá vydáva kód a prijíma externé príspevky, si musí byť vedomá, že má práva na to, čo s ním spája. Licenčná zmluva pre prispievateľov je zmluva medzi projektom a prispievateľom, ktorá zvyčajne udeľuje širokú licenciu na autorské práva a výslovnú patentovú licenciu so zárukami originality a autority. Umožňuje spoločnosti neskôr relicencovať svoj projekt alebo ponúkať komerčné licencie popri licencii s otvoreným zdrojovým kódom. Jej nákladom je trenie.

Vývojársky certifikát pôvodu (Developer Certificate of Origin) , ktorý používa linuxové jadro a mnoho ďalších projektov, nie je udelením licencie, ale zjednodušeným potvrdením, ktoré sa pridáva ako podpisový riadok ku každému commitu, aby prispievateľ mohol odoslať kód pod licenciou projektu. Menej zaťažujúce a menej ochranné: žiadna patentová licencia, žiadne opätovné udeľovanie licencií.

Ak je možné udeliť dvojitú licenciu alebo budúcu licenciu, použite CLA; ak je projekt skutočne verejným majetkom, zvyčajne stačí DCO. V každom prípade sa uistite, že vaše pracovné zmluvy a zmluvy so dodávateľom prideľujú autorské práva ku kódu, ktorý vaši ľudia píšu.

Praktický kontrolný zoznam politík

• Generujte inventár komponentov pre každý produkt a vydávajte ich v procese zostavovania, nie manuálne.
• Zverejnite internú politiku: zoznam povolených položiek, zoznam zakázaných položiek a postup schvaľovania pre všetko ostatné.
• Písomne ​​definujte, čo sa považuje za distribúciu – lokálne inštalácie, zariadenia, kontajnery, SDK, mobilné aplikácie, firmvér.
• S každým produktom odošlite vygenerovaný súbor s údajmi.
• Schvaľujte výber licencií v čase návrhu, pri výbere komponentu, nie pri vydaní.
• Rozhodnite, či príspevky do externých projektov vyžadujú schválenie, vzhľadom na príslušné patentové udelenia, a pred prvým externým príspevkom si vyberte CLA alebo DCO.
• Zosúladiť záruky duševného vlastníctva, odškodnenie a podmienky úschovy s otvoreným zdrojovým kódom, ktorý je skutočne v produkte obsiahnutý.
• Vykonajte kontrolu pred procesom získavania finančných prostriedkov alebo predaja, nie počas neho.

Law & More radí softvérovým spoločnostiam a ich investorom z Eindhoven a Amsterdam o dodržiavaní predpisov o otvorenom zdrojovom kóde, kontrole licencií, dohodách s prispievateľmi a pracovnom postupe s otvoreným zdrojovým kódom v rámci transakcie.