Zastrzeżenie: Jestem deweloperem, nie prawnikiem; te informacje są uważane za poprawne, ale nie są poradami prawnymi; jeśli uważasz, że coś jest niepoprawne, proszę, napisz komentarz i poprawimy to razem🔧

Przedtem nie przejmowałem się licencją pakietu npm. Mogłem sprawdzić licencję bezpośredniej zależności, ale nigdy nie sprawdzałem zależności 3rd party (przejściowych).

🚓 A potem spotkałem facetów z działu prawnego 🚓

Teraz wierzę, że programiści powinni mieć podstawowe zrozumienie licencjonowania oprogramowania, aby mieć konstruktywny dialog z zespołami prawnymi w swoich firmach. Ten post zbiera ogólną wiedzę o licencjach Open-Source i jak to się odnosi do zależności npm i rozwoju Full-Stack JavaScript w ogóle.

Zorientujmy się, kiedy powinieneś zacząć martwić się o licencje.

Kiedy wymagania licencyjne są uruchamiane?

Jeśli wykonujesz linkowanie z bibliotekami open source, a następnie dystrybuujesz powstałe oprogramowanie, wtedy twoje oprogramowanie musi być zgodne z wymaganiami linkowanych bibliotek.

Przyjrzyjrzyjmy się bliżej linkowaniu i dystrybucji stosowanym w aplikacjach JavaScript.

Łączenie

Używanie bibliotek stron trzecich zwykle oznacza łączenie ich:

  • Jeśli łączysz (tj. Z webpackiem) swój kod z pakietami open source, liczy się to jako statyczne łączenie
  • Jeśli używasz pakietu open source w swojej aplikacji Node.JS (tj. poprzez require) lub podłączasz go do strony internetowej poprzez tag script, jest to dynamiczne linkowanie

Uwaga: podczas budowania pakietu lub uruchamiania aplikacji Node.JS wykonujesz ten sam typ linkowania zarówno z natychmiastowymi (wymienionymi w twoim package.json), jak i przechodnimi (wymienionymi w 3rd party package.json) zależnościami. Natychmiastowe i przechodnie licencje zależności mają taki sam wpływ na twoje oprogramowanie.

To nie było dla mnie intuicyjne wcześniej 🤔

Dystrybucja

Samo używanie bibliotek open source nie musi wywoływać wymagań licencyjnych. Zazwyczaj wymagania licencyjne są uruchamiane, gdy rozpowszechniasz oprogramowanie:

  • Przekazywanie oprogramowania pomiędzy pracownikami tej samej firmy nie jest rozpowszechnianiem
  • Gdy użytkownicy wchodzą w interakcję z Twoją aplikacją Node.JS przez sieć, nie jest to dystrybucja dla większości licencji open source; ale jest to dystrybucja dla licencji Network Protective, takich jak AGPL
  • Umieszczenie plików JavaScript na publicznym serwerze WWW jest dystrybucją

Która licencja jest ok

Większość licencji open source generalnie należy do jednego z tych typów:

  • Public Domain i licencje permisywne, takie jak MIT, które pozwalają robić wszystko, z wyjątkiem pozywania autora
  • Copyleft lub licencje ochronne, takie jak GPL, uniemożliwiają łączenie (patrz wyżej) z oprogramowaniem prawnie zastrzeżonym; przypadek brzegowy to licencje chroniące sieć, takie jak Affero GPLv3, które wyzwalają przez interakcję w sieci;
  • Pomiędzy dwoma powyższymi są słabo chroniące licencje jak MPL, która ma mniej ograniczeń dla dynamicznego linkowania (dopóki biblioteka nie jest w swoim własnym pliku)

Sprawdźmy typowe scenariusze dla programisty JavaScript:

Tworzysz aplikację internetową

Najprawdopodobniej łączysz wszystkie swoje pliki, w tym biblioteki w jeden plik JS i umieszczasz go na serwerze WWW. Wykonujesz statyczne łączenie i dystrybucję. Dobrze jest używać pakietów z licencjami Permissive w pakiecie.

Jeśli musisz użyć pakietu z licencją słabo chroniącą jak MPL masz opcje:

  1. Wczytaj bibliotekę z osobnego pliku (np. poprzez tag skryptu)
  2. Zastosuj kompatybilną licencję open source do swojego pakietu (ale sprawdź komentarz poniżej i porozmawiaj ze swoim zespołem prawnym przed)

Jeśli twój pakiet nie posiada ✨cennej własności intelektualnej✨ to druga opcja powinna być w porządku. Nie wierzę, że konkurenci skorzystają z twojego obfuskowanego kodu. Ale jeśli pakiet zawiera cenną własność intelektualną, to zastosowanie licencji open source jest przyznaniem swobodnego korzystania z niej.

Tworzysz aplikację Node.JS

W tym przypadku, zwykle podłączasz biblioteki poprzez wywołanie require(). Jest to dynamiczne łączenie. Dobrze jest używać licencji Permissive, a nawet Weakly Protective. Tylko upewnij się, że pakiety pozostają w swoich własnych plikach z odpowiednimi licencjami.

Jeśli dostarczasz tylko SaaS i nie rozprowadzasz w żaden inny sposób, możesz używać nawet pakietów z licencją Protective. Dla wielu licencji ochronnych, interakcja sieciowa nie jest dystrybucją. Wyjątkiem są licencje chroniące sieć jak Affero GPLv3

Tworzysz pakiet Open Source NPM

Normalnie, podłączasz zależności stron trzecich poprzez package.json. Według mojej najlepszej wiedzy, wymienianie zależności w package.json nie może być traktowane jako łączenie. Łączenie zostanie wykonane przez programistę aplikacji, który użyje twojego pakietu na etapie budowania lub uruchamiania.

Jeśli nie chcesz zdezorientować użytkowników pakietu, upewnij się, że wszystkie zależności (zarówno natychmiastowe jak i przechodnie) mają licencje zgodne z licencją twojego pakietu.

Typowo licencje zależności powinny być bardziej liberalne lub na tym samym poziomie liberalności co licencja twojego pakietu.

Na przykład, jeśli twój pakiet ma licencję Apache 2.0 możesz używać zależności z licencją MIT i BSD. Ale nie powinieneś używać zależności z licencją MPL1.1 lub LGPLv3, ponieważ mają one silniejszy copyleft.

Strzałka od pola A do pola B oznacza, że można łączyć oprogramowanie z tymi licencjami; połączony wynik efektywnie ma licencję B, ewentualnie z dodatkami z A; obraz z pracy Davida A. Wheeler

Gdy musisz umieścić pakiety lub źródła stron trzecich w pakiecie NPM, nie zapomnij wymienić licencji stron trzecich i praw autorskich. Większość licencji open source wymaga potwierdzenia autora.

Dobrą praktyką jest również określenie poprawnego wyrażenia SPDX w licencji package.json. Uważam, że to pole musi być obowiązkowe do publikowania na npm.org.

Jak to rozgryźć

Wiele zespołów zaczyna myśleć o licencjach, gdy oprogramowanie jest gotowe do wysyłki. Używam do tego narzędzia ScanCode. To naprawdę idzie do każdego folderu twojego projektu i próbuje wykryć każdą licencję lub prawa autorskie.

Zrzut ekranu z https://github.com/nexB/scancode-toolkit

Prawdopodobnie musisz użyć tego lub podobnego narzędzia przed dystrybucją swojej aplikacji. Upewnij się, że sprawdzasz wystarczająco dużo, a nie za dużo:

  • zainstaluj wszystkie zależności produkcyjne przed uruchomieniem narzędzia
  • upewnij się, że devDependencies nie są sprawdzane przez narzędzie; normalnie nie rozpowszechniasz z zależnościami deweloperskimi;

Uwaga: jeśli, tak jak ja, patrzysz na licencje pakietów po tym, jak zintegrowałeś pakiet ze swoją aplikacją, możesz znaleźć się w trudnej sytuacji.

Running ScanCode just before deadline; image from https://giphy.com

How you figure it out before it’s too late

Zastanawiałem się, kiedy jest najlepszy czas na poznanie licencji zależności pakietów. Dla mnie, normalny przepływ odkrywania pakietów to:

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

Niestety npm.org nie zajmuje się tak naprawdę zależnościami przechodnimi. Istnieją narzędzia internetowe, takie jak http://npm.anvaka.com/; ale to nie pasuje do mojego przepływu odkrywania pakietów i ciągle zapominam go użyć. Pomyślałem, że najlepszym momentem na poznanie zależności pakietów jest wpisanie $ npm install <pkg>

To było moje myślenie, kiedy zbudowałem narzędzie CLI o nazwie npm-consider, które analizuje pakiet ze wszystkimi przechodnimi zależnościami przed zainstalowaniem lub nawet pobraniem go.

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

Aby zaoszczędzić jedno polecenie dla ciebie, zawija $ npm install i ma te same argumenty. Jeśli jesteś w porządku z zależnościami po prostu wybierz Install i uruchomi npm install jak zwykle. Jeśli jesteś zaniepokojony wybierz Szczegóły i zobacz całe drzewo zależności:

Pokazuje szczegóły podczas instalacji komponentu popularnej biblioteki geoprzestrzennej Turf.js; zauważ, że sam pakiet ma licencję Permissive, ale jedna z jego zależności ma licencję AGPL; nie możesz jej użyć dla oprogramowania własnościowego;

Wierzę, że taka funkcjonalność musi być częścią npm CLI. Jeśli się z tym zgadzasz, proszę ⭐️ projekt na GitHubie, a ja popchnę ten pomysł do przodu.

Źródła

Wypisuję moje źródła na wypadek, gdybyś chciał podwójnie sprawdzić moje wnioski:

  • Zrozumienie modelu zależności npm
  • Open source licensing: Co każdy technolog powinien wiedzieć | Opensource.com
  • Różne licencje i komentarze na ich temat
  • Licencja Free-Libre / Open Source Software (FLOSS) Slide
  • License Center | ifrOSS
  • Porównanie licencji wolnego i otwartego oprogramowania – Wikipedia
  • Biblioteka (informatyka) – Wikipedia

Jeśli artykuł był pomocny, proszę 👏 i może napiszę jeszcze jeden 😀

.