Licencje open source bez żargonu: o co w ogóle chodzi?
GPL, MIT i Apache to trzy najpopularniejsze licencje open source na świecie. Decydują o tym, co wolno zrobić z kodem: czy można go użyć w zamkniętej aplikacji, czy trzeba udostępnić modyfikacje, jak wygląda sprawa z prawami autorskimi i patentami. Dobra wiadomość jest taka, że da się je zrozumieć bez studiowania prawa – wystarczy podejść do nich jak do trzech różnych „charakterów” tego samego pomysłu: dzielenia się kodem.
W uproszczeniu:
MIT – minimalne wymagania, bardzo liberalna licencja.
Apache 2.0 – też liberalna, ale rozbudowana o temat patentów i ochronę twórców.
GPL – licencja „zaraźliwa”: gdy z niej korzystasz, twój kod też musi być otwarty (copyleft).
Zrozumienie tych różnic jest kluczowe, jeśli tworzysz własne biblioteki, współtworzysz open source albo po prostu chcesz bezpiecznie używać cudzych paczek w projektach komercyjnych.
Podstawy: co właściwie daje licencja open source?
Cztery wolności użytkownika oprogramowania
Większość najbardziej znanych licencji open source opiera się na czterech prostych wolnościach. To nie jest teoria dla idealistów – te zasady przekładają się na realne prawo do korzystania z kodu:
wolność uruchamiania programu w dowolnym celu (komercyjnym, prywatnym, edukacyjnym),
wolność analizowania jak program działa oraz dostosowywania go do własnych potrzeb,
wolność rozpowszechniania kopii (dzielenia się z innymi),
wolność udoskonalania i publikowania swoich zmian.
Różnica między GPL, MIT i Apache dotyczy głównie tego, jakie warunki trzeba spełnić, korzystając z tych wolności. Inaczej mówiąc: co musisz zrobić, gdy bierzesz czyjś kod i łączysz go z własnym.
Copyleft vs permisive: dwa sposoby na „wolność”
Licencje GPL, MIT i Apache dzielą się na dwie duże grupy:
copyleft (np. GPL) – jeśli korzystasz z kodu objętego taką licencją w swoim projekcie i go rozpowszechniasz, twój projekt również musi być na licencji zgodnej z GPL (w praktyce publicznie dostępny w kodzie źródłowym),
permissive (np. MIT, Apache 2.0) – możesz użyć kodu w projekcie open source albo w pełni zamkniętym i nie musisz otwierać całości swojej aplikacji.
To jest najważniejsza linia podziału: czy licencja „zaraża” cały twój projekt (GPL), czy pozwala ci zachować projekt jako własność zamkniętą (MIT, Apache).
Dlaczego wybór licencji ma znaczenie w praktyce
Licencja nie jest „formalnością do README”. Kod bez licencji jest prawnie zablokowany – z punktu widzenia prawa autorskiego masz do niego mniej praw, niż do przypadkowego zdjęcia z internetu. Jeśli sam publikujesz projekt, licencja decyduje:
czy ktoś może użyć twojego kodu w płatnej, zamkniętej aplikacji,
czy modyfikacje do twojego kodu muszą być publicznie udostępniane,
czy chcesz wymusić dalsze dzielenie się kodem (GPL) albo dać pełną swobodę (MIT/Apache),
czy twoja biblioteka będzie mogła być używana w firmach z mocno konserwatywnym działem prawnym.
Jeśli tylko korzystasz z cudzych bibliotek, licencja powie ci, czy możesz zintegrować daną paczkę z komercyjnym produktem bez ujawniania kodu źródłowego całej aplikacji.
Licencja MIT: minimalizm i maksymalna swoboda
Co w praktyce oznacza licencja MIT
Licencja MIT jest jedną z najprostszych i najbardziej liberalnych licencji open source. W dużym skrócie mówi: „rób z tym kodem, co chcesz, ale nie obwiniaj autora, jeśli coś pójdzie nie tak, i zostaw informację skąd kod pochodzi”.
Najczęstsze zastosowanie: biblioteki frontendowe, małe narzędzia CLI, przykładowe implementacje algorytmów, projekty edukacyjne. MIT jest tak krótka, że wiele osób rzeczywiście czyta ją od początku do końca, zamiast „ufać domyślnie”.
Dozwolone działania w licencji MIT
MIT pozwala praktycznie na wszystko, co ma sens dla programisty:
możesz używać kodu w projektach prywatnych i komercyjnych,
możesz modyfikować kod i nie dokumentować wszystkich zmian publicznie,
możesz rozpowszechniać kod w oryginale lub zmodyfikowany (jako open source albo zamknięty produkt),
możesz zmienić licencję na swoją część kodu (choć nie możesz cofnąć MIT dla już istniejących kopii),
możesz sprzedawać produkt oparty na tym kodzie, bez obowiązku dzielenia się zyskiem z autorem.
To wszystko sprawia, że wiele firm nie ma żadnego problemu, żeby wykorzystywać biblioteki na MIT w produktach SaaS, aplikacjach desktopowych czy modułach chmurowych.
Obowiązki i ograniczenia przy MIT
MIT ma tylko kilka konkretnych wymagań:
musisz zachować informację o prawach autorskich – zazwyczaj jest to plik LICENSE albo nagłówek w kodzie,
musisz zachować treść licencji MIT w rozpowszechnianym kodzie (np. dołączając ją do paczki binarnej lub źródeł),
nie możesz pozywać autora za szkody wynikające z użycia kodu (standardowa klauzula „bez gwarancji”).
Nie ma obowiązku udostępniania modyfikacji, nie ma wymogu otwierania całego projektu. Jeśli w aplikacji używasz 20 bibliotek MIT, nikt nie wymaga, żebyś publikował jej kod na GitHubie. Jedyne, o co licencja się „upomina”, to zachowanie zasług i zrzeczenie się odpowiedzialności.
Przykład zastosowania licencji MIT w projekcie
Przykład z życia: tworzysz bibliotekę JavaScript do obsługi wykresów i wypuszczasz ją na GitHubie na licencji MIT. Ktoś inny buduje komercyjną aplikację SaaS do raportowania wyników sprzedaży i wstawia twoją bibliotekę do panelu użytkownika. Może:
nie pokazywać publicznie kodu całej aplikacji,
modyfikować twoją bibliotekę pod swoje potrzeby,
pobierać opłaty abonamentowe od klientów.
Warunek: w kodzie źródłowym (we własnym repozytorium, buildzie, dokumentacji) powinien zachować informację, że fragmenty pochodzą z twojej biblioteki MIT oraz dodać tekst licencji MIT. Nie musi natomiast nikomu „oddawać” zmian wprowadzonych do kodu.
Licencja Apache 2.0: swoboda plus ochrona patentowa
Na czym polega licencja Apache 2.0
Apache License 2.0 jest również licencją permisywną, podobnie jak MIT, ale zawiera znacznie więcej szczegółów. Została zaprojektowana przez Fundację Apache m.in. po to, aby:
dać twórcom i użytkownikom kodu jasną ochronę przed roszczeniami patentowymi,
uregulować kwestię znaków towarowych (np. nazwa „Apache” nie może być używana dowolnie),
zapewnić przejrzyste zasady włączania kodu do dużych projektów komercyjnych.
Apache 2.0 jest częstym wyborem w projektach zaplecza (serwery, narzędzia devops, frameworki) oraz w projektach fundacji i dużych firm, które muszą patrzeć szerzej niż tylko na kod – uwzględniają też patenty i markę.
Co wolno, korzystając z licencji Apache 2.0
Pod względem „co mogę zrobić z kodem” Apache 2.0 jest podobna do MIT:
wolno używać kodu w projektach prywatnych, komercyjnych i open source,
wolno modyfikować kod i nie ma obowiązku upubliczniania poprawek,
wolno rozpowszechniać zmodyfikowane wersje na własnej licencji,
wolno sprzedawać rozwiązania oparte na tym kodzie.
Największa różnica w stosunku do MIT dotyczy nie zakresu swobody, ale szczegółów technicznych i patentów. Apache 2.0 precyzyjniej mówi, co się dzieje, jeśli twórca ma patenty związane z danym kodem.
Klauzule patentowe i ich znaczenie
Apache 2.0 zawiera tzw. udzielenie licencji patentowej. W praktyce oznacza to:
jeżeli autorzy kodu mają patenty, które obejmują funkcjonalność tego kodu, to udzielają użytkownikom niewyłącznej, globalnej licencji na korzystanie z tych patentów w zakresie potrzebnym do używania tego kodu,
jeśli ktoś, kto używa kodu na Apache 2.0, zacznie pozywać autorów z powodu naruszenia patentów dotyczących tego kodu, traci udzieloną mu licencję patentową w ramach Apache.
Dla zwykłego programisty to brzmi abstrakcyjnie, ale dla średnich i dużych firm to jedna z kluczowych kwestii. Działy prawne lubią projekty na Apache 2.0, bo ryzyko patentowe jest lepiej opisane i częściowo zminimalizowane.
Obowiązki użytkownika kodu Apache 2.0
Licencja Apache 2.0 wymaga więcej drobiazgów niż MIT, ale nadal nie są to trudne rzeczy:
zachowujesz informacje o prawach autorskich i tekst licencji,
jeśli zmieniasz pliki źródłowe, musisz oznaczyć je jako zmodyfikowane (np. w nagłówku pliku lub w dokumentacji),
jeśli projekt ma plik NOTICE, przy dalszej dystrybucji musisz dołączyć ten plik lub jego równoważnik (np. sekcję „Credits”),
nie możesz sugerować, że twórcy lub Fundacja Apache rekomendują twój produkt, jeśli tego oficjalnie nie zrobili,
nie dostajesz automatycznie prawa do używania znaków towarowych (logo, nazwy) tak, jak ci się podoba.
To są szczegóły, które mają znaczenie, gdy tworzysz np. własną dystrybucję serwera opartego na Apache HTTP Server albo forka narzędzia devops. Z punktu widzenia „zwykłej” biblioteki JS czy Pythona, różnica w stosunku do MIT jest głównie na poziomie zapisów patentowych i obowiązku oznaczania modyfikacji.
Licencja GPL: copyleft i „zaraźliwość” kodu
Czym jest copyleft w wydaniu GPL
Licencja GNU GPL (najczęściej mowa o wersji 3, ale wciąż popularna jest też 2) została stworzona po to, aby kod zawsze pozostał wolny – również wtedy, gdy ktoś go wykorzysta w swoim własnym projekcie. Mechanizm jest prosty:
Jeśli łączysz swój kod z kodem na GPL i rozpowszechniasz to dalej, całość musisz udostępnić na licencji GPL lub zgodnej.
To właśnie nazywa się „zaraźliwością” lub efektem „wirusa GPL”. Dla jednych to zaleta – bo zmusza firmy do dzielenia się poprawkami. Dla innych wada – bo utrudnia budowanie zamkniętych produktów na bazie kodu GPL.
Najważniejsze konsekwencje korzystania z GPL
GPL gwarantuje cztery wolności użytkownika, ale dodaje kluczowy warunek: dziel się na tych samych zasadach. W praktyce oznacza to:
możesz używać kodu GPL w wewnętrznych projektach firmy, bez obowiązku niczego publikować, dopóki nie ma dystrybucji poza organizację,
jeśli jednak rozpowszechniasz software (sprzedajesz licencje, udostępniasz binaria, dajesz klientowi instalator), a w środku jest kod GPL, to musisz udostępnić kod źródłowy całego połączonego dzieła,
nie możesz zmienić licencji na bardziej restrykcyjną (zamkniętą) dla kodu pochodzącego z GPL – możesz jedynie dodać własny kod, ale całość dystrybucji objęta jest GPL.
To nie jest detal. Dla wielu firm jest to wystarczający powód, aby unikać bibliotek GPL w produktach dystrybuowanych klientom. Z drugiej strony, dla twórców takich projektów jak Linux, GCC czy GIMP, GPL jest gwarancją, że ich praca nie stanie się nagle zamkniętym, własnościowym systemem.
GPL a usługi SaaS i oprogramowanie w chmurze
Istotna różnica dotyczy tego, czy soft jest dystrybuowany jako produkt, czy tylko uruchamiany na serwerze. Standardowa GPL skupia się na dystrybucji kopii programu. Jeżeli:
GPL przy dystrybucji, ale nie przy samym użyciu
Różnica między „używaniem” a „dystrybuowaniem” bywa kluczowa. Z punktu widzenia GPL sytuacja wygląda tak:
jeśli instalujesz program GPL na swoim serwerze i użytkownicy tylko z niego korzystają przez sieć (np. logują się do panelu www), to nie jest to dystrybucja kopii programu,
obowiązek udostępnienia kodu pojawia się dopiero wtedy, gdy przekazujesz komuś program jako taki – np. instalator, paczkę Docker, obraz maszyny, pendrive z binarką.
Dlatego sporo firm stosuje strategię: „korzystamy z GPL na serwerze, ale nic nie wydajemy na zewnątrz” – w takim modelu GPL realnie nie „wgryza się” w ich własny kod. Problem zaczyna się dopiero tam, gdzie klient dostaje coś, co może zainstalować u siebie.
AGPL – „GPL do chmury”
Na klasyczną „lukę SaaS” powstała licencja Affero GPL (AGPL). Działa jak GPL, ale ma dodatkowy hak:
Jeśli zmodyfikujesz program na AGPL i udostępniasz go użytkownikom przez sieć (np. jako SaaS), to musisz umożliwić im pobranie kodu źródłowego tej zmodyfikowanej wersji.
AGPL celuje bezpośrednio w scenariusz: biorę open source, robię z tego zamknięty SaaS, nikomu nic nie oddaję. Dla twórców systemów webowych (np. CRM, platform edukacyjnych) to często świadomy wybór – chcą, aby firmy nie mogły „zamknąć” ich rozwiązania tylko dlatego, że działają w chmurze, a nie jako instalka.
Skutki wyboru GPL/AGPL dla firm
Z perspektywy komercyjnej różnice są wyraźne:
GPL jest „groźna” głównie wtedy, gdy wydajesz oprogramowanie klientom – licencja wymaga wtedy otwarcia całego połączonego kodu,
AGPL rozszerza ten obowiązek również na scenariusz, gdy tylko hostujesz usługę, ale modyfikujesz oprogramowanie.
Stąd też częsta praktyka: biblioteki i komponenty jako MIT/Apache, natomiast całe aplikacje serwerowe jako GPL/AGPL – tak, aby „wymusić” współdzielenie ulepszeń przy integracjach i forkach.
GPL vs LGPL – co z bibliotekami?
Aby złagodzić skutki „zaraźliwości” w przypadku bibliotek, powstała LGPL (Lesser GPL). W skrócie:
LGPL pozwala linkować bibliotekę z kodem zamkniętym, bez konieczności udostępniania całej aplikacji na GPL,
jeśli jednak modyfikujesz samą bibliotekę LGPL, to te zmiany muszą być udostępnione na LGPL/GPL.
W praktyce oznacza to: możesz pisać komercyjną aplikację, która dynamicznie linkuje się z biblioteką LGPL (np. przez DLL, .so, .dylib), a Twoja aplikacja może pozostać zamknięta. Musisz jedynie zapewnić użytkownikowi możliwość podmiany tej biblioteki na własnoręcznie skompilowaną wersję.
Przykład praktyczny: kiedy GPL cię „złapie”
Wyobraź sobie, że tworzysz desktopową aplikację do montażu wideo i chcesz użyć biblioteki efektów na GPL:
jeśli tylko testujesz ją wewnętrznie, nic nie udostępniasz na zewnątrz – nie musisz niczego publikować,
gdy jednak sprzedasz aplikację, dołączając tę bibliotekę (statycznie lub dynamicznie, ale w ramkach jednej całości), cała aplikacja podlega zasadom GPL – w praktyce musisz udostępnić jej kod na GPL,
gdyby ta sama biblioteka była na LGPL, mógłbyś ją dołączyć jako osobny moduł / bibliotekę współdzieloną i utrzymać swój kod w modelu zamkniętym.
Jak mieszają się GPL, MIT i Apache w jednym projekcie
Łączenie licencji – kto „wygrywa”?
Przy łączeniu różnych licencji kluczowe jest, która z nich ma charakter copyleft i jak silny:
kod na MIT można praktycznie łączyć ze wszystkim – MIT „nie narzuca się” na całość projektu,
kod na Apache 2.0 jest też dość elastyczny, ale posiada klauzule patentowe, które muszą być zgodne z licencją nadrzędną,
GPL ma tendencję do „przeciągania” całego połączonego dzieła na siebie: jeśli połączysz komponent MIT z GPL, dystrybuowana całość praktycznie kończy na GPL.
Dlatego mówi się, że GPL jest „silniejsza” od MIT/Apache w sensie skutku końcowego dla całego programu. Zwykle to właśnie ona określa zasady dystrybucji gotowego produktu.
MIT + GPL: codzienny scenariusz w open source
Kod MIT możesz bez problemu włączyć do projektu na GPL – wynik:
oryginalne pliki MIT nadal mają swoje nagłówki i licencję,
ale cały projekt, jako dystrybuowany produkt, ma charakter GPL,
nie możesz nagle zamknąć fragmentu MIT „odklejonego” od kontekstu GPL, jeśli jest on nierozdzielną częścią całości.
Dla autora biblioteki MIT to akceptowalny scenariusz: jego kod jest dalej dostępny na MIT (w innych projektach), a w konkretnym projekcie GPL staje się częścią większego „ekosystemu copyleft”.
Apache 2.0 + GPL: zgodność i niezgodność
Relacja Apache 2.0 z GPL jest bardziej złożona. W uproszczeniu:
kodu na Apache 2.0 można użyć w projektach na GPLv3 – Fundacja FSF uważa Apache 2.0 za kompatybilną z GPLv3,
ta sama biblioteka nie jest kompatybilna z GPLv2 bez „lub późniejsza”, bo licencje się „kłócą” w szczegółach patentowych.
Jeżeli więc widzisz projekt na „GPLv2 only”, włączanie do niego kodu na Apache 2.0 będzie problematyczne. Natomiast „GPLv2 or later” daje furtkę – możesz traktować całość jako GPLv3 i wtedy kompatybilność wraca.
Dlaczego nie ma „GPL + MIT z zastrzeżeniem zamknięcia”
Częsty błąd początkujących: próba dodania zapisu w stylu „ten fragment kodu jest na GPL, ale nie wolno…”. Licencje copyleft mają swoją logikę:
jeśli deklarujesz GPL, to nie możesz dołożyć kolidujących ograniczeń (np. zakazu komercyjnego użycia),
próba stworzenia „GPL z dodatkowymi zakazami” kończy się czymś, co nie jest już GPL i może być niekompatybilne z resztą ekosystemu.
Stąd rada: albo GPL „w czystej postaci”, albo inna licencja. Mieszanie GPL z restrykcjami „tylko dla edukacji”, „bez komercji” wycina projekt z normalnego obiegu open source.
Źródło: Pexels | Autor: Digital Buggu
Jak dobrać licencję do projektu: proste scenariusze
Chcę, żeby kod był używany wszędzie, bez zobowiązań
Jeśli celem jest maksymalna adopcja (biblioteka, małe narzędzie CLI, snippet) i nie przeszkadza ci, że ktoś zrobi z tego zamknięty produkt, najprostsza opcja to:
MIT – minimum formalności, pełna swoboda dla użytkownika,
ewentualnie Apache 2.0, jeśli projekt ma kontakt z większym biznesem i chcesz jasnych reguł patentowych.
Chcę wymusić dzielenie się poprawkami
Gdy bardziej zależy ci na tym, aby kontrybucje wracały do społeczności, niż na adopcji przez zamknięte produkty, rozsądne wybory to:
GPL – jeśli tworzysz aplikację instalowaną u użytkownika (desktop, self-hosted backend),
AGPL – jeśli budujesz oprogramowanie typowo serwerowe / webowe i nie chcesz, aby ktoś zrobił z tego zamknięty SaaS,
LGPL – jeśli chodzi o bibliotekę, która ma być używana także przez zamknięte aplikacje, ale same ulepszenia biblioteki mają pozostać otwarte.
Chcę, żeby firmy nie bały się mojego kodu, ale zależy mi na jasności
Dla projektów, które mają być włączane do stacków korporacyjnych (bazy danych, middleware, narzędzia devops), często rozsądne jest:
Apache 2.0 – przejrzysta, dopracowana licencja z klauzulami patentowymi i plikiem NOTICE, dobrze „czyta się” działom prawnym,
w mniejszych projektach – MIT z dodatkową dokumentacją, jak poprawnie zachować nagłówki i wzmianki o autorach.
Przykład decyzji: biblioteka vs produkt SaaS
Załóżmy, że tworzysz:
Bibliotekę do obsługi płatności – chcesz, żeby używały jej sklepy SaaS, aplikacje mobilne, integracje w firmach. Najczęściej: MIT albo Apache 2.0. Im mniej tarcia, tym chętniej integratorzy ją przyjmą.
Gotowy panel do zarządzania subskrypcjami – to już pełna aplikacja. Jeśli nie chcesz, aby ktoś brał ją, zamykał i sprzedawał jako SaaS bez dzielenia się zmianami, rozważ AGPL. Kto ją uruchomi publicznie, musi udostępnić zmiany w kodzie.
Najczęstsze pułapki przy licencjach GPL, MIT i Apache
Mylenie „publicznie dostępne” z „open source”
To, że kod jest widoczny na GitHubie, nie oznacza, że jest open source w sensie prawnym. Bez wyraźnej licencji:
domyślnie wszystkie prawa zastrzeżone,
inni nie mają prawa kopiować, modyfikować i używać kodu komercyjnie.
Dopiero dodanie licencji MIT/Apache/GPL jasno definiuje, co wolno. Repo bez licencji to w praktyce „kod do wglądu, ale nie do używania”.
Ignorowanie zależności w łańcuchu
W projektach produkcyjnych często pojawia się sytuacja: twoja aplikacja zależy od biblioteki A, a ta od B i C. Jeśli:
B albo C są na GPL, a twoja aplikacja je wbudowuje lub dystrybuuje razem z nimi,
klient dostaje pakiet jako całość,
to ocena, czy całość podlega GPL, nie zatrzymuje się na pierwszym poziomie. Trzeba patrzeć na cały łańcuch zależności, zwłaszcza tam, gdzie integracja jest ścisła (linkowanie, bundling, statyczne wklejanie kodu).
„To tylko plugin / moduł, więc nie podlega GPL”
Pliki rozszerzeń (wtyczki, moduły) często są traktowane jako osobne dzieła. Dla GPL to, czy plugin jest „oddzielny”, zależy od:
sposobu integracji (API po sieci vs bezpośrednie wywołania funkcji w tym samym procesie),
tego, czy plugin ma sens samodzielnie, czy jest ściśle zależny od kodu GPL.
Im bardziej plugin przypomina klasyczny moduł ładowany w pamięci i wywoływany jak lokalna biblioteka, tym większe szanse, że będzie traktowany jako „dzieło pochodne” i obejmie go GPL. Granice są niestety płynne i w trudnych przypadkach opierają się już na interpretacji prawnej.
Brak informacji o modyfikacjach przy Apache 2.0
Przy Apache 2.0 wiele osób zapomina o obowiązku oznaczania zmodyfikowanych plików. Tymczasem:
jeżeli zmieniasz kod, powinieneś zaznaczyć to w nagłówku pliku lub w dokumentacji (komentarz z datą, opisem zmian),
to ważne przy dalszej dystrybucji – odbiorca musi widzieć, co pochodzi od oryginalnych autorów, a co od ciebie.
Przy większych forkujących projektach (własne dystrybucje serwerów, narzędzia CLI) takie zaniedbanie potrafi generować konflikty i wątpliwości co do autorstwa fragmentów kodu.
Praktyczne nawyki pracy z licencjami w projektach
Dodawanie licencji do nowego repozytorium
Przy zakładaniu projektu kilka prostych kroków oszczędza problemów później:
w nagłówkach kluczowych plików dodaj krótki komentarz z informacją o licencji i autorze,
w README umieść krótką sekcję „License” z nazwą licencji i ewentualnie linkiem do jej pełnego brzmienia.
Śledzenie licencji zależności
Monitorowanie licencji w istniejących projektach
Przy rosnącej liczbie zależności, ręczne śledzenie licencji szybko przestaje być możliwe. Z pomocą przychodzą narzędzia automatyczne:
menedżery paczek (npm, pip, cargo, Composer) – często pozwalają wygenerować listę pakietów wraz z licencjami,
skanery licencyjne – np. cargo-license, wtyczki do mvn, narzędzia typu FOSSA, Snyk, OWASP Dependency-Check,
proste skrypty CI, które sprawdzają, czy w projekcie nie pojawiła się licencja spoza „białej listy”.
W małych zespołach wystarczy czasem plik licenses.md z tabelką (nazwa pakietu, wersja, licencja, link). W większych – integracja skanera z pipeline’em: commit wprowadzający niepożądaną licencję po prostu nie przechodzi.
Łączenie MIT, GPL i Apache w jednym monorepo
Monorepo z kilkoma komponentami (np. frontend, backend, biblioteka wspólna) często ma sens, ale miesza też licencje. Typowy wzór:
biblioteka narzędziowa – MIT/Apache 2.0,
aplikacja końcowa – GPL lub AGPL,
jakieś narzędzia developerskie – MIT/BSD.
Żeby nie powstał bałagan, dobrze jest:
dodać osobne pliki LICENSE w podkatalogach (np. libs/payment/LICENSE, apps/server/LICENSE),
w głównym README opisać, że repo zawiera kilka komponentów o różnych licencjach,
w nagłówkach plików jasno wskazać, którego komponentu i licencji dotyczą.
Dzięki temu ktoś, kto chce użyć tylko biblioteki MIT z twojego monorepo, nie jest „przypadkiem” wciągnięty w wymogi GPL aplikacji końcowej.
Prywatne forki a obowiązki licencyjne
Są dwa różne światy: użycie kodu wewnątrz firmy i dystrybucja na zewnątrz. Jeśli:
forkujesz projekt GPL/MIT/Apache wyłącznie do wewnętrznego użytku,
nie dystrybuujesz binarek ani kodu poza swoją organizację,
to obowiązki są znacznie mniejsze. Nie musisz publikować wewnętrznych patchy na GitHubie tylko dlatego, że używasz GPL. Zmienia się to w momencie:
sprzedaży produktu z dołączonym kodem (instalator, paczka Docker, appliance),
uruchomienia publicznej usługi opartej na AGPL,
przekazania zmodyfikowanego kodu partnerom lub klientom.
Wtedy uruchamiają się wszystkie „haczyki” licencyjne: konieczność udostępnienia kodu źródłowego, informacji o licencji, autorach i ewentualnych modyfikacjach.
Kontenery mieszają kod z różnych źródeł: baza systemowa, runtime, aplikacja, biblioteki. Z prawnego punktu widzenia użytkownik dostaje jeden produkt. Kilka praktycznych zasad pomaga trzymać to w ryzach:
utrzymuj w repo plik THIRD-PARTY-LICENSES lub podobny, gdzie zbierasz licencje wszystkich dołączanych komponentów,
jeżeli obraz zawiera komponenty GPL, zaplanuj, jak udostępniasz ich kod źródłowy (np. osobne repo, paczki źródłowe, linki w dokumentacji),
przy Apache 2.0 pamiętaj o kopiowaniu plików NOTICE z używanych projektów do własnego obrazu lub dokumentacji.
W praktyce niektóre firmy dodają do własnych obrazów /licenses z zebranymi licencjami wszystkich istotnych komponentów – to ułatwia życie audytom i klientom korporacyjnym.
Kontrybucje do obcych projektów a prawa autorskie
Gdy wysyłasz pull request do projektu na MIT, Apache lub GPL, nadal jesteś autorem swojego wkładu – o ile nie podpisałeś umowy przenoszącej prawa (np. z pracodawcą). Jednocześnie:
twój wkład automatycznie jest objęty licencją tego projektu (MIT/GPL/Apache),
maintainerzy mogą wymagać podpisania CLA (Contributor License Agreement),
w większych projektach coraz częściej stosuje się DCO (Developer Certificate of Origin) – potwierdzasz, że masz prawa do tego, co wysyłasz.
W praktyce: zanim wyślesz większą kontrybucję do projektu GPL/Apache, sprawdź pliki CONTRIBUTING i CLA. Jeżeli pracujesz na etacie, dobrze też mieć jasną politykę w firmie, czy i na jakich zasadach twoje kontrybucje są „służbowe”.
Firmowe zasady dotyczące GPL, MIT i Apache
W wielu organizacjach istnieją proste „traffic lights” dla licencji:
zielone: MIT, BSD, Apache 2.0 – można używać szeroko, zwykle bez zgód specjalnych,
żółte: LGPL – wymagana konsultacja, bo trzeba pilnować separacji bibliotek i aplikacji,
czerwone: GPL, AGPL – użycie tylko po zatwierdzeniu przez prawników / architektów.
Jeżeli w projekcie masz wpływ na decyzje architektoniczne, sensowne jest dobranie komponentów tak, aby nie wprowadzać „czerwonych” licencji tam, gdzie to nie jest absolutnie konieczne. Czasem zamiana małej biblioteki GPL na odpowiednik MIT usuwa cały problem.
Zmiana licencji w trakcie życia projektu
Moment, w którym projekt zyskuje popularność, bywa też momentem myślenia o zmianie licencji. Nie zawsze jest to możliwe:
jeśli jesteś jedynym autorem (lub masz formalnie scedowane prawa od współautorów), możesz zmienić licencję na inną,
jeśli projekt ma wielu kontrybutorów, a nie ma CLA z przeniesieniem praw, zmiana licencji wymaga zgody wszystkich autorów wkładów,
kodu zaciągniętego z innych projektów nie możesz „przelicencjonować” wbrew jego oryginalnym warunkom.
Dlatego przy startowaniu większego projektu dobrze jest przemyśleć od razu, czy w przyszłości planowana jest np. komercyjna „dual licencja”. Wtedy modele typu „GPL + komercyjna” lub „AGPL + sublicencje” wymagają innego podejścia organizacyjnego.
Dual licensing: open source + komercyjnie
Niektórzy autorzy publikują kod jednocześnie na licencji copyleft (np. GPL/AGPL) i oferują firmom dodatkową licencję komercyjną. W efekcie:
społeczność dostaje projekt na licencji GPL/AGPL,
klient komercyjny może wykupić licencję, która pozwala np. zamknąć modyfikacje lub wbudować kod w SaaS bez obowiązków AGPL.
Taki model wymaga posiadania pełni praw autorskich do całości istotnego kodu (lub odpowiednich umów z kontrybutorami). Bez tego nie da się legalnie udzielać sprzecznych zezwoleń na ten sam fragment kodu.
MIT, Apache, GPL a fragmenty kodu „copy-paste”
Często kopiujemy pojedyncze funkcje z blogów, Gistów, odpowiedzi na Stack Overflow. Od strony licencji to też ma znaczenie:
fragment z projektu na MIT/Apache/GPL wklejony do twojego repo nadal jest objęty tą licencją,
jeżeli twój projekt jest na licencji niekompatybilnej (np. komercyjnej, zamkniętej, bez zgody autora), możesz naruszać prawa autorskie,
Stack Overflow ma własną licencję (CC BY-SA), która też ma efekt „kopyleftowy”.
Bezpieczniej jest albo używać bibliotek jako zależności, albo przynajmniej zachować informacje o pochodzeniu kodu i sprawdzić licencję przed wklejeniem „magicznego snippet-u”.
Audyt licencyjny przed wydaniem wersji 1.0
Przed pierwszym „poważnym” release’em da się jeszcze sporo naprawić bez publicznego zamieszania. Prosty checklist:
czy w repo jest jasny LICENSE i wzmianka o licencji w README?
czy wszystkie główne zależności mają licencje kompatybilne z twoją?
czy w kodzie nie ma fragmentów „z internetu” bez jasnej informacji o licencji?
czy przy Apache 2.0 nie brakuje plików NOTICE i oznaczeń zmian?
czy kojarzysz, które pliki napisałeś sam, a które są forkiem / portem cudzych rozwiązań?
Lepszy jeden wieczór poświęcony na taki przegląd niż późniejsze wycofywanie releasów lub przepisywanie krytycznych modułów „na szybko”, bo audyt klienta coś znalazł.
Licencje a dokumentacja, grafiki i inne zasoby
MIT, Apache i GPL dotyczą przede wszystkim kodu. Dokumentacja, diagramy, ikonki czy fonty potrafią być objęte zupełnie innymi licencjami (CC BY, CC BY-SA, własne zastrzeżone warunki). W jednym repo możesz mieć więc:
kod na MIT,
dokumentację na CC BY 4.0,
logo na „all rights reserved”.
Jeżeli ktoś ma z twojego projektu korzystać komercyjnie, jasne oznaczenie licencji nie tylko dla kodu, ale i dla zasobów nietechnicznych usuwa sporo pytań. Np. sekcja „Branding” w dokumentacji, gdzie wskazujesz, że znak firmowy nie jest częścią licencji open source.
Co robić przy naruszeniu licencji
Jeżeli zauważysz, że ktoś używa twojego kodu na MIT/Apache/GPL z naruszeniem warunków (np. bez atrybucji, z usuniętym NOTICE, z zamkniętym forkiem GPL), zwykle sprawdza się prosty schemat:
skontaktować się bezpośrednio – kulturalny mail z opisem problemu i oczekiwanym sposobem naprawy,
dać rozsądny czas na reakcję – część naruszeń wynika z niewiedzy lub błędu w procesie builda,
dalsze kroki (publiczne ogłoszenie, prawnik) rozważać dopiero, gdy druga strona świadomie ignoruje temat.
W drugą stronę: jeśli ktoś zgłasza ci możliwe naruszenie, lepiej od razu zrobić przegląd repo i buildów i poprawić sytuację, niż wchodzić w spór o oczywiste braki.
Najczęściej zadawane pytania (FAQ)
Na czym polega podstawowa różnica między licencjami GPL, MIT i Apache?
MIT i Apache 2.0 to licencje „permissive” – pozwalają używać kodu zarówno w projektach open source, jak i w pełni zamkniętych, bez obowiązku udostępniania całego kodu aplikacji. GPL to licencja „copyleft”: jeśli połączysz kod GPL z własnym i będziesz go rozpowszechniać, całość musi być dostępna na zgodnej licencji, z kodem źródłowym.
W praktyce: MIT i Apache dają więcej swobody firmom i projektom komercyjnym, GPL wymusza dalsze dzielenie się kodem na tych samych zasadach.
Czy mogę użyć biblioteki na licencji MIT w komercyjnej, zamkniętej aplikacji?
Tak. Licencja MIT pozwala używać kodu w projektach komercyjnych i zamkniętych bez obowiązku udostępniania całego kodu źródłowego klientom czy społeczności.
Twoje główne obowiązki to zachowanie informacji o prawach autorskich oraz dołączenie tekstu licencji MIT do rozpowszechnianych kopii (np. w pliku LICENSE lub dokumentacji). Nie musisz publikować swoich modyfikacji ani ujawniać całej bazy kodu.
Czy korzystając z kodu na GPL, muszę udostępnić cały kod źródłowy mojego projektu?
Jeśli łączysz kod na GPL z własnym kodem w jednym projekcie i ten projekt rozpowszechniasz (np. sprzedajesz jako aplikację desktopową, dystrybuujesz binarki), wtedy tak – musisz udostępnić pełen kod źródłowy tego oprogramowania na licencji zgodnej z GPL.
Obowiązek nie dotyczy użytkowania „wewnętrznego” (np. gdy aplikacja działa tylko w twojej firmie i nie jest dystrybuowana) ani sytuacji, gdy z kodem GPL komunikujesz się wyłącznie przez zewnętrzne API jako z osobnym programem. Granice są jednak subtelne, dlatego przy złożonych przypadkach warto skonsultować się z prawnikiem.
Czy licencja Apache 2.0 pozwala na użycie kodu w zamkniętej aplikacji?
Tak. Apache 2.0, podobnie jak MIT, jest licencją permisywną – możesz używać kodu w projektach komercyjnych i zamkniętych, modyfikować go i nie musisz upubliczniać swoich zmian.
Różnica względem MIT polega głównie na dodatkowych zapisach dotyczących patentów i znaków towarowych. Apache 2.0 przyznaje ci prawo do korzystania z ewentualnych patentów związanych z kodem, ale jednocześnie chroni autorów przed pozwami patentowymi ze strony użytkowników, którzy z kodu korzystają.
Jaką licencję wybrać do własnej biblioteki open source: GPL, MIT czy Apache?
To zależy od celu projektu:
Wybierz MIT, jeśli chcesz maksymalnie prostą licencję i pozwolić na dowolne użycie (także w zamkniętych produktach), bez skomplikowanych zapisów.
Wybierz Apache 2.0, jeśli chcesz podobną swobodę jak MIT, ale z mocniejszym uregulowaniem kwestii patentów i lepszą „czytelnością” dla działów prawnych dużych firm.
Wybierz GPL, jeśli zależy ci, by wszelkie projekty, które połączą się z twoim kodem i będą rozpowszechniane, również musiały udostępnić swój kod źródłowy (efekt „zaraźliwy”).
W uproszczeniu: MIT/Apache – większa adopcja komercyjna, GPL – większa gwarancja, że inni też będą się dzielić kodem.
Co się stanie, jeśli opublikuję projekt bez żadnej licencji?
Brak licencji nie oznacza „domyślnie open source”. Z punktu widzenia prawa autorskiego wszelkie prawa są zastrzeżone: inni nie mają formalnego prawa do kopiowania, modyfikowania ani rozpowszechniania twojego kodu, nawet jeśli publicznie jest na GitHubie.
Efekt jest odwrotny do często zamierzonego: zamiast zachęcać do używania i współpracy, prawnie blokujesz możliwość legalnego wykorzystania projektu. Dlatego zawsze dodaj wybraną licencję (np. MIT, Apache 2.0 lub GPL) w pliku LICENSE.
Czy mogę zmienić licencję projektu z MIT na inną, np. komercyjną?
Możesz zmienić licencję na swoją przyszłą pracę – jako autor decydujesz, na jakich warunkach udostępniasz nowe wersje. Nie możesz jednak „cofnąć” MIT dla kopii, które już zostały wydane i pobrane; one nadal pozostają legalnie dostępne na MIT.
Możliwy jest więc model podwójnego licencjonowania: wcześniejsze wersje na MIT pozostają open source, a nowsze wydajesz np. na innej licencji lub w wersji komercyjnej, o ile masz prawa do całego kodu (lub wkłady innych współautorów są odpowiednio uregulowane).
Wnioski w skrócie
GPL, MIT i Apache to różne „charaktery” tego samego pomysłu – dzielenia się kodem – ale z odmiennymi warunkami użycia, modyfikacji i dystrybucji.
Najważniejsza oś podziału to copyleft vs permissive: GPL „zaraża” projekt wymogiem otwarcia kodu, a MIT i Apache pozwalają zachować aplikację zamkniętą.
MIT to najbardziej minimalistyczna licencja: praktycznie pełna swoboda użycia (także komercyjnego i zamkniętego) przy zachowaniu informacji o autorze i braku odpowiedzialności twórcy.
Apache 2.0, podobnie liberalna jak MIT, dodatkowo mocno reguluje kwestie patentów i ochrony twórców, co bywa ważne dla firm z rozbudowanymi działami prawnymi.
GPL wymaga, aby projekty korzystające z kodu na tej licencji (i rozpowszechniane dalej) również były udostępnione na zgodnej licencji, z otwartym kodem źródłowym.
Wybór licencji ma bezpośredni wpływ na to, czy ktoś może użyć twojego kodu w płatnym, zamkniętym produkcie oraz czy musi publikować swoje modyfikacje.
Korzystając z cudzych bibliotek, to właśnie licencja decyduje, czy możesz bezpiecznie włączyć je do komercyjnego produktu bez obowiązku ujawniania całego kodu aplikacji.
