Odmítnutí odpovědnosti: Jsem vývojář, ne právník; tyto informace považuji za správné, ale nejsou právním poradenstvím; pokud si myslíte, že je něco špatně, napište prosím komentář a společně to opravíme🔧

Předtím jsem se o licenci balíčku npm nezajímal. Mohl jsem zkontrolovat licenci bezprostřední závislosti, ale nikdy jsem nekontroloval závislosti třetích stran (přechodné).

🚓 A pak jsem potkal lidi z právního oddělení 🚓

Teď věřím, že vývojáři by měli mít základní znalosti o softwarových licencích, aby mohli vést konstruktivní dialog s právními týmy ve svých firmách. Tento příspěvek shromažďuje obecné znalosti o open-source licencích a o tom, jak se týkají závislostí na npm a obecně fullstackového vývoje v JavaScriptu.

Ujasníme si, kdy byste se měli začít starat o licence.

Kdy se spouští licenční požadavky?

Pokud provádíte propojení s knihovnami s otevřeným zdrojovým kódem a následně výsledný software distribuujete, pak váš software musí být v souladu s požadavky na propojené knihovny.

Podívejme se blíže na propojování a distribuci aplikovanou na aplikace JavaScriptu.

Linkování

Používání knihoven třetích stran obvykle znamená jejich linkování:

  • Pokud svůj kód svazujete (tj. pomocí WebPacku) s open source balíčky, počítá se to jako statické linkování
  • Pokud ve své aplikaci Node.JS používáte open source balíčky (tj. pomocí require) nebo jej připojíte k webové stránce pomocí značky skript, jedná se o dynamické propojení

Poznámka: při sestavování balíčku nebo spouštění aplikace Node.JS provádíte stejný typ propojení jak s okamžitými (uvedenými ve vašem package.json), tak s přechodnými (uvedenými v package.json třetích stran) závislostmi. Licence okamžitých i tranzitivních závislostí mají na váš software stejný vliv.

Dříve mi to nepřišlo intuitivní 🤔

Distribuce

Pouhé použití open source knihoven nemusí vyvolat licenční požadavky. Obvykle jsou licenční požadavky vyvolány při distribuci softwaru:

  • Předávání softwaru mezi zaměstnanci stejné společnosti není distribucí
  • Když uživatelé interagují s vaším uzlem.JS aplikací po síti, nejedná se o distribuci pro většinu open source licencí; jedná se však o distribuci pro Network Protective licence, jako je AGPL
  • Umisťování JavaScriptových souborů na veřejný webový server je distribuce

Která licence je v pořádku

Většina open source licencí obecně spadá do jednoho z těchto typů:

  • Public Domain a Permissive licence jako MIT, které umožňují cokoli kromě žalování autora
  • Copyleft nebo ochranné licence jako GPL zabraňují propojení (viz výše) s proprietárním softwarem; okrajovým případem jsou síťové ochranné licence jako Affero GPLv3, které se spouští interakcí po síti;
  • Mezi oběma výše uvedenými jsou slabě ochranné licence jako MPL, které mají menší omezení pro dynamické linkování (dokud není knihovna ve vlastním souboru)

Podívejme se na běžné scénáře pro vývojáře JavaScriptu:

Vytváříte webovou aplikaci

Nejspíše spojíte všechny soubory včetně knihoven do jednoho JS souboru a umístíte jej na webový server. Provádíte statické linkování a distribuci. Použití balíčků s povolenou licencí ve svazku je v pořádku.

Pokud potřebujete použít balíček se slabě ochrannou licencí, jako je MPL, máte možnosti:

  1. Načíst knihovnu ze samostatného souboru (tj. prostřednictvím značky skriptu)
  2. Použijte na balíček kompatibilní open source licenci (ale předtím se podívejte na komentář níže a poraďte se s právním týmem)

Pokud váš balíček nemá ✨cenné duševní vlastnictví✨, pak by měla být druhá možnost v pořádku. Nevěřím, že konkurence bude mít z vašeho obfuskovaného kódu prospěch. Pokud však svazek obsahuje cenné duševní vlastnictví, pak použití licence open source znamená poskytnutí jeho volného použití.

Vytváříte aplikaciNode.JS

V tomto případě obvykle připojujete knihovny pomocí volání require(). Jedná se o dynamické propojení. Je v pořádku používat licence Permissive a dokonce i Weakly Protective. Jen se ujistěte, že balíčky zůstávají ve vlastních souborech s příslušnými licencemi.

Pokud poskytujete pouze službu SaaS a nešíříte ji žádným jiným způsobem, můžete použít i balíčky s licencí Protective. U mnoha ochranných licencí není síťová interakce distribucí. Výjimkou jsou síťové ochranné licence jako Affero GPLv3

Vytváříte balíček NPM s otevřeným zdrojovým kódem

Obvykle připojujete závislosti třetích stran prostřednictvím souboru package.json. Podle mých nejlepších znalostí nelze uvedení závislosti v package.json považovat za propojení. Propojení provede vývojář aplikace, který bude váš balíček používat ve fázi sestavení nebo spuštění.

Pokud nechcete zmást uživatele balíčku, ujistěte se, že všechny závislosti (okamžité i přechodné) mají kompatibilní licence s licencí vašeho balíčku.

Typicky by licence závislostí měly být více permisivní nebo na stejné úrovni permisivity jako licence vašeho balíčku.

Příklad pokud má váš balíček licenci Apache 2.0, můžete použít závislosti s licencí MIT a BSD. Neměli byste však používat závislosti s licencí MPL1.1 nebo LGPLv3, protože mají silnější copyleft.

Šipka z rámečku A do rámečku B znamená, že můžete kombinovat software s těmito licencemi; kombinovaný výsledek má ve skutečnosti licenci B, případně s doplňky z A; obrázek z práce Davida A. Wheeler

Pokud potřebujete do balíčku NPM vložit balíčky nebo zdrojové kódy třetích stran, nezapomeňte uvést licence a autorská práva třetích stran. Většina licencí otevřených zdrojů vyžaduje uvedení autora.

Také je dobrým zvykem uvést v souboru package.json platný výraz SPDX. Domnívám se, že toto pole musí být pro publikování na npm.org povinné.

Jak na to přijít

Mnoho týmů začne o licencích přemýšlet, až když je software připraven k odeslání. Já k tomu používám nástroj ScanCode. Opravdu prochází každou složku vašeho projektu a snaží se zjistit každou licenci nebo autorská práva.

Snímek obrazovky z https://github.com/nexB/scancode-toolkit

Před distribucí aplikace pravděpodobně budete muset použít tento nebo podobný nástroj. Ujistěte se, že kontrolujete dostatečně a ne příliš:

  • před spuštěním nástroje nainstalujte všechny produkční závislosti
  • ujistěte se, že nástroj nekontroluje devDependencies; normálně se s vývojovými závislostmi nedistribuuje;

Poznámka: pokud stejně jako já zkoumáte licence balíčků až poté, co jste balíček integrovali do své aplikace, můžete se ocitnout ve složité situaci.

Spouštění ScanCode těsně před uzávěrkou; obrázek z https://giphy.com

Jak na to přijít, než bude pozdě

Přemýšlel jsem, kdy je nejlepší čas dozvědět se o licencích závislostí balíčků. Pro mě je běžný průběh objevování balíčků následující:

🔍 Google 👉 npm.org 👉 GitHub 👉 $ npm install

Naneštěstí npm.org přechodné závislosti moc neřeší. Existují webové nástroje, například http://npm.anvaka.com/; ten mi ale do mého toku zjišťování balíčků nezapadá a stále ho zapomínám používat. Myslel jsem si, že nejlepším okamžikem pro zjištění závislostí balíčků je zadání příkazu $ npm install <pkg>

Tak jsem uvažoval, když jsem vytvořil nástroj CLI s názvem npm-consider, který analyzuje balíček se všemi tranzitivními závislostmi ještě před jeho instalací nebo dokonce stažením.

https://github.com/delfrrr/npm-consider

Abych vám ušetřil jeden příkaz, obaluje $ npm install a má stejné argumenty. Pokud vám nevadí závislosti, stačí zvolit Install a spustí se npm install jako obvykle. Pokud máte obavy, zvolte Podrobnosti a zobrazí se celý strom závislostí:

Zobrazení podrobností při instalaci komponenty populární geoprostorové knihovny Turf.js; všimněte si, že samotný balíček má licenci Permissive, ale jedna z přechodných závislostí má licenci AGPL; skutečně ji nelze použít pro proprietární software;

myslím si, že taková funkce musí být součástí npm CLI. Pokud souhlasíte, prosím ⭐️ projekt na GitHubu a já tuto myšlenku prosadím.

Zdroje

Uvádím své zdroje pro případ, že byste si chtěli mé závěry překontrolovat:

  • Pochopení modelu závislostí npm
  • Licencování open source: Co by měl vědět každý technolog | Opensource.com
  • Různé licence a komentáře k nim
  • Licence FLOSS (Free-Libre / Open Source Software) Slide
  • Licenční centrum | ifrOSS
  • Porovnání licencí svobodného a otevřeného softwaru – Wikipedie
  • Library (computing) – Wikipedie

Pokud byl článek užitečný, prosím 👏 a možná napíšu ještě jeden 😀