W 2021 roku twórcy silnika szachowego Stockfish pozwali ChessBase do sądu. Powód? ChessBase naruszyła Powszechną Licencję Publiczną GNU (GPL). Wykorzystali oni kod open source Stockfish we własnym produkcie, jednocześnie reklamując go jako własny, co stanowiło naruszenie umowy. Po latach domniemanej niezgodności, zespół Stockfish pozwał ChessBase. Doprowadziło to do zawarcia głośnej ugody. Wynik sprawy zmusił ChessBase do usunięcia swojej oferty z rynku.
Problem polega na tym, że większość aplikacji korzysta z zewnętrznych bibliotek lub kodu. Nie chodzi o to, że programiści są leniwi, ale nie musimy wymyślać koła na nowo dla każdej nowej aplikacji. Korzystanie z otwartego oprogramowania daje nam dostęp do bezpośrednich rozwiązań naszych problemów. Prowadzi to do ważnej części tworzenia aplikacji: sprawdzania licencji zainstalowanych zależności.
Jeśli tego nie zrobimy, możemy znaleźć się w sytuacji podobnej do ChessBase i ponieść poważne konsekwencje prawne. Może się tak zdarzyć, ponieważ jedna z bibliotek mogła zostać stworzona na restrykcyjnej lub niekompatybilnej licencji.
Jak pojedynczy pakiet może zmusić cię do otwarcia kodu źródłowego
Wyobraź sobie sytuację, w której instalujesz przydatny pakiet w swojej aplikacji. Pracujesz dla dużej firmy, która właśnie opracowała nowe rozwiązanie i wszystko jest gotowe do uruchomienia. Problem polega jednak na tym, że użyta biblioteka jest licencjonowana na zasadach Powszechnej Licencji Publicznej GNU (GPL).
Ten rodzaj licencji, choć nie jest z natury zły, wiąże się z obowiązkami, które mogą nie być zgodne z celami projektu. Przykładowo, licencja GPL wymaga, by wszelkie oprogramowanie utworzone na podstawie kodu objętego licencją GPL, w tym twoje własne oprogramowanie, jeśli jest uważane za dzieło pochodne, było udostępniane publicznie. Oznacza to, że pracodawca może być prawnie zobowiązany do udostępnienia kodu źródłowego istotnych części aplikacji. Może to spowodować ujawnienie tajemnic handlowych lub własności intelektualnej.
Dlaczego ręczne kontrole mogą przynieść oszczędności, ale wiąże się to z kosztami
Ręczne przeglądanie wszystkich pakietów w aplikacji może wydawać się dobrym sposobem na uniknięcie problemów. Ale tutaj jest haczyk,aplikacje często opierają się na setkach zewnętrznych bibliotek. Każda z tych bibliotek może pobierać dodatkowe zależności, nawet nie zdając sobie z tego sprawy.Liczba ta sprawia, że ręczne sprawdzanie jest czasochłonne i podatne nabłędy. Łatwo jest przeoczyć pakiet lub źle zinterpretować licencję.
Ponadto, nawet jeśli uda ci się ukończyć przegląd, będziesz musiał udokumentować swoje ustalenia w sposób, do którego można się później odwołać. Choć teoretycznie ręczne kontrole mogą uchronić Cię przed kłopotami, w większości przypadków są one niepraktyczne. Dotyczy to zwłaszcza dużych projektów. Czy automatyczne kontrole mogą być odpowiedzią, której szukamy?
Jak uruchomić automatyczne sprawdzanie licencji?
Jak zawsze w przypadku oprogramowania, ktoś już zmierzył się z tym problemem i go rozwiązał. Istnieje wiele narzędzi, które sprawdzają licencje i generują szczegółowe raporty. Narzędzia te zmniejszają ryzyko przeoczenia problematycznych licencji i ułatwiają dokumentowanie ustaleń.
W ekosystemie Node.js popularne menedżery zależności, takie jak npm i Yarn, oferują rozwiązania pomagające usprawnić ten proces. Przykładowo, Yarn zawiera polecenie yarn licenses list. Generuje ono czytelny raport wszystkich zależności i ich licencji.
Jeśli korzystasz z menedżera pakietów npm, nie ma wbudowanego polecenia do sprawdzania licencji. Zamiast tego będziesz musiał polegać na narzędziach innych firm. Oto trzy z najpopularniejszych opcji:
Jak korzystać z narzędzia do sprawdzania licencji podczas audytów?
Jednym z najskuteczniejszych narzędzi do audytu licencji jest license-checker. Generuje on przejrzyste, łatwe do odczytania raporty zależności projektu i ich licencji. Aby rozpocząć, zainstaluj go globalnie za pomocą npm:
bash
npm install -g license-checker Po zainstalowaniu przejdź do katalogu projektu i uruchom aplikację:
bash
license-checker Spowoduje to wygenerowanie szczegółowego raportu podobnego do wyników narzędzi Yarn do sprawdzania licencji.
Narzędzie do sprawdzania licencji może również utworzyć podsumowanie zależności projektu, grupując je według typu licencji. Jest to pomocne w szybkim zrozumieniu licencji aplikacji. Aby wygenerować podsumowanie, wystarczy uruchomić następujące polecenie:
bash
license-checker --summary
Czym jest plik BOM i dlaczego jest potrzebny?
Po wygenerowaniu raportu licencyjnego ważne jest, aby zapisać go do wykorzystania w przyszłości i udostępnić go swojemu zespołowi lub pracodawcy. Dobrym sposobem na to jest utworzenie pliku Bill of Materials (BOM), który dokumentuje wszystkie zewnętrzne licencje pakietów. Wygenerowanie takiego pliku jest proste: wystarczy przesłać dane wyjściowe narzędzia (takiego jak license-checker) do pliku:
bash
license-checker > BOM.txtAby zapewnić jeszcze większe bezpieczeństwo, warto rozważyć zintegrowanie tego kroku z potokiem CI w celu oznaczenia niezatwierdzonych licencji. Ponadto narzędzia takie jak generatory SBOM mogą być zgodne ze standardami branżowymi, takimi jak SPDX, w celu zwiększenia zgodności z przepisami
Dlaczego audyt licencji nie podlega negocjacjom
Jako programiści łatwo jest przeoczyć audyty licencji, zwłaszcza gdy żongluje się napiętymi terminami. Jednak pominięcie tego kroku może poważnie zaszkodzić nie tylko tobie, ale i całej firmie. Chociaż zautomatyzowane narzędzia są niezbędne, nadal mogą wymagać ludzkiego nadzoru, zwłaszcza w przypadku interpretacji przypadków brzegowych, takich jak zależności z podwójną licencją lub niestandardowy tekst licencji.
Poświęć trochę czasu na przeprowadzenie audytu licencji dla swoich zależności, udostępnij wyniki swojemu zespołowi lub pracodawcy (plik BOM świetnie się do tego nadaje) i rozważ zautomatyzowanie procesu w swoim potoku CI. To niewielki wysiłek, który może zaoszczędzić mnóstwo bólu głowy w przyszłości. Nie pozwól, aby jedna przeoczona licencja stała się powodem, dla którego Twoja ciężka praca kończy się problemami prawnymi.
