Umowa licencji otwartej (Open Source / CC)

Umowa licencji otwartej w Polsce to nieodpłatna, powszechna licencja niewyłączna udzielana przez właściciela autorskich praw majątkowych do oprogramowania, treści lub innego utworu każdemu użytkownikowi, który akceptuje jej warunki. Podstawą prawną jest art. 67 ustawy z dnia 4 lutego 1994 r. o prawie autorskim i prawach pokrewnych (Dz.U. 1994 nr 24 poz. 83 ze zm., dalej pr. aut.), który stanowi, że twórca może udzielić upoważnienia do korzystania z utworu na zasadach licencji. Licencje otwarte opierają się na zasadzie, że uprawnienia z art. 17 pr. aut. — wyłączne prawo do korzystania i rozporządzania — są przez twórcę z góry udzielane każdemu, kto spełni warunki licencji.

Najpopularniejsze modele licencji otwartych funkcjonujące na rynku polskim to: licencja MIT (Massachusetts Institute of Technology) — permisywna, zezwalająca na dowolne użycie, modyfikację i dystrybucję, w tym komercyjną, pod warunkiem zachowania informacji o autorze; licencja Apache 2.0 — permisywna z klauzulą patentową chroniącą użytkowników przed roszczeniami z tytułu patentów; licencje GNU (GPL v3, LGPL v3, AGPL v3) — copyleftowe, wymagające udostępniania modyfikacji na tożsamej licencji; rodzina licencji Creative Commons (CC BY, CC BY-SA, CC BY-NC, CC0) — stosowane głównie do treści, grafiki i zbiorów danych, nie do kodu.

W polskim systemie prawnym licencje otwarte są prawnie skuteczne, ponieważ art. 67 pr. aut. dopuszcza udzielanie licencji niewyłącznych w dowolnej formie — nawet dorozumianej lub przez opublikowanie dzieła z tekstem licencji. Sąd Okręgowy w Warszawie w kilku orzeczeniach potwierdził skuteczność licencji GPL i MIT jako umów licencyjnych w rozumieniu prawa polskiego, w tym możliwość dochodzenia roszczeń za naruszenie warunków licencji otwartej na zasadach ogólnych KC.

Rynek oprogramowania open source w Polsce dynamicznie rośnie. Według danych Głównego Urzędu Statystycznego (GUS) sektor IT stanowi jeden z najszybciej rozwijających się segmentów polskiej gospodarki. Polskie spółki z o.o. i startupy coraz częściej udostępniają komponenty open source na GitHub i GitLab, jednocześnie utrzymując w tajemnicy część kodu jako know-how. Prawidłowy wybór licencji otwartej — permisywnej (MIT, Apache 2.0) lub copyleftowej (GPL) — ma fundamentalne znaczenie dla strategii komercjalizacji i możliwości integracji z innymi projektami.

Wzór dostępny na forms-legal.com pozwala na sporządzenie umowy licencji otwartej dostosowanej do polskiego prawa autorskiego — z wyraźnym wskazaniem pól eksploatacji (art. 50 pr. aut.), warunków atrybucji, wymagań copyleft i zakresu dopuszczalnego użycia komercyjnego. Wzór może być używany zarówno jako samodzielna licencja dołączana do pliku LICENCE.md, jak i jako umowa formalna zawierana z konkretnym podmiotem w specyficznych okolicznościach.

Autorskie prawa osobiste twórcy są w każdym przypadku niezbywalne (art. 16 pr. aut.) i żadna licencja otwarta nie może ich przenieść. Prawo do autorstwa, do integralności utworu i do oznaczenia go nazwiskiem twórcy pozostają przy twórcy. Licencje otwarte regulują wyłącznie autorskie prawa majątkowe (art. 17 pr. aut.) — uprawnienia do korzystania i rozporządzania.

Umowa licencji otwartej w Polsce jest potrzebna zawsze, gdy twórca chce udostępnić swoje dzieło publicznie z zachowaniem określonych warunków korzystania.

Publikacja biblioteki open source przez firmę technologiczną. Polskie spółki z o.o. i spółki akcyjne działające w sektorze IT publikują biblioteki programistyczne, frameworki i narzędzia na platformach GitHub lub GitLab. Wybór właściwej licencji (MIT, Apache 2.0 lub GPL) decyduje o tym, czy inne firmy mogą integrować bibliotekę w swoich komercyjnych produktach bez udostępniania kodu.

Startupy udostępniające część kodu. Model biznesowy „open core” polega na udostępnieniu podstawowej wersji oprogramowania jako open source, przy jednoczesnej sprzedaży rozszerzonych funkcji jako płatnej licencji komercyjnej. Startupy zarejestrowane w Polsce i finansowane przez fundusze venture capital coraz częściej stosują ten model dla szybszego zdobycia społeczności użytkowników.

Organizacje non-profit i instytucje publiczne. Fundacje, stowarzyszenia i jednostki samorządu terytorialnego udostępniają tworzone przez siebie narzędzia cyfrowe na licencjach otwartych, zgodnie z zasadami otwartości danych publicznych wynikającymi z ustawy z dnia 11 sierpnia 2021 r. o otwartych danych i ponownym wykorzystywaniu informacji sektora publicznego.

Artystci i twórcy mediów cyfrowych. Fotografowie, ilustratorzy, muzycy i filmowcy udostępniają swoje prace na licencjach Creative Commons (CC BY, CC BY-SA, CC0), umożliwiając ich bezpłatne używanie przy spełnieniu warunków atrybucji. Licencja CC0 jest odpowiednikiem zrzeczenia się praw autorskich majątkowych w zakresie dopuszczonym przez polskie prawo.

Projekty badawcze finansowane ze środków UE. Projekty realizowane w ramach Horyzontu Europa (Horyzont 2020, Horyzont Europa) i programów NCBR często wymagają udostępnienia wyników badań lub oprogramowania na licencjach otwartych jako warunek dofinansowania. Komisja Europejska preferuje licencje permisywne lub CC BY dla materiałów naukowych.

Zbiory danych (datasets) i modele AI. Wraz z rozwojem sztucznej inteligencji rośnie potrzeba licencjonowania zbiorów danych treningowych i wytrenowanych modeli. Licencje Creative Commons (CC BY) lub dedykowane licencje Open Data są stosowane przez badaczy publikujących na platformach takich jak Hugging Face.

Umowa licencji otwartej w Polsce powinna zawierać następujące elementy, zapewniające jej prawną skuteczność zgodnie z art. 67 pr. aut. i KC.

Oznaczenie Licencjodawcy i utworu. Dane właściciela autorskich praw majątkowych — firma lub imię i nazwisko, adres kontaktowy lub URL projektu. Precyzyjne oznaczenie utworu będącego przedmiotem licencji: tytuł, wersja, URL repozytorium. Dla programów komputerowych — opis zakresu (np. „kod źródłowy biblioteki X, wersja 2.3, dostępny pod adresem github.com/...”). Prawidłowe oznaczenie ułatwia identyfikację praw i dochodzenie roszczeń przed Sądem Okręgowym w przypadku naruszeń.

Pola eksploatacji (art. 50 pr. aut.). Zgodnie z art. 41 ust. 2 pr. aut. licencja obejmuje wyłącznie wyraźnie wymienione pola eksploatacji. Typowy zakres licencji otwartej dla kodu źródłowego: utrwalanie i zwielokrotnianie (kopiowanie), pobranie i instalacja, uruchamianie, modyfikowanie i tworzenie opracowań, dystrybucja oryginału i modyfikacji, publiczne udostępnianie w sieci internetowej. Dla treści (CC BY): odtwarzanie, kopiowanie, publiczne udostępnianie, modyfikowanie i tworzenie opracowań.

Warunek atrybucji. Wyraźne wskazanie, czy użytkownicy muszą zachować informację o Licencjodawcy i źródle. Licencje MIT i Apache 2.0 wymagają zachowania informacji o autorze w kopii kodu i dokumentacji. Licencje CC BY i CC BY-SA wymagają podania imienia i nazwiska lub firmy autora oraz tytułu dzieła. Brak warunku atrybucji (np. CC0) oznacza, że użytkownik może nie podawać źródła. forms-legal.com zaleca zawsze wymagać atrybucji, jeżeli projekt ma wartość dla Licencjodawcy.

Warunek copyleft. Wskazanie, czy modyfikacje dzieła muszą być udostępniane na tożsamej licencji. GPL v3 jest silnym copyleft — wszelkie dzieła pochodne (modyfikacje, oprogramowanie linkujące z biblioteką GPL) muszą być GPL. LGPL v3 jest słabym copyleft — biblioteki LGPL mogą być linkowane w komercyjnych aplikacjach zamkniętego kodu. MIT i Apache 2.0 nie mają warunku copyleft. Wybór modelu zależy od strategii komercjalizacji.

Dopuszczalność użytku komercyjnego. Wyraźne wskazanie, czy licencja dopuszcza użytkowanie w celach komercyjnych. MIT, Apache 2.0, GPL, CC BY i CC BY-SA dopuszczają użycie komercyjne. Licencja CC BY-NC (Non-Commercial) zabrania użycia komercyjnego. Brak jednoznacznego postanowienia może powodować wątpliwości interpretacyjne i spory.

Wyłączenie gwarancji. Klauzula „as is” wyłączająca odpowiedzialność Licencjodawcy za wady oprogramowania lub szkody wynikłe z jego użycia. W prawie polskim wyłączenie odpowiedzialności jest dopuszczalne w zakresie niedotyczącym szkód wyrządzonych umyślnie (art. 473 § 2 KC). Wyłączenie gwarancji jest standardem we wszystkich popularnych licencjach open source i chroni twórców przed roszczeniami użytkowników.

Dyspozycja na wypadek wygaśnięcia. Wskazanie, co się dzieje z licencją w przypadku naruszenia jej warunków. Licencje GPL i Apache 2.0 przewidują, że licencja wygasa automatycznie przy naruszeniu warunków. Po wygaśnięciu użytkownik traci prawo do korzystania z licencji, chyba że naruszenie zostanie naprawione w określonym terminie.

Umowę licencji otwartej w Polsce wypełnia się według następujących kroków, dostosowując standardowy wzór do specyfiki projektu i strategii Licencjodawcy.

Krok 1 — określ swoje cele. Przed wyborem modelu licencji zdecyduj, czy chcesz: dopuścić użycie komercyjne bez ujawniania kodu (MIT, Apache 2.0), wymagać, aby modyfikacje były open source (GPL v3), chronić przed roszczeniami patentowymi (Apache 2.0), czy licencjonujesz treści zamiast kodu (Creative Commons). Dla większości polskich firm technologicznych licencja MIT lub Apache 2.0 jest optymalnym wyborem.

Krok 2 — oznacz Licencjodawcę i utwór. Wpisz swoje dane (firma lub imię i nazwisko) i adres kontaktowy lub URL projektu. Podaj pełną nazwę i wersję projektu oraz URL repozytorium (GitHub, GitLab). Precyzyjne oznaczenie ułatwia użytkownikom zidentyfikowanie uprawnionego i kontakt w sprawie rozszerzenia praw.

Krok 3 — wybierz model licencji. Z listy wybierz model odpowiadający Twojej strategii. Jeżeli nie jesteś pewny, konsultuj się z prawnikiem specjalizującym się w prawie IT lub skorzystaj z narzędzia choosealicense.com jako orientacyjnego przewodnika. Dla projektów finansowanych ze środków UE sprawdź wymagania konkretnego programu (Horyzont Europa wymaga CC BY dla publikacji naukowych).

Krok 4 — wybierz wymagania licencji. Zdecyduj o: atrybucji (zalecana dla projektów, gdzie branding ma znaczenie), warunku copyleft (wymagany w GPL, opcjonalny w innych modelach) i dopuszczalności użytku komercyjnego. Te trzy parametry definiują zakres ochrony Licencjodawcy.

Krok 5 — dołącz tekst licencji do projektu. Skopiuj tekst licencji do pliku LICENCE lub LICENSE.md w głównym katalogu repozytorium. Dodaj skróconą informację o licencji (copyright notice) do każdego pliku z kodem źródłowym — na przykład: „Copyright (c) 2026 [Licencjodawca Nazwa]. Licensed under MIT License.”

Krok 6 — zaktualizuj dokumentację. Wpisz informację o licencji w pliku README.md projektu, aby użytkownicy mogli ją łatwo zidentyfikować bez czytania pełnego tekstu licencji. Dla platform takich jak npm (Node.js), PyPI (Python) lub Maven (Java) — upewnij się, że pole „license” w pliku konfiguracyjnym (package.json, setup.py, pom.xml) wskazuje poprawny identyfikator SPDX licencji (np. „MIT”, „Apache-2.0”, „GPL-3.0-or-later”).

Licencje otwarte w Polsce podlegają przepisom ustawy z dnia 4 lutego 1994 r. o prawie autorskim i prawach pokrewnych oraz ogólnym zasadom prawa zobowiązań z Kodeksu cywilnego.

Skuteczność prawna. Licencja otwarta jest umową licencyjną w rozumieniu art. 67 pr. aut. Jej zawarcie następuje przez przyjęcie oferowanych warunków — użytkownik, który kopiuje lub używa oprogramowania na warunkach licencji, zawiera umowę w trybie art. 70² KC (przyjęcie oferty przez przystąpienie do wykonania). Sąd Okręgowy potwierdził tę interpretację w orzeczeniach dotyczących licencji GPL.

Forma licencji. Licencja niewyłączna na korzystanie z utworu nie wymaga formy pisemnej (art. 67 ust. 5 pr. aut. wymaga jej tylko dla licencji wyłącznej). Licencja opublikowana w repozytorium lub dołączona do oprogramowania jest skuteczna w formie elektronicznej. Nie wymaga kwalifikowanego podpisu elektronicznego.

Naruszenie licencji open source. Naruszenie warunków licencji (np. użycie kodu GPL w komercyjnym oprogramowaniu bez udostępnienia kodu) skutkuje odpowiedzialnością za naruszenie praw autorskich (art. 79 pr. aut.). Licencjodawca może żądać: zaniechania naruszenia, odszkodowania, zapłaty wielokrotności stosownego wynagrodzenia (art. 79 ust. 1 pkt 3 pr. aut. — trzykrotność stosownego wynagrodzenia przy zawinionym naruszeniu). Organy celne KAS mogą zajmować na granicy produkty zawierające naruszający kod.

SZTUCZNA INTELIGENCJA i licencje. Korzystanie z danych treningowych objętych licencją otwartą do trenowania modeli AI jest zagadnieniem prawnie nierozstrzygniętym w Polsce i UE. Propozycje Europejskiego Aktu o Sztucznej Inteligencji (AI Act, wchodzący w życie etapami 2024–2026) wprowadzają obowiązki przejrzystości dla dostawców modeli AI co do danych treningowych.

Licencje otwarte w Polsce są często stosowane błędnie — zarówno przez twórców, jak i użytkowników — co prowadzi do naruszeń praw autorskich lub nieoczekiwanych ograniczeń komercyjnych.

Brak wyraźnego tekstu licencji w repozytorium. Opublikowanie kodu na GitHub bez pliku LICENCE lub LICENSE.md nie oznacza, że jest on open source — prawa autorskie przysługują twórcy z mocy ustawy (art. 8 pr. aut.) i inni nie mogą używać kodu bez licencji. Brak pliku licencyjnego naraża użytkowników kodu na odpowiedzialność za naruszenie.

Mieszanie kodu GPL i MIT w jednym projekcie. Dołączenie biblioteki licencjonowanej pod GPL do projektu MIT tworzy obowiązek udostępnienia całego projektu na licencji GPL (efekt wirusowy). Deweloperzy często nieświadomie włączają biblioteki GPL do projektów o zamkniętym kodzie, co Licencjodawca może wykryć narzędziami automatycznego skanowania (np. FOSSA, Black Duck).

Nieprawidłowe wskazanie właściciela praw. Plik LICENCE z datą i nazwą właściciela to ważny dowód w sporach przed Sądem Okręgowym. Brak lub błędne oznaczenie Licencjodawcy utrudnia dochodzenie roszczeń za naruszenie. Należy wskazać podmiot posiadający autorskie prawa majątkowe — nie zawsze jest to programista, który pisał kod (może to być pracodawca, zgodnie z art. 12 pr. aut.).

Nieaktualizowanie licencji przy zmianie modelu biznesowego. Projekt opublikowany jako MIT może być później „re-licencjonowany” na GPL lub licencję komercyjną wyłącznie za zgodą wszystkich współtwórców. Bez zebrania podpisów pod Contributor License Agreement (CLA) od wszystkich autorów wkładów do projektu re-licencjonowanie jest niemożliwe. Brak CLA od początku blokuje późniejsze zmiany licencji.

Ignorowanie wymogu atrybucji. Firmy używające bibliotek MIT lub Apache 2.0 często pomijają obowiązek zachowania informacji o autorze. MIT License wymaga, aby copyright notice i tekst licencji były zawarte we wszystkich kopiach oprogramowania. Pominięcie tego wymogu stanowi naruszenie licencji i może skutkować roszczeniami Licencjodawcy na podstawie art. 79 pr. aut.