Firma programistyczna z Krakowa spędza osiemnaście miesięcy na budowie systemu zarządzania produkcją. Produkt trafia na rynek. Trzy miesiące później pojawia się konkurencja z niemal identycznym rozwiązaniem. Twórcy pytają: czy polskie prawo w ogóle ich chroni? Odpowiedź brzmi – tak, ale tylko wtedy, gdy firma rozumie, jak ta ochrona działa i gdzie ma swoje granice.

Polskie prawo autorskie chroni oprogramowanie komputerowe automatycznie – od chwili jego stworzenia, bez rejestracji, bez opłat. Podstawą jest ustawa z 4 lutego 1994 r. o prawie autorskim i prawach pokrewnych, która traktuje program komputerowy jak utwór literacki. Ochrona trwa przez 70 lat po śmierci twórcy. Jednak sama ochrona z mocy prawa nie wystarczy – firma musi aktywnie zarządzać tymi prawami, żeby je skutecznie egzekwować.

Ten przewodnik wyjaśnia: jak powstaje ochrona, kto jest właścicielem praw, jak przenosić je na spółkę, jakie błędy kosztują firmy technologiczne największe straty, oraz jak skonstruować strategię IP odporną na audyty due diligence i roszczenia konkurencji. Omawiamy trzy scenariusze biznesowe – producenta oprogramowania, firmę IT wdrażającą rozwiązania dla klientów i zagranicznego inwestora wchodzącego na rynek polski.

Jak powstaje ochrona prawnoautorska oprogramowania w Polsce?

Ochrona powstaje w momencie ustalenia utworu – czyli gdy kod po raz pierwszy przyjmuje uchwytną postać. Nie jest wymagana żadna rejestracja w Urzędzie Patentowym RP ani UPRP, żaden depozyt, żaden symbol ©. Wystarczy, że program wykazuje cechę indywidualności twórczej: musi być przejawem własnej intelektualnej działalności twórcy.

To rozróżnienie ma praktyczne znaczenie. Algorytm sam w sobie nie podlega ochronie autorskoprawnej – jest metodą, a metody chronić można co najwyżej patentem. Chroniony jest natomiast konkretny kod źródłowy, kod wynikowy, a nawet interfejs użytkownika, jeśli wykazuje oryginalność. Baza danych dołączona do oprogramowania może korzystać z odrębnej ochrony sui generis na podstawie ustawy o ochronie baz danych z 2001 r.

W praktyce – wiele firm o tym zapomina – ochrona nie obejmuje idei, koncepcji ani funkcjonalności. Konkurent, który przepisze program od zera, realizując identyczną funkcję, nie narusza praw autorskich. Naruszenie następuje dopiero przy kopiowaniu konkretnej implementacji. Dlatego strategia IP powinna łączyć prawo autorskie z ochroną tajemnicy przedsiębiorstwa (ustawa o zwalczaniu nieuczciwej konkurencji) oraz – tam gdzie to możliwe – z patentem na wynalazek wspomagany komputerowo.

Dla firm z sektora finansowego istotny jest też kontekst regulacyjny: DORA (Rozporządzenie UE 2022/2554), które weszło w życie 17 stycznia 2025 r., nakłada na podmioty finansowe obowiązki w zakresie zarządzania ryzykiem ICT. Obejmują one dokumentację i weryfikację własności praw do oprogramowania używanego w infrastrukturze krytycznej. Brak porządku w IP może więc stać się problemem compliance.

Kto jest właścicielem praw – twórca, pracownik czy spółka?

To pytanie kosztuje polskie firmy technologiczne najwięcej. Odpowiedź zależy od podstawy prawnej współpracy z programistą. Trzy scenariusze wyglądają zupełnie inaczej, a pomylenie ich konsekwencji może zablokować sprzedaż spółki lub całą rundę inwestycyjną.

Scenariusz 1 – umowa o pracę. Jeżeli programista tworzy oprogramowanie w ramach obowiązków pracowniczych, pracodawca nabywa autorskie prawa majątkowe z chwilą przyjęcia utworu – na podstawie art. 74 ust. 3 ustawy o prawie autorskim. Nabycie następuje automatycznie, bez dodatkowej cesji. Jednak „przyjęcie" nie jest formalnością: pracodawca powinien je udokumentować, np. protokołem odbioru lub wpisem w systemie kontroli wersji z datą.

Scenariusz 2 – umowa B2B lub zlecenie. Programista-freelancer lub software house działający jako podmiot zewnętrzny zachowuje prawa autorskie, dopóki ich wyraźnie nie przeniesie. Samo wykonanie dzieła i zapłata wynagrodzenia nie przenoszą praw. Umowa musi wskazywać pola eksploatacji (art. 50 ustawy o prawie autorskim) – bez ich wyliczenia przeniesienie jest nieskuteczne w zakresie niewymienionych pól. Pominięcie pola eksploatacji „Internet" albo „dystrybucja w modelu SaaS" to typowy błąd, który odkrywają audytorzy podczas due diligence.

Scenariusz 3 – współtwórczość. Gdy oprogramowanie tworzą wspólnie pracownicy i zewnętrzni wykonawcy, powstaje utwór współautorski. Każdy współtwórca ma udział w prawach. Rozporządzanie całością wymaga zgody wszystkich – co może sparaliżować decyzje biznesowe spółki przez lata.

Dla zagranicznych inwestorów wchodzących na rynek polski – na przykład funduszy PE prowadzących transakcje SPA – kwestia własności IP jest elementem każdego badania due diligence. Więcej o strukturyzacji inwestycji technologicznych w Polsce czytaj w naszym opracowaniu IP protection strategy for Hungary tech companies in Poland.

Konkretna sytuacja Państwa spółki może się okazać nieodwracalnie niekorzystna, jeśli prawa do kluczowego produktu formalnie należą do byłego wykonawcy. Każdy miesiąc zwłoki w uregulowaniu własności IP to ryzyko, że twórca zmieni zdanie, zbankrutuje lub przeniesie prawa na podmiot trzeci.

Jeśli Państwa spółka korzysta z oprogramowania tworzonego przez zewnętrznych programistów lub współpracowników B2B i nie przeprowadzono audytu umów – przeprowadzimy przegląd dokumentacji i ocenimy, które prawa wymagają cesji: info@kordeckipartners.com.

Jak przenieść prawa na spółkę – procedura krok po kroku?

Przeniesienie autorskich praw majątkowych wymaga umowy zawartej w formie pisemnej pod rygorem nieważności. To jeden z nielicznych przypadków, gdy prawo cywilne narzuca formę bezwzględnie. E-mail z potwierdzeniem lub korespondencja przez komunikator – bez kwalifikowanego podpisu elektronicznego – nie wystarczy.

Procedura składa się z pięciu etapów:

  • Inwentaryzacja – sporządzenie listy wszystkich elementów oprogramowania z przypisaniem twórców i podstawy prawnej współpracy (umowa o pracę, zlecenie, B2B, open source).
  • Audyt umów – weryfikacja, czy istniejące umowy przenoszą prawa na wszystkich wymaganych polach eksploatacji, w tym dystrybucja cyfrowa, SaaS, modyfikacja, sublicencja.
  • Uzupełnienie cesji – zawarcie umów przeniesienia praw z każdym twórcą, który nie przeniósł ich skutecznie; termin: jak najszybciej, bo roszczenia z tytułu naruszenia praw autorskich przedawniają się po 5 latach.
  • Klauzule w nowych umowach – wprowadzenie standardowych klauzul IP assignment do wzorów umów o pracę i B2B, z wyraźnym wyliczeniem pól eksploatacji oraz klauzulą dotyczącą przyszłych wersji oprogramowania.
  • Dokumentacja dewelopmentu – prowadzenie rejestru commitów, historii wersji i protokołów odbioru jako dowód daty pierwszego ustalenia i tożsamości twórców.

Firma IT z Warszawy wdrażająca system ERP dla sieci handlowej odkryła w trakcie audytu przed sprzedażą udziałów, że czterech kluczowych programistów-freelancerów nigdy nie podpisało cesji. Negocjacje z nabywcą zostały wstrzymane na sześć tygodni. Koszt naprawienia sytuacji – nowe umowy, konsultacje prawne, korekta wyceny – wyniósł wielokrotność tego, co kosztowałoby prawidłowe ułożenie umów na początku projektu.

Warto też pamiętać o ochronie danych osobowych: jeśli oprogramowanie przetwarza dane użytkowników, RODO (Rozporządzenie UE 2016/679) nakłada obowiązki na administratora danych. Przeniesienie praw do kodu nie przenosi automatycznie obowiązków wynikających z RODO – nabywca musi przeprowadzić własną analizę roli administratora lub procesora.

Jakie błędy najczęściej kosztują firmy technologiczne prawa do własnego produktu?

Błędy w zarządzaniu IP oprogramowania rzadko wynikają z nieznajomości prawa. Częściej są efektem pośpiechu, zaufania i przekonania, że „to się samo ureguluje". W praktyce – nie reguluje się.

Najczęstsze pułapki to:

  • Brak cesji od współzałożycieli. Spółka powstaje, wszyscy piszą kod, ale nikt nie przenosi praw na podmiot. Po rozstaniu współzałożyciel blokuje sprzedaż startupu.
  • Open source bez analizy licencji. Użycie komponentu na licencji GPL w oprogramowaniu komercyjnym może wymusić ujawnienie całego kodu źródłowego. Licencje copyleft działają jak „wirus" – infekują całość.
  • Umowy bez klauzuli o przyszłych wersjach. Cesja obejmuje kod istniejący w dniu podpisania. Kolejne wersje produktu – jeśli umowa milczy – pozostają przy twórcy.
  • Brak ochrony tajemnicy przedsiębiorstwa. Prawo autorskie nie chroni architektury systemu ani know-how. Bez umów o poufności (NDA) i procedur ochrony tajemnicy przedsiębiorstwa, odejście kluczowego dewelopera może oznaczać utratę przewagi konkurencyjnej.
  • Pominięcie regulacji AI Act. Systemy AI wbudowane w oprogramowanie podlegają Rozporządzeniu UE 2024/1689 (AI Act), które weszło w życie 1 sierpnia 2024 r. Systemy wysokiego ryzyka wymagają conformity assessment. Brak oceny zgodności to ryzyko prawne niezależne od ochrony autorskoprawnej.

Szwedzki producent oprogramowania przemysłowego otwierający oddział w Polsce (więcej o strategii IP dla firm skandynawskich w Polsce: IP protection strategy for Sweden tech companies in Poland) stanął przed problemem: polska spółka-córka podpisała umowy z lokalnymi programistami bez klauzul IP assignment. Negocjacje z inwestorem strategicznym ujawniły lukę. Naprawienie sytuacji zajęło trzy miesiące i wymagało renegocjacji z siedmioma wykonawcami.

Osobną kategorię ryzyka stanowi trademark. Prawo autorskie nie chroni nazwy oprogramowania ani logo produktu. Znak towarowy zarejestrowany w Urzędzie Unii Europejskiej ds. Własności Intelektualnej (EUIPO) lub UPRP daje ochronę niezależną od prawa autorskiego – i jest konieczny dla pełnej strategii IP. Prawnik IP w Warszawie powinien ocenić oba instrumenty łącznie.

Konkretna sytuacja Państwa firmy – szczególnie jeśli produkt jest w fazie skalowania lub przygotowań do transakcji – wymaga natychmiastowego przeglądu umów. Odkrycie luki w IP po podpisaniu term sheet to jeden z najbardziej kosztownych scenariuszy w transakcjach technologicznych.

Jeśli Państwa spółka przygotowuje się do rundy inwestycyjnej lub sprzedaży i nie przeprowadzono audytu IP – ocenimy stan własności praw, zidentyfikujemy luki i przeprowadzimy cesje: info@kordeckipartners.com.

Trzy scenariusze biznesowe – jak zarządzać IP oprogramowania w praktyce?

Strategia ochrony oprogramowania różni się w zależności od modelu biznesowego. Poniżej trzy scenariusze z konkretnymi wskazówkami.

Producent oprogramowania (ISV – Independent Software Vendor). Firma tworzy produkt i sprzedaje licencje. Priorytetem jest pełna konsolidacja praw majątkowych w spółce – bez wyjątków. Każda umowa z programistą (pracownik, B2B, podwykonawca) musi zawierać cesję na wszystkich polach eksploatacji, w tym przyszłe wersje i modyfikacje. Równolegle konieczna jest rejestracja znaku towarowego produktu. Polityka licencyjna powinna precyzować, co licencjobiorca może, a czego nie może robić z kodem – szczególnie w zakresie reverse engineering i sublicencji. Czas na przygotowanie kompletnej dokumentacji IP dla nowego produktu: 4–8 tygodni.

Firma IT wdrażająca oprogramowanie dla klientów. Tu kluczowe pytanie brzmi: kto jest właścicielem kodu napisanego na zamówienie? Domyślnie – twórca (firma IT). Klient, który zapłacił za wdrożenie, nie nabywa praw, jeśli umowa tego nie przewiduje. Dobre praktyki to: wyraźne określenie w umowie wdrożeniowej, czy klient nabywa prawa majątkowe czy tylko licencję, wskazanie zakresu licencji (eksploatacja, modyfikacja, sublicencja) oraz zachowanie przez firmę IT praw do komponentów wielokrotnego użytku (tzw. background IP). Warto też zadbać o klauzulę dotyczącą struktury korporacyjnej spółki, jeśli IP stanowi główną wartość biznesową.

Zagraniczny inwestor technologiczny wchodzący na rynek polski. Inwestor z Niemiec, Szwecji lub Stanów Zjednoczonych musi pamiętać, że polskie prawo autorskie – choć zharmonizowane z dyrektywami UE – różni się w szczegółach od systemów common law. Autorskie prawa osobiste (prawo do autorstwa, integralności) są w Polsce niezbywalne. Twórca zawsze pozostaje autorem – nawet po przeniesieniu praw majątkowych. Nie można ich wyłączyć umową. W praktyce oznacza to, że inwestor powinien zadbać o klauzule o niewykonywaniu praw osobistych (waiver of moral rights), a nie ich zbyciu.

Checklist – co przygotować przed audytem IP oprogramowania:

  • Lista wszystkich modułów i komponentów oprogramowania z przypisaniem twórców.
  • Kopie umów z programistami (pracownicy, B2B, freelancerzy) z weryfikacją klauzul cesji.
  • Analiza komponentów open source i zastosowanych licencji (GPL, MIT, Apache, LGPL).
  • Dokumentacja historii wersji (git log, protokoły odbioru, korespondencja z datami).
  • Weryfikacja rejestracji znaków towarowych dla nazwy produktu i logo.

Często zadawane pytania

P: Czy oprogramowanie tworzone przez pracownika zawsze należy do pracodawcy?

O: Nie zawsze. Artykuł 74 ustęp 3 ustawy o prawie autorskim przyznaje pracodawcy autorskie prawa majątkowe tylko do programów stworzonych w ramach obowiązków pracowniczych. Jeśli pracownik napisał kod poza godzinami pracy, na własnym sprzęcie i nie w zakresie swoich obowiązków – prawa pozostają przy nim. Granica bywa niewyraźna i powinna być uregulowana umownie. Dobra umowa o pracę z programistą precyzuje zakres twórczości objętej przejściem praw i obejmuje klauzulę dotyczącą projektów pobocznych.

P: Ile kosztuje i jak długo trwa przygotowanie kompletnej dokumentacji IP dla startupu?

O: Audyt i porządkowanie IP dla startupu we wczesnej fazie (3–10 programistów, jeden produkt) trwa zazwyczaj 4–8 tygodni. Koszt obsługi prawnej zależy od liczby umów do przeglądu i liczby wymaganych cesji – orientacyjnie od kilku do kilkunastu tysięcy złotych. Rejestracja znaku towarowego w EUIPO to dodatkowe 850–1 500 EUR opłaty urzędowej plus honorarium prawnika. Inwestycja zwraca się przy pierwszym due diligence – odkrycie luki IP na etapie transakcji kosztuje wielokrotnie więcej.

P: Czy AI generujące kod może być autorem oprogramowania w świetle polskiego prawa?

O: Według aktualnego stanu polskiego prawa autorskiego – nie. Autorem może być wyłącznie człowiek. Kod wygenerowany w całości przez sztuczną inteligencję, bez twórczego wkładu człowieka, nie korzysta z ochrony prawa autorskiego. W praktyce granica jest rozmyta: jeśli programista w sposób twórczy kieruje modelem AI, selekcjonuje i modyfikuje wyniki, jego wkład może uzasadniać ochronę. Rozporządzenie AI Act (Rozporządzenie UE 2024/1689) nie reguluje bezpośrednio własności praw autorskich do kodu – to obszar, który czeka na interwencję ustawodawcy.

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, prawa technologicznego i regulacji AI. Pracujemy z polskimi przedsiębiorcami, inwestorami zagranicznymi i działami prawnymi korporacji. W sprawie Państwa sytuacji: info@kordeckipartners.com.

Zastrzeżenie: Niniejsza publikacja służy wyłącznie celom informacyjnym i nie stanowi porady prawnej. Informacje zawarte w materiale nie powinny być traktowane jako substytut profesjonalnej porady prawnej dostosowanej do konkretnych okoliczności. KORDECKI & Partners nie ponosi odpowiedzialności za działania podjęte lub zaniechane na podstawie treści tego materiału. W sprawie porady dotyczącej Państwa konkretnej sytuacji prosimy o kontakt: info@kordeckipartners.com.