Open source w produkcie komercyjnym: GPL, MIT, Apache i obowiązki licencyjne

Open source to licencja, a nie brak właściciela

Kod opublikowany w repozytorium pozostaje przedmiotem praw autorskich, chyba że wynika inaczej z odpowiednich okoliczności prawnych. Licencja udziela określonych uprawnień i przewiduje warunki ich wykonywania. Nie należy zakładać, że publicznie dostępny kod bez pliku LICENSE można bez ograniczeń skopiować do własnego produktu. W firmie konieczny jest rejestr komponentów, ich wersji i podstaw korzystania, niezależnie od popularności repozytorium.

Licencje permisywne – przykład MIT

Licencja MIT dopuszcza szeroki zakres użycia, modyfikowania, łączenia i dystrybucji, również w produktach komercyjnych. Istotne jest zachowanie wymaganego oznaczenia praw autorskich i tekstu licencji w odpowiednich kopiach lub istotnych fragmentach oprogramowania. Sam fakt korzystania z MIT nie oznacza konieczności publicznego otwierania całego autorskiego kodu przedsiębiorcy. Nie można jednak usunąć wymaganych informacji tylko dlatego, że produkt jest sprzedawany pod inną marką.

Apache 2.0 i zagadnienia patentowe

Apache License 2.0 również pozwala na szerokie komercyjne wykorzystanie, ale zawiera odrębne zasady dotyczące informacji licencyjnych, zmian w plikach i dokumentu NOTICE, jeśli ma zastosowanie. Istotny jest także mechanizm licencji patentowej oraz warunki jej zakończenia w określonych sporach patentowych. Przy projektach dużego ryzyka prawnego nie należy traktować Apache 2.0 jako odpowiednika MIT w każdej kwestii. Potrzebna jest analiza rzeczywiście użytej wersji.

GPL i mechanizm copyleft

Licencje GNU GPL zawierają zasady, które przy określonym rozpowszechnianiu programu lub utworu objętego ich warunkami mogą wymagać udostępnienia odpowiedniego kodu źródłowego oraz zachowania kompatybilnych warunków licencyjnych. Dokładny zakres zależy od wersji GPL, sposobu łączenia komponentów i dystrybucji. Nie można jednak streszczać GPL twierdzeniem, że każde użycie biblioteki automatycznie zmusza firmę do opublikowania całego kodu. Należy przeanalizować konkretne zależności.

GPL, LGPL i AGPL nie są identyczne

LGPL przewiduje szczególne zasady korzystania z bibliotek, a AGPL obejmuje dodatkowe mechanizmy odnoszące się do użytkowania przez sieć. Znaczenie ma to, czy firma dystrybuuje kod, oferuje usługę SaaS albo modyfikuje konkretny komponent. Te same zasady nie działają automatycznie we wszystkich licencjach. W projektach opartych na wielu bibliotekach trzeba wyjaśnić, które z nich są komponentami programu, a które narzędziami wykorzystywanymi tylko w procesie budowania.

Dystrybucja a użycie wewnętrzne

Obowiązki udostępnienia kodu źródłowego mogą zależeć od tego, czy oprogramowanie jest przekazywane odbiorcy, czy tylko wykorzystywane wewnętrznie. Zewnętrzny klient instalujący aplikację znajduje się w innej sytuacji niż pracownik uruchamiający narzędzie na firmowym serwerze. W modelu chmurowym trzeba dodatkowo sprawdzić, czy dana licencja zawiera reguły dotyczące dostępu przez sieć. Nie istnieje jedna odpowiedź dla każdego rodzaju SaaS i każdej wersji licencji copyleft.

Kompatybilność licencji

Produkt może zawierać komponenty na kilku licencjach, których warunki trzeba odczytać łącznie. Niektóre sposoby łączenia i dystrybucji mogą rodzić konflikt między obowiązkami wynikającymi z poszczególnych licencji. W praktyce należy znać drzewo zależności i ustalić, w jaki sposób biblioteki są wykorzystywane. Nie wystarczy zeskanować wyłącznie bezpośrednich zależności z pliku konfiguracyjnego; znaczenie mogą mieć również komponenty przejściowe.

SBOM i automatyczny audyt zależności

Software Bill of Materials pozwala zidentyfikować komponenty, wersje i ich źródła. Narzędzia skanujące licencje są użyteczne, ale wyniki wymagają kontroli, ponieważ metadane repozytoriów bywają niepełne lub błędne. Firma powinna dokumentować decyzje dotyczące niejasnych licencji, źródeł binarnych i kodu skopiowanego bezpośrednio do projektu. Audyt łączy kwestie praw autorskich z bezpieczeństwem łańcucha dostaw i zarządzaniem podatnościami.

Postanowienia w umowie z wykonawcą software house

Gdy kod tworzy zewnętrzny wykonawca, należy wymagać wykazu komponentów open source oraz potwierdzenia zgodności z licencjami. Warto określić, kto odpowiada za usuwanie niezgodnych zależności i za roszczenia osób trzecich. Samo ogólne oświadczenie o przeniesieniu praw autorskich do całego projektu nie oznacza, że wykonawca może przenieść prawa do cudzych bibliotek. Kontrakt musi rozróżniać kod autorski i komponenty licencjonowane.

Jak reagować na naruszenie licencji

Po wykryciu niezgodności warto ustalić komponent, wersję, sposób wykorzystania i realnie naruszony warunek. Rozwiązaniem może być usunięcie nieprawidłowego elementu, spełnienie obowiązków informacyjnych albo zmiana modelu dystrybucji. Nie każda niezgodność wymaga wycofania całego produktu, ale opóźnianie reakcji zwiększa ryzyko. Należy dokumentować podjęte działania i unikać publicznego oświadczenia, że oprogramowanie jest „wolne od praw autorskich”.

Czym różni się kod źródłowy od dokumentacji wdrożenia

W niektórych reżimach licencyjnych obowiązek dotyczący odpowiedniego kodu źródłowego nie kończy się na przekazaniu pojedynczego pliku tekstowego. Trzeba zbadać właściwą definicję kodu źródłowego oraz ewentualne wymagania obejmujące skrypty i informacje potrzebne do wytworzenia działającego programu. Zakres zależy od konkretnej wersji licencji i modelu dystrybucji. Nie należy ani sztucznie poszerzać go na każdą część infrastruktury firmy, ani ograniczać do minimalnego fragmentu pozwalającego jedynie odczytać nazwę zależności. Dokumentacja powinna odpowiadać rzeczywistemu sposobowi przekazywania produktu.

Strategia przy nabyciu spółki technologicznej

Przy transakcji M&A audyt licencji open source powinien stanowić część badania własności intelektualnej obok umów z pracownikami i wykonawcami. Warto zweryfikować, czy firma zna pochodzenie kodu, ma rejestr komponentów, posiada obowiązkowe oznaczenia i prawidłowo obsługuje dystrybucję. Brak problemu zgłoszonego przez społeczność projektu nie oznacza automatycznie zgodności. Istotne mogą być również zależności porzucone, podatności bezpieczeństwa i pakiety o niejasnym prawie do udostępnienia. Wynik audytu powinien wskazywać konkretny plan usunięcia niezgodności, a nie tylko ogólne oświadczenie sprzedającego.

Powiązane analizy

Umowa wdrożenia AI – klauzule · Umowa przeniesienia praw autorskich