Jak bezpečně používat open source software

Open source software, tedy programy, jejichž zdrojový kód je volně dostupný k dalším úpravám, již není pouze volnočasovou aktivitou několika málo nadšenců. Už i giganti jako Microsoft či Google touto formou zpřístupňují svá stávající řešení, případně dále rozvíjejí otevřené systémy někoho jiného. Open source software se také stal oblíbeným stavebním kamenem při vývoji komerčního softwaru. Je však jeho použití skutečně bezpečné? Nezadělává si s ním společnost na právní problémy? Cílem tohoto příspěvku je rozbít některé mylné představy spojené s využitím programů s otevřeným zdrojovým kódem v komerčních projektech. Ukážeme si, že tento software zpravidla není možné použít libovolně a bez omezení, na druhou stranu to však neznamená, že ho lze používat pouze nekomerčně.

Pravidla licencí

Spolu s open source softwarem je poskytován i přístup k jeho zdrojovému kódu a právo ho měnit a dále šířit s minimálním omezením.^1 💬 Protikladem je takzvaný proprietární software, u něhož zdrojový kód není volně přístupný.^2 💬 Uživatel tak nemá možnost jej jakkoli upravovat a příslušná licenční smlouva mu také zpravidla zakazuje další distribuci a omezuje způsoby užití. Typickým příkladem open source softwaru je jádro operačního systému Linux, kancelářský balík Libre Office (open source alternativa k proprietárnímu Microsoft Office) či internetový prohlížeč Mozilla Firefox.

Sama skutečnost, že je poskytován zdrojový kód a právo změn, však neznamená, že takovýto program je možné používat a šířit zcela libovolně. Ve většině případů je další použití omezeno licenčními podmínkami − takzvanou open source licencí. Podle míry těchto omezení lze pak licence dělit do několika kategorií.

Míra omezení pro další použití záleží na přítomnosti takzvané copyleftové doložky. Ta stanoví povinnost šířit upravený software pod stejnou licencí, pod jakou byl distribuován ten původní, tedy i opět zpřístupnit zdrojový kód upraveného programu.^3 💬

Smyslem copylefotvé doložky je chránit otevřenost zdrojového kódu a zajistit, že i upravený software bude přístupný celé komunitě vývojářů spolu s pozměněným zdrojovým kódem. Proto je tato doložka často kamenem úrazu při vývoji komerčního systému, kde je zpřístupnění kódu a poskytnutí práva změn většinou nežádoucí.

Ne všechny open source licence však takovouto doložku obsahují. Podle síly copyleftového efektu je můžeme rozdělit do tří kategorií:

Silně copyleftové licence − jako například GNU GPL verze 2^4 💬 nebo 3^5 💬 − vyžadují, aby všechny odvozeniny od licencovaného open source softwaru byly šířeny pod stejnou licencí. Tato povinnost dopadá na upravené verze licencovaného softwaru, jeho zapojení do většího systému i využití částí jeho zdrojového kódu.

Důsledkem je pak povinnost zpřístupnit zdrojový kód odvozeného softwaru. Kvůli tomu zpravidla není možné software se silně copyleftovou licencí používat v komerčních projektech.

Slabě copyleftové licence také obsahují tuto doložku, ta se však nevztahuje na propojení open source softwaru s proprietárním softwarem pomocí rozhraní, bez propojení jejich zdrojových kódů. Prakticky je tak možné použít software šířený pod slabě copyleftovou licencí jako takzvanou knihovnu v rámci rozsáhlejšího komerčního řešení. Knihovna v rámci něj může poskytovat sadu funkcionalit, které lze spustit přes společné rozhraní. Příkladem může být knihovna funkcí pro vytváření a úpravu dokumentů ve formátu PDF.

Copyleftová doložka však zůstává v platnosti pro zdrojový kód, z něhož tak není možné kopírovat jeho části. Pokud je z takto chráněného softwaru zdrojový kód převzat, aktivuje se copyleftová doložka a výsledný software je třeba šířit pod open source licencí a s přístupem ke zdrojovému kódu. Příkladem slabě copyleftové licence může být licence LGPL verze 2.1.^6 💬

Permisivní či necopyleftové licence, jako jsou třeba licence MIT^7 💬 nebo licence z rodiny BSD^8 💬, jsou ideální volbou pro vývojáře komerčního softwaru. Tyto licence inkriminovanou doložku neobsahují, a dávají tak vývojáři možnost volby, zda bude odvozené dílo distribuovat jako open source či proprietární software. Licenční podmínky bývají zpravidla velmi stručné a obsahují pouze požadavek uvedení jména autora a zřeknutí se odpovědnosti za případné vady či chyby v původním open source softwaru.

Rizika plynoucí z porušení licencí

Skutečnost, že open source licence jsou právně závazné a vymahatelné, potvrzuje soudní praxe ze zahraničí, například z Německa. Ne vždy se ale vývojářům podaří obhájit jejich nároky. Například v kauze Hellwig vs. VMware soud zamítl nároky Christopha Hellwiga, vývojáře jádra operačního systému Linux, proti společnosti VMware.

Podle Hellwiga společnost porušila licenční podmínky tím, že vytvořila odvozený software za použití zdrojového kódu publikovaného pod GNU GPL verze 2, a to aniž by zveřejnila zdrojový kód výsledného softwaru.^9 💬 Soud žalobu zamítl proto, že se Hellwigovi nepodařilo vzhledem k velkému počtu spolupracujících nezávislých vývojářů prokázat, že je autorem dotčené části kódu právě on.

Již v roce 2004 v kauze Welte vs. Sitecom však německý soud potvrdil právní závaznost licence a rozhodl, že výrobce síťových prvků Sitecom porušil licenční podmínky, když do firmware svých routerů zahrnul open source zpřístupněný pod GNU GPL verze 2, aniž by podmínky této licence splnil. Společnost Sitecom neuvedla, že jejich firmware obsahuje open source, neodkázala na text licence a především nezveřejnila zdrojový kód firmware.^10 💬 Obdobným žalobám pak čelila řada dalších IT společností.^11 💬

Z výše uvedeného je patrné, že nároky z porušení open source licence mohou být vymáhány stejně jako nároky z jakéhokoli jiného porušení autorských práv k softwaru. Proto nelze brát tyto licenční podmínky na lehkou váhu.

Jak se vyhnout právním rizikům

K porušování podmínek často dochází vlivem nedostatečných opatření na straně vývojářské firmy. Pokud společnost nemá jasně nastavenou politiku používání otevřených zdrojových kódů, jednotliví programátoři je mohou použít, aniž by si uvědomovali, že je to v rozporu s licenčními podmínkami, respektive že z toho pro společnost plynou nějaké povinnosti. Typicky může jít o použití open source softwaru pod silně copyleftovou licencí, jako je GNU GPL v rámci vývoje proprietárního softwaru.

Vhodnou prevencí takových situací je nastavení politiky používání open source softwaru. Ta by především měla určovat, jaký software, respektive pod jakou licencí je možné v rámci vývoje v dané společnosti používat. Jaký je naopak z použití vyloučen a jak řešit sporné případy.

Vyloučeno bude typicky užití programů se silně copyleftovou licencí, a dovoleno naopak použití permisivních licencí. Jasná pravidla je pak vhodné doplnit instrukcemi, na koho se má vývojář obrátit, pokud si není jistý, zda může určitý zdrojový kód použít. Vedle toho by měla nastavená pravidla dávat vývojářům vodítka, jak mají správně plnit povinnost informovat o použití otevřeného zdrojového kódu v daném softwaru a jeho autorech, jak připojovat licenční soubory a jak evidovat použití příslušného kódu.

Pokud totiž v rámci vývoje není evidováno, společnost nemá možnost zpětně ověřit, zda skutečně dodržuje veškeré relevantní licenční podmínky. Takový stav může být nežádoucí například při vstupu nového investora. Ten může požadovat záruky či důkazy o tom, že společnost používá open source v souladu s jeho podmínkami.

Takový deficit lze částečně kompenzovat speciálním auditem. Jeho podstatou je zmapování veškerého open source softwaru aktuálně využívaného ve vyvíjených produktech a posouzení souladu s jeho podmínkami.

Vedle použití komplexních, avšak velmi nákladných nástrojů pro automatizaci této úlohy je možné audit realizovat i bez zvláštní softwarové podpory. Podmínkou však je úzká součinnost vývojového týmu se specialistou na open source licence, který musí posoudit rizika spojená s danou licencí. Vedle výše zmíněných všeobecně známých licencí se v praxi lze setkat i s jejich modifikacemi či zcela specifickými licencemi, které vyžadují samostatné posouzení.

Pokud má být open source software použit v rámci vývoje na zakázku, pak by měl zákazník ve smlouvě s dodavatelem mimo jiné požadovat záruky, že veškerý zdrojový kód bude použit v souladu s licenčními podmínkami a že na něj nebudou uvaleny žádné další povinnosti nebo pouze ty, které jsou výslovně sjednány. Použitý open source software by měl být rovněž důsledně dokumentován. Pokud má zákazník dostatečné odborné kapacity, pak si může rovněž vyhradit, že bude použití jednotlivých open source nástrojů schvalovat.

Open source software je možné bezpečně používat v komerčních projektech, je však třeba respektovat jeho licenční podmínky, které jsou právně závazné a vymahatelné. Ty mohou omezovat podmínky šíření odvozeného softwaru pomocí takzvané copyleftové doložky. V komerčním vývoji je proto nejlépe použitelný software šířený pod některou z permisivních licencí, která tuto doložku neobsahuje, například MIT nebo BSD-3.

Pro prevenci rizik spojených s použitím otevřeného zdrojového kódu při vývoji je vhodné nastavit pravidla pro jeho používání, případně ošetřit jeho užití ve smlouvě s dodavatelem. Pokud není užití tohoto softwaru zdokumentováno, je možné tento deficit kompenzovat příslušným auditem.

^{zpět🡹 1) The Open Source Definition [on-line]. Dostupné z: opensource.org/osd [cit. 26.3.2019]. Též srov. Tomíšek in Polčák, s. 196.}

^{zpět🡹 2) Tomíšek in Polčák, s. 196.}

^{zpět🡹 3) Co je to copyleft?. GNU Operating Systém [on-line]. Dostupné z: www.gnu.org/licenses/copyleft.cs.html [cit. 26.3.2019].}

^{zpět🡹 4) GNU General Public License, version 2 [on-line]. 2017. Dostupné z: www.gnu.org/licenses/old-licenses/gpl-2.0.html.en.}

^{zpět🡹 5) GNU General Public License, version 3 [on-line]. 2016. Dostupné z: www.gnu.org/licenses/gpl.html.}

^{zpět🡹 6) GNU Lesser General Public License, version 2.1 [on-line]. 2018. Dostupné z: www.gnu.org/licenses/old-licenses/lgpl-2.1.html [cit. 26.3.2019].}

^{zpět🡹 7) MIT license [on-line]. Dostupné z: opensource.org/licenses/MIT.}

^{zpět🡹 8) The 3-Clause BSD license [on-line]. Dostupné z: opensource.org/licenses/BSD-3-Clause.}

^{zpět🡹 9) Frequently Asked Questions about Christoph Hellwig's VMware Lawsuit [on-line]. Dostupné z: sfconservancy.org/copyleft-compliance/vmware-lawsuit-faq.html.}

^{zpět🡹 10) Jaeger, T. Enforcement of the GNU GPL in Germany and Europe..}

^{zpět🡹 11) Welte vs Fortinet UK Ltd. (2005), Welte vs D-Link (2006), Welte vs Skype (2008), Welte in AVM vs Cybits (2011) nebo Welte vs Fantec (2013). Žalobce Harald Welte dokonce založil projekt Gpl-violations.org, který aktivně podporuje vývojáře open source v prosazování jejich autorských práv.}

Článek byl publikován v magazínu Právní rádce.