Licencja open source w 2026: kompletny przewodnik prawny

Licencja open source to umowa, na mocy której twórca oprogramowania udostępnia kod źródłowy do używania, modyfikowania i redystrybuowania - pod określonymi warunkami. To nie jest "darmowe oprogramowanie bez praw autorskich". Prawa autorskie pozostają przy twórcy, a licencja tylko określa, co możesz robić.

3 rodzaje licencji, które musisz znać:

Permisywne - minimalne wymogi: zachowaj informację o autorstwie. Możesz włączyć do oprogramowania komercyjnego bez ujawniania własnego kodu.
Słaby copyleft - modyfikacje samej biblioteki musisz udostępnić, ale nie całość Twojego oprogramowania.
Silny copyleft - "wirusowe". Jeśli włączysz taki kod do swojego oprogramowania, Twoje oprogramowanie również musi być wydane na tej samej licencji. Tu giną biznesy.

Wielu founderów dowiaduje się o tym dopiero podczas due diligence przed rundą inwestycyjną.

Masz wątpliwości albo chcesz przeprowadzić audyt licencji / umów w swojej organizacji?

Wyceń bezpłatnie w ciągu godziny i zabezpiecz się →

Czym jest oprogramowanie open source

Open source to model dystrybucji oprogramowania, w którym kod źródłowy jest publicznie dostępny i można go używać, badać, modyfikować i redystrybuować - zgodnie z warunkami konkretnej licencji.

Co to nie jest:

Nie jest synonimem "darmowe" (free software = wolne, nie bezpłatne)
Nie jest "public domain" (kod public domain nie ma żadnej licencji — open source ma)
Nie jest "no rights reserved" (prawa autorskie pozostają przy twórcy)
Nie jest "robisz co chcesz" (każda licencja nakłada obowiązki)

Oficjalna definicja open source pochodzi od Open Source Initiative (OSI) i wymaga spełnienia 10 kryteriów, w tym: dostępność kodu źródłowego, możliwość redystrybucji, brak dyskryminacji konkretnych grup użytkowników lub dziedzin zastosowań.

W Polsce open source funkcjonuje w ramach prawa autorskiego - ustawa o prawie autorskim i prawach pokrewnych (art. 74 i nast.) traktuje program komputerowy jak utwór literacki. Open source nie jest "wyjątkiem od prawa autorskiego"; jest konkretnym sposobem korzystania z praw autorskich przez ich właściciela.

Trzy rodzaje licencji open source

Na rynku istnieje ponad 200 licencji open source. Z perspektywy praktycznej wszystkie dzielą się na trzy kategorie według tego, co musisz zrobić ze swoim własnym kodem, jeśli włączysz do niego kod open source.

A. Licencje permisywne (permissive)

Najmniej restrykcyjne. Pozwalają używać kodu w komercyjnym, zamkniętym oprogramowaniu pod warunkiem zachowania informacji o autorstwie i licencji.

Twoje obowiązki przy permisywnej licencji:

Zachowaj copyright notice w kodzie i dokumentacji
Zachowaj tekst licencji (np. plik LICENSE w repo)
Wskaż znaczące modyfikacje

Twoje prawa: możesz włączyć kod do oprogramowania komercyjnego, możesz nie udostępniać własnego kodu, możesz sprzedawać produkt zawierający taki kod.

B. Licencje słaby copyleft (weak copyleft / LGPL-style)

Wymagają, abyś udostępniał modyfikacje samej biblioteki open source, ale nie całego Twojego oprogramowania, które tej biblioteki używa.

Twoje obowiązki przy weak copyleft:

Jeśli zmodyfikujesz kod biblioteki - udostępnij modyfikacje na tej samej licencji
Pozwól użytkownikowi końcowemu wymienić bibliotekę na inną wersję
Wskaż użycie biblioteki w dokumentacji

Twoje prawa: twój własny kod aplikacji może pozostać zamknięty, jeśli używa biblioteki LGPL/MPL jako odrębnego komponentu.

C. Licencje silny copyleft (strong copyleft) - "wirusowe"

Najbardziej restrykcyjne. Jeśli włączysz kod silnego copyleft do swojego oprogramowania, całe Twoje oprogramowanie musi być wydane na tej samej licencji, z udostępnieniem pełnego kodu źródłowego.

Twoje obowiązki przy strong copyleft:

Cały kod produktu zawierającego komponent GPL/AGPL musi być wydany na GPL/AGPL
Udostępnij pełny kod źródłowy - łącznie z Twoimi modyfikacjami
Obowiązek obejmuje również udostępnienie kodu przez sieć (SaaS, API)
Nie możesz wprowadzić dodatkowych ograniczeń licencyjnych

Konsekwencja praktyczna: jeśli zbudujesz SaaS używający komponentu AGPL i nie udostępnisz kodu - naruszasz licencję. W praktyce oznacza to ryzyko utraty praw autorskich do własnego oprogramowania i pozew o naruszenie.

Co tak naprawdę robi licencja "wirusowa"

Termin "wirusowy" funkcjonuje w branży, ale prawnie mylący. Licencje copyleft nie "infekują" Twojego kodu w sensie technicznym. Mechanizm jest umowny.

Krok 1: Łączysz swój kod z kodem GPL/AGPL. W momencie, gdy budujesz swoje oprogramowanie w taki sposób, że stanowi ono "dzieło pochodne" (derivative work) lub "dzieło połączone" (combined work) z kodem GPL - uruchamiają się warunki licencji.

Krok 2: Decydujesz się dystrybuować swoje oprogramowanie (lub udostępnić przez sieć, w przypadku AGPL). Sama wewnętrzna modyfikacja kodu open source na własne potrzeby zazwyczaj nie uruchamia obowiązków licencyjnych. Obowiązki aktywują się przy dystrybucji.

Krok 3: Licencja stawia warunki dystrybucji. GPL mówi: "możesz dystrybuować, ale tylko jeśli udostępnisz pełny kod źródłowy całego oprogramowania na tej samej licencji". AGPL dodaje: "to samo dotyczy udostępniania przez sieć".

Krok 4: Naruszenie licencji = naruszenie praw autorskich. Jeśli dystrybuujesz oprogramowanie zawierające kod GPL bez spełnienia warunków to twoja licencja na ten kod automatycznie wygasa. Z prawnego punktu widzenia korzystasz z cudzego kodu bez podstawy prawnej. Twórca może wnieść pozew o naruszenie praw autorskich.

Krok 5: W skrajnym przypadku - straty finansowe i wizerunkowe. Słynne sprawy: Cisco vs FSF (2008), VMware vs Hellwig (2016), McHardy vs różne firmy linuksowe (seria spraw 2010–2020). Każda kończyła się ugodą lub wyrokiem nakazującym udostępnienie kodu lub zapłatę odszkodowania.

Czy "wirusowa" licencja oznacza, że tracisz prawa autorskie? Często powtarzany mit. Prawdę jest taka: nie tracisz praw autorskich, ale tracisz prawo do dystrybucji swojego oprogramowania w sposób inny niż na tej licencji, dopóki używasz w nim kodu copyleft. Jeśli wymienisz kod copyleft na własny to odzyskujesz pełną kontrolę nad swoją licencją.

Open source w SaaS

Do około 2007 roku open source miał istotną lukę: GPL nie obejmowała przypadku, gdy oprogramowanie nie jest dystrybuowane, lecz tylko udostępniane jako usługa.

Jeśli zbudowałeś SaaS używający kodu GPL, mogłeś go modyfikować bez udostępniania zmian, bo nigdy nie dystrybuowałeś binariów. Twoi użytkownicy korzystali z aplikacji przez przeglądarkę, nigdy nie dostając kopii oprogramowania.

To zostało nazwane "ASP loophole" (luka ASP). AGPL powstała w 2007, żeby ją zamknąć.

Co AGPL zmienia dla SaaS:

Jeśli modyfikujesz program licencjonowany na AGPL i udostępniasz go użytkownikom przez sieć (HTTP, API, SaaS) - masz obowiązek udostępnić im pełny kod źródłowy zmodyfikowanej wersji.

Wniosek dla CTO/foundera SaaS:

Jeśli budujesz SaaS i widzisz w stacku zależność na AGPL to zatrzymaj się i skonsultuj.
Jeśli widzisz zależność na SSPL/BSL to nie jest open source w klasycznym rozumieniu, mogą obowiązywać dodatkowe restrykcje komercyjne.
Audyt zależności open source powinien być częścią Twojego procesu CI/CD, nie jednorazową akcją.

Najczęstsze błędy prawne w software house

Błąd #1: "Programista wstawił kod GPL do projektu klienta i nikt nie sprawdził"

Klasyczna sytuacja: programista B2B kopiuje fragment z Stack Overflow lub repo GitHub, integruje w produkcji, nikt nie sprawdza pochodzenia kodu. Pół roku później klient idzie na due diligence przed rundą A. DD wykrywa kod GPL w jego SaaS. Konsekwencje: opóźnienie rundy, renegocjacja waluacji, czasem wycofanie inwestora.

Zabezpieczenie: klauzula w umowie B2B z programistą zobowiązująca do nieużywania kodu na licencjach copyleft bez pisemnej zgody zlecającego.

Błąd #2: "Mamy oświadczenie programisty, że to jego oryginalny kod"

Standardowe oświadczenie w umowie B2B brzmi: "Wykonawca oświadcza, że jest wyłącznym twórcą Utworu i przysługują mu pełne autorskie prawa majątkowe do Utworu."

To oświadczenie staje się nieprawdziwe w momencie, gdy programista wkleił linię kodu z biblioteki open source. Skutek prawny: programista odpowiada za niezgodność, ale to słabe zabezpieczenie biznesowe - nie pomoże, gdy klient kończy due diligence.

Lepsza klauzula: wyraźnie wymień jakie licencje open source są dopuszczalne (np. MIT, Apache 2.0, BSD), z obowiązkiem zgłoszenia każdej takiej zależności i prowadzenia rejestru SBOM (Software Bill of Materials).

Błąd #3: "Klient kupił od nas software z prawami autorskimi, ale w środku jest LGPL"

Sprzedajesz klientowi software z pełnym przeniesieniem autorskich praw majątkowych. Klient zakłada, że ma "wszystko". Po roku okazuje się, że w środku jest biblioteka LGPL. Klient nie może wymienić tej biblioteki, bo nie ma do niej pełnych praw. Ma tylko licencję wynikającą z LGPL.

Skutek: klient nie może zamknąć całego stacka swojego produktu. Nie może go też freely sublicensować dalej w nieoczywistych warunkach.

Rozwiązanie: w umowie deweloperskiej rozgranicz: (a) komponenty objęte pełnym przeniesieniem praw autorskich, (b) komponenty open source - z osobną listą i ich licencjami.

Błąd #4: "Mamy w produkcji bibliotekę z licencją 'do non-commercial use only'"

To nie jest open source. To source-available lub proprietary. Licencje typu Creative Commons NC, JSON License ("the Software shall be used for Good, not Evil") czy własne customowe licencje deweloperów to nie są open source w rozumieniu OSI.

Konsekwencja: używasz cudzego oprogramowania bez podstawy prawnej, jeśli prowadzisz działalność komercyjną. Klasyczny błąd: junior wpisuje "open source" w wyszukiwarkę, znajduje bibliotekę z napisem "free for personal use" i wstawia ją do produkcji.

Open source a umowy B2B z programistami

Dla CEO software house'u temat open source ma dwie warstwy: (a) co programista robi z cudzym kodem, (b) co Ty robisz z kodem programisty.

Klauzula open source w umowie B2B

W każdej umowie B2B z programistą rekomendujemy klauzulę pokrywającą:

Obowiązek deklaracji
Lista dopuszczalnych licencji
Zakaz wirusowych licencji w kodzie klienta
Obowiązek prowadzenia SBOM
Oświadczenie i indemnifikacja

Klauzula open source w umowie z klientem software house'u

Z drugiej strony, w umowach Software House → Klient warto transparentnie opisać:

Co jest oryginalnym kodem software house'u
Co jest open source
Co jest proprietary third-party

Brak takiej transparencji jest powszechną przyczyną sporów post-delivery, gdy klient odkrywa zależności open source w momencie najmniej dla niego korzystnym (np. próba sprzedaży produktu kolejnemu inwestorowi).

Open source a inwestycja VC - co weryfikuje due diligence

Każda profesjonalna runda inwestycyjna zawiera technical due diligence lub osobny IP due diligence. Open source jest jednym z głównych obszarów weryfikacji.

Typowe pytania w DD:

Czy spółka prowadzi SBOM swoich produktów?
Jakie licencje open source są w stacku produktów komercyjnych?
Czy są zależności na licencjach copyleft (GPL/AGPL) w core produktach?
Czy obowiązki wynikające z licencji są spełnione (notices, source availability, etc.)?
Czy umowy z deweloperami zawierają klauzule otwierające na audyt i zabezpieczenie?
Czy są jakiekolwiek otwarte spory lub roszczenia związane z naruszeniem licencji open source?

Czerwone flagi, które obniżają wycenę lub przerywają deal:

AGPL w core produkcie SaaS bez planu mitygacji
Nieudokumentowane zależności open source w głównym produkcie
Wykorzystanie kodu z "non-commercial" licencji w działalności komercyjnej
Brak polityki open source w organizacji deweloperskiej
Brak SBOM lub niemożność jego szybkiej rekonstrukcji

Zielone flagi, które przyspieszają DD:

Pełen SBOM dostępny w 24 godziny
Lista licencji z mapowaniem na obowiązki
Polityka wewnętrzna open source udokumentowana
Klauzule open source w umowach z deweloperami
Tooling w CI/CD (skanery, alerty)

FAQ - pytania, które dostaję najczęściej

Czy mogę używać kodu open source w komercyjnym produkcie?

Tak - większość licencji open source (MIT, Apache 2.0, BSD, MPL, LGPL) pozwala na użycie komercyjne. Ograniczenia dotyczą głównie tego, jak używasz (np. czy musisz ujawnić własny kod, czy musisz zachować informacje o autorstwie). Wyjątek to silne copyleft (GPL, AGPL) - pozwalają na komercyjne użycie, ale wymuszają wydanie własnego oprogramowania na tej samej licencji.

Czy licencja MIT jest "lepsza" niż GPL?

To nie jest pytanie "lepsza/gorsza", tylko "do czego". MIT jest lepsza dla maksymalnej adopcji (programiści chętniej używają, łatwiej zintegrować z komercyjnym produktem). GPL jest lepsza dla ochrony ekosystemu open source. Wybór zależy od strategii dystrybucji.

Czy mogę zmienić licencję mojego projektu open source?

Możesz - ale tylko jeśli jesteś wyłącznym właścicielem praw autorskich do całego kodu. Jeśli akceptowałeś contributions od innych deweloperów bez CLA (Contributor License Agreement), każdy z nich zachowuje prawa do swojego wkładu i nie możesz zmienić licencji bez ich zgody. To dlatego duże projekty wymagają CLA - żeby maintainer mógł w przyszłości dostosowywać licencję.

Jakie licencje są bezpieczne dla SaaS?

Bezpieczne (możesz używać bez ujawnienia własnego kodu): MIT, Apache 2.0, BSD, MPL 2.0, LGPL (przy dynamic linking).

Ryzykowne dla SaaS: GPL (przy dystrybucji binariów), AGPL (zawsze, nawet w SaaS).

Niezalecane jako "open source": SSPL, BSL, Elastic License — mają restrykcje komercyjne, traktuj je jak proprietary.

Co to jest "dual licensing"?

Model, w którym jeden projekt jest dostępny pod dwiema różnymi licencjami do wyboru przez użytkownika. Typowy układ: GPL/AGPL dla społeczności + komercyjna licencja dla firm, które nie chcą ujawniać kodu. Pozwala maintainerowi monetyzować projekt komercyjnie, jednocześnie utrzymując ścieżkę open source dla społeczności.

Co jeśli nie wiem, jaka jest licencja kodu, który mam w produkcji?

Czerwona flaga. Skontaktuj się z autorem kodu lub usuń ten kod z produkcji. Brak licencji = brak prawa do użycia.

Co dalej

Open source to fundament współczesnego software development. Nie da się go uniknąć, ale można go używać świadomie. Trzy konkretne kroki na ten tydzień, jeśli prowadzisz software house lub SaaS:

Sprawdź SBOM swojego głównego produktu. Jeśli go nie masz - to pierwszy problem do rozwiązania
Zweryfikuj, czy nie ma w stacku zależności GPL/AGPL w SaaS - jeśli są, zaplanuj mitygację
Sprawdź umowy B2B ze swoimi programistami - czy zawierają klauzule open source z listą dopuszczalnych licencji