Licence na software s otevřeným zdrojovým kódem podle nizozemského a unijního práva

Téměř každý komerční softwarový produkt obsahuje komponenty s otevřeným zdrojovým kódem, obvykle stovky, které si vybírají vývojáři spíše než právníci. To se stává problémem, když nikdo nemůže říci, které licence platí, co vyžadují a zda produkt splňuje požadavky. Tento článek vysvětluje, jak fungují licence s otevřeným zdrojovým kódem podle nizozemského a unijního práva, kde leží riziko a co je třeba mít zavedeno.

Co je to licence s otevřeným zdrojovým kódem z právního hlediska

Licence s otevřeným zdrojovým kódem je autorskoprávní licence udělená za určitých podmínek. Nejedná se o zřeknutí se práv, nejde o věnování se veřejné doméně ani o vzdání se práv. Autor si ponechává autorská práva podle čl. 1 Aw a čl. 10 Aw, které chrání počítačové programy jako díla, a licence umožňuje jednání, které by jinak porušovalo výlučná práva podle čl. 12 Aw a čl. 13 Aw.

Důsledek je důležitější než definice. Dodržujte pravidla a vaše kopírování a distribuce budou zákonné. Pokud je nedodržíte, povolení se nevztahuje na to, co jste udělali: vaše použití je porušením autorských práv, nikoli porušením smlouvy. Většina licencí copyleft toto potvrzuje automatickým ukončením v případě porušení – GPLv2 bez jakékoli lhůty pro nápravu, zatímco GPLv3 a AGPLv3 obnovují práva, pokud je porušení napraveno v definovaném okně po oznámení.

Nizozemské soudy tuto úvahu uplatňují. V případu Rb. Amsterdam 22. září 2020, ECLI:NL:RBAMS:2020:4717, distributor, který odstranil text licence a upozornění na autorská práva z rozvětvené kódové základny, byl shledán za distributora, který ztratil své oprávnění a porušil autorská práva. Přidání velkého množství nového kódu nevytvořilo nezávislé dílo: originál zůstal rozpoznatelně přítomen, takže s ním putovaly i závazky.

Dvě rodiny: permisivní a copyleftová

Permisivní licence – MIT, licence BSD, Apache 2.0 – umožňují použití, úpravy a redistribuci, a to i v rámci produktů s uzavřeným zdrojovým kódem, za předpokladu, že zachováte upozornění na autorská práva a text licence.

Licence copyleft vyžadují, abyste při distribuci softwaru nebo čehokoli na něm postaveného činili pod stejnou licencí a zpřístupnili odpovídající zdrojový kód. Liší se v dosahu.

Spouštěč copyleftu a otázka prolinkování

Copyleftové závazky se týkají distribuce, nikoli užívání. Společnost provozující interně software licencovaný GPL, ať už je jakkoli silně upravený, nic nedistribuuje a nic nedluží. První otázkou je vždy „Distribuovali jsme?“ a proto jsou kontejnery, zařízení, firmware a SDK důležitější než interní nástroje.

Druhá otázka je složitější. GPL hovoří o „díle založeném na Programu“, čímž si vypůjčuje americký koncept odvozeného díla. Nizozemské právo takový termín nemá: analýza se zaměřuje na práva na reprodukci a adaptaci a ptá se, zda byl reprodukován chráněný projev z originálu.

Praktickým případem je linkování. Zda linkování proprietárního modulu s knihovnou GPL vytváří jedno dílo podléhající copyleftu, nebylo nizozemským soudem nikdy rozhodnuto a neexistuje žádný závazný orgán EU. Názor Nadace pro svobodný software (Free Software Foundation), že linkování vytváří kombinované dílo, je interpretací správce licencí, nikoli zákonem, a opačný názor je stejně neověřený. Oblíbená odpověď internetu – dynamické linkování je bezpečné, statické linkování ne – nemá oporu v nizozemském autorském právu, které se neptá, jak se kompilátor chová. Obhájitelnější analýza se ptá, jak úzce jsou komponenty kombinovány: sdílejí adresní prostor a datové struktury, je kombinace dodávána jako jeden produkt, může fungovat samostatně, reprodukuje proprietární strana záhlaví, makra nebo inline kód ze strany s copyleftem? Tyto otázky obvykle řeší riziko. Pokud ne, izolujte komponentu za hranicí procesu, nahraďte ji nebo si vezměte komerční licenci.

AGPL a využití sítě

Licence AGPL existuje, protože copyleft je aktivován distribucí a poskytovatelé SaaS nedistribuují. Její síťová klauzule vyžaduje, že pokud software upravíte a zpřístupníte jej uživatelům, kteří s ním interagují na dálku, nabídnete jim odpovídající zdrojový kód vaší upravené verze.

Často se opomíjejí tři body. Povinnost se vztahuje na uživatele služby, což u produktu s otevřenou registrací není příliš útěchou. Je spuštěna modifikací, takže nemodifikovaná komponenta ji neaktivuje, ale opravená verze ano. A vyvolává stejnou otázku kombinované práce jako GPL pro zbytek vašeho stacku – proto mnoho společností zakazuje AGPL v produkčním kódu.

Kompatibilita licencí

Kompatibilita je problém kombinování komponent, jejichž licence ukládají závazky, které nelze splnit v jedné distribuci: permisivní licence jsou kompatibilní téměř se vším, copyleftové licence pouze s tím, co umožňují jejich vlastní podmínky. Standardním případem je Apache 2.0 a GPLv2. Nadace Apache Software Foundation a Nadace Free Software Foundation se shodují, že kombinace není povolena, protože ustanovení Apache 2.0 o ukončení patentu a odškodnění jsou dalšími omezeními, která GPLv2 neumožňuje. GPLv3 byla navržena tak, aby je akceptovala. Kompatibilita je také směrová: kód Apache lze začlenit do projektu GPLv3, ale ne naopak. Jedna komponenta GPL na nesprávném místě může vynutit volbu mezi opětovným licencováním, přepracováním nebo odstraněním – mnohem levnější před vydáním než po něm.

Povinnosti uvádění zdroje a oznámení

Nejčastěji porušované povinnosti jsou ty nejméně dramatické: reprodukce oznámení o autorských právech, licenčních textů, prohlášení o vyloučení odpovědnosti a v Apache 2.0 i obsahu NOTICE v materiálech doprovázejících distribuci. Každá rodina je ukládá, včetně MIT a BSD. Porušují se, protože je nikdo nevlastní, a nejsnadněji se opravují – obvykle se jedná o vygenerovaný soubor s uvedením zdroje dodávaný s produktem. Výše ​​uvedený nizozemský případ se odráží právě v tomto selhání.

Udělení patentů a odvetná opatření proti patentům

MIT a BSD se o patentech nezmiňují a není jasné, zda lze patentovou licenci implicitně považovat. Apache 2.0 přidal výslovnou patentovou licenci bez licenčních poplatků od každého přispěvatele, spolu s doložkou o odvetných opatřeních: pokud zahájíte patentový spor s tvrzením, že dílo porušuje patent, vaše patentová licence zanikne. GPLv3 obsahuje srovnatelné udělení patentu a vlastní patentová ustanovení.

Dva důsledky pro společnosti s patentovými portfolii. Pokud vaši inženýři přispívají k projektům s licencí Apache nebo GPLv3, udělujete licence na základě svých vlastních patentů. A pokud někdy uplatníte patenty vůči společnosti závislé na stejných komponentách s licencí Apache, které používáte, odveta vás může stát licenci, na kterou se spoléháte.

Licence EUPL a nizozemský veřejný sektor

Veřejná licence Evropské unie verze 1.2, schválená Evropskou komisí prováděcím rozhodnutím v květnu 2017, je copyleftová licence schválená OSI se třemi charakteristickými znaky.

• Jazyk. Existuje v úředních jazycích EU, všechny schválené verze mají stejnou platnost, takže nizozemský orgán může uzavírat smlouvy v holandštině.
• Kompatibilita. Dodatek uvádí seznam kompatibilních licencí – mimo jiné GPLv2 a v3, AGPLv3, LGPL, MPL 2, EPL 1.0, OSL a CeCILL – a umožňuje, aby odvozené dílo kombinující kód EUPL s kódem pod uvedenou licencí bylo distribuováno pod touto licencí.
• Dosáhnout. Jeho definice distribuce zahrnuje zpřístupnění díla online nebo offline. nebo poskytování přístupu k jeho základním funkcíma článek 5 EUPL přenáší povinnost copyleftu až na vzdálenou interakci, v níž je nabízena stejná funkce. Dotýká se tedy softwaru dodávaného jako služba, na rozdíl od GPL.

Nizozemský zákazník z veřejného sektoru může vyžadovat licenci EUPL spíše jako věc politiky než zákona. Zákon o interoperabilitě v Evropě, nařízení (EU) 2024/903, nařizuje subjektům veřejného sektoru, aby upřednostňovaly řešení interoperability bez omezujících licenčních podmínek, jako je open source, kde je to ekvivalentní; na národní úrovni se princip open source, tenzij, opírá o rozhodnutí vlády a politické linie, nikoli o zákon: Wet digitale overheid usnadňuje infrastrukturu digitální identity, ale neukládá žádnou vymahatelnou povinnost zveřejnit veškerý zdrojový kód. Přečtěte si dokumentaci k zadávacímu řízení: požadavek EUPL je závazný pro váš výstup a může být neslučitelný s proprietárním kódem, který jste zamýšleli znovu použít.

Vymáhání v praxi

Kdo může žalovat? Držitel práv – jednotliví přispěvatelé nebo nadace či společnost, která je držitelem přidělených autorských práv. Fragmentované autorství je praktickou brzdou: žalobce musí prokázat vlastnictví sporného kódu. Tím byl zamítnut nejznámější evropský případ GPL, kde žaloba vývojáře jádra proti dodavateli virtualizace neuspěla pro nedostatek důkazu o autorství (LG Hamburg 8. července 2016, 310 O 89/15; potvrzeno OLG Hamburg 28. února 2019, 5 U 146/16).

Co stanoví judikatura. Německé soudy opakovaně uznaly, že licence open source jsou platné a že porušení činí distribuci nezákonnou, počínaje prvním soudním příkazem GPL (LG München I 19. května 2004, 21 O 6123/04). Americký federální obvodní soud dospěl ke stejnému závěru ve věci Jacobsen v. Katzer , 535 F.3d 1373 (Fed. Cir. 2008): licenční podmínky jsou podmínky týkající se rozsahu udělení, nikoli pouhé smlouvy, takže porušení podporuje nárok na autorská práva a soudní příkaz. Americký soudní spor zkoumá, zda může následný příjemce vymáhat GPL jakožto oprávněná třetí strana. To je ústřední otázka ve věci Software Freedom Conservancy v. Vizio před kalifornským vrchním soudem: zda mohou spotřebitelé jako oprávněné třetí strany požadovat uvolnění zdrojového kódu podle GPLv2. Konečné rozhodnutí o věcné spravedlnosti se očekává až po soudním řízení s porotou v roce 2026, takže o této otázce ještě nebylo rozhodnuto.

Jak by k tomu přistoupil nizozemský soud. Jako porušení autorských práv podle Auteurswet: žalobce prokáže vlastnictví a reprodukci nebo sdělení; žalovaný se dovolá licence; žalobce odpoví, že jeho podmínky nebyly splněny, takže obhajoba selhává. Smluvní nápravná opatření podle čl. 6:265 BW fungují paralelně, ale autorské právo je silnější cestou.

Nápravné prostředky. Soudní příkaz podle čl. 3:296 BW, obvykle s penále a dostupný v rámci zkráceného řízení; náhrada škody podle čl. 27 Aw a vyúčtování zisku podle čl. 27a Aw; stažení z trhu, vydání nebo zničení podle čl. 28 Aw; a plná náhrada přiměřených a úměrných nákladů právního zastoupení podle čl. 1019h Rv. V případech, kdy byl software distribuován zdarma, je obtížné ztrátu vyčíslit a německý odvolací soud odmítl přiznat náhradu škody, zatímco soudní příkaz potvrdil (OLG Hamm 13. června 2017, 4 U 72/16). Škoda je jen zřídka: je to soudní příkaz, stažení z trhu, rozhodnutí o nákladech řízení a nutnost zveřejnit zdroj, který jste nikdy nezamýšleli zveřejnit.

Když zjistíte problém s dodržováním předpisů

K odhalení obvykle dochází na základě bezpečnostního dotazníku zákazníka, skenování během due diligence nebo dopisu od držitele práv. Náprava pak probíhá následovně. Zastavte distribuci dotčené verze, pokud je narušení závažné. Zjistěte, která komponenta, která verze, která licence, které produkty a verze a po jakou dobu. Zjistěte, co licence skutečně vyžaduje – často soubor s uvedením zdroje, nikoli verzi zdrojového kódu. Připravte artefakty: oznámení, texty licencí, kompletní odpovídající zdrojový kód včetně skriptů pro sestavení a písemnou nabídku, pokud je použit. Odešlete verzi, která je v souladu s pravidly, a poté držiteli práv sdělte, co jste udělali, místo abyste se hádali o tom, zda jste museli.

Podle GPLv3 a AGPLv3 dává nápravné lhůtě rychlost právní hodnotu; podle GPLv2 neexistuje právo na nápravu, a proto většina vymáhání práva končí sjednaným závazkem k dodržování předpisů. Upozorňujeme také, že imunita se váže na radu vašeho právníka, nikoli na interní technickou zprávu.

Open source v oblasti fúzí a akvizic a due diligence

Při akvizici softwaru je open source standardním postupem pro ověření pravosti a nezveřejněná copyleftová složka v hlavním produktu je jedním z mála zjištění, která skutečně posunou obchod: pokud produkt nelze distribuovat bez zveřejnění jeho zdrojového kódu, kupující získává jiné aktivum, než za které byla stanovena cena.

Očekávejte skenování kódové základny, inventář komponent s licencemi a otázky ohledně ujednání mezi přispěvateli a dodavateli. Typickými výsledky jsou specifické odškodnění, uchování do doby nápravy, odkládací podmínka vyžadující odstranění nebo záruka open source na míru. Prodávající by měli nejprve provést skenování: zjištění, která zveřejníte, jsou vyjednáváním, zjištění, která učiní poradce kupujícího, jsou pákou. Kupující by neměli usilovat o to, aby „společnost vlastnila její duševní vlastnictví“, ale o prohlášení, že žádný produkt neobsahuje open source vyžadující zveřejnění proprietárního zdrojového kódu.

Kusovník, skenování a zákon o kybernetické odolnosti

Kusovník softwaru je soupis komponent produktu s verzemi a licencemi. Donedávna byl čistě smluvní, nyní je také regulační.

Zákon o kybernetické odolnosti, nařízení (EU) 2024/2847, vstoupil v platnost 10. prosince 2024 a zavádí se postupně. Povinnosti hlášení aktivně zneužívaných zranitelností a závažných incidentů v článku 14 CRA platí od 11. září 2026; ustanovení o oznamování subjektů posuzování shody od 11. června 2026; nařízení v plném znění od 11. prosince 2027 (článek 71 CRA). Příloha I CRA vyžaduje, aby výrobci identifikovali a dokumentovali komponenty ve výrobku, mimo jiné vypracováním kusovníku softwaru v běžně používaném a strojově čitelném formátu, který zahrnuje alespoň závislosti na nejvyšší úrovni. Nemusí být zveřejněn; orgány dozoru nad trhem si ho mohou vyžádat.

Volně prodejný a open source software dodávaný mimo komerční činnost nespadá do působnosti CRA. Nařízení zavádí správce open source softwaru – právnickou osobu, která poskytuje trvalou podporu vývoji open source softwaru určeného pro komerční činnosti – s lehčími povinnostmi v článku 24 CRA: zdokumentovaná politika kybernetické bezpečnosti, spolupráce s orgány dozoru nad trhem a podávání zpráv. Pokud komercializujete open source software nebo financujete projekt, který komercializují jiní, uveďte, jakou roli zastáváte. Komise přijala své první pokyny dne 27. července 2026: pokyny Komise k uplatňování zákona o kybernetické odolnosti (CRA), které jsou připojeny ke sdělení C(2026) 5252 a které se mimo jiné zabývají tím, kdy volně prodejný a open source software spadá do působnosti. Nebyl přijat žádný prováděcí akt předepisující formát pro seznam materiálů softwaru, takže prozatím zůstává opatřením vlastní standard nařízení – běžně používaný, strojově čitelný formát.

Analýza složení softwaru spuštěná v CI generuje inventář, který zároveň slouží k prověření shody s předpisy, kontrole licencí a diligence. Takové nástroje přehlížejí kód od dodavatele, chybně identifikují projekty s duální licencí a nedokážou číst licenční podmínky: výstup považují za začátek kontroly, nikoli za samotnou kontrolu.

Pokud publikujete svůj vlastní kód: CLA a DCO

Společnost, která vydává kód a přijímá externí příspěvky, si musí být jistá, že má práva na to, co začleňuje. Licenční smlouva pro přispěvatele je smlouva mezi projektem a přispěvatelem, která obvykle poskytuje širokou licenci na autorská práva a výslovnou patentovou licenci se zárukami originality a autority. Umožňuje společnosti později znovu licencovat svůj projekt nebo nabízet komerční licence vedle licence s otevřeným zdrojovým kódem. Jejím nákladem je tření.

Vývojářský certifikát původu (Developer Certificate of Origin) , používaný linuxovým jádrem a mnoha dalšími projekty, není udělením licence, ale zjednodušeným potvrzením, které se přidává jako podpisový řádek ke každému commitu, aby přispěvatel mohl odeslat kód pod licencí projektu. Méně zatěžující a méně ochranné: žádná patentová licence, žádné relicencování.

Pokud je možné dvojí licencování nebo budoucí licence, použijte CLA; pokud je projekt skutečně veřejným majetkem, obvykle postačí DCO. V každém případě se ujistěte, že vaše pracovní smlouvy a smlouvy se smluvními partnery přidělují autorská práva ke kódu, který vaši lidé píší.

Praktický kontrolní seznam zásad

• Generujte inventář komponent pro každý produkt a vydávejte je v rámci sestavovacího kanálu, nikoli ručně.
• Zveřejněte interní zásady: seznam povolených, seznam zakázaných a postup schvalování pro vše ostatní.
• Písemně definujte, co se počítá jako distribuce – instalace na místě, zařízení, kontejnery, SDK, mobilní aplikace, firmware.
• S každým produktem odešlete vygenerovaný soubor s atribucí.
• Schvalujte výběr licencí v době návrhu, při výběru komponenty, nikoli při vydání.
• Rozhodněte, zda příspěvky k externím projektům vyžadují schválení, s ohledem na příslušné patentové udělení, a před prvním externím příspěvkem vyberte CLA nebo DCO.
• Slaďte záruky duševního vlastnictví, odškodnění a podmínky úschovy s otevřeným zdrojovým kódem, který je skutečně v produktu obsažen.
• Proveďte kontrolu před procesem získávání finančních prostředků nebo prodeje, ne během něj.