Zgodność licencyjna open source

Ta strona ma charakter ogólnoinformacyjny i nie stanowi porady prawnej. W sprawie decyzji dotyczących konkretnego produktu proszę skonsultować się z prawnikiem.

Rodzaje licencji open source

Rodzaj	Przykłady	Czego zwykle wymaga
Permisywna	MIT, BSD, Apache-2.0	Zachowania informacji o prawach autorskich i licencji. Apache-2.0 zawiera też postanowienia patentowe.
Słaby copyleft	LGPL, MPL-2.0	Udostępniania zmian w samym licencjonowanym komponencie
Silny copyleft	GPL-2.0, GPL-3.0	Oprogramowanie dystrybuowane z takim komponentem musi być oferowane na tych samych warunkach, wraz z kodem źródłowym
Sieciowy copyleft	AGPL-3.0	Tego samego co silny copyleft, a dodatkowo obowiązuje, gdy użytkownicy korzystają z oprogramowania przez sieć
Source-available	BUSL, SSPL	To nie open source: kod źródłowy jest widoczny, ale korzystanie z niego jest ograniczone

Czym jest licencja copyleft?

Licencja copyleft pozwala używać, zmieniać i udostępniać oprogramowanie pod warunkiem, że to, co Państwo dystrybuują, pozostaje na tych samych warunkach. Dzięki temu open source pozostaje otwarte. Ryzyko dla produktu komercyjnego polega na tym, że komponent z silnym copyleftem zlinkowany z Państwa kodem może wywołać pytanie, czy własny kod również trzeba udostępnić.

To, czy tak jest, zależy od sposobu użycia komponentu i sposobu dostarczania produktu. Oprogramowanie dystrybuowane do klientów jest bardziej narażone niż narzędzie wewnętrzne, a produkt SaaS zwykle unika warunków dystrybucji GPL, ale nie warunków AGPL.

Typowe ryzyka związane ze zgodnością

• Licencje przechodnie. Pakiet na licencji permisywnej może zależeć od pakietu objętego copyleftem. Sprawdzanie tylko zależności bezpośrednich tego nie wychwyci.
• Brakujące informacje licencyjne. Większość licencji wymaga zachowania informacji o autorstwie, a zapomniany plik z tymi informacjami to najczęstsze uchybienie.
• Zmienione licencje. Projekt może zmienić licencję w nowej wersji, więc aktualizacja może zmienić warunki, które Państwa obowiązują.
• Deklaracja a rzeczywistość. Metadane pakietu mogą być błędne lub niekompletne, a kod dołączony do projektu może mieć własną licencję.
• Due diligence. Nabywcy i duzi klienci proszą o inwentarz licencji, zwykle w krótkim terminie.

Jak zachować zgodność

1. Napisać politykę. Określić, które licencje są dozwolone, które wymagają przeglądu, a które są zakazane, w zależności od rodzaju produktu.
2. Zbudować inwentarz. SBOM wymienia każdy komponent wraz z licencją, łącznie z zależnościami przechodnimi.
3. Sprawdzać automatycznie. Egzekwować politykę w CI, aby nowa zależność była odrzucana w chwili dodania, a nie podczas audytu.
4. Spełniać obowiązki. Generować pliki z informacjami licencyjnymi i udostępniać kod źródłowy tam, gdzie wymaga tego licencja.
5. Przechowywać zapisy. Przechowywać inwentarz dla każdego wydania, ponieważ pytanie zwykle dotyczy wersji już dostarczonej.

Co robi oprogramowanie do zgodności licencyjnej

Zgodność licencyjna to standardowy element analizy składu oprogramowania. Narzędzia identyfikują komponenty, raportują ich licencje i oznaczają naruszenia Państwa polityki. Różnią się głębokością:

• Licencje deklarowane: większość narzędzi odczytuje to, co każdy pakiet deklaruje w metadanych. To szybkie i obejmuje typowy przypadek.
• Głębokie skanowanie licencji: FOSSA i Black Duck analizują też tekst licencji w kodzie oraz pomagają w raportach atrybucji i przeglądzie prawnym. Zob. CRACI a FOSSA i CRACI a Black Duck.
• Bezpłatne narzędzia: wiele generatorów SBOM i skanerów SCA bezpłatnie raportuje licencje deklarowane. Zob. najlepsze narzędzia SCA.

Gdzie jest miejsce CRACI

CRACI obsługuje licencje deklarowane w buildzie. Jako Państwa runner GitHub Actions rejestruje każdy pakiet pobrany przez zadanie, a każdy z nich ma deklarowaną licencję, więc licencje copyleft zostają wychwycone, zanim trafią do produktu. Reguły polityki licencyjnej mogą zablokować build ze względu na licencję, a eksporty SBOM w formatach CycloneDX i SPDX zawierają deklarowaną licencję każdego komponentu. CRACI opiera się na tym, co deklarują pakiety, więc jeśli potrzebują Państwo workflow przeglądu prawnego lub analizy tekstu licencji, należy użyć obok niego specjalistycznego narzędzia.

Zgodność licencyjna open source: najczęściej zadawane pytania

Czym jest zgodność licencyjna open source?

Oznacza wiedzę o tym, które licencje open source dotyczą używanego oprogramowania, i spełnianie ich warunków, takich jak zachowanie informacji licencyjnych lub udostępnianie kodu źródłowego.

Czym jest licencja copyleft?

To licencja, która pozwala używać i zmieniać oprogramowanie pod warunkiem, że to, co Państwo dystrybuują, pozostaje na tych samych warunkach. Najbardziej znanym przykładem jest GPL.

Czy można używać kodu GPL w oprogramowaniu komercyjnym?

Tak, ale jeśli dystrybuują Państwo oprogramowanie, które go zawiera, może być konieczne udostępnienie jego kodu źródłowego na licencji GPL. Znaczenie ma sposób połączenia kodu, dlatego w Państwa przypadku należy zasięgnąć porady prawnej.

Czy copyleft dotyczy SaaS?

Warunki GPL wchodzą w grę zasadniczo przy dystrybucji, której SaaS zwykle unika. AGPL zamyka tę lukę, rozszerzając warunki na użytkowników korzystających z oprogramowania przez sieć.

Jaka licencja open source jest najbezpieczniejsza do użytku komercyjnego?

Licencje permisywne, takie jak MIT, BSD i Apache-2.0, wymagają najmniej. Nadal trzeba zachować ich informacje licencyjne.

Jak sprawdzić licencje swoich zależności?

Wygenerować SBOM z zależnościami przechodnimi i deklarowanymi licencjami albo użyć narzędzia SCA. Egzekwować politykę w CI, aby nowe naruszenia powodowały niepowodzenie buildu.