Po co w ogóle są licencje open source i dlaczego nie wystarczy „kod za darmo”
Co naprawdę reguluje licencja oprogramowania
Licencja oprogramowania to umowa między autorem a użytkownikiem, która określa, co wolno robić z kodem, a czego nie. Dotyczy to przede wszystkim praw autorskich do samego kodu źródłowego oraz (często) do zbudowanych z niego binariów. Licencja reguluje m.in. prawo do kopiowania, modyfikacji, dystrybucji, łączenia z innym kodem czy komercyjnego wykorzystywania.
Licencja nie reguluje wszystkiego, co jest „obok” oprogramowania. Zwykle nie dotyka wprost takich kwestii jak:
znaki towarowe i nazwa projektu (np. „Firefox”, „WordPress” – mogą być chronione niezależnie od licencji kodu),
dane użytkowników i ich przetwarzanie (to domena RODO, ustaw o ochronie danych itd.),
API usługi (licencja kodu biblioteki niekoniecznie decyduje o warunkach korzystania z API w chmurze),
warunki wsparcia, SLA, płatne usługi wokół projektu.
Licencja to po prostu zapis: „dopuszczam takie i takie użycie kodu, pod warunkiem spełnienia takich a takich wymogów”. Jeśli czegoś nie ma w licencji, obowiązuje domyślne prawo autorskie – czyli zazwyczaj wszelkie prawa zastrzeżone.
Różnica między „kod dostępny publicznie” a kodem z licencją open source
Wiele osób zakłada, że skoro repozytorium jest na GitHubie, to „kod jest darmowy, więc można go używać jak się chce”. To błędne założenie. Samo opublikowanie kodu w internecie nie oznacza udzielenia licencji open source. Bez wyraźnej licencji prawnie sytuacja wygląda tak, jakby autor napisał na dole: „wszelkie prawa zastrzeżone”.
Jeśli projekt nie ma licencji:
nie ma prawnego przyzwolenia na kopiowanie fragmentów do własnych repozytoriów,
nie ma jasności co do komercyjnego wykorzystania (może skończyć się zarzutem naruszenia praw autorskich),
firmowe działy prawne uznają projekt za ryzykowny – często wprost zakazują użycia w produktach.
Projekt staje się realnie „open source” dopiero wtedy, gdy autor doda licencję spełniającą kryteria np. Open Source Initiative (OSI) albo Free Software Foundation (FSF). Sama dostępność kodu nie tworzy praw po stronie użytkownika – tworzy je dopiero licencja.
Domyślne prawa autora bez licencji i ich konsekwencje
Bez licencji autorowi przysługują pełne prawa autorskie. To oznacza m.in., że tylko on decyduje o:
kopiowaniu kodu i jego dalszym rozpowszechnianiu,
publicznym udostępnianiu (np. hosting binariów),
modyfikacji i tworzeniu dzieł pochodnych.
Dla osoby, która chciałaby użyć takiego kodu, praktycznie wszystko poza czytaniem w przeglądarce jest wątpliwe prawnie. Skopiowanie klasy, zbudowanie binariów, zintegrowanie biblioteki z produktem – bez licencji to poruszanie się po bardzo cienkim lodzie. Dlatego tak ważne jest, by projekt miał jednoznaczną, zrozumiałą licencję.
W praktyce wiele firm ma wewnętrzne zasady: brak licencji lub niejasna licencja → automatyczny zakaz włączania kodu do produktu. To z kolei zamyka projektowi drogę do szerszej adopcji, nawet jeśli autor „w domyśle” chciał pozwolić na wszystko.
Główne cele licencji open source
Licencje open source mają kilka konkretnych zadań. Po pierwsze, zapewniają swobodę korzystania z oprogramowania – ale nie w trybie „wolna amerykanka”, tylko według ustalonych reguł. Po drugie, ustalają zasady współpracy w projekcie: co trzeba zachować (np. informację o autorach), co należy udostępnić (np. zmiany w kodzie), czego nie wolno robić (np. użyć nazwę projektu w sposób sugerujący oficjalne wsparcie).
Kolejna funkcja to ochrona autorów i użytkowników. Ochrona autora polega na tym, że nie odpowiada on za szkody spowodowane przez oprogramowanie („as is”, brak gwarancji). Ochrona użytkownika to np. kwestia patentów (istotna przy licencji Apache 2.0): ktoś, kto udostępnia kod, nie może nagle pozwać użytkownika za to, że korzysta z opatentowanego rozwiązania zawartego w tym kodzie.
Licencje open source wpływają również na to, jak łatwo zbudować społeczność. Im prościej i czytelniej opisane są prawa i obowiązki, tym bardziej przewidywalny jest projekt dla nowych kontrybutorów i firm. To jeden z powodów, dla których tak popularne stały się standardowe licencje jak MIT, Apache 2.0 czy GPL – wszyscy mniej więcej wiedzą, co one oznaczają.
Znaczenie licencji dla wykorzystania komercyjnego i budowy ekosystemu
Wbrew obiegowym opiniom open source nie wyklucza komercji. Kod na licencji MIT czy Apache 2.0 może być bez przeszkód używany w zamkniętych, płatnych produktach. Nawet GPL dopuszcza komercyjne wykorzystanie, choć wymusza otworzenie dzieła pochodnego na tej samej licencji przy dystrybucji.
Licencja decyduje o tym, jak wygląda model biznesowy wokół projektu. Permissive (MIT, Apache) ułatwiają tworzenie produktywnego ekosystemu firm budujących usługi, pluginy czy komercyjne dodatki. Licencje copyleft (GPL) sprzyjają powstawaniu wspólnego dobra, do którego wszyscy dorzucają kod i z którego wszyscy mogą korzystać na tych samych zasadach, ale ograniczają możliwość zamykania modyfikacji.
Dla świadomego autora kluczowe jest więc pytanie: czy celem jest jak największa adopcja w biznesie, czy wymuszenie otwartości rozwinięć? Odpowiedź przesuwa wybór licencji w stronę MIT/Apache albo GPL.
Źródło: Pexels | Autor: Markus Winkler
Podstawowe pojęcia: open source, wolne oprogramowanie, copyleft, permissive
Open source a wolne oprogramowanie: różnica praktyczna
Terminy „open source” i „wolne oprogramowanie” często są używane zamiennie, ale stoją za nimi trochę inne akcenty. Ruch free software (FSF, Richard Stallman) koncentruje się na kwestii wolności użytkownika, podczas gdy open source (OSI) podkreśla bardziej model współpracy i praktyczne korzyści. W praktycznych decyzjach licencyjnych różnica jest jednak niewielka.
Najprościej: oprogramowanie open source to takie, którego kod źródłowy jest dostępny, a licencja pozwala na używanie, analizę, modyfikację i dystrybucję, z pewnymi zastrzeżeniami. Wolne oprogramowanie definiuje podobne wolności, ale akcentuje je jako prawa użytkownika, które powinny być chronione.
Z punktu widzenia osoby wybierającej między MIT, Apache a GPL ważniejsze są konkretne mechanizmy licencji (copyleft vs permissive) niż różnica między „open source” a „free software” na poziomie ideologicznym.
Cztery wolności użytkownika w uproszczeniu
FSF definiuje cztery podstawowe wolności, które w dużej mierze realizują licencje open source:
Wolność uruchamiania programu w dowolnym celu – czy to hobbystycznie, czy komercyjnie.
Wolność analizowania, jak program działa, i dostosowywania go do własnych potrzeb – wymaga dostępu do kodu źródłowego.
Wolność rozpowszechniania kopii – dzielenia się oprogramowaniem z innymi, bez dodatkowych opłat licencyjnych.
Wolność rozpowszechniania zmodyfikowanych wersji – tak, aby społeczność mogła korzystać z usprawnień.
Licencje typu MIT i Apache realizują te wolności w sposób bardzo elastyczny, umożliwiając także zamknięte forki. GPL dodaje mechanizm copyleft, który ma chronić te wolności również dla późniejszych użytkowników dzieł pochodnych.
Permissive vs copyleft – dwa główne podejścia
Licencje open source z grubsza dzielą się na dwie grupy:
permissive – pozwalają na bardzo szerokie wykorzystanie, w tym w oprogramowaniu zamkniętym, bez obowiązku otwierania zmian (np. MIT, Apache 2.0, BSD),
copyleft – wymagają, by dzieła pochodne były licencjonowane na tych samych (lub kompatybilnych) zasadach i aby udostępniać kod źródłowy przy dystrybucji (np. GPL, LGPL, AGPL).
W praktyce wybór między permissive a copyleft to wybór między:
maksymalną swobodą dla użytkowników i firm (permissive) – często kosztem tego, że ktoś może „odgrodzić się” i nie dzielić zmian,
wymuszoną współdzieloną otwartością (copyleft) – często kosztem mniejszej adopcji biznesowej.
MIT i Apache 2.0 to licencje permissive. GPL to klasyczny przykład mocnego copyleftu, który rozciąga wymogi otwarcia kodu na całe dzieło pochodne.
Silne i słabe copyleft – tylko zarys
Copyleft może być silny albo słaby. Silny copyleft (np. GPL) zakłada, że jeśli tworzysz dzieło pochodne, to całość musi być objęta tą samą licencją. Słaby copyleft (np. LGPL, MPL) stosuje wymogi otwarcia tylko do określonych komponentów (np. bibliotek), pozwalając na ich łączenie z kodem zamkniętym bez „zarażenia” całego produktu.
Przykład: biblioteka pod LGPL może być dynamicznie linkowana z zamkniętą aplikacją, a sama aplikacja może pozostać własnościowa. W przypadku GPL, w zależności od interpretacji, nawet dynamiczne linkowanie może być traktowane jako tworzenie dzieła pochodnego, które wymaga objęcia GPL całości.
Dla codziennej praktyki programisty ważne jest, by rozumieć, że słabe copyleft wprowadza mniej restrykcji niż GPL, ale nadal wymaga publikacji zmian w samym komponencie objętym licencją copyleft.
Dzieło pochodne, dystrybucja i linkowanie – minimalny poziom zrozumienia
Dzieło pochodne to w uproszczeniu kod, który wykorzystuje fragmenty innego kodu w sposób twórczy i z nim się łączy. Może to być modyfikacja plików źródłowych, ale też wbudowanie kodu do większego projektu.
Dystrybucja oznacza przekazywanie oprogramowania dalej – np.:
sprzedaż lub udostępnianie binariów,
dołączanie oprogramowania do urządzenia (router, sprzęt IoT),
publikacja paczek instalacyjnych, kontenerów.
Samo uruchamianie oprogramowania w chmurze bez udostępniania binariów (model SaaS) nie zawsze jest traktowane jak dystrybucja w sensie licencyjnym – stąd powstanie takich licencji jak AGPL, które próbują ten lukę domknąć.
Linkowanie (statyczne, dynamiczne) to wrażliwy temat przy GPL. Statyczne linkowanie zwykle jest uznawane za tworzenie dzieła pochodnego. Dynamiczne bywa źródłem sporów – FSF często uważa je również za tworzenie dzieła pochodnego, natomiast w praktyce prawniczej interpretacje różnią się. Kluczowe jest zrozumienie, że sposób technicznego włączenia biblioteki może wpływać na to, czy cały produkt „dziedziczy” wymogi GPL.
MIT – najprostsza i najbardziej „luźna” licencja
Zakres uprawnień: co wolno na licencji MIT
Licencja MIT jest jedną z najkrótszych i najprostszych licencji open source. W praktyce pozwala na:
używanie kodu w dowolnym celu (osobistym, komercyjnym, edukacyjnym),
kopiowanie i rozpowszechnianie kodu w niezmienionej formie,
modyfikowanie kodu według własnych potrzeb,
łączenie kodu z innym oprogramowaniem, również własnościowym,
sprzedawanie oprogramowania bazującego na tym kodzie, także jako zamkniętego produktu.
W pewnym sensie MIT mówi: „możesz robić z tym kodem prawie wszystko, bylebyś nie udawał, że nie istnieją pierwotni autorzy, i nie oczekiwał od nich odpowiedzialności za szkody”. Dlatego dla wielu firm licencja MIT jest idealna – prosta, przewidywalna, bez „wirusowego” copyleftu.
Obowiązki użytkownika: co trzeba zachować
W zamian za szerokie uprawnienia licencja MIT nakłada minimalne obowiązki na użytkownika. Najważniejsze z nich:
zachowanie informacji o prawach autorskich (copyright notice),
dołączenie treści licencji MIT do kopii oprogramowania lub istotnych jego części.
Oznacza to w praktyce, że jeśli np. włączasz bibliotekę MIT do swojej aplikacji i rozpowszechniasz tę aplikację, powinieneś w dokumentacji, pliku LICENSE lub oświadczeniu licencyjnym zachować informację o autorach i samej licencji. Nie musisz natomiast udostępniać źródeł własnego kodu, nawet jeśli intensywnie wykorzystuje kod MIT.
W oprogramowaniu komercyjnym często wygląda to tak, że w sekcji „About”, „Licences” czy w pliku NOTICE znajduje się lista komponentów open source wraz z ich licencjami, w tym MIT.
Brak copyleft: konsekwencje dla autorów i firm
Co MIT nie reguluje: patenty, znaki towarowe, nazwa projektu
Licencja MIT jest celowo minimalistyczna. Poza prawami autorskimi właściwie niczego nie reguluje. Ma to praktyczne skutki, o których wielu autorów i firm uczy się dopiero przy pierwszym audycie prawnym.
Po pierwsze, MIT nie zawiera wyraźnego udzielenia licencji patentowej. W uproszczeniu: jeśli autor projektu posiada patenty na pewne rozwiązania zastosowane w kodzie, MIT nie mówi wprost, że wolno z nich korzystać. W świecie typowych bibliotek webowych zwykle nikt nie przejmuje się patentami, ale w obszarach jak kryptografia, kompresja czy multimedia ten brak może być problemem.
Po drugie, MIT nie daje prawa do używania znaków towarowych. Jeśli framework ma zarejestrowaną nazwę lub logo, MIT nie oznacza automatycznie, że możesz wykorzystać je w nazwie własnego produktu. To osobny reżim prawny, niezależny od licencji na kod.
Po trzecie, MIT nie narzuca wymagań co do sposobu przypisywania autorstwa poza zachowaniem nagłówka licencyjnego. Jeśli chcesz mieć np. obowiązkowe wyróżnienie „Powered by X” w interfejsie użytkownika, sama MIT tego nie zapewni – musiałby to regulować osobny kontrakt lub dodatkowy zapis (co zwykle odradzają prawnicy, bo komplikujesz zgodność z OSI).
Typowe zastosowania MIT w projektach i firmach
MIT najczęściej spotyka się w:
małych bibliotekach i narzędziach developerskich – autorowi zależy przede wszystkim na tym, by kod był jak najszerzej używany, także komercyjnie,
komponentach frontendowych – tam, gdzie powstaje dużo forów i modyfikacji, a nikt nie chce spierać się o obowiązek otwierania kodu,
projektach akademickich i proof-of-concept – zespół badawczy publikuje kod tak, aby ewentualne firmy mogły z łatwością włączyć go do produktów,
wewnętrznych bibliotekach firmowych udostępnionych publicznie – organizacja nie planuje modelu biznesowego wokół danego repozytorium, ale chce budować wizerunek i ekosystem.
Jeśli celem jest „zero tarcia prawnego” i brak oczekiwań co do tego, że użytkownicy będą zwracać kod z powrotem, MIT jest rozsądnym wyborem.
Kiedy MIT może nie być wystarczające dla autora
MIT nie każdemu twórcy będzie odpowiadać. Problemy pojawiają się głównie wtedy, gdy:
chcesz wymusić otwartość modyfikacji – MIT tego nie robi, więc ktoś może stworzyć zamkniętą wersję twojego projektu i nigdy nie opublikować usprawnień,
obawiasz się patentów i agresywnej konkurencji – MIT nie zapewnia wyraźnej licencji patentowej ani klauzul o odwołaniu licencji w razie pozwu,
planujesz model dual-licensing z mocnym copyleftem po jednej stronie
Jeśli czujesz, że chcesz jednocześnie szerokiej adopcji i choć minimalnego zabezpieczenia patentowego, naturalnym kolejnym krokiem jest rozważenie Apache 2.0.
Źródło: Pexels | Autor: Digital Buggu
Apache 2.0 – wersja permissive z ochroną patentową
Dlaczego powstała i czym się wyróżnia
Licencja Apache 2.0 to odpowiedź na potrzeby większych organizacji i projektów, dla których MIT jest zbyt ogólna. Nadal jest licencją permissive, ale dodaje kilka istotnych elementów, zwłaszcza w obszarze patentów, a także strukturuje obowiązki wobec użytkownika w bardziej szczegółowy sposób.
W praktyce Apache 2.0 jest często postrzegana jako „MIT plus” – zbliżona swobodą użycia, lecz lepiej przygotowana na spory patentowe i przejrzystsza przy dużej skali komercyjnej.
Kluczowe uprawnienia w Apache 2.0
Pod względem tego, co wolno zrobić z kodem, Apache 2.0 jest bardzo zbliżona do MIT:
można używać kodu komercyjnie i niekomercyjnie,
można modyfikować, rozpowszechniać, sprzedawać, łączyć z kodem zamkniętym,
nie ma obowiązku publikowania zmian ani otwierania całego produktu.
Najważniejsza różnica polega na tym, że Apache 2.0: wyraźnie udziela licencji patentowej na wkład wniesiony przez kontrybutorów. Dla firm jest to istotny argument, gdy rozważają wykorzystanie komponentu w produkcie generującym duże przychody.
Licencja patentowa i jej odwołanie
Apache 2.0 wprowadza dwa mechanizmy, które bezpośrednio dotyczą patentów:
udzielenie licencji patentowej – każdy kontrybutor udziela użytkownikom niewyłącznej licencji na patenty, które są niezbędne do korzystania z jego wkładu w projekcie,
warunek „patent retaliation” – jeśli użytkownik pozywa kontrybutora lub innego użytkownika za naruszenie patentu dotyczącego tego kodu, jego licencja zostaje automatycznie odwołana.
Dzięki temu Apache 2.0 działa trochę jak „strefa zdemilitaryzowana”: możesz korzystać z kodu, ale jeśli spróbujesz wykorzystać patenty przeciwko innym uczestnikom ekosystemu w sprawie dotyczącej tego projektu, tracisz prawa do używania go na tej licencji.
Obowiązki: NOTICE, zmiany w plikach i atrybucja
Apache 2.0 wprowadza bardziej rozbudowane obowiązki niż MIT, zwłaszcza jeśli modyfikujesz kod i rozpowszechniasz go dalej. Do najważniejszych należą:
zachowanie informacji o prawach autorskich i treści licencji – podobnie jak w MIT, ale z bardziej formalną strukturą,
dołączenie pliku NOTICE – jeśli projekt go zawiera, a ty rozpowszechniasz binaria, powinieneś udostępnić użytkownikowi treść NOTICE w rozsądny sposób (np. w dokumentacji, w interfejsie „About”, w pakiecie instalacyjnym),
jasne oznaczenie zmian w plikach – zaleca się, aby w zmodyfikowanych plikach zaznaczyć, że zostały zmienione, i wskazać autora oraz datę lub zakres zmian.
Te wymagania są nieco bardziej uciążliwe przy dużych forkujących projektach, ale w zamian dają przejrzystą historię i lepszą ochronę identyfikacji autorów.
Apache 2.0 a znaki towarowe
Podobnie jak MIT, Apache 2.0 nie przenosi praw do znaków towarowych. Sama licencja wyraźnie wskazuje, że nie daje prawa do używania nazw projektów, logo czy oznaczeń fundacji Apache jako marki własnego produktu.
Jeśli budujesz komercyjną usługę na bazie np. Elasticsearch czy Kafki, nazwy produktów mogą być chronione niezależnie od licencji na kod. To powód, dla którego czasem widzi się „X-compatible” zamiast użycia chronionej nazwy wprost.
Kompatybilność z GPL i konsekwencje wyboru Apache 2.0
Apache 2.0 bywa wrażliwa pod kątem kompatybilności z GPL:
jest kompatybilna z GPLv3 – kod na Apache 2.0 można włączyć do projektu GPLv3 (ale całość musi być wtedy wydana pod GPLv3),
nie jest uznawana za kompatybilną z GPLv2 „only” – różnica wynika m.in. z zapisów patentowych.
Dla twórcy oznacza to, że jeśli wybierze Apache 2.0, jego kod może być użyty w projektach GPLv3, ale nie w projektach zastrzegających wyłącznie GPLv2 bez opcji „lub nowsza”. Z kolei jeśli planujesz kiedyś przejść na GPLv2-only lub chcesz, by twój kod był łatwo łączony z takimi projektami, MIT może być bezpieczniejszym wyborem.
Źródło: Pexels | Autor: Markus Winkler
GPL – copyleft, który rozciąga się na dzieła pochodne
Idea GPL: wzajemność zamiast maksymalnej swobody
Licencja GPL (v2 i v3) została zaprojektowana z zupełnie inną filozofią niż MIT czy Apache. Jej główna zasada to wymuszona wzajemność: jeśli korzystasz z kodu, rozwijasz go i rozpowszechniasz dalej, to inni powinni dostać takie same wolności jak ty, włącznie z dostępem do kodu źródłowego.
W efekcie GPL nie ogranicza swobody użycia wewnętrznego – możesz uruchamiać programy GPL wewnątrz firmy bez żadnych zobowiązań publikacyjnych. Kluczowe stają się dwa momenty: tworzenie dzieła pochodnego oraz dystrybucja.
Co uruchamia obowiązek udostępnienia kodu w GPL
W typowym scenariuszu obowiązek udostępnienia kodu pojawia się, gdy:
tworzysz dzieło pochodne, które wykorzystuje kod GPL (np. modyfikujesz go, linkujesz statycznie lub – według interpretacji FSF – dynamicznie), oraz
rozpowszechniasz to dzieło pochodne poza swoją organizacją (sprzedaż, udostępnienie binariów, dystrybucja na nośnikach, w urządzeniach itd.).
W takiej sytuacji jesteś zobowiązany:
licencjonować całość dzieła pochodnego na GPL (lub kompatybilną),
zapewnić odbiorcom dostęp do pełnego kodu źródłowego, obejmującego także twoje modyfikacje i powiązany kod „zarażony” GPL.
Jeśli program jest używany wyłącznie wewnętrznie (np. narzędzie administracyjne, które nie jest dystrybuowane klientom), obowiązek publikacji nie powstaje – niezależnie od tego, jak głęboko zmodyfikowałeś kod GPL.
GPLv2 vs GPLv3 – najważniejsze różnice praktyczne
Między wersją 2 a 3 licencji GPL jest wiele szczegółowych różnic, ale w codziennej praktyce kluczowe są trzy obszary:
patenty – GPLv3 wyraźniej reguluje kwestie patentowe, w tym umowy patentowe między firmami (np. Microsoft–Novell), starając się uniemożliwić obchodzenie copyleft poprzez licencje patentowe,
„tivoizacja” – GPLv3 wymaga, aby użytkownik miał możliwość uruchomienia zmodyfikowanej wersji programu na urządzeniu, jeśli producent dystrybuuje tam kod GPL; GPLv2 nie zawiera tak szczegółowych regulacji,
kompatybilność z innymi licencjami – GPLv3 została zaprojektowana tak, aby współgrała m.in. z Apache 2.0, natomiast GPLv2 nie.
W praktyce część projektów pozostała przy GPLv2 (np. jądro Linux), a część przeszła na GPLv3, aby lepiej zabezpieczyć się przed konstrukcjami prawnymi omijającymi ducha copyleft.
„Wirusowość” GPL: na czym konkretnie polega
Metafora „wirusowości” jest uproszczeniem, ale dobrze obrazuje efekt: wymogi GPL rozciągają się na dzieła pochodne. W uproszczeniu:
jeśli statycznie linkujesz bibliotekę GPL do własnego kodu i rozpowszechniasz binaria, całość jest traktowana jako jedno dzieło pochodne i musi być dostępna na GPL,
w przypadku dynamicznego linkowania sprawa jest bardziej sporna; FSF zwykle uznaje je za tworzenie dzieła pochodnego, część prawników – nie zawsze, zależnie od konkretnego przypadku,
jeśli tylko komunikujesz się z programem GPL przez sieć (np. przez API), zwykle nie powstaje dzieło pochodne, więc obowiązek udostępniania kodu nie obejmuje całej aplikacji; może natomiast objąć modyfikacje w samym programie GPL, jeśli są dystrybuowane.
W praktyce firmy często unikają bibliotek na pełnej GPL w komponentach aplikacji dystrybuowanych klientom, aby nie ryzykować, że cały produkt będzie musiał być objęty GPL.
GPL a SaaS – dlaczego powstała AGPL
Model SaaS (software as a service) pokazał lukę w klasycznym copyleft: jeśli aplikacja na GPL działa na serwerze i nie jest dystrybuowana jako kod lub binaria, to obowiązek udostępnienia kodu nie jest uruchamiany. Użytkownicy korzystają z funkcji programu, ale nie dostają praw typowych dla oprogramowania „instalowanego”.
Aby objąć ten scenariusz, powstała AGPL (Affero GPL), która rozszerza obowiązki: jeśli modyfikujesz program AGPL i udostępniasz go użytkownikom przez sieć (np. jako usługę webową), musisz udostępnić kod źródłowy tej zmodyfikowanej wersji użytkownikom usługi.
Dla wielu firm AGPL jest jeszcze bardziej „toksyczna” niż GPL, bo dotyka typowego dziś modelu chmurowego. Z tego powodu biblioteki i aplikacje na AGPL są często omijane w komercyjnych produktach SaaS.
Kiedy GPL ma sens dla autora
GPL jest racjonalnym wyborem wtedy, gdy celem jest maksymalizacja wspólnego dobra, a nie swobody firm:
chcesz, by każdy, kto rozwija twoje oprogramowanie i rozpowszechnia je dalej, musiał oddać ulepszenia społeczności,
tworzysz narzędzie, które ma służyć jako podstawa ekosystemu otwartego, a nie biblioteka do wbudowania w zamknięte produkty,
twoje główne źródło przychodu to nie sprzedaż licencji, ale np. usługi, wsparcie, hosting, a otwartość kodu jest atutem, nie przeszkodą.
MIT vs Apache vs GPL w praktyce – scenariusze użycia
Mała biblioteka frontendowa używana w aplikacjach SaaS
Wyobraźmy sobie prostą bibliotekę JavaScript do formatowania dat, którą chcesz opublikować na GitHubie. Wiesz, że twoim głównym „klientem” będą frontendowcy budujący zamknięte aplikacje webowe i SaaS.
Jeśli celem jest maksymalna adopcja i brak obaw prawnych u użytkowników, najczęściej wybór zawęża się do MIT lub Apache 2.0:
MIT – minimalne wymagania, praktycznie każdy produkt (również zamknięty) może używać biblioteki bez konieczności publikowania kodu źródłowego. Wystarczy zachować notę licencyjną w dokumentacji/„About”.
Apache 2.0 – podobna swoboda, ale z dodatkowymi obowiązkami (NOTICE, oznaczanie zmian) i tarczą patentową. Dla małej biblioteki UI często jest to „overkill”, chyba że pracujesz w branży z wysokim ryzykiem sporów patentowych.
GPL w tym scenariuszu rzadko ma sens, jeśli chcesz, żeby biblioteka była używana szeroko. Włączenie biblioteki na GPL do aplikacji, którą dystrybuujesz klientom (np. jako desktop/web w on-premise), może „pociągnąć” cały frontend pod GPL, co bywa nieakceptowalne dla firm.
Silnik aplikacji a wtyczki – model „core + pluginy”
Częsty wzorzec to silnik (core) oprogramowania i zestaw wtyczek pisanych przez społeczność lub partnerów. Wybór licencji dla „rdzenia” wpływa wprost na to, jak mogą być licencjonowane dodatki.
Jeśli rdzeń jest na GPL i wtyczki są ładowane jako moduły w tym samym procesie (importowane jako biblioteki, korzystają z wewnętrznych API), istnieje duża szansa, że zostaną uznane za dzieła pochodne. Wtedy:
rozszerzenia dystrybuowane razem z core muszą być na licencji zgodnej z GPL,
partnerzy, którzy chcą pisać zamknięte pluginy, będą mieli utrudnione zadanie (często wchodzą wtedy układy dual-licensing lub komercyjne wyjątki).
Jeśli ten sam silnik wydasz na MIT lub Apache 2.0, autorzy wtyczek mogą dowolnie licencjonować swoje rozszerzenia – otwarcie lub zamknięcie kodu nie wpływa na zgodność z rdzeniem. To model stosowany np. w wielu ekosystemach JS, gdzie core jest open source permissive, a pluginy bywają komercyjne.
Granica bywa cieńsza, jeśli wtyczki komunikują się z core przez zewnętrzne interfejsy (REST, gRPC, CLI). Im bardziej interakcja przypomina „używanie programu”, a nie wspólne dzieło, tym trudniej uznać plugin za dzieło pochodne pod GPL.
Biblioteka backendowa w produkcie on‑premise
Załóżmy, że piszesz backendową bibliotekę w Go, która upraszcza integrację z popularnym systemem płatności. Klienci to głównie firmy dostarczające swoim klientom aplikacje on‑premise (instalowane w infrastrukturze klienta lub na urządzeniach).
Jeśli biblioteka jest na GPL, a produkt końcowy jest dystrybuowany jako binaria, to:
statyczne linkowanie niemal na pewno „zaraża” całość GPL,
dynamiczne linkowanie jest sporne, ale wiele firm traktuje je ostrożnie jak ryzykowne.
W efekcie większość producentów oprogramowania unika w takim miejscu GPL. Przy MIT lub Apache 2.0 można biblioteki użyć w produkcie zamkniętym, bez obowiązku ujawniania kodu.
Różnica między MIT a Apache 2.0 w tym scenariuszu sprowadza się zwykle do pytania: czy istnieje realne ryzyko sporów patentowych? Jeśli tworzysz bibliotekę implementującą skomplikowane algorytmy, integracje z zastrzeżonymi protokołami itp., Apache 2.0 może być bezpieczniejsza dla ciebie i użytkowników.
Framework webowy a dostawcy hostingu
Wyobraź sobie nowy framework webowy, który ma być alternatywą dla istniejących rozwiązań. Chcesz, by korzystali z niego zarówno indywidualni developerzy, jak i duże firmy hostingowe.
Z punktu widzenia licencji:
MIT/Apache 2.0 – hostingi mogą oferować usługę „Framework X as a Service”, nie udostępniając żadnego własnego kodu. Mogą też wprowadzać prywatne modyfikacje frameworka (forki), które nigdy nie wrócą do upstreamu.
GPL – jeśli hosting dystrybuuje framework jako pakiet do zainstalowania (np. w obrazie VM czy kontenerze), jest zobowiązany do udostępnienia kodu (w tym modyfikacji). Jednak jeśli tylko uruchamia oryginalny framework i świadczy usługę (czysty SaaS), copyleft się nie uruchamia.
AGPL – hosting, który modyfikuje framework i oferuje go jako usługę, musi udostępnić kod tych modyfikacji użytkownikom serwisu, nawet jeśli nic nie dystrybuuje jako pakiety.
Dla autora frameworka wybór AGPL może być sposobem, aby uniemożliwić „prywatyzowanie” ulepszeń przez dużych graczy SaaS. Dla firm hostingowych jest to natomiast sygnał ostrzegawczy i powód do szukania alternatyw na bardziej liberalnych licencjach.
Projekt wewnętrzny w korporacji a obowiązki licencyjne
Wiele zespołów w dużych organizacjach nieświadomie miesza komponenty o różnych licencjach w kodzie, który ma być dystrybuowany do klientów. Sytuacja wygląda inaczej, gdy oprogramowanie jest wyłącznie wewnętrzne, a inaczej, gdy jest instalowane u klienta.
Jeśli tworzysz system CRM używany tylko w sieci wewnętrznej korporacji, możesz dość swobodnie korzystać nawet z komponentów na pełnej GPL – brak dystrybucji na zewnątrz oznacza brak obowiązku udostępniania kodu. Problem zaczyna się, gdy ten sam system ma trafić jako produkt do klientów:
komponenty na MIT/Apache 2.0 – zachowujesz noty licencyjne, ale nie musisz otwierać własnego kodu,
komponenty na GPL – jeśli są silnie zintegrowane (linkowane, modyfikowane), można być zmuszonym do udostępnienia kodu całego systemu, a nie tylko zmian w bibliotece.
Dlatego audyty licencyjne (tzw. open source compliance) przed komercyjną dystrybucją są standardem – chodzi właśnie o wychwycenie „zarażających” komponentów i świadome decyzje, co z nimi zrobić.
Startup open source a model biznesowy
Coraz więcej startupów zaczyna od otwartego kodu i dopiero potem szuka modelu monetyzacji. Wybór licencji wpływa bezpośrednio na to, jakie scenariusze są możliwe.
Przy licencjach MIT/Apache 2.0 najczęstsze modele to:
open core – podstawowy silnik jest open source, a płatne moduły lub usługi są zamknięte,
komercyjny hosting – oprogramowanie jest darmowe, ale płacisz za zarządzany serwis (np. w chmurze),
support i consulting – płatne wsparcie, szkolenia, implementacje szyte na miarę.
Problem: duży dostawca chmury może wziąć kod, zaoferować lepszy hosting pod własną marką i nie wnieść nic z powrotem (zjawisko „strip‑mine OSS”).
Aby to ograniczyć, część firm wybiera GPL/AGPL plus model dual-licensing: społeczność dostaje wersję copyleft, a partnerzy komercyjni mogą wykupić licencję komercyjną z prawem do budowy własnych, zamkniętych rozszerzeń. To jednak wymaga kontroli praw autorskich (np. CLA) i spójnej strategii, inaczej powstaje chaos licencyjny.
Kontrybucje społeczności a przeniesienie praw autorskich
Sam wybór licencji to jedno; drugim elementem jest sposób zarządzania prawami do kontrybucji. Jeśli projekt przyjmie dużą liczbę wkładów od osób trzecich, za kilka lat może być trudno zmienić licencję lub wprowadzić model dual‑licensing.
Istnieją dwa główne podejścia:
brak przeniesienia praw – każdy kontrybutor zachowuje prawa do swojego wkładu, udzielając jedynie licencji zgodnej z licencją projektu (np. MIT/Apache/GPL). Zmiana licencji projektu później wymaga zgody wszystkich współautorów lub bardzo precyzyjnych klauzul w dokumentacji kontrybucji.
CLA (Contributor License Agreement) lub przeniesienie praw – autor kontrybucji udziela szerokiej licencji na wkład (czasem przenosi prawa autorskie) na rzecz podmiotu zarządzającego projektem. To umożliwia późniejsze zmiany licencji lub wydanie części kodu na innej licencji komercyjnej.
Dla kontrybutorów oznacza to, że przy projektach z CLA trzeba świadomie zaakceptować, że właściciel może np. sprzedawać komercyjne wersje oparte na wspólnym kodzie. Dla właściciela jest to często jedyna droga do elastycznej strategii licencyjnej w przyszłości.
Łączenie kodu o różnych licencjach w jednym projekcie
Przy większych projektach rzadko spotyka się sytuację, w której wszystko jest na jednej licencji. Powszechne są kombinacje: kod własny + zależności MIT/Apache + pojedyncze komponenty GPL lub AGPL. Każda kombinacja ma konsekwencje.
Przykładowe reguły orientacyjne:
MIT + Apache 2.0 – zwykle bezproblemowe w jedną i drugą stronę, przy czym jeśli łączysz i dystrybuujesz razem, sensowne jest objęcie całości licencją, która spełnia wymagania obu (np. Apache 2.0 + zachowanie MITowego nagłówka w konkretnych plikach).
MIT/Apache → GPL – kod permissive możesz „podnieść” do GPL (łącząc go z projektem GPL), ale w drugą stronę już nie; raz zintegrowany w dziele GPL staje się jego częścią i podlega copyleftowi.
GPL + kod zamknięty – jeśli tworzą jedno dzieło pochodne (linkowanie, wspólny binarny artefakt), GPL zwykle wymaga otwarcia kodu. Rozdzielenie na osobne procesy komunikujące się po sieci redukuje to ryzyko, ale wymaga przemyślanej architektury.
Dobrą praktyką jest prowadzenie SBOM (Software Bill of Materials) – listy wszystkich zależności wraz z licencjami. Dopiero mając taki spis, da się realnie ocenić, czy planowany sposób dystrybucji jest zgodny z licencjami wszystkich komponentów.
Licencja biblioteki a publikacja na marketplace (App Store, Play itp.)
Dystrybucja aplikacji przez sklepy z aplikacjami dodaje kolejny wymiar: regulaminy tych platform bywają w konflikcie z copyleft.
Znany problem to publikowanie aplikacji na GPL w sklepach, których regulaminy nakładają dodatkowe ograniczenia na użytkownika (np. brak prawa do dalszej redystrybucji lub inny model DRM). Niektóre interpretacje mówią, że regulamin sklepu jest w sprzeczności z GPL, bo nakłada ograniczenia, których GPL zabrania.
Dlatego część projektów na GPL celowo unika oficjalnych marketplace’ów albo udostępnia binaria poza nimi (np. na własnych stronach czy w alternatywnych repozytoriach). Przy MIT/Apache takie konflikty są znacznie rzadsze, bo licencje te nie wymuszają takich samych gwarancji wolności dalszej redystrybucji.
Biblioteki klienckie do usług chmurowych
Duzi dostawcy chmurowi udostępniają SDK do swoich API, żeby zachęcać do integracji. Te biblioteki są niemal zawsze na licencjach permissive (MIT, Apache 2.0, BSD). Powód jest prosty: chcą, żeby integracja była możliwie bezbolesna dla klientów o różnych modelach licencjonowania.
Gdyby SDK było na GPL, każda aplikacja korzystająca z tego SDK i dystrybuowana dalej mogłaby być „ciągnięta” w stronę GPL, co zmniejszyłoby liczbę firm gotowych na integrację. Apache 2.0 bywa preferowana ze względu na aspekt patentowy – szczególnie gdy SDK implementuje nietrywialne protokoły lub formaty komunikacji.
Zmiana licencji w istniejącym projekcie
Po kilku latach rozwoju bywa, że autor lub organizacja chce zmienić licencję projektu – np. z GPL na MIT lub odwrotnie. Możliwość takiej zmiany zależy od historii prawniczej projektu.
Jeśli:
jesteś jedynym autorem całego kodu lub posiadasz przeniesione prawa od innych (np. dzięki CLA), możesz zasadniczo zmienić licencję w dowolnym momencie dla kolejnych wersji,
masz wielu kontrybutorów bez CLA, zmiana na bardziej restrykcyjną lub bardziej liberalną licencję wymaga zgody wszystkich współautorów danego fragmentu kodu; w praktyce bywa to niewykonalne.
Typowy kompromis: pozostawienie dotychczasowych wersji na starej licencji i wydanie przyszłych wersji na nowej, jeśli nowy kod jest pisany w znacznej mierze od zera lub przez jednego podmiotowego właściciela praw. To kolejny argument, żeby o kwestiach licencji myśleć na początku, a nie dopiero wtedy, gdy projekt zacznie być szeroko używany.
Najczęściej zadawane pytania (FAQ)
Czym różni się „kod dostępny na GitHubie” od kodu na licencji open source?
Kod dostępny publicznie (np. na GitHubie) bez licencji to nadal „wszelkie prawa zastrzeżone”. Możesz go obejrzeć, ale prawnie nie masz jasnego przyzwolenia na kopiowanie, modyfikację czy włączanie go do własnych projektów, zwłaszcza komercyjnych.
Kod na licencji open source ma jasno określone zasady użycia. Licencja wyraźnie mówi, co wolno (np. używać komercyjnie, modyfikować, dystrybuować), a czego nie (np. usuwać informacji o autorze). Dla firm to kluczowe: brak licencji zwykle oznacza automatyczny zakaz użycia w produkcie.
Co dokładnie reguluje licencja open source, a czego nie obejmuje?
Licencja open source reguluje głównie prawa autorskie do kodu: kopiowanie, modyfikację, dystrybucję, wykorzystanie komercyjne, łączenie z innym kodem. Często określa też wyłączenie odpowiedzialności autora („as is”) oraz zasady związane z patentami (np. w Apache 2.0).
Licencja zazwyczaj nie reguluje znaków towarowych (nazwa projektu, logo), przetwarzania danych użytkowników, warunków korzystania z API czy płatnych usług towarzyszących. Te obszary podlegają osobnym regulaminom, prawu ochrony danych, prawu znaków towarowych itd.
Czy mogę legalnie użyć kodu z GitHuba w projekcie komercyjnym?
To zależy od licencji. Jeśli repozytorium ma licencję MIT lub Apache 2.0, użycie w projekcie komercyjnym (w tym zamkniętym) jest co do zasady dozwolone, pod warunkiem spełnienia kilku prostych wymogów, np. zachowania informacji o licencji i autorach.
Przy GPL sytuacja jest inna: możesz używać kodu komercyjnie, ale jeśli dystrybuujesz produkt zawierający ten kod, musisz udostępnić źródła dzieła pochodnego na tej samej licencji. Jeśli projektu w ogóle nie ma licencji, bez zgody autora użycie w komercji jest bardzo ryzykowne prawnie.
Jaka jest praktyczna różnica między licencjami MIT, Apache 2.0 i GPL?
MIT i Apache 2.0 to licencje „permissive” – dają szeroką swobodę, także dla oprogramowania zamkniętego. MIT jest bardzo krótka: wymaga głównie zachowania informacji o prawach autorskich i wyłączenia odpowiedzialności. Apache 2.0 dodaje elementy związane z patentami oraz nieco bardziej rozbudowane warunki.
GPL to licencja „copyleft”: pozwala na komercyjne użycie, ale jeśli dystrybuujesz dzieło pochodne, musisz udostępnić jego kod źródłowy na tej samej licencji. W praktyce MIT/Apache są chętniej wybierane, gdy celem jest maksymalna adopcja przez firmy, a GPL – gdy priorytetem jest wymuszenie otwartości modyfikacji.
Czym się różni open source od „wolnego oprogramowania” (free software)?
Oba pojęcia opisują oprogramowanie, którego kod źródłowy jest dostępny i które można używać, analizować, modyfikować i rozpowszechniać. Różnica dotyczy głównie akcentów: ruch free software kładzie nacisk na wolności użytkownika jako prawa, a open source – na model współpracy i praktyczne korzyści biznesowe.
Z perspektywy wyboru MIT/Apache/GPL ważniejsze są konkretne mechanizmy licencyjne (copyleft vs permissive) niż etykieta „open source” czy „free software”. Te same licencje (np. GPL) są jednocześnie akceptowane przez OSI i FSF.
Co to znaczy licencja „permissive” i „copyleft” w praktyce użycia kodu?
Licencje permissive (MIT, Apache, BSD) pozwalają na niemal dowolne wykorzystanie kodu, w tym w oprogramowaniu zamkniętym, bez obowiązku udostępniania zmian. W praktyce ułatwiają tworzenie komercyjnych produktów i usług wokół projektu, bo nie „zarażają” całego kodu wymogiem otwarcia.
Licencje copyleft (GPL, AGPL, w łagodniejszej wersji LGPL) wymagają, by dzieła pochodne były licencjonowane na tych samych zasadach i by przy dystrybucji udostępnić kod źródłowy. Chronią wolności użytkowników w kolejnych generacjach projektu, ale ograniczają możliwość włączenia kodu do zamkniętych produktów.
Jaką licencję wybrać dla własnego projektu open source?
Najbardziej praktyczne jest wyjście od celu. Jeśli zależy ci na jak najszerszej adopcji, w tym przez firmy i projekty zamknięte, typowy wybór to MIT albo Apache 2.0 (Apache bywa preferowana, gdy w grę wchodzą patenty i większe organizacje). Jeśli chcesz, by każdy, kto rozwija twój kod i go dystrybuuje, musiał także udostępniać źródła – rozważ GPL.
W małych bibliotekach i narzędziach deweloperskich dominuje MIT/Apache ze względu na prostotę i niską barierę integracji. GPL częściej pojawia się w aplikacjach końcowych, frameworkach czy narzędziach, gdzie autorom szczególnie zależy na tym, by rozszerzenia i forki pozostały otwarte.
