Kód z GitHubu v komerčním produktu: licence a co zkontrolovat

Vyvíjíte produkt a na GitHubu najdete hotový díl: knihovnu, šablonu nebo celý projekt, který dělá přesně to, co potřebujete. Claude navrhne, abyste ho přidali do svého projektu. Pak se zarazíte: kód je sice veřejně dostupný, ale můžete ho opravdu použít, natož prodávat produkt, který ho obsahuje? Může vás jeho autor později žalovat?

Proberu to postupně: proč samotný otevřený kód na GitHubu neznamená svolení, které licence vám dovolují kód použít a prodávat produkt, které podmínky copyleftu mohou vyžadovat odpovídající zdroje zahrnutého díla a jak licenci zkontrolovat za minutu před použitím kódu. Žádné „záleží na situaci“.

Praktické informace o práci s Ailootem najdete v dokumentaci.

Je pravda, že když je kód na GitHubu, můžete ho zdarma používat?#

Hlavní pastí je zde slovo „otevřený“. Zdrojový kód vidíte, a tak se zdá, že když nebyl skrytý, smíte ho používat. Tato úvaha je chybná. „Otevřený ke čtení“ a „licencovaný k použití“ jsou dvě různé věci.

Ve výchozím nastavení je každé tvůrčí dílo, včetně kódu, chráněné autorským právem od okamžiku svého vytvoření. Dokud autor výslovně neudělí svolení, nesmíte ho používat. Takto to popisuje GitHub na své vlastní stránce s přehledem licencí.

Druhou vrstvu představuje samotný GitHub. Lidé si myslí, že když zveřejněním kódu souhlasili s pravidly GitHubu, mohou také používat cizí kód, který tam najdou. Pravidla říkají přesný opak. Zveřejněním repozitáře autor ostatním umožňuje pouze si ho prohlížet a vytvářet forky, tedy kopie přímo na GitHubu. To neopravňuje k použití kódu ve vlastní práci.

Klíčová slova jsou v poslední větě: „v rámci funkcí GitHubu“ a „další práva vyplývají z licence“. Fork zůstává na GitHubu. Jakmile chcete kód použít ve vlastním produktu, natož ho prodávat, potřebujete od autora samostatnou licenci. Žádná licence, žádné právo — i když je kód přímo před vámi.

Co rozhoduje o tom, zda můžete použít cizí kód?#

Vše závisí na jednom souboru. Řádně spravovaný repozitář obsahuje licenční soubor — obvykle LICENSE, někdy LICENSE.md, případně je licence zmíněna přímo v souboru README. Jde o svolení autora, které stanoví podmínky, za nichž smíte kód používat. GitHub obvykle zobrazuje název licence v postranním panelu stránky repozitáře ještě předtím, než otevřete samotný soubor.

Abyste se neztratili v právnickém jazyce, je užitečné číst licenci prostřednictvím tří otázek týkajících se vaší situace:

1. Můžete tento kód použít v komerčním produktu, za který lidé platí?
2. Můžete kód upravovat podle svých potřeb?
3. Musíte následně zveřejnit zdrojový kód svého produktu, nebo ho můžete ponechat neveřejný?

Téměř všechny rozdíly mezi licencemi spočívají v různých odpovědích na třetí otázku. Na první dvě oblíbené otevřené licence nejčastěji odpovídají „ano“: používejte ho, upravujte ho, prodávejte ho. Lidé ale narážejí na to, zda vás licence donutí zveřejnit vlastní kód. Dále si pomocí těchto tří otázek projdeme hlavní typy.

Které licence dovolují použít kód a prodávat produkt?#

Začněme dobrou zprávou. Pro člověka, který vyvíjí produkt na prodej, jsou nejlepší volbou licence ze skupiny zvané permisivní. Je jich několik, ale nejběžnější jsou tři: MIT, Apache 2.0 a BSD. Všechny tři odpovídají na první dvě otázky „ano“ a dovolují vám ponechat vlastní zdrojový kód neveřejný.

Nejběžnější a nejjednodušší je MIT. Její text se vejde do jediného odstavce.

Jednoduše řečeno, MIT vám dovoluje s kódem dělat téměř cokoli, včetně prodeje produktu a ponechání vlastního zdrojového kódu neveřejným. Jedinou povinností je připojit text licence a řádek s uvedením autorství. Například Babel, .NET a Rails jsou vydány pod licencí MIT, takže jste kód pod touto licencí téměř jistě už použili.

Apache 2.0 funguje podobně, ale přidává dva důležité body. Zaprvé výslovnou ochranu před patentovými nároky: autoři kódu slibují, že vás kvůli patentům na tento kód nezažalují. Zadruhé několik dalších formálních požadavků na použití.

BSD (ve verzích se dvěma a třemi doložkami) je v zásadě podobná MIT: používejte ji, upravujte ji, prodávejte ji, zachovejte upozornění na autorská práva. Všechny tři licence jsem zařadil do tabulky, abyste jejich rozdíly viděli na první pohled.

Jak to použít v praxi: pokud u cizího kódu vidíte MIT, Apache 2.0 nebo BSD, můžete být klidní: smíte ho použít v komerčním produktu, upravovat ho a ponechat svůj vlastní zdrojový kód neveřejný. Jen nesmíte odstranit licenční soubor a uvedení autorství z převzaté části.

Jak platí povinnosti ke zdrojovému kódu GPL a AGPL?#

Copyleft zachovává zahrnuté dílo a odvozeniny pod stejnou licencí při splnění příslušných podmínek. Distribuce zdrojových či binárních kopií zahrnutého nebo kombinovaného odvozeného díla pod GPLv3 vyžaduje dodržení licence a povinností k odpovídajícím zdrojům. Automaticky se nevztahuje na každý nezávislý program stejného produktu či serveru.

U webové služby samotný hosting knihovny GPL na vlastním serveru bez předávání kopií uživatelům nevyžaduje zveřejnit celou službu. Distribuce zahrnuté kombinované aplikace zákazníkům může povinnosti spustit; před rozhodnutím o doprovodných zdrojích ověřte propojení a licenci. Prohlížečový klient dodávaný uživatelům je samostatná distribuční otázka.

AGPLv3 přidává síťovou podmínku: upravíte-li program a uživatelé s verzí komunikují vzdáleně, musí jim výrazně nabídnout odpovídající zdrojový kód. To je přesnější než tvrzení, že hosting jakékoli komponenty AGPL otevírá všechny nezávislé části služby.

U proprietárního produktu prozkoumejte zahrnuté dílo, propojení komponent, distribuci kopií a případnou síťovou interakci AGPL. Nemůžete-li splnit příslušné povinnosti, vyberte kompatibilní permisivní alternativu nebo získejte samostatné svolení. Komerční použití je dovoleno; rozhoduje skutečná licence a propojení.

Co dělat, když repozitář vůbec nemá licenční soubor?#

Častou chybou je předpokládat, že pokud chybí licence, neplatí žádná omezení a kód můžete volně používat. Je to přesně naopak. Chybějící licence neznamená svolení; ve výchozím nastavení znamená, že svolení nemáte. Kód bez licence zůstává pod plnou ochranou autorských práv autora a nesmíte s ním nakládat.

Znovu platí pravidlo, kterým jsme začali: ve výchozím nastavení je kód chráněn autorským právem a bez výslovného svolení ho nesmíte kopírovat, upravovat ani šířit. Možnost prohlížet si ho a vytvářet jeho forky v rámci GitHubu tuto překážku neodstraňuje — nedává vám právo použít kód ve vlastním produktu.

Co dělat v praxi, pokud kód nemá licenci, ale opravdu ho potřebujete:

1. Napište autorovi. Přímo v diskusích repozitáře nebo e-mailem se zeptejte, zda můžete kód použít a za jakých podmínek. Někdy autor jen zapomněl přidat licenci a na požádání ji doplní.
2. Najděte náhradu. Téměř ke každému úkolu existuje druhý, třetí i desátý podobný repozitář — mezi nimi najdete takový se správnou licencí MIT nebo Apache.
3. Nepoužívejte ho. Pokud nemáte svolení a neexistuje náhrada, kód vám nepatří a nesmíte ho vložit do produktu, který chcete prodávat. Pokušení říct si „kdo na to přijde?“ špatně skončí ve chvíli, kdy produkt začne vydělávat a přitahovat pozornost.

Co když Claude do projektu sám přidal cizí kód?#

Je tu ještě druhá rovina, kterou lze snadno zaměnit s první. Něco jiného je navštívit repozitář a zkopírovat z něj soubor: pak se na vás přímo vztahují všechny výše uvedené informace o licenci. Něco jiného je, když pro vás Claude napíše kód na základě zadání.

V běžných případech AI vytvoří vlastní text sestavený pro váš úkol, místo aby zkopírovala soubor někoho jiného. Otázka se pak přesouvá do jiné oblasti: komu patří generovaný kód a můžete ho prodávat? To je rozsáhlé samostatné téma, kterému se věnuji v článku o tom, komu patří kód napsaný pomocí AI.

Je ale třeba pamatovat na výjimku. Někdy AI vytvoří rozpoznatelnou část cizího kódu téměř slovo od slova — celou funkci ze známé knihovny. V takovém případě se licence knihovny uplatní bez ohledu na to, kdo fyzicky stiskl klávesy. Velké hotové bloky, které Claude převzal celé, proto kontrolujte stejně, jako kdybyste je zkopírovali sami.

Jak před použitím kódu zkontrolovat licenci: postup#

Shrňme si to do krátkého kontrolního seznamu pro prověření jakéhokoli cizího kódu předtím, než ho přidáte do svého projektu. Postupujte od začátku do konce.

1. Najděte název licence na stránce repozitáře

   Otevřete repozitář na GitHubu. Název licence bývá vidět v pravém sloupci nebo pod seznamem souborů — například „MIT License“, „Apache-2.0“ nebo „GPL-3.0“. Pokud je pole prázdné a neexistuje licenční soubor, je to už varovný signál; vraťte se k tomu v posledním kroku.

2. Otevřete samotný licenční soubor

   V seznamu souborů najděte LICENSE, LICENSE.md nebo COPYING a otevřete ho. Ujistěte se, že název odpovídá tomu, co je uvedeno v postranním panelu, a že se licence vztahuje na kód, který používáte, nikoli jen na samostatnou část repozitáře.

3. Určete typ: permisivní, nebo copyleftový

   MIT, Apache 2.0 a BSD jsou permisivní; kód můžete použít v uzavřeném komerčním produktu. GPL a AGPL jsou copyleftové; před určením povinností prověřte zahrnuté dílo, distribuci a případnou síťovou podmínku AGPL. Samotný název neurčuje zahrnutí nezávislých komponent.

4. Porovnejte licenci se svou situací

   Odpovězte na tři otázky: prodáváte produkt, upravujete kód a chcete zdrojový kód ponechat neveřejný? MIT, Apache a BSD se hodí pro uzavřený produkt určený k prodeji. U GPL a AGPL určete, které zahrnuté či kombinované dílo vyžaduje odpovídající zdroje a kdy povinnost vzniká; posuďte splnitelnost těchto podmínek.

5. Pokud licenci nemá, nepoužívejte ho

   Pokud licenční soubor chybí a README neuvádí nic o svolení, kód nesmíte používat. Napište autorovi a požádejte o svolení, nebo najděte rovnocennou náhradu se správnou licencí. „Je veřejně dostupný“ neznamená, že máte svolení.

Tato kontrola se zdá zdlouhavá až do chvíle, kdy váš produkt poprvé vyroste, začne vydělávat a někdo se zeptá na cizí kód, který obsahuje. Dvě minuty na začátku stojí méně než řešení sporu později. Samostatně rozebírám, co s produktem dělat potom, aby po spuštění nezůstal stát: Vytvořil jsem produkt s AI; co dál.

Přejděte na Ailoot.