Umowy IT i własność intelektualna oprogramowania dla firm

Ponad 70% sporów między firmami a programistami lub software house'ami wynika z jednego prostego błędu: umowa nie określa jednoznacznie, kto jest właścicielem kodu. Gdy firma płaci dziesiątki tysięcy złotych za stworzenie systemu, a po zakończeniu projektu okazuje się, że prawa autorskie pozostały przy wykonawcy — to nie jest scenariusz z filmów. To rzeczywistość, z którą mierzę się w swojej kancelarii regularnie. Prawo IT w Polsce jest pełne pułapek, które kosztują firmy fortunę. Zanim podpiszesz kolejną umowę z programistą, software house'em czy freelancerem, przeczytaj ten artykuł.

W Kancelarii Cenkier w Lublinie specjalizujemy się m.in. w obsłudze prawnej firm technologicznych oraz przedsiębiorców zlecających tworzenie oprogramowania. Widzę, jak bardzo różni się sytuacja prawna klienta w zależności od tego, czy umowa była dobrze skonstruowana, czy nie. Różnica między bezpiecznym kontraktem a umową pełną luk może oznaczać różnicę między sukcesem projektu a wieloletnim procesem sądowym.

Ten artykuł powstał z myślą o przedsiębiorcach — zarówno tych zamawiających oprogramowanie, jak i tych je tworzących. Znajdziesz tu konkretne zapisy umowne, które powinieneś znać, przykłady niebezpiecznych klauzul oraz wyjaśnienie, jak regulacje takie jak NIS2 czy AI Act wpływają na treść kontraktów IT.

Przeniesienie praw autorskich czy licencja — fundamentalna różnica w umowach IT

To pierwsze pytanie, które zadaję każdemu klientowi przynoszącemu mi umowę IT: czy umowa przewiduje przeniesienie majątkowych praw autorskich, czy tylko udzielenie licencji? Brzmi technicznie, ale konsekwencje są ogromne. Gdy nabywasz prawa autorskie, stajesz się właścicielem kodu — możesz go modyfikować, rozwijać, sprzedawać, licencjonować innym. Gdy uzyskujesz jedynie licencję, pozostajesz zależny od twórcy.

Przeniesienie majątkowych praw autorskich musi być dokonane w formie pisemnej pod rygorem nieważności (art. 53 Ustawy o prawie autorskim i prawach pokrewnych). Nie wystarczy ustna umowa, e-mail ani nawet regulamin. Jeśli umowa nie zawiera wyraźnego postanowienia o przeniesieniu praw, to oznacza, że prawa pozostają przy twórcy. I tu zaczyna się problem — firma, która zapłaciła za stworzenie systemu, może korzystać z niego tylko na zasadach licencji, której zakres może być bardzo ograniczony.

Licencja może być wyłączna lub niewyłączna. Licencja wyłączna — podobnie jak przeniesienie praw — wymaga formy pisemnej. Licencja niewyłączna pozwala twórcy udzielać jej wielu podmiotom jednocześnie. Wyobraź sobie, że zapłaciłeś za stworzenie platformy e-commerce, a twój software house tę samą platformę sprzedaje pod inną marką twoim konkurentom. Jeśli w umowie była tylko niewyłączna licencja, działał w pełni legalnie.

W praktyce najczęściej rekomendują przeniesienie pełnych majątkowych praw autorskich na wszystkich znanych polach eksploatacji. Szczególnie ważne jest wymienienie pól eksploatacji wprost — ustawa wymaga, by umowa obejmowała tylko te pola, które zostały w niej wyraźnie wskazane. Pole eksploatacji nieuwzględnione w umowie pozostaje przy twórcy.

Kod napisany przez pracownika a kod napisany przez zleceniobiorcę — art. 74 UPAPP

Art. 74 ust. 3 Ustawy o prawie autorskim i prawach pokrewnych stanowi, że majątkowe prawa autorskie do programu komputerowego stworzonego przez pracownika w wyniku wykonywania obowiązków ze stosunku pracy przysługują pracodawcy, o ile umowa o pracę nie stanowi inaczej. To jedna z najważniejszych zasad w prawie IT — i jedna z najczęściej pomijanych.

Warto jednak zwrócić uwagę na niuanse. Przepis mówi: w wyniku wykonywania obowiązków ze stosunku pracy. Jeśli programista zatrudniony na etacie stworzył kod w czasie wolnym, na prywatnym sprzęcie, a nie w ramach swoich obowiązków służbowych — prawo autorskie do tego kodu należy do niego, nie do pracodawcy. Dlatego umowy o pracę w branży IT powinny precyzyjnie definiować zakres obowiązków pracownika i jasno regulować kwestię prac twórczych wykonywanych poza godzinami pracy.

Zupełnie inaczej wygląda sytuacja, gdy zamawiasz kod u freelancera lub firmy zewnętrznej. Tu art. 74 UPAPP nie ma zastosowania. Domyślna zasada jest prosta: twórca jest właścicielem praw autorskich. Jeśli umowa B2B lub umowa o dzieło nie zawiera klauzuli o przeniesieniu praw, twój kontrahent pozostaje właścicielem kodu, który dla ciebie stworzył. Znam przypadki, gdy firma chciała zmienić software house, a poprzedni wykonawca odmówił przekazania praw do kodu — i miał do tego pełne prawo, bo umowa tego nie przewidywała.

Osobną kwestią jest coraz popularniejsze tworzenie kodu przy użyciu narzędzi AI — GitHub Copilot, ChatGPT, Cursor. Tutaj prawo autorskie jest wyjątkowo niepewne. W Polsce, podobnie jak w większości krajów UE, ochrona praw autorskich przysługuje wyłącznie dziełom stworzonym przez człowieka. Kod wygenerowany w całości przez AI może nie korzystać z żadnej ochrony prawnoautorskiej. Twoja umowa powinna zawierać postanowienia dotyczące korzystania z narzędzi AI przez wykonawcę i jasno regulować odpowiedzialność w tym zakresie.

Co chronić w oprogramowaniu — kod źródłowy, dokumentacja, API

Wiele firm skupia się wyłącznie na kodzie źródłowym, zapominając, że oprogramowanie to znacznie więcej. Dokumentacja techniczna — specyfikacje, diagramy architektury, podręczniki użytkownika — korzysta z ochrony praw autorskich jako utwór literacki. Jeśli twoja umowa nie obejmuje przeniesienia praw do dokumentacji, możesz otrzymać gotowy system, ale bez możliwości legalnego korzystania z jego dokumentacji.

Interfejsy API to szczególnie wrażliwy obszar. Wyrok Trybunału Sprawiedliwości UE w sprawie Oracle v. Google zmienił sposób, w jaki myślimy o ochronie API. Zasadniczo sama struktura i funkcjonalność API nie podlega ochronie praw autorskich, ale konkretna implementacja już tak. Jeśli twoja umowa przewiduje tworzenie API, powinieneś zadbać o odpowiednie zapisy dotyczące własności interfejsów i dokumentacji.

Nie zapominaj o bazie danych — zarówno strukturze bazy danych, jak i jej zawartości. Europejskie prawo przewiduje odrębną ochronę baz danych (prawo sui generis), niezależną od praw autorskich. Twoja umowa IT powinna wyraźnie określać, kto jest właścicielem bazy danych i kto ma prawo do wyodrębniania i wtórnego wykorzystania jej zawartości.

Pamiętaj też o tajemnicy przedsiębiorstwa. Algorytmy, logika biznesowa, metody przetwarzania danych — wszystko to może stanowić tajemnicę przedsiębiorstwa chronioną ustawą o zwalczaniu nieuczciwej konkurencji. Umowa IT powinna zawierać solidne klauzule poufności (NDA) obejmujące zarówno okres realizacji projektu, jak i czas po jego zakończeniu.

NIS2, AI Act i RODO w kontraktach IT — nowe obowiązki prawne

Dyrektywa NIS2, implementowana do polskiego prawa, znacząco rozszerzyła obowiązki cyberbezpieczeństwa. Jeśli zamawiasz oprogramowanie dla firmy działającej w sektorze kluczowym lub ważnym (energetyka, transport, bankowość, ochrona zdrowia, infrastruktura cyfrowa), twoja umowa IT musi uwzględniać wymagania bezpieczeństwa wynikające z NIS2. Wykonawca powinien być zobowiązany do stosowania odpowiednich środków technicznych i organizacyjnych, a umowa powinna przewidywać audyty bezpieczeństwa i obowiązki raportowania incydentów.

W Kancelarii Cenkier w Lublinie doradzamy firmom w zakresie compliance NIS2 i przygotowywania kontraktów, które uwzględniają nowe wymogi. To nie jest opcja — to obowiązek prawny, którego naruszenie grozi poważnymi sankcjami finansowymi.

AI Act — rozporządzenie UE o sztucznej inteligencji — wchodzi w życie stopniowo od 2024 roku. Jeśli zamawiasz lub tworzysz systemy AI lub systemy zawierające komponenty AI, twoja umowa musi adresować klasyfikację ryzyka systemu, wymagania dotyczące przejrzystości, obowiązki dokumentacyjne oraz odpowiedzialność za decyzje podejmowane przez AI. Prawnik specjalizujący się w prawie IT powinien pomóc ci ocenić, czy twój system AI należy do kategorii wysokiego ryzyka i jakie niesie to konsekwencje kontraktowe.

RODO — Ogólne Rozporządzenie o Ochronie Danych — to kolejny obszar, który musi znaleźć odzwierciedlenie w umowie IT. Jeśli twoje oprogramowanie przetwarza dane osobowe, umowa powinna zawierać umowę powierzenia przetwarzania danych osobowych (art. 28 RODO). Wykonawca jako podmiot przetwarzający musi spełniać określone wymagania bezpieczeństwa. Brak umowy powierzenia to naruszenie RODO — zarówno po stronie zamawiającego, jak i wykonawcy.

Escrow kodu źródłowego — zabezpieczenie przed zniknięciem wykonawcy

Wyobraź sobie, że twoja firma jest uzależniona od systemu ERP stworzonego przez zewnętrzny software house. Wykonawca nagle ogłasza upadłość lub po prostu zamyka działalność. Nie masz dostępu do kodu źródłowego — masz tylko działającą aplikację. Co robisz? Nie możesz samodzielnie naprawić błędów, rozwijać systemu ani przenieść go do innego wykonawcy.

Escrow kodu źródłowego to rozwiązanie właśnie na takie sytuacje. Polega na tym, że kod źródłowy (wraz z dokumentacją, narzędziami do budowania itp.) jest przekazywany do niezależnego podmiotu — agenta escrow — który przechowuje go i zobowiązuje się do przekazania zamawiającemu w określonych przypadkach (tzw. release events). Release events to zazwyczaj: ogłoszenie upadłości wykonawcy, zaprzestanie utrzymania systemu, naruszenie warunków umowy.

Umowa escrow powinna precyzować, co dokładnie jest przedmiotem depozytu, jak często jest aktualizowany, jakie dokumenty potwierdzają jego aktualność oraz szczegółowe warunki udostępnienia zamawiającemu. To koszt, który warto ponieść w przypadku systemów krytycznych dla działalności firmy. Pamiętaj, że bez escrow twoja pozycja negocjacyjna wobec wykonawcy jest znacznie słabsza — jesteś od niego całkowicie uzależniony.

W ramach doradztwa prawnego w zakresie umów IT pomagam klientom nie tylko negocjować umowy escrow, ale też oceniać, które projekty wymagają tego rodzaju zabezpieczenia. Nie każde oprogramowanie wymaga escrow — ale systemy krytyczne, takie jak platformy sprzedażowe, systemy ERP czy oprogramowanie produkcyjne, zdecydowanie tak.

SLA, kary umowne i limity odpowiedzialności — jak chronić firmę

Service Level Agreement (SLA) to jeden z najważniejszych elementów umowy IT dotyczącej utrzymania i serwisu oprogramowania. SLA określa parametry jakości usługi — dostępność systemu (uptime), czasy reakcji na zgłoszenia, czasy naprawy błędów różnych kategorii. Bez SLA nie masz żadnych podstaw prawnych do reklamowania niskiej jakości wsparcia technicznego.

Typowe parametry SLA to dostępność systemu na poziomie 99,5% lub 99,9%, czas reakcji na incydenty krytyczne (np. 1 godzina), czas naprawy incydentów krytycznych (np. 4 godziny), czas naprawy błędów standardowych (np. 3 dni robocze). Każde naruszenie parametrów SLA powinno wiązać się z automatyczną karą umowną lub uprawnieniem do odstąpienia od umowy po określonej liczbie naruszeń.

Kary umowne to skuteczne narzędzie motywacyjne — ale muszą być skalibrowane. Kara zbyt niska nie motywuje do terminowego działania, kara zbyt wysoka może być uznana za nadmierną i obniżona przez sąd. Rekomendują karę za każdy dzień opóźnienia w dostawie lub naprawie błędu, z górnym limitem (np. 20-30% wartości kontraktu). Pamiętaj też, że zastrzeżenie kary umownej nie wyklucza dochodzenia odszkodowania uzupełniającego — chyba że umowa zawiera klauzulę wyłączną.

Limity odpowiedzialności to z kolei zabezpieczenie po stronie wykonawcy. Software house'y standardowo próbują ograniczyć swoją odpowiedzialność do wartości wynagrodzenia z umowy lub jej określonego wielokrotności. To może być akceptowalne — ale tylko jeśli nie obejmuje odpowiedzialności za rażące niedbalstwo, umyślne działanie lub naruszenie danych osobowych. Absolutnie nie zgadzaj się na wyłączenie odpowiedzialności za szkody spowodowane naruszeniem RODO — to może narazić cię na odpowiedzialność wobec osób, których dane zostały naruszone.

Praktyczne przykłady niebezpiecznych zapisów umownych w kontraktach IT

Przez lata praktyki widziałam setki umów IT. Chcę podzielić się konkretnymi przykładami zapisów, które powinny zapalić czerwoną lampkę. Pierwszy przykład: klauzula przyznająca jedynie niewyłączną, nieprzenoszalną licencję na korzystanie z oprogramowania. Ten zapis oznacza, że nie możesz przekazać oprogramowania nowemu właścicielowi firmy w przypadku sprzedaży, nie możesz przenieść licencji na spółkę zależną, a po wygaśnięciu umowy możesz stracić prawo do korzystania z systemu.

Drugi przykład: klauzula zobowiązująca zamawiającego do niekorzystania z usług podmiotów konkurencyjnych wobec wykonawcy przez 3 lata od zakończenia umowy. To zakaz konkurencji po stronie zamawiającego — rzadki, ale spotykany. W praktyce oznacza, że po zakończeniu współpracy z jednym software house'em przez trzy lata nie możesz zlecić żadnego projektu IT innej firmie z tej samej branży. To absurdalne ograniczenie, na które nie powinieneś się zgadzać.

Trzeci przykład: wymóg, że wszelkie zmiany w oprogramowaniu wymagają zgody wykonawcy — nawet jeśli prawa do kodu zostały przeniesione. To próba zachowania kontroli nad kodem pomimo przeniesienia praw. Czwarty przykład: jednostronne uprawnienie wykonawcy do zmiany wynagrodzenia z zachowaniem 30-dniowego okresu wypowiedzenia — szczególnie niebezpieczne w przypadku systemów abonamentowych, gdzie zmiana warunków w połowie projektu może zdestabilizować budżet. W Kancelarii Cenkier każdą taką klauzulę analizujemy pod kątem jej skuteczności prawnej i propozycji bezpieczniejszej alternatywy.

Prawo IT Lublin — jak Kancelaria Cenkier może pomóc Twojej firmie

Prawo IT to dziedzina, która łączy prawo autorskie, prawo umów, prawo ochrony danych osobowych, prawo nowych technologii i coraz szerzej — regulacje takie jak NIS2 czy AI Act. To wymaga specjalistycznej wiedzy i doświadczenia w pracy z firmami technologicznymi. W Kancelarii Cenkier Lublin oferuję kompleksowe wsparcie w zakresie umów IT — od analizy i negocjacji, przez tworzenie szablonów umownych, po reprezentację w sporach z wykonawcami oprogramowania.

Pomagam zarówno firmom zamawiającym oprogramowanie (zabezpieczenie praw do kodu, SLA, escrow), jak i firmom tworzącym oprogramowanie (ochrona własnej własności intelektualnej, ograniczenie odpowiedzialności, jasne określenie zakresu prac). Doradzam też w kwestiach compliance — RODO w kontekście IT, NIS2, przygotowanie do wymagań AI Act.

Jeśli masz umowę IT do sprawdzenia, planujesz projekt software'owy lub prowadzisz spór z wykonawcą oprogramowania — skontaktuj się ze mną. Kancelaria Cenkier mieści się w Lublinie przy ul. Krótkiej 4/3 (20-077 Lublin). Telefon: +48 792 911 906, e-mail: kancelaria@cenkier.pl. Analiza umowy IT to inwestycja, która może zaoszczędzić ci wielokrotnie więcej niż kosztuje.

Branża IT zmienia się w zawrotnym tempie. Prawo IT musi za nią nadążać. Każda umowa IT to dokument, który będzie regulował współpracę przez miesiące lub lata — warto zadbać, by był napisany tak, by chronić twoje interesy, a nie tworzyć pułapki, z których wyjście kosztuje fortunę.