Častou chybou je spoléhat na to, že klient pošle stejný klíč. Klient ho musí generovat před prvním odesláním a použít stejný i při opakování. Pokud ho vygeneruje znovu, idempotence nefunguje. Další chyba je ukládat pouze stav „probíhá" bez výsledku. Když první požadavek stále běží a přijde druhý, server musí vrátit 409 nebo počkat, ne spustit operaci znovu. Také se nevyplácí vracet při opakování jiný formát odpovědi než při prvním úspěchu.
Open source licence nejsou jen formalita na GitHubu. Určují, co smíte s kódem dělat, jak ho upravovat a šířit dál. Pokud je nedodržíte, můžete se dostat do právního sporu i při nejlepší vůli. Přitom stačí málo – pochopit, co která licence vyžaduje, a nastavit procesy tak, aby se na to nezapomínalo.
Pokud vyvíjíte software pro vlastní potřebu a nikdy ho nešíříte, většina povinností vás netrápí. Jakmile ale kód poskytnete zákazníkovi, vložíte ho do produktu nebo zpřístupníte jako službu, musíte splnit podmínky všech použitých licencí. U copyleftu to znamená připravit a zveřejnit zdrojový kód odvozeného díla. U permisivních licencí stačí přiložit text licence a seznam autorů. Vždy si před vydáním nechte zkontrolovat shodu licence s obchodním modelem – někdy je jednodušší problematickou knihovnu nahradit jinou než řešit právní výklad.
Jak si ohlídat licence v praxi Začněte tím, že si uděláte inventuru všech závislostí. Nestačí se podívat do souboru s požadavky, protože licence se mohou lišit i mezi podverzemi. Použijte nástroj pro skenování licence (například skener závislostí), který vygeneruje seznam knihoven a jejich licenčních podmínek. Výsledek neberte jako konečný verdikt – vždy si u klíčových knihoven ověřte text licence přímo v repozitáři, protože někteří autoři přidávají dodatečné podmínky nebo výjimky.
Nakonec si nastavte pravidla pro budoucnost. Každý nový soubor by měl mít jasnou licenci a původ. Při převzetí kódu od klienta si vždy nejdřív ověřte, zda smíte dílo používat, upravovat a dál šířit. Rozdíl mezi vlastní licencí a licencí klienta rozhoduje o tom, zda projekt převezmete bezpečně, nebo si přinesete problém, který se vrátí při dalším vydání.
U každého požadavku nastav metodu, hlavičky a tělo. Pro JSON posílaný v těle zvol raw a typ JSON, hlavičku Content-Type nastav na application/json. U autentizace nepřidávej token ručně do každého požadavku. Zvol záložku Authorization, typ Bearer Token a hodnotu načti z proměnné. Pokud token vyprší, v odpovědi dostaneš stavový kód 401 a nebudeš muset procházet všechny požadavky. Do hlaviček patří i Accept s očekávaným typem odpovědi.
Přebíráte projekt od klienta a v repozitáři leží kód, který jste nepsali. První otázka nezní, kdy to spustíme, ale kdo je vlastníkem práv a za jakých podmínek se smí kód dál používat, upravovat a šířit. Licence open source není totéž co vlastnictví. Vlastníkem může být klient, ale licence udává, co s dílem smíte dělat. Dokud to nemáte písemně, pracujete na cizím riziku.
Čistý kód v JavaScriptu nepoznáte podle toho, že funguje. Fungovat může i změť funkcí, které se navzájem volají přes globální proměnné. Čistý kód poznáte podle toho, že ho za půl roku pochopíte i vy sám, a že ho bez obav upraví někdo jiný. Rozdíl mezi čitelným a nečitelným kódem přitom není v délce ani v použitém frameworku. Je v rozhodnutích, která děláte při psaní každé funkce.
Častá chyba je zaměnit licenci kódu a licenci dokumentace nebo dat. Kód může být pod MIT, ale přiložená dokumentace pod CC BY-NC, která zakazuje komerční využití. Další častý omyl je předpoklad, že „open source" automaticky znamená „bez podmínek". Není to pravda – i permisivní licence vyžadují uvedení autora a kopii licence. Zapomínat na uvedení atribuce je nejrychlejší cesta k porušení.
Další past je zapomenout na vedlejší činnosti. Lidé odhadují jen „hlavní" práci a opomíjejí code review, opravy po testech, komunikaci se zákazníkem nebo čekání na přístupy. Do rozpadu proto patří i tyto položky, i když zaberou jen hodinu. Právě ony často rozhodují o tom, jestli se úkol stihne.
Základní rozdíl je mezi permisivními a copyleftovými licencemi. Permisivní (například MIT, BSD, Apache) vám umožní kód použít i v uzavřeném produktu, pokud zachováte text licence a uvedete autory. Copyleftové (například GPL, LGPL, AGPL) naopak vyžadují, abyste odvozené dílo šířili pod stejnou licencí. U AGPL se pozor: povinnost sdílet zdroják vzniká i při pouhém poskytování služby po síti, ne až při distribuci softwaru.
Dodržování licencí není jednorázový úkol. Zaveďte pravidelnou kontrolu při každém přidání nové závislosti a při každém vydání. Ve smlouvě s dodavatelem si vymíňte, že všechny použité komponenty mají licence slučitelné s vaším produktem. A pokud si nejste jistí, obraťte se na právníka specializovaného na duševní vlastnictví. Ušetříte si čas i peníze za zpětné řešení problému, který vznikl kvůli přehlédnuté podmínce.