Ochrona oprogramowania – prawa autorskie w polskim

Firma z Krakowa wdraża własny system zarządzania magazynem. Programiści pracują miesiącami. Produkt gotowy – a spółka nie wie, czy naprawdę jest jego właścicielem. Prawa autorskie do kodu mogą należeć do twórców, nie do pracodawcy. Taki błąd odkrywa się zwykle przy sprzedaży, licencjonowaniu albo sporze z byłym pracownikiem.

Ochrona oprogramowania w Polsce opiera się na ustawie z dnia 4 lutego 1994 r. o prawie autorskim i prawach pokrewnych. Programy komputerowe chronione są jak utwory literackie – automatycznie, bez rejestracji, od chwili ustalenia kodu. Prawa majątkowe do oprogramowania stworzonego przez pracownika przechodzą na pracodawcę z mocy art. 74 ust. 3 ustawy, ale tylko w granicach zakresu obowiązków służbowych i wyłącznie wtedy, gdy umowa o pracę obowiązuje.

Przewodnik prowadzi przez cztery kluczowe obszary: podstawy ochrony, prawa pracownicze i kontraktowe, scenariusze biznesowe oraz najczęstsze błędy. Na końcu – lista kontrolna i odpowiedzi na pytania, które klienci zadają najczęściej.

Na czym polega ochrona oprogramowania w polskim prawie?

Ochrona powstaje automatycznie. Nie trzeba składać wniosku do żadnego urzędu, nie trzeba rejestrować kodu w KRS ani w żadnej innej instytucji. Wystarczy, że program komputerowy ma indywidualny charakter – nawet minimalny. Ustawa chroni zarówno kod źródłowy, jak i kod wynikowy. Chroni też interfejsy, o ile wykazują oryginalność.

Ochrona trwa 70 lat od śmierci twórcy. W praktyce – dla oprogramowania komercyjnego – oznacza to ochronę przez kilka pokoleń. Ważne zastrzeżenie: ustawa nie chroni algorytmów, idei ani koncepcji biznesowych. Chroni konkretną implementację. Dwie firmy mogą niezależnie napisać podobny algorytm sortowania – żadna nie narusza praw drugiej, o ile kodu nie skopiowała.

Polska implementuje w tym zakresie dyrektywę 2009/24/WE o ochronie prawnej programów komputerowych. Unijne ramy wyznaczają minimalny standard. Polskie przepisy idą w kilku miejscach dalej – szczególnie w zakresie ochrony praw osobistych twórcy, które są niezbywalne. Twórca zawsze zachowuje prawo do autorstwa, nawet po przeniesieniu praw majątkowych na spółkę.

Warto pamiętać o RODO (Rozporządzenie UE 2016/679). Jeśli oprogramowanie przetwarza dane osobowe, obok ochrony autorskiej pojawia się odrębna warstwa regulacyjna. Naruszenie RODO może wiązać się z karą do 20 mln EUR lub 4% globalnego obrotu. To nie jest kwestia IP – to kwestia compliance, którą trzeba rozwiązać równolegle. Nadzór sprawuje PUODO.

Kto jest właścicielem kodu – pracownik, zleceniobiorca czy firma?

To pytanie generuje najwięcej sporów. Odpowiedź zależy od podstawy prawnej współpracy. Trzy sytuacje wymagają odmiennego podejścia.

Pierwsza – umowa o pracę. Art. 74 ust. 3 ustawy o prawie autorskim przyznaje pracodawcy prawa majątkowe do oprogramowania stworzonego przez pracownika w ramach obowiązków służbowych. Kluczowe słowa: „w ramach obowiązków". Jeśli programista napisał narzędzie po godzinach, na własnym sprzęcie, bez polecenia przełożonego – prawa należą do niego. Pracodawca nie ma tu automatycznego roszczenia.

Druga – umowa B2B lub zlecenie. Tu ustawa milczy. Brak przeniesienia praw w umowie oznacza, że wykonawca zachowuje prawa majątkowe. Spółka otrzymuje jedynie licencję – jeśli w ogóle wynika to z umowy. W praktyce wiele kontraktów B2B w Polsce nie zawiera klauzuli cesji praw autorskich. Odkrycie tego faktu przy exit z inwestorem może zablokować transakcję na tygodnie.

Trzecia – współautorstwo. Gdy kod tworzą dwie lub więcej osób, powstaje utwór współautorski. Do rozporządzania nim potrzebna jest zgoda wszystkich współtwórców – chyba że umowa stanowi inaczej. W zespołach scrumowych, gdzie kilkanaście osób commituje do jednego repozytorium, ustalenie autorstwa bywa trudne. Logi git pomagają, ale nie zastępują umów.

Uważamy, że bezpieczniejszym rozwiązaniem jest każdorazowe stosowanie klauzuli cesji praw w umowach z wykonawcami zewnętrznymi – łącznie z oświadczeniem o zrzeczeniu się wykonywania praw osobistych w zakresie dozwolonym przez prawo. To dodatkowe zdanie w umowie może oszczędzić miesięcy sporu.

Jakie są trzy scenariusze biznesowe i jak każdy z nich wygląda w praktyce?

Scenariusze różnią się nie tylko branżą, ale też poziomem ryzyka i kosztami naprawy ewentualnych błędów.

Scenariusz 1 – firma produkcyjna z Mazowsza. Spółka wdrożyła system MES (Manufacturing Execution System) zbudowany przez zewnętrzne studio IT. Umowa dotyczyła „wdrożenia systemu" – bez klauzuli o przeniesieniu praw. Gdy studio ogłosiło upadłość, masa upadłościowa objęła prawa do kodu. Nowy właściciel praw zażądał opłaty licencyjnej. Spółka straciła 8 miesięcy na negocjacje i zapłaciła kilkaset tysięcy złotych za prawa, które powinna nabyć przy podpisaniu pierwotnej umowy. Temat prawa upadłościowego i jego skutków dla wierzycieli opisujemy szerzej w analizie prawa rady wierzycieli w polskim postępowaniu upadłościowym.

Scenariusz 2 – startup IT z Wrocławia. Trzech założycieli buduje SaaS. Każdy pisze kod, nikt nie podpisał umowy wewnątrz spółki. Po dwóch latach jeden ze wspólników odchodzi i twierdzi, że zachowuje prawa do modułu, który napisał samodzielnie. Inwestor seed wstrzymuje rundę – due diligence ujawniło problem. Rozwiązanie zajęło 6 tygodni i kosztowało 40 000 PLN w honorariach prawniczych. Wcześniejsza umowa wspólników z klauzulą cesji kosztowałaby ułamek tej kwoty.

Scenariusz 3 – inwestor zagraniczny wchodzący na rynek polski. Spółka z Niemiec przejmuje polskiego dostawcę oprogramowania. Due diligence IP ujawnia, że 30% kodu napisali freelancerzy bez cesji praw. Transakcja nie może zamknąć się w pierwotnym terminie. Strony negocjują retroaktywne cesje – część wykonawców jest nieosiągalna. Ostatecznie kupujący obniżył cenę o 15% jako wycenę ryzyka IP. To realna strata dla sprzedającego.

Jakie błędy najczęściej popełniają firmy przy ochronie oprogramowania?

Błędy powtarzają się niezależnie od branży. Zebraliśmy te, które widzimy najczęściej w praktyce kancelarii IP Warszawa.

Brak klauzuli cesji w umowach z B2B. Najczęstszy i najkosztowniejszy błąd. Samo wynagrodzenie za stworzenie kodu nie przenosi praw autorskich.
Pomijanie pól eksploatacji. Przeniesienie praw musi wymieniać konkretne pola eksploatacji (art. 50 ustawy). Ogólne sformułowanie „wszelkie prawa" może być kwestionowane.
Nieuwzględnienie open source. Kod oparty na licencjach GPL może wymuszać ujawnienie kodu źródłowego całego systemu. Audyt open source przed sprzedażą to standard – nie opcja.
Brak zabezpieczenia znaku towarowego. Ochrona autorska chroni kod, nie nazwę produktu. Znak towarowy to odrębna procedura – Urząd Patentowy RP lub EUIPO.
Ignorowanie AI Act przy systemach opartych na AI. AI Act (Rozporządzenie UE 2024/1689) wszedł w życie 1 sierpnia 2024 r. Systemy AI wysokiego ryzyka wymagają oceny zgodności. To nie jest kwestia IP – ale dotyka każdego, kto sprzedaje oprogramowanie z komponentem AI.

Osobną kategorię stanowią błędy przy oprogramowaniu finansowym. DORA (Rozporządzenie UE 2022/2554) obowiązuje od 17 stycznia 2025 r. Instytucje finansowe muszą zarządzać ryzykiem ICT – w tym ryzykiem prawnym związanym z dostawcami oprogramowania. Brak cesji praw do krytycznego systemu IT to ryzyko operacyjne raportowane do KNF. Więcej o ochronie oprogramowania w kontekście prawa autorskiego znajdą Państwo w naszym wcześniejszym materiale: ochrona oprogramowania – prawa autorskie w polskim prawie.

Konkretna sytuacja Państwa firmy może wymagać oceny, zanim błąd stanie się nieodwracalny – szczególnie gdy zbliża się transakcja, runda inwestycyjna lub kontrola regulatora. Każdy z opisanych scenariuszy pokazuje, że czas naprawy skraca się dramatycznie pod presją terminu.

Jeśli Państwa spółka tworzy lub nabywa oprogramowanie i nie ma pewności co do stanu praw autorskich – przeprowadzimy audyt IP, ocenimy umowy z wykonawcami i przygotujemy rekomendacje: info@kordeckipartners.com.

Lista kontrolna: co przygotować, zanim podpiszesz umowę na tworzenie oprogramowania?

Poniższa lista obejmuje minimum, które każda spółka powinna sprawdzić przed zawarciem umowy z deweloperem – niezależnie od wielkości projektu.

Klauzula cesji praw autorskich majątkowych na wszystkich polach eksploatacji wskazanych w art. 50 ustawy o prawie autorskim.
Oświadczenie wykonawcy o nienaruszaniu praw osób trzecich i braku elementów open source objętych licencjami wirusowymi (GPL, LGPL).
Klauzula dotycząca praw do dokumentacji, specyfikacji i materiałów pomocniczych – nie tylko kodu.
Postanowienie o zachowaniu poufności obejmujące kod źródłowy przez minimum 5 lat po zakończeniu umowy.
Wskazanie, kto jest autorem poszczególnych modułów – szczególnie przy zespołach mieszanych (pracownicy + B2B).

To nie jest lista wyczerpująca. Przy projektach powyżej 200 000 PLN warto zlecić pełny audyt IP przed podpisaniem umowy. Koszt audytu to ułamek kosztów sporu lub utraconej transakcji.

Często zadawane pytania

P: Czy muszę rejestrować oprogramowanie, żeby było chronione prawem autorskim?

O: Nie. Ochrona powstaje automatycznie z chwilą ustalenia kodu, bez żadnej rejestracji. Nie istnieje w Polsce żaden obowiązkowy rejestr oprogramowania. Możliwe jest notarialne poświadczenie daty powstania utworu lub złożenie kodu w depozycie – co ułatwia dowodzenie pierwszeństwa w sporze, ale nie jest warunkiem ochrony. Ochrona trwa 70 lat od śmierci twórcy.

P: Czy licencja open source może zablokować sprzedaż spółki?

O: Tak – i zdarza się to częściej, niż można by sądzić. Licencje copyleft (np. GPL w wersji 2 i 3) wymagają udostępnienia kodu źródłowego całego systemu, jeśli zawiera on komponenty GPL. Dla kupującego oznacza to ryzyko utraty przewagi konkurencyjnej. Audyt licencji open source jest standardową częścią due diligence technologicznego i powinien zostać przeprowadzony co najmniej 30 dni przed planowanym zamknięciem transakcji.

P: Co zrobić, gdy były pracownik twierdzi, że posiada prawa do kodu napisanego w czasie zatrudnienia?

O: Artykuł 74 ustęp 3 ustawy o prawie autorskim przyznaje pracodawcy prawa majątkowe do oprogramowania stworzonego w ramach obowiązków pracowniczych – bez potrzeby dodatkowych umów. Kluczowe jest wykazanie, że kod powstał w zakresie tych obowiązków. Pomocne są: zakres obowiązków z umowy o pracę, dokumentacja projektowa, logi systemowe i korespondencja służbowa. Jeśli pracownik pisał kod poza godzinami i na własny koszt, sprawa jest mniej oczywista – wtedy warto skonsultować się z prawnikiem przed zajęciem stanowiska.

O kancelarii

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

Jakub Górski specjalizuje się w prawie własności intelektualnej, technologiach i regulacjach AI.