Co to jest licencja GPL (GNU General Public License) i na czym polega?

Licencja GPL (GNU General Public License) to najpopularniejsza umowa prawna typu copyleft, która gwarantuje użytkownikom prawo do swobodnego uruchamiania, analizowania, modyfikowania i udostępniania kodu źródłowego oprogramowania. Polega ona na bezwzględnym wymogu, by każda zmodyfikowana lub rozbudowana wersja programu oparta na kodzie GPL była dystrybuowana dokładnie na tych samych, otwartych warunkach. Zasada jest prosta. Jeśli bierzesz nasz otwarty kod i robisz na jego bazie własny produkt, musisz udostępnić źródła tego nowego produktu społeczności.

Twórcą tego mechanizmu jest Richard Stallman, a nadzór nad nim sprawuje Free Software Foundation. GPL odwraca tradycyjne pojęcie praw autorskich. Zamiast zabraniać kopiowania i modyfikacji, licencja ta wykorzystuje prawo autorskie do wymuszenia wolności oprogramowania. To fundament, na którym zbudowano jądro Linuxa, systemy GNU i tysiące narzędzi deweloperskich używanych na serwerach całego świata. Wymuszamy otwartość prawem.

Dlaczego licencja GPL nazywana jest licencją wirusową?

Określenie „wirusowa” ma zabarwienie pejoratywne, narzucone głównie przez prawników z korporacji produkujących oprogramowanie o zamkniętym kodzie. Prawda jest zresztą absolutnie taka, że licencja GPL po prostu chroni własne warunki przed zawłaszczeniem. Kiedy programista włącza kod na licencji GNU General Public License do swojego prywatnego, autorskiego projektu, cały wynikowy projekt (tzw. dzieło pochodne) automatycznie dziedziczy warunki GPL. Musisz udostępnić wszystko. Nie ma wyjątków.

W praktyce oznacza to potężny ból głowy dla firm technologicznych. Jeśli pobierzesz z GitHuba małą bibliotekę matematyczną na GPL i podepniesz ją do swojego komercyjnego systemu do fakturowania, w świetle prawa cały twój system staje się objęty licencją GPL. Powinieneś udostępnić jego kod źródłowy każdemu klientowi, któremu sprzedałeś licencję na użytkowanie. Mechanizm ten rozprzestrzenia się z pliku na plik, z modułu na moduł, infekując zamknięte repozytoria niczym wirus. Tak to działa.

Pamiętam wdrożenie systemu monitoringu sieci w małej spółce na warszawskim Targówku. Zrobiliśmy instalację oprogramowania opartego w dużej mierze na GPL, po czym zarząd zażądał zamknięcia zmodyfikowanego kodu w ich prywatnym repozytorium do odsprzedaży zewnętrznym partnerom. Powiedziałem im wprost, że łamią prawo autorskie. Zrobiliśmy na wdrożeniu audyt zależności, potem zawiesiło się całe środowisko testowe, więc wprowadzono poprawkę izolującą otwarty kod przed poniedziałkiem. Najlepszym wyjściem z takich sytuacji jest zawsze fizyczne oddzielenie logiki biznesowej w osobnych mikrousługach, które komunikują się z modułami GPL wyłącznie przez standardowe API sieciowe, a nie przez bezpośrednie linkowanie bibliotek w pamięci.

Czy oprogramowanie na licencji GPL można sprzedawać za pieniądze?

Tak. Oprogramowanie na licencji GPL można legalnie sprzedawać za dowolną kwotę. To jeden z największych i najgłupszych mitów branży IT, że wolne oprogramowanie musi być darmowe. Free Software Foundation wyraźnie zaznacza, że słowo „free” odnosi się do wolności słowa, a nie do darmowego piwa. Możesz spakować system Linux na pendrive i sprzedawać go za tysiąc złotych pod warunkiem, że znajdziesz kupca.

Haczyk polega na czymś zupełnie innym. Jeśli sprzedasz mi ten program za tysiąc złotych, licencja GPL daje mi prawo do natychmiastowego opublikowania jego kodu źródłowego w internecie za darmo. Ja mam do tego pełne prawo. Ty nie możesz mi tego zabronić żadną dodatkową umową NDA, bo licencja nadrzędna to unieważnia. Dlatego model biznesowy wokół GPL rzadko opiera się na samej sprzedaży binarnej kopii programu.

Pieniądze zarabia się na usługach. Red Hat zbudował potężne imperium, sprzedając wsparcie techniczne, certyfikacje i gwarancje bezpieczeństwa dla swojego systemu operacyjnego opartego na GPL. Klienci korporacyjni płacą za to, żeby ktoś odebrał telefon o drugiej w nocy, gdy serwer bazy danych odmawia posłuszeństwa. Sam kod jest wolny, ale czas inżyniera kosztuje rynkowe stawki. Dobrym pomysłem jest oferowanie płatnych wdrożeń i konfiguracji systemu, zamiast próby ukrywania samego kodu przed klientem.

Jak licencja GNU General Public License wpływa na zamknięty kod w firmie?

Obecność kodu GPL w zamkniętym środowisku korporacyjnym to tykająca bomba prawna. Zależnie od tego, jak technicznie łączysz swoje oprogramowanie z kodem GPL, możesz narazić firmę na utratę własności intelektualnej. Granica przebiega w miejscu, które prawnicy nazywają tworzeniem dzieła pochodnego. Statyczne linkowanie bibliotek (static linking) z kodem GPL w językach takich jak C czy C++ bezwzględnie tworzy dzieło pochodne. Wynikowy plik wykonywalny to jeden wielki blok kodu objęty nakazem otwarcia.

Dynamiczne linkowanie (dynamic linking) to szara strefa. Free Software Foundation twardo stoi na stanowisku, że linkowanie dynamiczne również tworzy dzieło pochodne i wymusza GPL na całości. Część prawników ma odmienne zdanie, ale mało kto ma ochotę testować to w sądzie z potężną fundacją. Chociaż prawdę mówiąc brakuje nam twardych danych z wokand za ubiegły rok, więc wydaje się to tylko jedną z możliwych hipotez na najbliższy kwartał przed spowolnieniem rynku, że większość pozwów o naruszenie GPL kończy się cichą ugodą finansową i pospiesznym usunięciem spornego kodu z produktu.

Prawda jest zresztą absolutnie taka, że deweloperzy często kompletnie ignorują pliki licencyjne. Zrzucają paczki z GitHuba, kompilują to u siebie na szybko we wtorek o trzeciej nad ranem, a potem dział prawny w korporacji dostaje zawału na audycie przed wypuszczeniem produktu na rynek zewnętrzny. Sam się nad tym borykałem dzisiaj u siebie w zespole. Nikt nie czyta nagłówków w plikach źródłowych. Szacuje się po cichu, że bez mała osiemdziesiąt procent firm ma w swoich repozytoriach nieudokumentowane zależności oparte na wirusowych licencjach, o których zarząd nie ma zielonego pojęcia.

Czym licencja GPL różni się od LGPL i AGPL?

Z biegiem lat rodzina licencji GNU rozrosła się o warianty dostosowane do specyficznych potrzeb technicznych. Zwykłe GPL okazało się zbyt restrykcyjne dla twórców małych bibliotek programistycznych. Gdyby popularna biblioteka C (glibc) była na zwykłym GPL, żaden zamknięty program nie mógłby działać na Linuxie. Dlatego stworzono LGPL (Lesser General Public License).

LGPL pozwala na dynamiczne linkowanie otwartej biblioteki z zamkniętym programem komercyjnym bez wymogu otwierania kodu tego programu. Wymóg copyleft dotyczy tylko samej biblioteki. Jeśli znajdziesz w niej błąd i go poprawisz, musisz odesłać poprawkę społeczności. Twój główny produkt pozostaje bezpieczny i zamknięty. To rozsądny kompromis.

Z kolei AGPL (Affero General Public License) to odpowiedź na lukę chmurową. Tradycyjne GPL aktywuje się w momencie dystrybucji oprogramowania (przekazania komuś fizycznej lub cyfrowej kopii). Firmy takie jak Google czy Amazon brały kod GPL, modyfikowały go, a następnie uruchamiały wyłącznie na własnych serwerach, oferując klientom dostęp przez przeglądarkę internetową (SaaS). Ponieważ nie dystrybuowały plików binarnych do klientów, nie musiały otwierać zmodyfikowanego kodu. AGPL łata tę dziurę. Wymusza udostępnienie kodu źródłowego każdemu użytkownikowi, który wchodzi w interakcję z oprogramowaniem przez sieć komputerową. Zmieniliśmy te zasady na robocie, żeby chronić serwisy przed przejęciem przez gigantów chmurowych bez oddawania czegokolwiek w zamian społeczności.

Jak audytować kod w firmie pod kątem licencji GNU?

Ręczne przeglądanie tysięcy plików w poszukiwaniu nagłówków licencyjnych nie ma dzisiaj sensu technicznego. Potrzebujesz automatyzacji wplecionej w proces budowania oprogramowania. Rynek oferuje wiele narzędzi do analizy kompozycji oprogramowania (SCA – Software Composition Analysis), które skanują menedżery pakietów (npm, pip, maven) i wyrzucają raporty o licencjach. Dobrą praktyką jest wdrożenie zasady, że każdy nowy pakiet dodawany do repozytorium musi przejść przez bramkę logiczną w systemie CI/CD.

Zablokuj pobieranie paczek z licencjami GPL i AGPL w głównych projektach komercyjnych na poziomie konfiguracji serwera budującego. Jeśli programista spróbuje przepchnąć zależność copyleftową, pipeline po prostu odrzuci jego kod, wyrzucając twardy błąd na konsolę. Tylko fizyczna blokada uczy ludzi czytania dokumentacji. Wysyłanie maili z prośbą o ostrożność ląduje u każdego w koszu. Audyt trzeba robić cyklicznie, bo licencje w projektach open source potrafią się zmienić między drobnymi aktualizacjami wersji. Projekt na licencji MIT nagle zmienia właściciela i nowa wersja wychodzi pod GPLv3. Uruchamiasz aktualizację na serwerze i budzisz się z problemem prawnym.

Czym różni się GPLv2 od GPLv3 w praktyce programisty?

Wersja druga licencji GPL powstała w 1991 roku. Działała świetnie przez kilkanaście lat, ale rozwój technologii ujawnił jej braki. Sprzęt zaczął blokować oprogramowanie. Najsłynniejszym przykładem była firma TiVo, produkująca cyfrowe rejestratory wideo. Używali w nich systemu Linux na licencji GPLv2. Zgodnie z prawem opublikowali kod źródłowy z modyfikacjami. Ale sprzęt TiVo był zablokowany kryptograficznie na poziomie bootloadera. Nawet jeśli pobrałeś kod, zmieniłeś go i skompilowałeś, urządzenie odmawiało uruchomienia niepodpisanego cyfrowo oprogramowania. Spełniono literę prawa, ale złamano jego ducha.

Richard Stallman wpadł w furię. Wersja GPLv3 z 2007 roku wprowadziła twardy zakaz tzw. tiwoizacji. Jeśli udostępniasz kod źródłowy produktu, w którym oprogramowanie jest wgrane w urządzenie konsumenckie, musisz również udostępnić wszelkie klucze instalacyjne i instrukcje niezbędne do wgrania zmodyfikowanego kodu na to urządzenie. Musisz oddać władzę nad sprzętem w ręce użytkownika.

Drugą ogromną zmianą były patenty. Wersja trzecia zawiera wyraźną klauzulę patentową. Jeśli firma XYZ tworzy kod naruszający jej własne patenty, a następnie udostępnia ten kod na licencji GPLv3, automatycznie i nieodwołalnie udziela wszystkim użytkownikom darmowej licencji na korzystanie z tych patentów w ramach tego oprogramowania. To chroni społeczność przed pozwami patentowymi ze strony korporacji, które najpierw dają kod, a potem pozywają za jego używanie. Część starych projektów, w tym samo jądro Linuxa, do dziś pozostaje przy wersji GPLv2, bo Linus Torvalds nie zgadzał się z radykalnym podejściem Stallmana do sprzętu. To stwarza potężny podział w świecie open source.

Jak udostępnić własny projekt na licencji GPL?

Proces nałożenia licencji na własny kod jest banalnie wręcz prosty i nie wymaga wynajmowania prawnika. Wystarczy wykonać kilka podstawowych operacji na plikach w repozytorium.

• Pobierz pełny tekst licencji GPL (najlepiej w wersji 3) ze strony Free Software Foundation i zapisz go w głównym katalogu swojego projektu w pliku tekstowym o nazwie LICENSE lub COPYING.
• Na samej górze każdego pliku z kodem źródłowym, który napisałeś, dodaj standardowy nagłówek informujący o prawach autorskich i licencji. Powinien on zawierać rok publikacji, twoje imię i nazwisko oraz krótką formułkę prawną mówiącą, że program jest wolnym oprogramowaniem rozprowadzanym na warunkach GNU GPL.
• Opublikuj kod publicznie, na przykład w serwisie GitHub, GitLab lub na własnym serwerze FTP.
• Dołącz plik README z jasną instrukcją, jak skompilować i uruchomić program, by spełnić warunek pełnej dostępności technicznej dla przyszłych użytkowników.

Od tego momentu każdy, kto pobierze twój kod, jest prawnie związany warunkami licencji wirusowej. Jeśli ktoś ukradnie twoją pracę i zamknie ją w komercyjnym produkcie bez podania źródeł, masz pełne prawo wytoczyć mu proces o naruszenie praw autorskich. Licencja GPL była wielokrotnie testowana w sądach na całym świecie, w tym w Niemczech i Stanach Zjednoczonych. Sądy traktują ją jako pełnoprawną i wiążącą umowę licencyjną.

Zastanów się dobrze, zanim zrzucisz swój kolejny projekt na GitHuba bez żadnego pliku licencyjnego, oddając go w prawną próżnię, lub zanim wkleisz cudzy kod z sieci bezpośrednio do bazy produkcyjnej swojej firmy. Przejrzyj swoje repozytoria jeszcze dzisiaj i sprawdź, na czym tak naprawdę opiera się twój biznes, bo ignorancja w zakresie wolnego oprogramowania kosztuje przed sądem więcej niż najdroższa komercyjna licencja na rynku.

Najczęściej zadawane pytania (FAQ)

• Co to jest licencja GPL? – Licencja GPL (GNU General Public License) to umowa wolnego oprogramowania typu copyleft. Gwarantuje prawo do uruchamiania, analizy, modyfikacji i udostępniania kodu, wymuszając, by zmodyfikowane wersje dziedziczyły te same otwarte warunki.
• Dlaczego licencja GPL nazywana jest wirusową? – Ponieważ podłączenie kodu GPL do własnego projektu wymusza otwarcie całego wynikowego kodu na tych samych zasadach. Mechanizm ten rozprzestrzenia wymóg wolności na całe oprogramowanie.
• Czy można sprzedawać oprogramowanie GPL? – Tak. Można pobierać opłaty za kopię oprogramowania. Należy jednak udostępnić kod źródłowy kupującemu, który zyskuje prawo do dalszego darmowego rozpowszechniania tego kodu.
• Czym różni się GPL od LGPL? – LGPL to kompromis. Pozwala łączyć otwartą bibliotekę z komercyjnym, zamkniętym programem za pomocą dynamicznego linkowania, bez wymogu otwierania kodu głównego produktu.
• Jak licencja AGPL chroni kod w chmurze? – AGPL łata lukę dystrybucyjną. Jeśli użytkownik korzysta z twojego zmodyfikowanego programu AGPL przez przeglądarkę internetową, masz obowiązek udostępnić mu kod źródłowy tego systemu.
• Jak nałożyć licencję GPL na własny projekt? – Dodaj pełny tekst licencji w pliku LICENSE w głównym folderze i wklej odpowiednią notkę o prawach autorskich na początku każdego z autorskich plików źródłowych.

Bibliografia:
1. Free Software Foundation – https://www.fsf.org
2. GNU Operating System – https://www.gnu.org
3. Open Source Initiative – https://opensource.org
4. Fundacja Wolnego i Otwartego Oprogramowania – https://fwioo.pl
5. GitHub Choose a License – https://choosealicense.com