Jak sprawdzić licencje open source w oprogramowaniu i przygotować SBOM?

Software house powinien móc ustalić skład każdej wydanej wersji oprogramowania. Bez takiej informacji trudno zweryfikować warunki licencji, zareagować na podatność, przygotować dokumentację dla klienta albo wykazać zgodność podczas audytu. Problem nie kończy się na bibliotekach wpisanych bezpośrednio do pliku zależności. Projekt może zawierać również zależności przechodnie instalowane przez inne pakiety, komponenty front-endowe, skopiowane fragmenty kodu, obrazy kontenerów, narzędzia generujące kod, sterowniki i biblioteki systemowe, czy też zasoby graficzne, fonty lub dokumentację udostępniane na odrębnych licencjach.

Ręczna lista przygotowana pod koniec projektu może nie uwzględniać pełnego obrazu oprogramowania. Potrzebny jest proces powiązany z konkretnym repozytorium, buildem i wersją produktu.

W ustaleniu poszczególnych komponentów oprogramowania nie chodzi tylko o weryfikację czy wolno i jak korzystać z oprogramowań open source. W niektórych projektach istotna jest szczególnie skalowalność i możliwość wykazania klientowi, audytorowi, inwestorowi albo organowi nadzoru bezpieczeństwa oprogramowania.

SBOM, czyli Software Bill of Materials, jest formalnym wykazem składników oprogramowania oraz relacji między nimi. Można go porównać do zestawienia materiałów wykorzystanych do wytworzenia konkretnej wersji produktu. Cyber Resilience Act definiuje SBOM jako formalny zapis zawierający szczegółowe informacje i relacje w łańcuchu dostaw komponentów znajdujących się w elementach programowych produktu.

Prawidłowo przygotowany SBOM może wskazywać między innymi:

Do najczęściej stosowanych formatów SBOM należą SPDX i CycloneDX. Oba służą do uporządkowanego zapisywania informacji o komponentach użytych w oprogramowaniu, ale mają nieco inne akcenty. SPDX został stworzony przede wszystkim z myślą o identyfikacji komponentów, praw autorskich i licencji open source, dlatego jest szczególnie przydatny przy analizie zgodności licencyjnej. CycloneDX jest mocniej ukierunkowany na cyberbezpieczeństwo i zarządzanie łańcuchem dostaw oprogramowania – poza informacją o komponentach może być wykorzystywany m.in. do powiązania ich z podatnościami i oceną ryzyka.

Nie, SBOM oraz weryfikacja licencji open source są ze sobą ściśle powiązane, ale pełnią inne funkcje. SBOM służy przede wszystkim do ustalenia, jakie komponenty znajdują się w konkretnej wersji oprogramowania. Analiza licencyjna idzie krok dalej, tj. pozwala ustalić, na jakich warunkach można z tych komponentów korzystać, modyfikować je i udostępniać. Osobnym elementem jest analiza podatności, która odpowiada na pytanie, czy konkretna wersja biblioteki lub innego komponentu zawiera znaną lukę bezpieczeństwa. Całość może uzupełniać wewnętrzna polityka open source określająca, kto w organizacji może zatwierdzić użycie danego komponentu i według jakich zasad.

Samo wygenerowanie SBOM w formacie SPDX albo CycloneDX nie oznacza więc, że oprogramowanie jest zgodne z warunkami licencji open source. SBOM jest przede wszystkim inwentaryzacją składu oprogramowania. Na jego podstawie można dopiero przeprowadzić właściwą analizę: ustalić licencję każdego komponentu, sprawdzić jej warunki i ocenić, jakie obowiązki powstają przy konkretnym sposobie wykorzystania kodu.

Ma to znaczenie zwłaszcza przy licencjach typu copyleft. Sama informacja, że w produkcie znajduje się komponent na licencji GPL, LGPL czy AGPL, nie daje jeszcze odpowiedzi, jakie będą tego konsekwencje. Trzeba zbadać m.in. czy komponent został zmodyfikowany, w jaki sposób został połączony z własnym kodem oraz czy oprogramowanie jest dystrybuowane, instalowane u klienta czy udostępniane jako usługa.

W praktyce można więc przyjąć proste rozróżnienie: SBOM odpowiada na pytanie „co znajduje się w naszym oprogramowaniu?”, a analiza licencyjna „co możemy z tym zrobić i jakie warunki musimy spełnić?”.

Nie istnieje jeden ogólny obowiązek przygotowania SBOM dla każdego projektu informatycznego. Obowiązek trzeba oceniać w odniesieniu do konkretnego produktu, roli przedsiębiorcy, regulacji sektorowych oraz umowy z klientem. Najważniejszą regulacją unijną jest rozporządzenie Parlamentu Europejskiego i Rady (UE) 2024/2847, czyli Cyber Resilience Act. Rozporządzenie dotyczy produktów z elementami cyfrowymi udostępnianych na rynku Unii Europejskiej i obejmuje również oprogramowanie, jeżeli spełnia przesłanki wskazane w rozporządzeniu.

Cyber Resilience Act wszedł w życie 10 grudnia 2024 r. Przepisy dotyczące notyfikacji jednostek oceniających zgodność stosuje się od 11 czerwca 2026 r., obowiązki raportowe z art. 14 będą stosowane od 11 września 2026 r., a zasadnicza część rozporządzenia od 11 grudnia 2027 r.

W dokumentacji technicznej produktu objętego CRA ma znaleźć się, co do zasady, SBOM w powszechnie używanym i maszynowo czytelnym formacie, obejmujący przynajmniej zależności najwyższego poziomu.

Open source nie oznacza braku praw autorskich. Autor udostępnia kod na warunkach licencji, która określa zakres dozwolonego korzystania oraz obowiązki użytkownika.

Na gruncie polskiej ustawy o prawie autorskim i prawach pokrewnych program komputerowy podlega ochronie jako utwór, a autorskie prawa majątkowe obejmują między innymi jego zwielokrotnianie, modyfikowanie i rozpowszechnianie. Dyrektywa 2009/24/WE harmonizuje podstawowe zasady ochrony programów komputerowych w Unii Europejskiej.

Jeżeli przedsiębiorca przekracza zakres zezwolenia albo nie wykonuje warunków licencji, może naruszać autorskie prawa majątkowe. Uprawniony może wówczas dochodzić roszczeń przewidzianych w art. 79 ustawy, w tym zaniechania naruszeń, usunięcia ich skutków, naprawienia szkody lub wydania uzyskanych korzyści. W określonych okolicznościach znaczenie mogą mieć również przepisy karne ustawy, ale odpowiedzialności karnej nie należy przedstawiać jako automatycznego skutku każdego uchybienia licencyjnego.

W relacji z klientem dochodzi odpowiedzialność kontraktowa. Jeżeli software house zapewnił, że produkt nie zawiera komponentów copyleft albo że wszystkie licencje zostały prawidłowo rozliczone, niezgodność może stanowić nienależyte wykonanie umowy.

Obowiązki zależą od dokładnej wersji licencji, sposobu połączenia komponentu z pozostałym kodem oraz modelu udostępniania produktu.

Licencje permisywne

Licencje MIT, BSD i Apache-2.0 pozwalają zwykle na szerokie komercyjne wykorzystanie kodu. Nie oznacza to jednak braku obowiązków. Najczęściej trzeba:

• zachować informację o prawach autorskich,
• dołączyć treść licencji,
• zachować wymagane informacje prawne,
• w przypadku Apache-2.0 prawidłowo obsłużyć plik NOTICE, jeżeli występuje,
• nie sugerować poparcia produktu przez autora komponentu.

Apache-2.0 reguluje również określone kwestie patentowe.

Licencje copyleft

Licencje GPL, LGPL, AGPL i MPL przewidują mechanizmy copyleft o różnym zakresie. Nie każda z nich prowadzi do objęcia tymi samymi obowiązkami całego produktu. W szczególności trzeba przeanalizować:

• czy komponent został zmodyfikowany,
• czy jest jedynie agregowany, czy połączony z własnym kodem,
• czy występuje linkowanie statyczne lub dynamiczne,
• czy produkt jest przekazywany klientowi lub użytkownikowi,
• czy kod jest udostępniany jako usługa sieciowa,
• czy zastosowanie ma wyjątek licencyjny,
• jaka dokładnie wersja licencji obowiązuje.

Jeżeli w tworzonym oprogramowaniu wykorzystywane są komponenty open source, umowa z klientem powinna określać zasady ich stosowania oraz podział odpowiedzialności pomiędzy software house, klienta oraz ewentualnych podwykonawców. W umowie można przede wszystkim określić, jakie rodzaje licencji są dopuszczalne, a użycie których wymaga wcześniejszej zgody klienta. Dotyczy to zwłaszcza licencji typu copyleft, takich jak GPL czy AGPL, jeżeli ze względu na sposób wykorzystania komponentu mogą wiązać się z dodatkowymi obowiązkami dotyczącymi kodu źródłowego.

Warto również ustalić zasady dokumentowania wykorzystanego open source. Umowa może określać, czy i kiedy software house przekazuje klientowi SBOM, w jakim formacie oraz jak szczegółowy powinien być wykaz komponentów. Osobno można uregulować przygotowanie wymaganych informacji licencyjnych i plików NOTICE oraz wykonanie ewentualnych obowiązków związanych z udostępnieniem kodu źródłowego.

Znaczenie ma także sposób postępowania już po zaakceptowaniu komponentu. Umowa może określać, kto odpowiada za monitorowanie podatności, w jakich sytuacjach komponent powinien zostać zaktualizowany lub zastąpiony oraz kto ponosi koszty takiej zmiany. Ma to szczególne znaczenie w projektach utrzymywanych przez kilka lat, w których skład oprogramowania i wersje wykorzystywanych bibliotek zmieniają się już po pierwszym wdrożeniu.

Osobnego uregulowania wymaga odpowiedzialność za zgodność licencyjną. Inaczej można rozłożyć ryzyko w odniesieniu do komponentu samodzielnie wybranego przez software house, a inaczej wtedy, gdy wykorzystanie konkretnej biblioteki zostało narzucone przez klienta. Umowa może również określać zakres oświadczeń wykonawcy dotyczących zgodności z licencjami open source oraz zasady postępowania w razie wykrycia naruszenia.

Nie zawsze dobrym rozwiązaniem jest natomiast zapewnienie, że tworzone oprogramowanie w ogóle nie zawiera komponentów open source. W wielu współczesnych projektach informatycznych takie zobowiązanie byłoby trudne do wykonania i nie odpowiada rzeczywistości. Samo wykorzystanie open source nie stanowi bowiem wady oprogramowania. Istotne jest to, jakie komponenty zostały wykorzystane, na jakich licencjach i czy wynikające z nich obowiązki zostały prawidłowo wykonane.

Podsumowując, SBOM to uporządkowany, możliwy do przetwarzania maszynowego wykaz komponentów znajdujących się w określonej wersji oprogramowania. Nie zastępuje jednak analizy prawnej licencji. SBOM odpowiada przede wszystkim na pytanie, co znajduje się w produkcie, natomiast weryfikacja licencji pozwala ustalić, na jakich warunkach można tego używać, modyfikować i udostępniać. W software house oba procesy powinny być połączone z pipeline’em CI/CD, dokumentacją wydania oraz zasadami współpracy z klientem.

Silesia Legal House wspiera software house’y i firmy technologiczne w prawnej weryfikacji komponentów open source oraz tworzeniu zasad ich bezpiecznego wykorzystywania w projektach. Możemy pomóc m.in. w analizie licencji wykazanych w SBOM, ocenie ryzyk związanych z licencjami copyleft, przygotowaniu wewnętrznej polityki korzystania z open source oraz odpowiednich postanowień w umowach z klientami. W razie wątpliwości dotyczących konkretnego komponentu lub całego projektu możesz skontaktować się z naszym zespołem.