Open Source · Prawo autorskie · IP · Zgodność licencji

Która licencja
open source pozwala Ci
na to, co planujesz?

Znalazłeś bibliotekę, framework lub narzędzie open source i chcesz wiedzieć, czy możesz je wykorzystać zgodnie z planem? Odpowiedz na kilka pytań i sprawdź, które licencje to dopuszczają — wraz z analizą kompatybilności przy łączeniu z innymi licencjami.

Wynik wskaże kompatybilne licencje, niekompatybilne z powodem i macierz zgodności — co się stanie, gdy połączysz dwie licencje.

Trzy grupy licencji open source

Permisywne, słaby copyleft, silny copyleft

Wszystkie licencje zatwierdzone przez OSI pozwalają na użycie komercyjne — to wymóg Open Source Definition. Kluczowe różnice dotyczą tego, co musisz zrobić z kodem pochodnym i czy możesz go zachować zamkniętym.

MIT
BSD

Permisywne — pełna swoboda

MIT, Apache 2.0, BSD, ISC. Możesz włączyć kod do zamkniętego produktu, nie ujawniać źródeł ani nie stosować tej samej licencji. Jedynym wymogiem jest zazwyczaj zachowanie informacji o autorstwie.

LGPL
MPL

Słaby copyleft — copyleft plikowy

LGPL, MPL 2.0, EPL 2.0. Copyleft obejmuje tylko bibliotekę lub zmodyfikowane pliki. Twój kod aplikacji może pozostać zamknięty, ale musisz umożliwić relinkowanie z podmienioną wersją biblioteki.

GPL
v2/v3

Silny copyleft — copyleft programowy

GPL v2, GPL v3. Połączenie z kodem GPL może objąć obowiązkami copyleft cały dystrybuowany program. Konieczne jest udostępnienie kodu na GPL. GPL nie zakazuje użycia komercyjnego — warunki dotyczą dystrybucji.

AGPL
v3

Copyleft sieciowy — zasięg SaaS

AGPL v3. Jak GPL, ale z dodatkowym obowiązkiem z sekcji 13: udostępnienie kodu użytkownikom korzystającym z usługi przez sieć — nawet bez dystrybucji oprogramowania.

Narzędzie

Kreator doboru licencji open source

Odpowiedz na pytania dotyczące planowanego użycia. Wynik pokaże kompatybilne i niekompatybilne licencje oraz macierz zgodności przy łączeniu z innymi popularnymi licencjami.

Pytanie 1 z 6
Czy kod Twojego produktu lub aplikacji musi pozostać zamknięty (kod źródłowy niedostępny publicznie)?

To najważniejsze pytanie dla decyzji o copyleft. Licencje z silnym copyleft (GPL, AGPL) mogą wymagać udostępnienia kodu Twojego produktu, jeśli go dystrybuujesz. Licencje permisywne i słaby copyleft pozwalają na zachowanie kodu zamkniętego.

💡 Wszystkie licencje OSI pozwalają na komercyjne użycie — to wymóg Open Source Definition. Pytanie dotyczy wyłącznie tego, czy kod źródłowy Twojego produktu musi być zastrzeżony.
Czy będziesz modyfikować pobrany kod open source?

Modyfikacja to każda zmiana w kodzie: naprawa błędów, dodanie funkcji, refaktoryzacja, adaptacja do własnych potrzeb. Nie chodzi o pisanie kodu „obok" biblioteki, ale o zmiany w jej plikach.

💡 Samo używanie biblioteki bez modyfikacji — czyli importowanie jej API z własnego kodu — nie jest modyfikacją w rozumieniu licencji. Copyleft aktywuje się dopiero przy modyfikacji i/lub dystrybucji.
Czy dystrybuujesz lub udostępniasz publicznie oprogramowanie zawierające ten kod?

Dystrybucja to: sprzedaż lub bezpłatne przekazanie oprogramowania innym osobom, publikacja aplikacji mobilnej, sprzedaż urządzenia z wbudowanym oprogramowaniem, udostępnienie kodu w repozytorium. Copyleft aktywuje się przy dystrybucji — nie przy wewnętrznym użytku.

💡 Jeśli modyfikujesz kod wyłącznie na wewnętrzny użytek firmy i nigdy go nie dystrybuujesz — copyleft GPL/AGPL co do zasady nie jest aktywowany (z wyjątkiem AGPL przy usługach sieciowych).
Na jakiej licencji chcesz wydać swoje opracowanie lub produkt zawierający ten kod?

Licencje copyleft wymagają, żeby opracowanie było udostępnione na tej samej lub kompatybilnej licencji. Nie możesz wtedy wybrać licencji zastrzeżonej (©) ani zupełnie innej otwartej licencji niezgodnej z oryginałem.

💡 MIT, Apache 2.0 i BSD nie mają warunku copyleft — możesz wydać opracowanie na dowolnej licencji. GPL, AGPL mają silny copyleft — opracowanie musi być na GPL/AGPL. LGPL i MPL mają copyleft ograniczony odpowiednio do biblioteki i pliku.
Czy oprogramowanie będzie dostępne jako publicznie dostępna usługa sieciowa, SaaS lub API?

Usługa sieciowa to aplikacja webowa, API, mikroserwis lub platforma SaaS, z której inni korzystają przez przeglądarkę lub HTTP — bez pobierania oprogramowania. To kluczowe pytanie dla AGPL v3.

💡 AGPL v3 dodaje obowiązek z sekcji 13: jeśli udostępniasz użytkownikom zdalną interakcję ze zmodyfikowaną wersją kodu AGPL przez sieć, musisz umożliwić im pobranie kodu źródłowego. Dotyczy to nawet sytuacji bez dystrybucji oprogramowania. Samo użycie niezmienionego kodu AGPL jako usługi nie aktywuje sekcji 13.
Czy potrzebujesz warunków licencji, których standardowe licencje open source nie oferują?

Licencje OSI-approved są globalne, nieograniczone czasowo i podmiotowo. Nie oferują: ograniczeń terytorialnych (np. tylko Polska), ograniczeń czasowych (np. na 3 lata), ograniczeń dla wybranych podmiotów (np. tylko dla uczelni), ograniczeń do określonych platform ani innych niestandardowych klauzul.

💡 Jeśli potrzebujesz któregokolwiek z powyższych — żadna licencja OSI-approved tego nie zapewni. Konieczna będzie indywidualna umowa licencyjna. Kancelaria może ją przygotować na potrzeby projektu.
Najczęstsze pytania

FAQ — licencje open source

Nie — open source to nie to samo co darmowe. Wszystkie licencje zatwierdzone przez OSI (Open Source Initiative) pozwalają na użycie komercyjne — to jest wymóg Open Source Definition. Oprogramowanie open source może być sprzedawane. Kluczowe pytanie nie brzmi „czy mogę zarabiać", ale „co muszę zrobić z kodem pochodnym, jeśli dystrybuuję produkt".
Copyleft GPL aktywuje się przy dystrybucji — przekazaniu oprogramowania innym osobom (sprzedaż, bezpłatne udostępnienie, publikacja aplikacji mobilnej, wbudowanie w urządzenie). Wewnętrzne używanie kodu GPL — nawet zmodyfikowanego — w ramach jednej firmy co do zasady nie aktywuje obowiązku copyleft. Usługa SaaS tradycyjnie nie jest uważana za dystrybucję w rozumieniu GPL (ale jest w rozumieniu AGPL).
Apache 2.0 zawiera warunki dotyczące licencji patentowych i klauzulę odwetową, które nie są obecne w GPL v2. GPL v2 wymaga, żeby dystrybuowany kod był objęty wyłącznie jej warunkami — a dodatkowe warunki z Apache 2.0 to uniemożliwiają. GPL v3 rozwiązuje ten problem, zawierając specjalny wyjątek kompatybilności dla Apache 2.0. Dlatego Apache 2.0 + GPL v2 = niekompatybilne, ale Apache 2.0 + GPL v3 = kompatybilne.
GPL ma silny copyleft obejmujący cały program. LGPL ma słabszy copyleft ograniczony do samej biblioteki. Aplikacja korzystająca z biblioteki LGPL poprzez dynamiczne linkowanie może zachować zamknięty kod — pod warunkiem że użytkownik może podmienić bibliotekę. Przy statycznym linkowaniu trzeba dostarczyć pliki obiektowe umożliwiające relinkowanie. LGPL jest popularnym wyborem dla bibliotek, które chcą być szeroko stosowane, ale nie wymuszają otwartości całego produktu.
AGPL v3 dodaje do GPL v3 dodatkowy obowiązek z sekcji 13: jeśli udostępniasz użytkownikom zdalną interakcję ze zmodyfikowaną wersją kodu AGPL przez sieć, musisz umożliwić im pobranie kodu źródłowego — nawet bez dystrybucji oprogramowania. To domknięcie „luki SaaS" w GPL. AGPL sama zaznacza, że zwykła interakcja sieciowa nie jest „conveying", ale obowiązek z sekcji 13 aktywuje się niezależnie. Wiele firm ma politykę wymagającą osobnej decyzji prawnej przed użyciem kodu AGPL.
Tak — licencje open source to pełnoprawne umowy licencyjne oparte na prawie autorskim. Naruszenie warunków licencji oznacza bezprawne korzystanie z cudzego kodu chronionego prawem autorskim. Możliwe konsekwencje to: roszczenia odszkodowawcze, żądanie wycofania produktu z obrotu, obowiązek ujawnienia kodu źródłowego wyrokiem sądu. Organizacja Software Freedom Conservancy i inne podmioty aktywnie dochodzą przestrzegania licencji GPL.
Kompatybilność licencji oznacza, że można legalnie połączyć kod z dwóch różnych licencji w jednym programie. Niekompatybilność (np. Apache 2.0 + GPL v2) oznacza, że połączenie jest niemożliwe prawnie — obowiązki z obu licencji są ze sobą sprzeczne. W praktyce błędy kompatybilności są jedną z najczęstszych przyczyn problemów prawnych przy zarządzaniu zależnościami open source. Warto prowadzić audyt licencji wszystkich zależności przed wdrożeniem produktu.