Jeżeli korzystasz z otwartego oprogramowania, bibliotek, frameworków lub narzędzi deweloperskich, prędzej czy później zetkniesz się z pytaniem: na jakich zasadach możesz ich używać, modyfikować i dystrybuować? Właśnie do tego służą licencje open source. To standardowe wzory licencyjne, które określają prawa i obowiązki wobec kodu udostępnionego publicznie. Instytucją, która zatwierdza te licencje w ramach formalnego procesu review, jest Open Source Initiative — organizacja, która w 1998 roku sformalizowała pojęcie open source i opracowała Open Source Definition, powszechnie uznawaną jako rynkowy standard oceny licencji.

Dla przedsiębiorcy, działu IT, agencji software’owej i każdej firmy budującej produkt cyfrowy to temat fundamentalny. Wbudowanie biblioteki open source w produkt komercyjny — bez sprawdzenia warunków jej licencji — może oznaczać obowiązek ujawnienia całego kodu źródłowego produktu jako alternatywa do bezprawnego użycia takiej licencji. Warto też pamiętać, że licencje open source to nadal pełnoprawne umowy licencyjne: naruszenie ich warunków może rodzić odpowiedzialność za naruszenie praw autorskich.

7 kluczowych wniosków dla tych, którzy nie mają czasu czytać całości

1. Open source nie oznacza „bez praw autorskich”. Autor kodu zachowuje prawa autorskie i udziela licencji na ściśle określonych warunkach. Naruszenie tych warunków to naruszenie praw autorskich — z pełnymi prawnymi konsekwencjami.
2. Kluczowy podział to permissive vs copyleft. Licencje permisywne (MIT, Apache 2.0, BSD) pozwalają na włączenie kodu do produktów zamkniętych. Licencje copyleft (GPL, AGPL) mogą wymuszać ujawnienie kodu pochodnego na tej samej licencji — zakres tego obowiązku zależy od sposobu integracji i typu licencji.
3. AGPL nakłada dodatkowe obowiązki dla usług sieciowych. AGPL dodaje odrębny obowiązek: operator serwera, który udostępnia użytkownikom interakcję z zmodyfikowaną wersją programu przez sieć, musi umożliwić im pobranie odpowiedniego kodu źródłowego. To istotne ograniczenie dla usług SaaS — nawet bez fizycznej dystrybucji oprogramowania.
4. Apache 2.0 zawiera ochronę patentową, MIT nie. Apache 2.0 wprost udziela licencji na wszelkie patenty objęte przez kontrybutorów i zawiera klauzulę odwetową na wypadek sporów patentowych. MIT tych gwarancji nie daje.
5. LGPL i MPL to copyleft o ograniczonym zasięgu. Pozwalają na łączenie z kodem zamkniętym poprzez dynamiczne linkowanie lub wyraźny podział plików — pod warunkiem zachowania otwartości samej biblioteki lub zmodyfikowanych plików. To popularny kompromis dla bibliotek używanych w produktach komercyjnych.
6. Kompatybilność licencji to osobny problem. Nie każdą licencję można mieszać z każdą. Kod GPL v2 i Apache 2.0 są ze sobą niekompatybilne. Kod GPL v3 i Apache 2.0 są kompatybilne. Łączenie licencji bez sprawdzenia ich zgodności może zrodzić nierozwiązywalne konflikty prawne.
7. Sama licencja open source to nie wszystko. Mogą istnieć dodatkowe warunki dotyczące znaków towarowych, klauzule contributor license agreement (CLA), zasady dotyczące patentów wnoszonych przez kontrybutorów oraz ograniczenia eksportowe. Warto je sprawdzić niezależnie od treści licencji.

Czym jest open source i kto o tym decyduje?

Open Source Initiative ocenia licencje według Open Source Definition — zestawu dziesięciu kryteriów. Najważniejsze z nich to: swobodna redystrybucja, dostępność kodu źródłowego, możliwość tworzenia opracowań i modyfikacji, integralność kodu autora oraz brak dyskryminacji osób, grup i dziedzin zastosowania. Licencja, która nie spełnia któregoś z tych kryteriów — choćby zakazywała użycia komercyjnego — nie jest licencją open source w rozumieniu OSI. Licencje spełniające te kryteria OSI oznacza jako „OSI Approved” — jest to organizacyjny i rynkowy standard, a nie akt powszechnie obowiązującego prawa.

Na liście OSI znajdziemy ponad 100 zatwierdzonych licencji. W praktyce ekosystem open source jest jednak znacznie bardziej skoncentrowany: MIT, Apache 2.0 i rodzina GPL należą do najczęściej spotykanych licencji w repozytoriach publicznych. Pozostałe zatwierdzone licencje są zazwyczaj niszowe, nieaktualne lub stworzone na specjalne potrzeby określonych branż lub projektów.

Dwa światy: licencje permisywne i copyleft

Wszystkie licencje open source można podzielić na dwie główne kategorie. To rozróżnienie jest ważniejsze niż znajomość szczegółów konkretnych licencji — i to ono powinno być punktem wyjścia przy każdej decyzji o wyborze lub użyciu komponentu open source.

Licencje permisywne — maksymalna swoboda

Licencje copyleft — otwartość przekazywana dalej

Trzy stopnie copyleft — czym się różnią?

Licencje copyleft nie są jednorodne. Różnią się zasięgiem obowiązku ujawnienia kodu. To praktycznie najważniejsza różnica, o której powinien wiedzieć każdy, kto buduje produkt na komponentach open source.

Silny copyleft (GPL, AGPL)

GPL nakłada obowiązek ujawnienia kodu na dzieła pochodne dystrybuowane publicznie. Połączenie z kodem GPL może — w zależności od sposobu integracji — objąć obowiązkami copyleft całość dystrybuowanego programu, zwłaszcza gdy powstaje jeden utwór lub dzieło pochodne w rozumieniu prawa autorskiego. FSF przyjmuje interpretację rozszerzającą to kryterium zarówno na statyczne, jak i dynamiczne linkowanie, choć kwestia ta pozostaje przedmiotem dyskusji prawnych. Jeśli produkt, który dystrybuujesz, zawiera lub łączy się z kodem GPL — zakres obowiązku copyleft warto skonsultować ze specjalistą.

Słaby copyleft / plikowy (LGPL, MPL)

Obowiązek ujawnienia kodu jest ograniczony do samej biblioteki lub zmodyfikowanych plików. Kod aplikacji, która dynamicznie linkuje bibliotekę LGPL, co do zasady nie musi być ujawniany — ale użytkownik musi mieć możliwość podmiany biblioteki (np. przez dostarczenie plików obiektowych umożliwiających relinkowanie). MPL stosuje analogiczne podejście na poziomie pliku — zmodyfikowane pliki MPL muszą pozostać otwarte, reszta projektu może być zamknięta.

Silny copyleft sieciowy (AGPL v3)

AGPL v3 to osobna kategoria, na którą warto zwrócić szczególną uwagę w kontekście usług cyfrowych. Działa jak GPL v3, ale dodaje odrębny obowiązek wynikający z sekcji 13: operator serwera sieciowego, który udostępnia użytkownikom zdalną interakcję ze zmodyfikowaną wersją programu, musi umożliwić im pobranie odpowiedniego kodu źródłowego. Sama AGPL wprost zaznacza, że zwykła interakcja przez sieć bez transferu kopii oprogramowania nie stanowi „conveying” w rozumieniu licencji — jednak obowiązek z sekcji 13 i tak się aktywuje, jeśli serwer oferuje zmodyfikowaną wersję. Z tego powodu wiele firm technologicznych (m.in. Google) wypracowało wewnętrzne polityki wymagające osobnej decyzji prawnej przed wdrożeniem kodu AGPL.

Najpopularniejsze licencje open source — od najbardziej permisywnej do najbardziej restrykcyjnej

OSI wyróżnia kategorię „Popular / Strong Community” — licencji, które nie tylko są zatwierdzone, ale mają szeroką adopcję i aktywne ekosystemy. Poniżej omówione są te, które mają realne znaczenie praktyczne. MIT, Apache 2.0 i rodzina GPL należą do najczęściej spotykanych licencji w repozytoriach publicznych — ich znajomość jest podstawą świadomej pracy z kodem open source.

MIT License — jedna z najpopularniejszych licencji świata

Permisywna · krótka · maksymalna swoboda · brak ochrony patentowej

MIT pozwala na dosłownie wszystko: używanie, kopiowanie, modyfikowanie, łączenie, publikowanie, sprzedawanie — bez żadnych dodatkowych warunków poza zachowaniem informacji o autorstwie i treści licencji. Nie narzuca copyleft, nie zawiera klauzul patentowych. Jest szczególnie popularna wśród bibliotek JavaScript (Node.js, React, jQuery, Angular), narzędzi deweloperskich i frameworków, które chcą trafić do jak najszerszego grona użytkowników niezależnie od modelu biznesowego.

Co można?

Można używać komercyjnie, modyfikować, dystrybuować, sublicencjonować i sprzedawać kod oraz produkty oparte na tym kodzie. Można włączyć do produktu zamkniętego bez ujawniania kodu źródłowego. Można udostępniać opracowania na dowolnej, samodzielnie wybranej licencji — w tym zastrzeżonej.

Czego nie można?

Nie można usuwać informacji o autorstwie i treści licencji z kopii kodu. Nie można pociągać autora do odpowiedzialności za szkody wynikające z użycia oprogramowania (klauzula „AS IS”). Brak gwarancji — nie można powoływać się na gwarancję autora.

Co wymusza?

Zachowanie kopii oryginalnego tekstu licencji i informacji o prawach autorskich we wszystkich dystrybucjach kodu lub jego istotnych fragmentów.

Apache License 2.0 — permisywna z ochroną patentową

Permisywna · ochrona patentowa · klauzula odwetowa · obowiązek zaznaczania zmian

Apache 2.0 ma podobną filozofię do MIT, ale jest znacznie obszerniejsza i bardziej precyzyjna. Kluczowym dodatkiem jest explicite udzielona licencja patentowa: każdy kontrybutor udziela odbiorcom nieodpłatnej, niewyłącznej licencji na wszelkie objęte przez siebie patenty niezbędne do korzystania z kodu. Dołączona jest klauzula odwetowa — jeśli wszczyna się postępowanie patentowe związane z projektem, traci się licencję patentową. Apache 2.0 jest niekompatybilna z GPL v2, ale kompatybilna z GPL v3. Stosują ją m.in. Android, Kubernetes, TensorFlow i wiele projektów ekosystemu Apache Foundation.

Co można?

Można używać komercyjnie, modyfikować, dystrybuować i sublicencjonować — w tym włączyć do produktu zamkniętego. Można udostępniać opracowania na dowolnej licencji. Obowiązuje wyraźna licencja patentowa ze strony kontrybutorów — to istotna ochrona dla produktów narażonych na spory patentowe.

Czego nie można?

Nie można używać nazw, logo ani znaków towarowych autora do promowania pochodnych produktów bez jego zgody. Nie można usuwać z dystrybucji informacji o prawach autorskich, zastrzeżeń i treści licencji. Nie można wszczynać postępowań patentowych związanych z projektem bez utraty licencji patentowej (klauzula odwetowa).

Co wymusza?

Włączenie kopii licencji Apache 2.0 do dystrybucji kodu lub jego binarnych wersji. Wyraźne oznaczenie wszelkich zmodyfikowanych plików jako zmienione. Zachowanie wszelkich informacji o prawach autorskich, patentach i zastrzeżeniach w dystrybucjach.

BSD 2-Clause — permisywna bliźniaczka MIT

Permisywna · minimalistyczna · brak ochrony patentowej · historyczne korzenie akademickie

BSD 2-Clause (zwana też Simplified BSD lub FreeBSD License) pochodzi z Uniwersytetu Kalifornijskiego w Berkeley i jest praktycznie równoważna licencji MIT — z tą różnicą, że sformułowana jest nieco inaczej. BSD 3-Clause dodaje jedno postanowienie: zakaz używania nazwy organizacji lub autora do promowania produktów pochodnych bez pisemnej zgody. W praktyce dla większości zastosowań MIT i BSD 2-Clause są wzajemnie zastępowalne. BSD jest szeroko stosowana w systemach BSD, FreeBSD, macOS oraz narzędziach sieciowych.

Co można?

Można używać, modyfikować, dystrybuować i sublicencjonować — w tym komercyjnie i w produktach zamkniętych. BSD 3-Clause zakazuje wyłącznie używania nazwy autora do promocji bez zgody.

Czego nie można?

Nie można usuwać informacji o prawach autorskich i treści licencji. BSD 3-Clause dodatkowo zakazuje sugerowania, że autor poleca produkt pochodny, bez jego wyraźnej zgody.

Co wymusza?

Zachowanie informacji o prawach autorskich i treści licencji w dystrybucjach kodu i produktów binarnych.

GNU GPL v2 i v3 — klasyczny silny copyleft

Silny copyleft · otwartość obowiązkowa · kluczowa różnica przy dystrybucji

GPL (General Public License) to najszerzej stosowana rodzina licencji copyleft, stworzona przez Free Software Foundation. GPL v2 jest licencją jądra Linuxa i wielu projektów GNU. GPL v3 wprowadza ważne nowości: ochronę przed tivoizacją, wyraźną licencję patentową oraz klauzulę odwetową. Istotna różnica: GPL v2 i GPL v3 są wzajemnie niekompatybilne — nie można łączyć kodu dostępnego wyłącznie na GPL v2 z kodem wyłącznie na GPL v3. GPL stosuje się m.in. w Linuxie (v2), WordPressie i całym ekosystemie GNU.

Co można?

Można używać, studiować, modyfikować i dystrybuować oprogramowanie — w tym komercyjnie. GPL nie zakazuje sprzedaży ani świadczenia usług na bazie kodu GPL.

Czego nie można?

Połączenie z kodem GPL i dystrybucja powstałego programu może — w zależności od sposobu integracji — objąć obowiązkami copyleft całość kodu. FSF przyjmuje interpretację, że zarówno statyczne, jak i dynamiczne linkowanie może tworzyć dzieło pochodne objęte GPL. Zakres tego obowiązku warto każdorazowo skonsultować ze specjalistą. GPL v3 zakazuje ponadto tivoizacji: nie można uniemożliwiać użytkownikom uruchamiania zmodyfikowanych wersji na urządzeniach.

Co wymusza?

Udostępnienie pełnego kodu źródłowego oprogramowania pochodnego wraz z dystrybucją. Dołączenie treści licencji GPL do dystrybucji. Zachowanie informacji o prawach autorskich i zastrzeżeń. W GPL v3: dostarczenie kluczy instalacyjnych na urządzeniach, jeśli je posiada dystrybutor.

GNU LGPL v2.1 i v3 — copyleft ograniczony do biblioteki

Słaby copyleft · dozwolone linkowanie z kodem zamkniętym · przeznaczony dla bibliotek

LGPL (Lesser General Public License) to zmodyfikowana wersja GPL zaprojektowana dla bibliotek. Aplikacja korzystająca z biblioteki LGPL poprzez dynamiczne linkowanie co do zasady nie musi być otwierana — copyleft obejmuje wyłącznie samą bibliotekę. Kluczowy warunek: użytkownik musi mieć możliwość podmiany biblioteki na zmodyfikowaną wersję, co w praktyce często wymaga dostarczenia plików obiektowych umożliwiających relinkowanie. Przy statycznym linkowaniu nie następuje automatyczne „przejście” całej aplikacji na LGPL, ale konieczność dostarczenia plików do relinkowania nadal obowiązuje. LGPL jest popularnym wyborem dla bibliotek systemowych i zestawów narzędziowych GUI (Qt w trybie LGPL).

Co można?

Można linkować aplikację z biblioteką LGPL bez konieczności ujawniania kodu samej aplikacji. Można używać komercyjnie. Można dystrybuować aplikacje binarne korzystające z biblioteki LGPL, nie ujawniając kodu aplikacji.

Czego nie można?

Nie można zamknąć kodu samej biblioteki LGPL ani jej zmodyfikowanych wersji. Zarówno przy linkowania dynamicznym, jak i statycznym należy umożliwić użytkownikowi podmianę biblioteki — np. przez dostarczenie plików obiektowych.

Co wymusza?

Udostępnienie kodu źródłowego samej biblioteki (lub jej zmodyfikowanej wersji) na warunkach LGPL. Umożliwienie użytkownikowi relinkowania z podmienioną wersją biblioteki. Zachowanie informacji o prawach autorskich i treści licencji LGPL.

Mozilla Public License 2.0 — copyleft plikowy

Słaby copyleft · plikowy · kompatybilna z GPL · dla projektów mieszanych

MPL 2.0 stosuje copyleft na poziomie pojedynczego pliku, a nie całego projektu lub programu. Zmodyfikowane pliki objęte MPL muszą pozostać otwarte na MPL, ale nowe pliki stworzone przez użytkownika i umieszczone w tym samym projekcie mogą być zamknięte. MPL 2.0 jest kompatybilna z GPL v2 i v3 oraz LGPL. Stosuje ją m.in. przeglądarka Firefox, Thunderbird i projekty Mozilla.

Co można?

Można łączyć kod MPL z kodem na innych licencjach w tym samym projekcie. Można tworzyć zamknięte rozszerzenia i komponenty obok kodu MPL. Można używać komercyjnie.

Czego nie można?

Nie można zamykać zmodyfikowanych plików MPL — muszą pozostać dostępne na MPL. Nie można usuwać informacji o prawach autorskich z plików MPL.

Co wymusza?

Udostępnienie kodu źródłowego zmodyfikowanych plików MPL na warunkach MPL 2.0. Zachowanie informacji o prawach autorskich i treści licencji w plikach MPL.

Eclipse Public License 2.0 — copyleft korporacyjny

Słaby copyleft · możliwość kompatybilności z GPL przez Secondary License · ochrona patentowa

EPL 2.0 (Eclipse Public License) to licencja stworzona przez Eclipse Foundation, stosowana w ekosystemie Eclipse IDE i projektach Java. Działa podobnie do MPL: copyleft na poziomie modułu lub projektu Eclipse, z możliwością łączenia z kodem zamkniętym. Kluczowym elementem jest rozbudowany system ochrony patentowej i wzajemnych zobowiązań kontrybutorów (patent retaliation clause). EPL 2.0 przewiduje mechanizm Secondary License, który w określonych warunkach — gdy dystrybutor doda odpowiedni notice — może umożliwić kompatybilność z GPL v2 lub późniejszą. Nie jest to jednak automatyczna i bezwarunkowa kompatybilność ze wszystkimi wariantami GPL.

Co można?

Można łączyć kod EPL z kodem na innych licencjach, w tym zamkniętymi. Można używać komercyjnie. W określonych konfiguracjach z użyciem mechanizmu Secondary License możliwa jest kompatybilność z GPL.

Czego nie można?

Nie można zamykać zmodyfikowanego kodu EPL dystrybuowanego w ramach projektu EPL bez towarzyszącego kodu źródłowego.

Co wymusza?

Udostępnienie kodu źródłowego wraz z dystrybucją. Dołączenie treści licencji EPL do dystrybuowanego oprogramowania. Przy użyciu Secondary License — dodanie wymaganego notice.

GNU AGPL v3 — copyleft sieciowy

Silny copyleft · obowiązek sieciowy z sekcji 13 · szczególne znaczenie dla usług internetowych

AGPL v3 (Affero General Public License) to wariant GPL v3 z dodatkowym obowiązkiem wynikającym z sekcji 13: operator serwera sieciowego, który pozwala użytkownikom na zdalną interakcję ze zmodyfikowaną wersją programu, musi umożliwić im pobranie odpowiedniego kodu źródłowego. AGPL nie redefiniuje pojęcia dystrybucji — sama licencja zaznacza, że zwykła interakcja sieciowa bez transferu kopii nie stanowi „conveying”. Obowiązek z sekcji 13 jest jednak odrębnym mechanizmem, który aktywuje się niezależnie od pytania o dystrybucję. Projekty dostępne aktualnie na AGPL v3 to m.in. Nextcloud i Mastodon. Historia licencjonowania niektórych projektów (m.in. MongoDB Community Server, Grafana, Elasticsearch) jest złożona — ich warunki zmieniały się na przestrzeni lat, co warto sprawdzić w dokumentacji konkretnej wersji.

Co można?

Można modyfikować, dystrybuować i używać kodu AGPL — w tym komercyjnie, o ile spełnione są warunki licencji.

Czego nie można?

Prowadzenie usługi SaaS lub API opartej na zmodyfikowanej wersji kodu AGPL jest możliwe, ale wymaga udostępnienia użytkownikom odpowiedniego kodu źródłowego zgodnie z sekcją 13. Pominięcie tego obowiązku stanowi naruszenie licencji.

Co wymusza?

Udostępnienie odpowiedniego kodu źródłowego użytkownikom wchodzącym w interakcję ze zmodyfikowaną wersją programu przez sieć — nawet bez fizycznej dystrybucji oprogramowania. Dołączenie informacji o licencji i prawach autorskich.

Kompatybilność licencji — dlaczego to ważne

Budując projekt z wielu komponentów open source o różnych licencjach, trzeba sprawdzić, czy te licencje są ze sobą kompatybilne. Niekompatybilność oznacza, że nie można legalnie połączyć tych dwóch fragmentów kodu w jeden dystrybuowany program.

O czym powinien pamiętać przedsiębiorca?

Z perspektywy biznesu kluczowe są cztery obszary.

Audyt zależności przed wdrożeniem produktu. Każda biblioteka, framework i narzędzie wbudowane w produkt niosą ze sobą warunki licencji. W projekcie z setkami zależności konieczne jest narzędzie do audytu licencji — np. FOSSA, WhiteSource (Mend), Black Duck lub wbudowane funkcje popularnych repozytoriów. Brak audytu to realne ryzyko prawne.

Copyleft i dystrybucja produktu. Copyleft w licencjach GPL jest aktywowany przez „dystrybucję” — przekazanie produktu użytkownikowi końcowemu, sprzedaż urządzeń, publikację aplikacji mobilnej. Usługa SaaS tradycyjnie nie była uważana za dystrybucję w rozumieniu GPL. AGPL nakłada jednak odrębny obowiązek wobec użytkowników korzystających z usługi przez sieć. Jeśli budujesz aplikację mobilną, firmware urządzenia lub dystrybucję systemu operacyjnego zawierającą kod GPL lub AGPL — zakres obowiązków warto omówić ze specjalistą.

Znaki towarowe to osobna kwestia. Licencja open source reguluje prawa do kodu — nie do nazwy projektu, logo ani marki. Apache 2.0 i wiele innych licencji wprost zakazuje używania nazw i znaków towarowych twórcy do promowania produktów pochodnych. Projekty takie jak React (licencja MIT), Node.js czy PostgreSQL mają oddzielne zasady dotyczące znaków towarowych, których licencja nie reguluje.

CLA i własność kodu. Wiele większych projektów open source wymaga od kontrybutorów podpisania Contributor License Agreement (CLA), który przenosi lub licencjonuje prawa autorskie do wnoszonych zmian na właściciela projektu. Jeśli Twoi pracownicy lub podwykonawcy kontrybuują do zewnętrznych projektów open source — warto wiedzieć, co podpisują i czy nie przenoszą na zewnątrz praw do kodu stworzonego w ramach Twojej firmy.

Podsumowanie

Licencje open source to narzędzia o bardzo różnym zasięgu — od MIT, które mówi po prostu „rób co chcesz, tylko nie skreślaj mojego imienia”, po AGPL, która nakłada obowiązki nawet wobec użytkowników korzystających z Twojej usługi online bez pobierania kodu. Kluczowy podział przebiega między permisywnymi (MIT, Apache 2.0, BSD) a copyleft (GPL, AGPL, LGPL, MPL, EPL). Dla firm budujących produkty komercyjne ten wybór ma fundamentalne znaczenie — i powinien być podjęty świadomie, a nie przez przypadek.

Warto pamiętać o trzech uproszczeniach, które prowadzą do błędów: po pierwsze, open source nie oznacza braku praw autorskich ani swobody użycia bez warunków. Po drugie, copyleft nie zakazuje komercyjnego użycia — warunkuje ujawnienie kodu pochodnego, ale zasięg tego obowiązku zależy od konkretnej licencji i sposobu integracji. Po trzecie, sama licencja komponentu nie przesądza o licencji całego produktu — decyduje sposób integracji, charakter dystrybucji i wzajemna kompatybilność licencji wszystkich elementów.