Ochrona oprogramowania – prawa autorskie w polskim

Firma programistyczna z Mazowsza kończy dwuletni projekt. Nagle okazuje się, że były pracownik udostępnił kod źródłowy konkurencji. Spółka pyta: czy mamy ochronę prawną? Odpowiedź zależy od tego, czy prawidłowo uregulowano prawa autorskie – zanim doszło do naruszenia.

Ochrona oprogramowania w Polsce opiera się na ustawie z 4 lutego 1994 r. o prawie autorskim i prawach pokrewnych. Kod źródłowy jest chroniony jak utwór literacki – bez rejestracji, od momentu ustalenia. Autorskie prawa majątkowe trwają 70 lat od śmierci twórcy lub od daty pierwszego rozpowszechnienia. Brak umowy pisemnej oznacza, że prawa pozostają przy twórcy – nie przy spółce, która za projekt zapłaciła.

Ten przewodnik prowadzi przez cztery etapy: podstawy ochrony, procedurę przeniesienia praw, typowe pułapki oraz strategię w środowisku regulacyjnym AI Act i DORA. Każdy etap zawiera konkretne działania, terminy i pytania kontrolne.

Czym jest ochrona oprogramowania w polskim prawie autorskim?

Prawo autorskie chroni oprogramowanie automatycznie. Ochrona powstaje z chwilą ustalenia utworu – wystarczy, że kod istnieje w formie możliwej do odczytania. Nie ma rejestru, nie ma opłat, nie ma wniosków do urzędu. To zasadnicza różnica względem patentu czy znaku towarowego, gdzie rejestracja jest warunkiem ochrony.

Ustawa o prawie autorskim wprost wymienia programy komputerowe jako kategorię utworów. Ochrona obejmuje kod źródłowy, kod wynikowy oraz dokumentację techniczną – o ile nosi cechy twórcze. Interfejs użytkownika podlega odrębnej analizie: sam wygląd ekranu bywa trudny do ochrony, ale warstwa kodu za nim stoi zawsze pod ochroną prawa autorskiego.

Ochrona nie obejmuje idei, algorytmów ani zasad działania. Chroni wyłącznie konkretną ekspresję – czyli sposób, w jaki programista zapisał rozwiązanie. Dwie aplikacje realizujące tę samą funkcję mogą być niezależnie chronione, jeśli kod różni się od siebie.

Dla spółki kluczowe jest ustalenie, kto jest podmiotem praw. Jeśli program stworzył pracownik w ramach obowiązków służbowych, prawa majątkowe przechodzą na pracodawcę z mocy art. 74 ust. 3 ustawy – bez dodatkowej umowy. Inaczej jest przy umowie o dzieło lub B2B: tu prawa pozostają przy wykonawcy, dopóki nie zostaną przeniesione w formie pisemnej. To pierwsza pułapka, w którą wpada wiele firm z sektora IT.

RODO (Rozporządzenie UE 2016/679) wchodzi w grę, gdy oprogramowanie przetwarza dane osobowe. Architektura systemu musi spełniać zasadę privacy by design. Naruszenie RODO nie uchyla ochrony autorskoprawnej, ale otwiera równoległą linię odpowiedzialności – nadzorowaną przez PUODO.

Jak krok po kroku przenieść prawa autorskie do oprogramowania?

Przeniesienie autorskich praw majątkowych do oprogramowania wymaga umowy pisemnej, wskazującej pola eksploatacji. Brak choćby jednego z tych elementów powoduje, że przeniesienie jest bezskuteczne w zakresie pominiętego pola. Sąd Najwyższy wielokrotnie potwierdzał, że nieoznaczenie pól eksploatacji równa się braku przeniesienia.

Procedura krok po kroku wygląda następująco:

Krok 1 – inwentaryzacja: ustal, kto faktycznie stworzył kod (pracownicy, podwykonawcy, open source). Termin: przed podpisaniem jakiejkolwiek umowy z klientem końcowym.
Krok 2 – umowa pisemna: zawrzyj umowę przeniesienia praw lub umowę licencyjną wyłączną. Wskaż pola eksploatacji: zwielokrotnianie, obrót, modyfikacja, najem, publiczne udostępnianie.
Krok 3 – wynagrodzenie: każde pole eksploatacji może wymagać odrębnego wynagrodzenia (art. 45 ustawy o prawie autorskim). Ryczałt jest dopuszczalny, ale musi wynikać z umowy.
Krok 4 – prawa zależne: jeśli spółka zamierza modyfikować kod, umowa musi przenosić prawo do tworzenia opracowań (art. 46 ustawy).
Krok 5 – dokumentacja: zachowaj wersje kodu z datowaniem (git log, systemy CI/CD). To dowód pierwszeństwa w sporze.

W praktyce – wiele firm o tym zapomina – umowa z programistą B2B często przenosi prawa dopiero po zapłacie ostatniej faktury. Jeśli projekt trwa 18 miesięcy, przez ten czas spółka korzysta z kodu bez tytułu prawnego. Ryzyko jest realne: wykonawca może wypowiedzieć współpracę i zablokować wdrożenie.

Firma produkcyjna z Górnego Śląska przekonała się o tym zimą 2024 r. Podwykonawca zatrzymał klucze do repozytorium po sporze o wynagrodzenie. Spółka przez 6 tygodni nie mogła wydać aktualizacji systemu MES. Zabezpieczenie sądowe (art. 730 k.p.c.) pozwoliło odblokować dostęp, ale koszty postępowania przekroczyły 40 000 PLN.

Przy projektach finansowanych ze środków KPO lub RRF pojawia się dodatkowy wymóg: instytucja finansująca może wymagać licencji zwrotnej lub przeniesienia praw na Skarb Państwa. Szczegóły opisujemy w materiale o compliance funduszy UE – wymagania KPO i RRF.

Jakie błędy najczęściej kosztują firmy IT ochronę praw?

Trzy kategorie błędów odpowiadają za większość sporów o prawa do oprogramowania. Pierwsze dwie są proceduralne. Trzecia wynika z niedoszacowania ryzyka regulacyjnego.

Błąd pierwszy: brak pisemnej umowy z programistami B2B. Ustna zgoda nie przenosi praw majątkowych. Nie wystarczy e-mail z potwierdzeniem. Nawet faktura z opisem „przeniesienie praw" jest niewystarczająca – doktryna i orzecznictwo wymagają odrębnego dokumentu wskazującego pola eksploatacji.

Błąd drugi: pominięcie prawa do modyfikacji. Spółka nabywa prawo do używania kodu, ale nie do jego zmiany. Rok później chce rozbudować system – i okazuje się, że każda modyfikacja wymaga zgody pierwotnego autora. To klasyczna pułapka przy przejęciach spółek IT: nabywca kupuje udziały, ale nie nabywa automatycznie praw do oprogramowania, jeśli prawa te nie były poprawnie przeniesione wewnątrz spółki.

Błąd trzeci: ignorowanie open source. Wiele projektów korzysta z bibliotek na licencjach GPL lub LGPL. Licencja GPL nakłada obowiązek udostępnienia kodu modyfikacji na tych samych warunkach. Firma, która osadzi komponent GPL w komercyjnym produkcie zamkniętym, ryzykuje naruszenie licencji – i żądanie ujawnienia całego kodu źródłowego.

Uważamy, że bezpieczniejszym rozwiązaniem jest audyt zależności open source przed każdym zamknięciem rundy inwestycyjnej lub transakcją M&A. Koszt takiego audytu to ułamek kosztów sporu.

Spółka SaaS z Trójmiasta odkryła wiosną 2025 r., że jej główny produkt zawiera komponent AGPL. Inwestor na etapie due diligence zażądał usunięcia zależności lub zmiany modelu licencyjnego. Refaktoryzacja zajęła 3 miesiące i opóźniła zamknięcie rundy o pół roku.

Jak AI Act i DORA zmieniają ochronę oprogramowania w 2026 r.?

Regulacja wyprzedza rynek – i rok 2026 jest tego dowodem. Dwa rozporządzenia unijne tworzą nowe obowiązki dla twórców i właścicieli oprogramowania: AI Act (Rozporządzenie UE 2024/1689) oraz DORA (Rozporządzenie UE 2022/2554). Oba weszły w życie i nakładają wymagania, które bezpośrednio wpływają na to, jak należy projektować, dokumentować i licencjonować kod.

AI Act klasyfikuje systemy sztucznej inteligencji według poziomu ryzyka. Systemy wysokiego ryzyka – w tym narzędzia do oceny kredytowej, rekrutacji i biometrii – wymagają oceny zgodności przed wprowadzeniem na rynek. Dokumentacja techniczna systemu AI musi opisywać architekturę modelu, dane treningowe i ograniczenia. To oznacza, że właściciel oprogramowania AI musi zachować kontrolę nad dokumentacją – co z kolei wymaga precyzyjnego uregulowania praw autorskich do wszystkich komponentów systemu.

DORA obowiązuje od 17 stycznia 2025 r. podmioty finansowe nadzorowane przez KNF. Rozporządzenie wymaga zarządzania ryzykiem ICT, w tym dokumentowania umów z dostawcami oprogramowania. Instytucja finansowa musi wiedzieć, na jakich warunkach licencyjnych korzysta z każdego komponentu krytycznego systemu IT. Brak tej wiedzy to bezpośrednie ryzyko regulacyjne. Szczegółowe omówienie obowiązków DORA znajdą Państwo w materiale DORA – zarządzanie ryzykiem ICT w polskich podmiotach.

Ochrona danych (RODO) pozostaje stałym tłem. Oprogramowanie przetwarzające dane osobowe musi spełniać zasadę privacy by design. Naruszenie tej zasady nie uchyla ochrony autorskoprawnej, ale PUODO może nałożyć karę niezależnie od tego, czy kod jest chroniony prawem autorskim.

Znak towarowy to narzędzie uzupełniające ochronę oprogramowania. Nazwa aplikacji, logo interfejsu i charakterystyczne elementy wizualne mogą być zarejestrowane w Urzędzie Patentowym RP lub EUIPO. Rejestracja znaku towarowego daje prawo wyłączne przez 10 lat (z możliwością przedłużania) i chroni przed naśladownictwem na poziomie marki – niezależnie od ochrony kodu.

Kancelaria IP Warszawa – tak szukają pomocy firmy, które chcą połączyć ochronę autorskoprawną ze strategią znaku towarowego. Uważamy, że oba instrumenty powinny działać równolegle: prawo autorskie chroni kod, znak towarowy chroni markę produktu.

Co przygotować – lista kontrolna dla właścicieli oprogramowania

Ochrona oprogramowania to proces, nie jednorazowy dokument. Poniższa lista kontrolna wskazuje minimum, które każda spółka IT powinna wdrożyć przed komercjalizacją produktu lub wejściem inwestora.

Umowy z twórcami: pisemne umowy przeniesienia praw z każdym programistą (pracownik, B2B, podwykonawca) – z wyraźnym wskazaniem pól eksploatacji i prawa do modyfikacji.
Audyt open source: pełna lista zależności z przypisanymi licencjami; weryfikacja zgodności z modelem komercyjnym produktu.
Dokumentacja wersji: datowane repozytorium kodu (git) jako dowód pierwszeństwa; polityka commitów opisująca autorstwo zmian.
Dokumentacja AI Act: dla systemów AI – technical documentation zgodna z Załącznikiem IV do AI Act; opis architektury, danych i ograniczeń.
Rejestracja znaku towarowego: wniosek do UPRP lub EUIPO dla nazwy i logo produktu; klasy 9 i 42 Nice dla oprogramowania i usług SaaS.

Trzy scenariusze biznesowe pokazują, jak lista działa w praktyce. Firma produkcyjna wdraża system MES: kluczowe jest przeniesienie praw od integratora i audyt licencji PLC. Startup IT zamyka rundę seed: inwestor wymaga clean IP – pełna dokumentacja umów z założycielami i pracownikami. Zagraniczny inwestor wchodzi na rynek polski: weryfikuje, czy prawa do oprogramowania są w spółce polskiej czy u zagranicznego podmiotu powiązanego – i żąda przeniesienia przed zamknięciem transakcji.

Konkretna sytuacja Państwa firmy wymaga oceny, zanim dojdzie do naruszenia lub transakcji. Brak właściwych umów przed wejściem inwestora lub sporem sądowym jest konsekwencją nieodwracalną – odtworzenie historii praw autorskich po fakcie jest kosztowne i często niemożliwe.

Jeśli Państwa spółka komercjalizuje oprogramowanie lub przygotowuje się do transakcji M&A – przeprowadzimy audyt IP, ocenimy umowy z twórcami i zidentyfikujemy luki w ochronie: info@kordeckipartners.com.

Często zadawane pytania

P: Czy rejestracja oprogramowania w urzędzie jest konieczna do uzyskania ochrony prawnoautorskiej?

O: Nie. Ochrona powstaje automatycznie z chwilą ustalenia utworu – bez żadnej rejestracji ani opłat. W Polsce nie istnieje rejestr programów komputerowych analogiczny do rejestru znaków towarowych. Rejestracja u notariusza lub w organizacji zbiorowego zarządzania może służyć jako dowód daty powstania, ale nie jest warunkiem ochrony. Warto jednak prowadzić datowane repozytorium kodu, bo w sporze to właśnie dowody pierwszeństwa decydują o wyniku.

P: Ile czasu zajmuje przeniesienie praw autorskich do oprogramowania i ile to kosztuje?

O: Sama umowa przeniesienia praw może być sporządzona w ciągu 3–5 dni roboczych przy gotowych danych o polach eksploatacji. Koszt obsługi prawnej zależy od złożoności projektu: dla standardowej umowy z jednym twórcą to wydatek rzędu 2 000–5 000 PLN netto. Przy projektach wielomodułowych z kilkudziesięcioma podwykonawcami – audyt i dokumentacja mogą kosztować od 15 000 do 40 000 PLN. Terminy wydłużają się, gdy konieczne jest ustalenie autorstwa historycznych commitów lub negocjacje z podwykonawcami.

P: Czy spółka nabywa prawa autorskie do kodu stworzonego przez pracownika automatycznie?

O: Tak, ale tylko w określonym zakresie. Artykuł 74 ustęp 3 ustawy o prawie autorskim stanowi, że prawa majątkowe do programu komputerowego stworzonego przez pracownika w wyniku wykonywania obowiązków ze stosunku pracy przysługują pracodawcy. Warunek jest jeden: program musi powstać w ramach obowiązków służbowych. Jeśli pracownik stworzył kod po godzinach, na własnym sprzęcie, poza zakresem umowy – prawa pozostają przy nim. Dlatego zakres obowiązków w umowie o pracę powinien precyzyjnie opisywać rodzaj tworzonego oprogramowania.

KORDECKI & Partners to kancelaria prawna z siedzibą w Warszawie i Krakowie, doradzająca klientom biznesowym w 30 jurysdykcjach. Zespół łączy doświadczenie w prawie polskim i międzynarodowym z praktycznym podejściem do ochrony własności intelektualnej, wdrożeń AI Act i DORA oraz transakcji M&A w sektorze technologicznym. Pracujemy z polskimi przedsiębiorcami, inwestorami zagranicznymi i działami prawnymi korporacji. W sprawie Państwa sytuacji: info@kordeckipartners.com.