Open source jest fundamentem nowoczesnego software. Problem nie polega na tym, że firma korzysta z cudzych bibliotek. Problem zaczyna się wtedy, gdy nikt nie wie, jakie komponenty są w produkcie, jaka wersja została użyta i jakie obowiązki licencyjne z niej wynikają.
Ryzyko często ujawnia się późno: klient enterprise pyta o SBOM, inwestor rozpoczyna due diligence, spółka przygotowuje sprzedaż produktu albo ktoś odkrywa komponent na licencji, której zespół wcześniej nie analizował.
Pierwszy krok: inwentaryzacja komponentów
Audyt open source zaczyna się od listy zależności. Potrzebujemy nazwy biblioteki, wersji, źródła, licencji, informacji o modyfikacjach i sposobie wykorzystania. W większych produktach dane te warto utrzymywać automatycznie w procesie developmentu, zamiast odtwarzać je przed transakcją.
Przydatnym formatem jest SBOM, ale sam dokument nie rozwiązuje kwestii prawnej. Trzeba jeszcze zinterpretować licencje i zrozumieć, jak komponent jest połączony z własnym kodem.
Permissive i copyleft – różne poziomy obowiązków
Licencje permissive zazwyczaj pozwalają szeroko korzystać z kodu, ale mogą wymagać zachowania informacji o prawach autorskich, treści licencji lub notice. Licencje copyleft mogą nakładać dalej idące obowiązki w określonych modelach dystrybucji.
Nie warto upraszczać problemu do hasła „GPL oznacza publikację całego kodu”. Ocena zależy od konkretnej licencji, sposobu połączenia komponentu, modyfikacji i tego, w jaki sposób produkt trafia do użytkownika.
Prawnik potrzebuje wiedzieć, jak komponent działa w produkcie. Developer potrzebuje wiedzieć, jakie skutki może mieć wybrana licencja.
Dystrybucja produktu a model SaaS
Obowiązki licencyjne mogą zależeć od tego, czy program jest przekazywany klientowi, instalowany w jego środowisku czy udostępniany jako usługa. Dlatego ta sama biblioteka może wymagać innej analizy w aplikacji desktopowej, urządzeniu embedded i usłudze chmurowej.
Niektóre licencje powstały właśnie po to, aby obejmować określone modele korzystania przez sieć. Przy produkcie SaaS nie można więc automatycznie zakładać, że brak klasycznej dystrybucji rozwiązuje każdy problem open source.
Notice, informacje o autorach i dokumentacja licencji
Nawet przy liberalnych licencjach obowiązki informacyjne potrafią zostać pominięte. Produkt może wymagać pliku THIRD-PARTY-NOTICES, informacji w dokumentacji albo zachowania konkretnego tekstu licencji.
Najlepiej przygotować jeden proces generowania i aktualizacji notice dla releasów. Ręczne kopiowanie informacji przez różne zespoły prowadzi do niespójności i szybko przestaje działać przy większym produkcie.
Umowy z developerami i software house’ami
Umowa powinna regulować zasady korzystania z komponentów osób trzecich. Można wymagać ujawnienia bibliotek, przestrzegania polityki klienta, zakazu określonych licencji bez zgody albo prowadzenia dokumentacji zależności.
Sam zapis, że wykonawca „gwarantuje legalność kodu”, ma ograniczoną wartość, jeżeli firma nie otrzymuje informacji, co rzeczywiście weszło do produktu. Przy zmianie dostawcy lub sprzedaży spółki brak dokumentacji staje się realnym problemem.
Open source policy dla zespołu
Polityka nie powinna blokować developerów przy każdej bibliotece. Jej celem jest podział komponentów na kategorie: akceptowane bez dodatkowej zgody, wymagające sprawdzenia i niedopuszczalne w określonych produktach.
Ważny jest też proces wyjątku. Jeżeli zespół ma silny techniczny powód, aby użyć komponentu o podwyższonym ryzyku, decyzja powinna być świadoma i udokumentowana, a nie ukryta w historii commitów.
Due diligence i klient enterprise
Podczas transakcji inwestor może sprawdzać łańcuch praw do kodu, umowy z developerami i ryzyko licencji open source. Klienci enterprise coraz częściej mają własne kwestionariusze dotyczące bezpieczeństwa i komponentów osób trzecich.
Firma, która ma aktualną inwentaryzację, policy i proces notice, odpowiada na takie pytania szybko. Firma bez tych elementów musi odtwarzać historię produktu pod presją transakcji, co zwiększa ryzyko opóźnień i obniża wiarygodność dokumentacji.
Jak zbudować proces open source compliance bez blokowania developerów?
Celem nie jest ręczne zatwierdzanie każdej popularnej biblioteki przez prawnika. Najpierw potrzebna jest widoczność: lista zależności, wersji i licencji możliwa do wygenerowania dla każdej istotnej wersji produktu. Zespół może korzystać z narzędzi technicznych, ale wynik musi być zrozumiały również dla osób odpowiadających za ryzyko i kontrakty z klientami.
Następnie tworzymy prostą politykę. Część licencji trafia na listę standardowo akceptowaną, część wymaga sprawdzenia w określonych scenariuszach, a część powinna uruchamiać eskalację przed użyciem. Kluczowe jest uwzględnienie nie tylko nazwy licencji, lecz także sposobu wykorzystania komponentu i dystrybucji produktu.
Przed ważnym releasem można automatycznie wygenerować raport zależności, sprawdzić nowe komponenty i potwierdzić wymagane notice’y. Dzięki temu ryzyko jest usuwane wtedy, gdy zmiana w kodzie jest jeszcze łatwa.
SBOM i dokumentacja pomagają także sprzedaży
Klienci enterprise coraz częściej pytają o komponenty zewnętrzne, bezpieczeństwo i proces zarządzania zależnościami. Aktualny wykaz komponentów ułatwia odpowiedź na questionnaire, przygotowanie załącznika kontraktowego i reakcję na podatność dotyczącą konkretnej biblioteki. To nie jest wyłącznie dokument dla prawników.
Przy due diligence analizujemy również umowy z developerami i software house’ami. Nawet świetnie prowadzony rejestr open source nie naprawi problemu, jeżeli firma nie ma uporządkowanych praw do własnego kodu albo kontrakt pozwala wykonawcy wprowadzać komponenty zewnętrzne bez żadnej kontroli. Te dwa obszary powinny być badane razem.
Checklista minimum dla open source compliance
Nie trzeba od razu budować rozbudowanego programu compliance. Minimum powinno jednak pozwalać odpowiedzieć, co znajduje się w produkcie i kto podjął decyzję o użyciu komponentu podwyższonego ryzyka.
- automatycznie generowana lista zależności i ich wersji dla głównych produktów;
- identyfikacja licencji oraz repozytorium wymaganych notice’ów;
- lista licencji standardowo akceptowanych oraz wymagających eskalacji;
- osoba lub zespół odpowiedzialny za wyjątki i pytania developerów;
- kontrola komponentów wprowadzanych przez zewnętrzne software house’y;
- sprawdzenie nowych zależności przed istotnym wydaniem produktu;
- możliwość szybkiego przygotowania informacji dla klienta enterprise lub inwestora.
Proces powinien być możliwie automatyczny. Jeżeli wymaga ręcznego raportowania każdej biblioteki przez developera, z dużym prawdopodobieństwem przestanie działać pod presją sprintu.
Możemy połączyć audyt licencji z analizą architektury, umów z developerami, policy zespołu i dokumentacji potrzebnej do due diligence.
Obsługa prawna firm technologicznych ↗