Kancelaria prawna IT w Poznaniu – umowy, kod i dane

Dla kogo jest ta strona

Ta strona jest dla firm i osób, które mają problem prawny wynikający z projektu informatycznego. Najczęściej zgłaszają się software house'y i agencje, które podpisały umowę wdrożeniową i utknęły na odbiorze; zamawiający, którym wdrożenie się opóźnia albo nie działa zgodnie z ofertą; startupy przed rundą finansowania; oraz firmy, które kupiły oprogramowanie i dopiero po fakcie zorientowały się, że nie mają do niego praw.

Kancelaria mieści się w centrum Poznania, przy ul. Solnej 27/2. Obsługa branży IT nie wymaga jednak stałej obecności w jednym miejscu – dokumenty analizuje się na plikach, a spotkania można prowadzić zdalnie. Sprawy sądowe i zabezpieczenia toczą się przed sądem właściwym dla sprawy, którym dla przedsiębiorców z Poznania będzie zwykle Sąd Okręgowy w Poznaniu albo – w sprawach gospodarczych o niższej wartości – Sąd Rejonowy Poznań-Stare Miasto.

Warto od razu powiedzieć, czego na tej stronie nie ma. Nie jest to oferta doradztwa podatkowego ani rzecznictwa patentowego. Prawo IT w praktyce to w dużej części prawo umów, prawo autorskie, ochrona danych osobowych oraz spory gospodarcze – i w tym zakresie prowadzę sprawy osobiście.

Umowy w branży IT – co realnie decyduje o ryzyku

Spory w IT rzadko wynikają z tego, że ktoś złamał prawo. Zwykle wynikają z tego, że umowa nie odpowiadała na pytanie, które później okazało się kluczowe: kiedy praca jest wykonana, kto decyduje o zmianie zakresu i co się dzieje, gdy strony przestaną się zgadzać.

Umowa wdrożeniowa

Najważniejszym elementem nie jest opis funkcjonalności, lecz procedura odbioru. Jeśli umowa nie określa, ile dni zamawiający ma na zgłoszenie uwag, co się dzieje po bezskutecznym upływie tego terminu i czym różni się usterka blokująca od kosmetycznej, to każdy etap projektu może utknąć na czas nieokreślony. Druga typowa luka to brak zdefiniowanej procedury zmian (change request) – bez niej każda modyfikacja zakresu staje się przedmiotem negocjacji od zera.

Istotne jest też rozróżnienie, czy umowa jest umową o dzieło, czy o świadczenie usług. Ma to wpływ na odpowiedzialność za rezultat, na terminy przedawnienia i na to, czy zamawiający może odstąpić od umowy.

SaaS, utrzymanie i SLA

W modelu abonamentowym klient nie kupuje oprogramowania, lecz dostęp do usługi. Konsekwencje są praktyczne: liczy się dostępność, czas reakcji i czas naprawy, a nie przeniesienie praw autorskich. Warto sprawdzić, czy SLA zawiera realne mierniki i sankcje, czy przewiduje okna serwisowe, a przede wszystkim – co się dzieje z danymi klienta po zakończeniu umowy. Brak klauzuli o wydaniu danych w użytecznym formacie potrafi zablokować migrację do innego dostawcy.

Podwykonawcy i umowy B2B

Software house pracujący z programistami na kontraktach B2B ponosi wobec klienta odpowiedzialność za całość. Jeśli umowy z podwykonawcami nie przenoszą praw autorskich w tym samym zakresie, w jakim zostały obiecane zamawiającemu, powstaje luka: firma sprzedaje prawa, których sama nie nabyła. To jeden z najczęstszych problemów wychodzących przy due diligence przed transakcją albo przed rundą inwestycyjną.

Powierzenie przetwarzania danych

Gdy dostawca IT przetwarza dane osobowe w imieniu klienta, potrzebna jest umowa powierzenia. Nie jest to formalność do podpisania na końcu – określa ona zakres instrukcji, dopuszczalnych podwykonawców (podpowierzenie), lokalizację przetwarzania i obowiązki przy naruszeniu ochrony danych. Jej brak jest naruszeniem samodzielnym, niezależnym od tego, czy doszło do wycieku.

Prawa autorskie do kodu – najczęstszy błąd

To zagadnienie zasługuje na osobny akapit, bo powtarza się częściej niż jakiekolwiek inne. Zapłata za wykonanie oprogramowania nie oznacza automatycznego nabycia praw autorskich do niego. W relacji B2B prawa majątkowe przechodzą na nabywcę tylko wtedy, gdy umowa wyraźnie tak stanowi, na piśmie i z określeniem pól eksploatacji. Bez tego zamawiający otrzymuje w najlepszym razie licencję – a jej zakres bywa później przedmiotem sporu.

Inaczej wygląda to przy umowie o pracę: majątkowe prawa autorskie do programu komputerowego stworzonego przez pracownika w ramach obowiązków służbowych przysługują z mocy ustawy pracodawcy. Dlatego zespół zatrudniony na etatach i zespół pracujący na kontraktach B2B wymagają zupełnie innej dokumentacji, mimo że wykonują tę samą pracę.

W praktyce warto sprawdzić cztery rzeczy: czy umowa przenosi prawa czy udziela licencji; czy licencja jest wyłączna i czy jest wypowiadalna; czy nabywca otrzymał prawo do modyfikacji i tworzenia opracowań (bez tego nie może legalnie rozwijać kodu); oraz czy uregulowano prawa do dokumentacji, projektów graficznych i interfejsu. Osobno należy przejrzeć wykorzystane komponenty open source – niektóre licencje nakładają obowiązki, które kolidują z zamkniętym modelem dystrybucji.

Dane osobowe w projektach informatycznych

W projektach IT ochrona danych rzadko sprowadza się do polityki prywatności. Pierwsze pytanie brzmi, w jakiej roli występuje dana firma: administratora, który decyduje o celach przetwarzania, czy podmiotu przetwarzającego, który działa na polecenie klienta. Od tego zależy zakres obowiązków i odpowiedzialności.

Praktyczne obszary, w których najczęściej pojawiają się problemy, to: podstawa prawna przetwarzania w aplikacji i zgodność z informacją dla użytkownika; wykorzystywanie danych produkcyjnych w środowiskach testowych; transfer danych poza Europejski Obszar Gospodarczy przy korzystaniu z chmury; retencja i usuwanie kont; a także procedura na wypadek naruszenia ochrony danych, w tym termin zgłoszenia do organu nadzorczego.

Osobnym tematem jest wykorzystywanie narzędzi opartych na sztucznej inteligencji w procesie wytwarzania oprogramowania – zarówno pod kątem danych wprowadzanych do takich narzędzi, jak i praw do wygenerowanych fragmentów kodu. To obszar, w którym praktyka wciąż się kształtuje, dlatego ostrożniejsze zapisy umowne są tu zwykle lepsze od kategorycznych.

Startupy, inwestor i wycena oparta na prawach

Dla startupu technologicznego dokumentacja praw do kodu jest częścią wyceny. Inwestor sprawdza, czy spółka rzeczywiście posiada to, co sprzedaje: czy prawa autorskie zostały skutecznie przeniesione od założycieli i podwykonawców, czy nie ma zaległych roszczeń byłych współpracowników, czy znaki towarowe i domeny należą do spółki, a nie do prywatnych osób.

Typowa ścieżka to term sheet, następnie badanie prawne i dopiero umowa inwestycyjna. Warto pamiętać, że term sheet bywa w części wiążący – zwłaszcza w zakresie wyłączności negocjacji i poufności. Szerzej o samym procesie transakcyjnym piszę na stronie o inwestycjach kapitałowych.

Przed rozmową z inwestorem opłaca się uporządkować dokumenty wcześniej. Braki w łańcuchu praw autorskich prawie zawsze da się naprawić, ale koszt i czas naprawy rosną, gdy robi się to pod presją terminu zamknięcia rundy.

Spory w projektach IT

Konflikt w projekcie informatycznym rozwija się zwykle według powtarzalnego schematu: opóźnienie, odmowa odbioru, wstrzymanie płatności, wezwanie do zapłaty, naliczenie kar umownych, odstąpienie od umowy. Na każdym z tych etapów zapisy umowy przesądzają o pozycji stron mocniej niż argumenty o jakości pracy.

Co ma znaczenie dowodowe: korespondencja projektowa, zgłoszenia w systemie ticketowym, protokoły odbioru i zapisy ze spotkań. W sporach IT to zwykle materiał kluczowy, dlatego warto zabezpieczyć go, zanim dostęp do systemu zostanie odcięty. Historia repozytorium i logi wdrożeń pozwalają zweryfikować, kiedy i w jakim zakresie prace faktycznie wykonano.

Nie każdy spór wymaga procesu. Część spraw kończy się na etapie wezwania i renegocjacji, zwłaszcza gdy obie strony mają interes w dokończeniu wdrożenia. Gdy jednak sprawa dotyczy niezapłaconych faktur, ścieżka bywa prostsza, niż się wydaje – opisuję ją na stronie o windykacji B2B. Przed rozpoczęciem współpracy z nowym kontrahentem warto natomiast wykonać weryfikację kontrahenta, bo najskuteczniejszą windykacją jest ta, której nie trzeba prowadzić.

Klauzule, o które toczy się najwięcej sporów

W umowach IT niemal cały spór koncentruje się wokół kilku zapisów. Warto przeczytać je uważnie przed podpisaniem, bo później są nienegocjowalne:

• Procedura odbioru – terminy, skutek milczenia zamawiającego, klasyfikacja usterek.
• Change request – kto zatwierdza zmianę zakresu i jak wpływa ona na termin oraz wynagrodzenie.
• Ograniczenie odpowiedzialności – limit kwotowy, wyłączenie utraconych korzyści; granicą jest tu bezwzględnie wina umyślna.
• Kary umowne – za co dokładnie, w jakiej wysokości i czy zastrzeżono możliwość dochodzenia odszkodowania ponad karę.
• Prawa autorskie – przeniesienie czy licencja, pola eksploatacji, prawo do modyfikacji.
• Poufność i zakaz konkurencji – zakres, czas trwania, a przy zakazie konkurencji także ekwiwalent.
• Escrow kodu źródłowego – kto ma dostęp do depozytu i w jakich sytuacjach może go uruchomić.
• Wyjście z umowy – wypowiedzenie, odstąpienie, wydanie danych i dokumentacji, wsparcie w okresie przejściowym.

Checklista przed podpisaniem umowy IT

Zestaw pytań, który wyłapuje większość ryzyk w kilkanaście minut lektury:

1. Czy z umowy wynika jednoznacznie, kiedy praca jest uznana za wykonaną?
2. Czy prawa autorskie są przenoszone, czy licencjonowane – i czy obejmują prawo do modyfikacji?
3. Czy łańcuch praw od podwykonawców pokrywa to, co obiecano zamawiającemu?
4. Czy istnieje procedura zmiany zakresu i czy określa wpływ na termin?
5. Czy odpowiedzialność jest ograniczona i czy limit jest realny wobec wartości projektu?
6. Czy kary umowne są symetryczne i policzalne?
7. Czy przewidziano wydanie danych oraz dokumentacji przy zakończeniu współpracy?
8. Czy zawarto umowę powierzenia przetwarzania danych, jeśli jest potrzebna?
9. Czy uregulowano komponenty open source i licencje osób trzecich?
10. Czy wskazano prawo właściwe i sąd – a przy kontrahencie zagranicznym, czy będzie wykonalne?

Kontrahent zagraniczny

Przy współpracy z podmiotem z innego kraju dwie klauzule decydują o tym, czy umowa jest wykonalna: prawo właściwe i jurysdykcja. Wyrok wygrany przed sądem, którego orzeczenia trudno wykonać w kraju siedziby dłużnika, ma ograniczoną wartość praktyczną. W obrocie w Unii Europejskiej egzekucja jest zwykle prostsza; poza nią należy sprawdzić, czy istnieje podstawa do uznania orzeczenia.

Osobno warto rozważyć zapis arbitrażowy. Bywa szybszy i bardziej poufny, ale też kosztowniejszy, i nie w każdej sprawie się opłaca. Przy umowach o niskiej wartości klauzula arbitrażowa potrafi skutecznie zniechęcić do dochodzenia roszczenia – co czasem jest właśnie intencją strony, która ją proponuje.

Znaczenie ma też język umowy. Jeśli obowiązują dwie wersje językowe, umowa powinna wskazywać, która jest rozstrzygająca – inaczej rozbieżność tłumaczenia staje się samodzielnym przedmiotem sporu.

Fixed price czy time and material

Model rozliczenia projektu jest decyzją prawną, nie tylko handlową, bo przesądza o tym, kto ponosi ryzyko niedoszacowania zakresu.

W modelu fixed price wykonawca bierze na siebie ryzyko, że prac będzie więcej, niż założono. Ten model wymaga precyzyjnego opisu przedmiotu umowy i działającej procedury zmian – bez nich każde nowe wymaganie staje się sporem o to, czy mieści się w cenie. Sprawdza się przy projektach o dobrze określonych granicach.

W modelu time and material ryzyko przechodzi na zamawiającego, który płaci za faktycznie poświęcony czas. Tutaj kluczowe są zapisy o raportowaniu, limicie budżetu i obowiązku ostrzeżenia o jego przekroczeniu. Umowa bez pułapu kosztów bywa dla zamawiającego trudna do kontrolowania.

Spotyka się także rozwiązania mieszane: stawka godzinowa z górnym limitem albo etap analizy rozliczany osobno, a wdrożenie ryczałtem po ustaleniu zakresu. To ostatnie podejście usuwa najczęstszą przyczynę sporów, bo cenę ustala się wtedy, gdy obie strony wiedzą już, co jest do zrobienia.

Jak wygląda pierwszy kontakt

Przy analizie umowy wystarczy zwykle sam dokument i krótka informacja o roli, w jakiej występuje firma – wykonawcy czy zamawiającego – oraz o tym, na jakim etapie jest projekt. Odpowiedź obejmuje wskazanie zapisów ryzykownych i propozycję zmian.

Przy sporze przydatne są od początku: umowa z załącznikami, korespondencja dotycząca zgłoszeń i odbiorów, faktury oraz informacja o terminach, które już upłynęły. Jeśli w sprawie pojawiło się pismo z sądu albo wezwanie z terminem, warto podać ten termin w pierwszej wiadomości – determinuje on kolejność działań.

Przed rozpoczęciem pracy ustalam zakres analizy, dokumenty do przejrzenia i model wynagrodzenia. Pierwsza rozmowa służy ocenie, czy sprawa mieści się w zakresie, w którym mogę realnie pomóc.

Granice tej obsługi

Uczciwie o zakresie. Nie prowadzę doradztwa podatkowego – kwestie IP Box, stawek ryczałtu dla programistów czy rozliczeń transgranicznych należą do doradcy podatkowego. Nie jestem rzecznikiem patentowym, więc zgłoszenia patentowe i rejestracje znaków towarowych prowadzą rzecznicy; mogę natomiast zająć się umowami dotyczącymi tych praw oraz sporami o ich naruszenie.

Nie wykonuję audytów bezpieczeństwa ani testów penetracyjnych – to praca dla specjalistów technicznych. Mogę uczestniczyć w takim procesie po stronie prawnej: ocenić obowiązki wynikające z umowy i przepisów o ochronie danych oraz przygotować dokumentację.

Sprawy prowadzę osobiście. W sytuacjach wymagających szczególnej specjalizacji korzystam ze współpracy z innymi prawnikami wyspecjalizowanymi w danej dziedzinie, o czym informuję przed rozpoczęciem pracy.

Pięć najczęstszych błędów

1. Założenie, że faktura przenosi prawa autorskie. Nie przenosi. Potrzebna jest umowa na piśmie z określonymi polami eksploatacji.
2. Rozpoczęcie prac przed podpisaniem umowy. Przy sporze o zakres nie ma wtedy punktu odniesienia, a strony przedstawiają dwie różne wersje ustaleń.
3. Brak procedury odbioru. Projekt utyka na etapie, w którym nikt nie potrafi wskazać, czy termin został naruszony.
4. Kopiowanie umowy z innego projektu. Wzorzec z wdrożenia nie działa dla SaaS, a wzorzec B2B nie zastąpi umowy powierzenia danych.
5. Zwlekanie z zabezpieczeniem dowodów. Po odcięciu dostępu do repozytorium i systemu zgłoszeń odtworzenie przebiegu projektu jest znacznie trudniejsze.

Najczęstsze pytania

Czy zapłata za wykonanie oprogramowania oznacza, że mam do niego prawa autorskie?

Nie. W relacji B2B prawa majątkowe przechodzą na nabywcę tylko wtedy, gdy umowa wyraźnie to przewiduje – na piśmie i ze wskazaniem pól eksploatacji. Bez takiego zapisu zamawiający zwykle uzyskuje jedynie licencję, której zakres bywa później sporny. Inaczej jest przy umowie o pracę: prawa do programu stworzonego przez pracownika w ramach obowiązków przysługują z mocy ustawy pracodawcy.

Czy do umowy z software house'em potrzebna jest umowa powierzenia danych?

Jeżeli dostawca będzie przetwarzał dane osobowe w imieniu klienta – na przykład utrzymując system z danymi użytkowników – to tak. Umowa powierzenia określa zakres polecenia, dopuszczalne podpowierzenie, lokalizację przetwarzania i obowiązki przy naruszeniu ochrony danych. Jej brak stanowi naruszenie niezależnie od tego, czy doszło do wycieku.

Zamawiający nie chce odebrać wdrożenia. Co zrobić?

Kluczowe jest to, co umowa mówi o procedurze odbioru: jaki jest termin na uwagi, jaki jest skutek jego bezskutecznego upływu i jak klasyfikowane są usterki. Następnie należy zabezpieczyć korespondencję, zgłoszenia i protokoły. Dopiero na tej podstawie można ocenić, czy zasadne jest wezwanie, naliczenie odsetek, czy odstąpienie od umowy.

Czy karę umowną z umowy IT można obniżyć?

Tak, sąd może zmniejszyć karę umowną – w szczególności gdy zobowiązanie zostało w znacznej części wykonane albo gdy kara jest rażąco wygórowana. Ocena jest jednak indywidualna i zależy od wartości umowy, stopnia wykonania prac oraz rozmiaru szkody.

Czy prowadzicie sprawy podatkowe programistów, na przykład IP Box?

Nie. Rozliczenia podatkowe, w tym IP Box, należą do doradcy podatkowego. Mogę natomiast zająć się dokumentacją praw autorskich i konstrukcją umów, na których takie rozliczenie się opiera.

Czy sprawę można prowadzić bez wizyty w Poznaniu?

W dużej mierze tak. Analiza umów, opinie i przygotowanie dokumentów odbywają się na plikach, a spotkania mogą mieć formę rozmowy telefonicznej lub wideokonferencji. Rozprawy toczą się przed sądem właściwym dla sprawy; obecność klienta nie zawsze jest przy nich konieczna, co zależy od rodzaju postępowania i decyzji sądu.

Ile kosztuje obsługa prawna projektu IT?

Zależy od zakresu. Analiza pojedynczej umowy rozliczana jest zwykle ryczałtem, stała obsługa – w modelu abonamentowym lub godzinowym, a spory sądowe według stawki ustalanej indywidualnie z uwzględnieniem wartości sprawy. Zakres i model rozliczenia ustalam przed rozpoczęciem pracy.