Łukasz Kulicki - kwestie prawne w IT

Cześć, z tej strony Łukasz Kobyliński. Witajcie w kolejnym odcinku podcastu „Stacja IT”. Dziś jest z nami Łukasz Kulicki i poruszymy tematykę prawa w IT.
Łukasz, powiedz kilka słów o sobie. Dlaczego zajmujesz się prawem w IT? Skąd ta ścieżka kariery?

Cześć. Dziękuję za zaproszenie, szczególnie że jest to mój pierwszy podcastowy występ, więc tym bardziej jest mi miło. Jestem radcą prawnym. Od pięciu, sześciu lat prowadzę kancelarię prawną, która specjalizuje się głównie w obsłudze prawnej firm działających na rynku nowych technologii. Są to m.in. start-upy, firmy technologiczne i IT. Natomiast większość moich klientów to są właśnie firmy działające na rynku programistycznym i są to głównie programiści oraz software house’y.

Jak to się zaczęło? Czy to, że pierwsi klienci byli z IT, to był przypadek, czy to było zaplanowane?

Muszę przyznać, że samo IT było dosyć przypadkowe, aczkolwiek gdy robię sobie retrospektywę, to okazuje się, że to nie był przypadek. Natomiast rzeczywiście zakładając jeszcze wtedy z moim wspólnikiem kancelarię, postanowiliśmy, że chcemy działać na ciekawym rynku i wybraliśmy rynek start-upowy. Sześć lat temu na polskim rynku jeszcze niespecjalnie popularny był taki termin jak start-up. Wówczas wszyscy to sobie inaczej tłumaczyli. Inwestorów nie było tak dużo. Rynek wyglądał zupełnie inaczej. My na tym rynku warszawskim byliśmy jedną z pierwszych takich kancelarii, które w tym się specjalizowały. Dopiero potem nastąpił bum na to wszystko, także w kancelariach prawnych, gdy prawnicy zaczęli się tym interesować. Natomiast u nas w kancelarii podział był taki, że mój wspólnik zajmował się umowami inwestycyjnymi, a ja zajmowałem się rzeczami związanymi z e-commerce’em, z ochroną danych osobowych, z pisaniem różnych innych umów, innych niż te inwestycyjne.

I w pewnym momencie samo wyszło, że ta multidyscyplinarność znalazła wspólny mianownik w umowach, kontraktach IT. Na początku nie przeszkadzało mi, że zajmowałem się trochę tym, trochę tamtym, np. ochroną danych osobowych, by za chwilę pisać jakąś umowę o dzieło na stronę internetową. Rozstrzał był dosyć szeroki, dopóki samo mi się to nie spięło w tych kontaktach IT. Więc jeśli chodzi o zainteresowanie tą tematyką, to historia wygląda właśnie tak. I można powiedzieć, że moją główną specjalizacją są teraz szeroko pojęte kontrakty IT. I od ponad trzech lat zajmuję się już tylko tym.

Powiedziałeś „kontrakty IT”. Czy należy je rozumieć jako umowy B2B między firmami, czy to może dotyczyć też indywidualnych osób?

Może to dotyczyć indywidualnych osób, bo przez „kontrakt” rozumiem po prostu umowę. Zdarza się, – chociaż bardzo rzadko – że zamawiający to firma, natomiast wykonawca jest programistą, który nie prowadzi działalności gospodarczej. Wtedy jest to kontrakt także pomiędzy zwykłą osobą fizyczną. Natomiast 99% umów IT stanowią umowy B2B.

Jaki jest najczęstszy typ umowy, którym się zajmujesz? Czy to jest zamówienie jakiegoś software’u od firmy, która jest wytwórcą?

Zasadniczo przedmiotem umowy jest zawsze dostarczenie jakiegoś oprogramowania. Natomiast różne są modele tego kontraktowania. Bo ten rynek bardzo się zmienił w ciągu tych trzech, czterech ostatnich lat. Mamy dwa główne podejścia do kontraktowania IT. Pierwsze to umowy o dzieło, czyli tzw. umowy wdrożeniowe, w których przedmiotem umowy jest wykonanie jakiegoś programu komputerowego. Drugie podejście polega na świadczeniu usług programistycznych i jest to umowa zlecenie. W umowie o dzieło liczy się efekt, a w umowie zlecenie tego efektu finalnego nie ma, liczy się natomiast ta należyta staranność wykonywania usług.

Czy w związku z tym, że sfokusowałeś się na branży IT, widzisz w niej jakąś specyfikę w porównaniu z innymi branżami, w których działają inne kancelarie? Czy to, że działasz na tym rynku o kilku lat, powoduje, że lepiej ją rozumiesz i zauważasz w niej jakieś specyficzne kwestie, którymi warto się zająć w kontekście IT?

Pierwszą barierą jaką napotykam jako prawnik wkraczający do branży IT – a tych prawników wkracza do tej branży coraz więcej i uważam, że dobrze, bo ta branża potrzebuje osób, które na tych kwestiach się znają – jest taka specyficzna mowa programistów. Ciężko to na początku zrozumieć. Natomiast to, co mnie bardzo zaskoczyło, chociaż może nie powinno, to duża otwartość programistów, by dzielić się wiedzą. Ja od swoich klientów wyciągnąłem bardzo dużo wiedzy, bardzo chętnie się dzielili i mam wrażenie, że byli zadowoleni, że ktoś z zewnątrz o to pyta, a w dodatku prawnik. Natomiast inną kwestią jest to, aby prawnicy do tej branży IT wchodzili. Bo rzeczywiście jest tak, że niestety programiści uważają, że te kwestie prawne można odłożyć na później i skoro potrafią napisać kod, to napiszą też umowę. To jest jeden z kardynalnych błędów, z których wywodzi się potem wiele innych. Natomiast programiści to taka grupa, która szybko dochodzi do wniosku, że jak już raz popełnili błąd, mając złą umowę, projekt im nie wyszedł, ktoś im nie zapłacił czy sami napisali tę umowę, to przy drugim projekcie pójdą do prawnika i poproszą o umowę. Więc szybko uczą się na własnych błędach i dowiadują, że potrzebują fachowej pomocy. Jak robię jakieś szkolenie, prelekcję dla programistów, to pierwsze pytanie, które zadaję, to: „Czy znacie różnice między odstąpieniem od umowy a wypowiedzeniem?”. I to im pokazuje, że to jest wiedza, której nie mają, a jest ona kluczowa do tego, żeby ich biznes rozwijał się prawidłowo, był odpowiednio zabezpieczony.

Niestety większość software house’ów skupia się na tym, żeby sprzedawać. Napędzają sobie tę sprzedaż. I poniekąd słusznie, bo żeby rozwijać firmę, trzeba sprzedawać. Natomiast zapominają o tym, że jeżeli nie będą mieli w ogóle umowy, co jest bardzo częste, albo będą mieli kiepską umowę, to jak ta kiepska umowa trafi na ich największy projekt, który aktualnie realizują, to może być to przyczyną upadku firmy lub dużych problemów w firmie.

Czy nawet jak dajesz programistom wzór czy propozycję umowy, to się częściej wtrącają w jej treść niż ludzie w innych branżach? Czy są w stanie zaakceptować jakieś propozycje?

Można powiedzieć, że ludzie nie czytają umów. Natomiast programiści zasadniczo czytają te umowy. I zawsze ciekawe jest to, że my przesyłamy umowę w jakimś pliku wordowskim, ona automatycznie wrzucana jest na jakąś chmurę, np. Google Docs. I ja widzę w czasie rzeczywistym, że ten klient czyta tę umowę, komentuje ją i przykłada się do tego. Więc taka może być różnica pomiędzy programistami a klientami z innych branż.

Czyli taki trudny klient, ale wdzięczny, chce współpracować i się angażuje?

Nie powiedziałbym, że trudny, ale zaangażowany. Niestety bywa też tak, że klient przychodzi z zapotrzebowaniem na jedną umowę, my ją piszemy, a nagle okazuje się, że trzeba ją zmodyfikować i napisać kolejny typ umowy, potem kolejny i kolejny. I tak, drobnymi krokami, ten klient zbiera swój pakiet umów, który jest mu potrzebny w jego działalności.

A czy sama specyfika branży wpływa jakoś na to, że czegoś musiałeś się nauczyć, stosując rozwiązania prawnicze? Bo pojawia się tu chociażby kwestia licencji na oprogramowanie, praw autorskich. Wydaje się, że w tym obszarze dużo jest takich rzeczy, które niekoniecznie pojawiają się gdzieś indziej, np. w sferze produkcji.

Kontrakty IT to są takie kontrakty, do których trzeba wrzucić wiele różnych elementów. Coś z kodeksu cywilnego, coś z ustawy o prawie autorskim. Trzeba mieć wiedzę z kilku różnych dziedzin. Teraz dochodzą dane osobowe. Więc pod tym względem jest to specyficzna branża.

Powiedzieliśmy o najczęstszych typach umów. Czy to jest tak, że firmy zwracają się do ciebie z prośbą o to, aby przygotować dobre umowy zlecenie, umowy o dzieło czy umowy typu B2B z wykonawcami, aby się zabezpieczyć w ten sposób, że to dzieło, które powstaje, jest przenoszone na firmę? Czy to są najczęstsze problemy, z którymi zwracają się do was firmy?

Myślę, że 70–80% klientów to są ci, którzy przychodzą i potrzebują albo przeanalizować umowę, którą właśnie położyli na stole, i zamawiają wykonawcę, albo ci, którzy chcą, aby napisać im umowę pod dany projekt. Coraz częściej zdarzają się też klienci, którzy przychodzą i mówią, że chcą napisać cały set swoich umów, które będą stosowali, bo np. od dwóch, trzech lat prowadzą software house, wcześniej korzystali ze wzorów umów, które sobie ściągnęli z Internetu, lub też własnymi siłami napisali takie umowy, składając je z kilku innych. A ostatni rodzaj klientów, który też się coraz częściej zdarza, to są ci, którzy przychodzą, bo mają jakiś problem wynikający z realizacji projektu IT. I ja bardziej profiluję się na prawnika, który obsługuje wykonawców niż zamawiających. Chociaż te proporcje też się oczywiście zmieniają, ale przez te lata mogę powiedzieć, że w branży IT większość moich klientów to są właśnie wykonawcy, software house’y.

Skoro obsługujesz najczęściej wykonawców, to co od strony wykonawcy jest najważniejsze w IT, żeby zabezpieczyć to w umowie? Jako wykonawcę rozumiemy najczęściej firmę, która dostarcza jakieś rozwiązanie, kod, usługę.

Do pewnego stopnia i wykonawcy, i zamawiającemu powinno zależeć na tym samym. I ta umowa powinna być jakoś wspólnie wypracowana. Mam tu na myśli w ogóle zasady realizacji projektu. Teraz na rynku jest moda na takie zwinne metodyki realizacji projektów IT. I najczęściej to, z czym się spotykam, to to, że przychodzi klient i mówi, że on pracuje w Agile’u i kropka. Natomiast gdybym wziął tu dziesięciu swoich klientów, 10 software house’ów, które obsługuję, i poprosił każdego z nich, żeby powiedział, czym dla niego jest Agile, to każdy powie co innego. Dlatego ta kwestia sposobu realizacji projektu IT, dokładnego opisania go w umowie to jest rzecz, na której powinno zależeć tak samo wykonawcy, jak i zamawiającemu, bo po pierwsze, z tego będą rozliczani, a po drugie – umowa ma być po prostu instrukcją do tego, jak realizować projekt IT. Nie chodzi o to, aby w trakcie realizacji prac zastanawiać się, czy zrobić tak, czy może inaczej. Chodzi o to, żeby ta umowa mówiła wprost o tym, jak się zachować w tego rodzaju sytuacji. Natomiast rzeczywiście są pewne specyficzne postanowienia, na których bardziej powinno zależeć wykonawcy, a są takie, na których bardziej powinno zależeć zamawiającemu. Jeśli chodzi o wykonawcę, to na pewno to są wszystkie kwestie związane z odpowiedzialnością – z ograniczeniem jego odpowiedzialności do jakiegoś poziomu. Można powiedzieć, że takim punktem wyjścia dla wykonawcy powinna być próba ograniczenia jego odpowiedzialności do stu procent wynagrodzenia, które dostaje.

Kolejnym postanowieniem, na którym powinno zależeć pracodawcy, to są postanowienia związane ogólnie z zabezpieczeniem jego płatności. I oczywiście można tu kombinować z różnymi rzeczami, z jakimiś kaucjami, gwarancjami, chociaż to przy dużych projektach IT ma zastosowanie. Przy mniejszych projektach, takich nawet za kilkaset tysięcy złotych czy do miliona złotych takich bardziej skomplikowanych zabezpieczeń nie spotkałem. Natomiast wykonawca ma jakieś narzędzia, żeby zmobilizować zamawiającego do tego, by to wynagrodzenie zapłacił. Jednym z nich jest chociażby zastrzeżenie w umowie momentu przeniesienia autorskich praw, które najczęściej w projektach się przenosi, na moment zapłaty wynagrodzenia. I to jest częsty błąd wykonawców, którzy te kwestie traktują tak trochę po macoszemu, a tu jest miejsce na to, żeby się zabezpieczyć. Dlatego że jeżeli ich klient, ich zamawiający nie dostanie tych autorskich praw majątkowych to tak naprawdę nie będzie mógł z wytworu pracy wykonawcy korzystać w sposób komercyjny. A często bywa tak, że zamawiający, klient jest podwykonawcą jakiegoś jeszcze większego podmiotu. Więc de facto nie będzie mógł skutecznie przenieść tych autorskich praw majątkowych na swojego klienta. I tworzy się takie domino.

Powiedziałeś o płatnościach, które mogą być rozłożone w czasie: jak to powiązać z tym, co powiedziałeś wcześniej o tym, że prawa autorskie mogą być przeniesione przy ostatniej płatności? Czy można te dwa elementy jakoś pogodzić?

Tak, przede wszystkim te autorskie prawa majątkowe można przenosić do tych utworów, które zostały wykonane w danym etapie. Czyli mamy podzieloną płatność na ileś część. Trzeba określić dokładną procedurę odbiorów, i co za tym idzie – procedurę testów tego oprogramowania przez zamawiającego. I po przejściu tej całej procedury można podpisać taki częściowy protokół odbioru do prac, które zostały wykonane w ramach danego etapu. Potem następuje płatność za ten etap. I dopiero w momencie płatności faktycznie te autorskie prawa majątkowe przechodzą na zamawiającego.

Czyli to jest od strony wykonawcy. Wykonawca musi zapewnić sobie kwestie płatności i takiego ułożenia sposobu pracy, który będzie odpowiadał obu stronom. A co od strony zamawiającego jest najczęstszym problemem, oprócz tego, żeby dostać odpowiedniej jakości usługę?

Z racji tego, że zamawiającemu powinno rzeczywiście zależeć na szybkiej realizacji tego projektu i tak jak wykonawcy powinno mu zależeć na dokładnym opisaniu modelu realizacji projektu, żeby móc ten projekt rzeczywiście dobrze realizować, wykonawcy zależy również na tym, by oprócz starania o to, aby oprogramowanie było dobre, co można potem potwierdzić procedurą testów, było dostarczone na czas. I z tym zasadniczo związana jest duża część negocjacji kontraktów IT, ponieważ zamawiający bardzo często próbuje stosować różnego rodzaju kary dla wykonawcy za opóźnienie w realizacji projektu. I zazwyczaj są to kary umowne za dzień, tydzień, miesiąc opóźnienia w realizacji projektu.

Powiedziałeś, że często pomagasz w przygotowaniu takich umów, które dotyczą pracy w trybie zwinnym. One są chyba trudniejsze niż umowy typu fixed price, w których wiadomo, że w jakimś terminie coś ma być dowiezione.

Przede wszystkim na rynku można usłyszeć, że teraz wszyscy pracują w Agile’u. To tak różowo niestety nie wygląda. Jeśli zasady współpracy rozłożymy na czynniki pierwsze, to okazuje się, że to jest standardowa umowa o dzieło z elementami tych metodyk zwinnych, po prostu z wrzuconymi rolami, sposobami realizacji projektu, np. w formie sprintu. Więc nie można powiedzieć, że na rynku tych umów agile’owych u tych małych czy średniej wielkości wykonawców jest sporo. Jest ich trochę. Natomiast nie jest ich dużo. To, co zauważam na rynku, to przejście z takiego modelu wykonywania projektów w trybie umów o dzieło, czyli że zamawiający wie, czego chce, daje specyfikację i wykonawca to robi. Rynek idzie raczej w takim kierunku, że zamawiający mniej więcej wie, czego chce, natomiast nie wie jeszcze, którą drogą będzie szedł do tego celu. I co więcej, strony z założenia przewidują, że ten cel końcowy może ulec modyfikacji. Więc jeśli tak rozumiemy te zwinne prace, to rzeczywiście tej zwinności trochę jest.

Natomiast ja tę zmianę w modelu kontraktowania nie upatrywałbym w tym, że nagle wszyscy odkryli, że praca w metodykach zwinnych jest efektywna czy modna, bo jest modna i być może jest efektywna w pewnych projektach. Osobiście upatrywałbym tego w tych zmianach rynkowych. Programistów mamy dosyć dużo, ale wciąż niestety zbyt mało, a zapotrzebowania na usługi programistów, nawet biorąc pod uwagę nasz polski rynek, jest bardzo dużo, żeby nie powiedzieć przeogromnie dużo. I co się teraz dzieje? Zamawiający szuka jakiegoś wykonawcy. Takiego, który będzie miał albo wolny termin, albo moce przerobowe. I żeby wybrać dobrego, sensownego wykonawcę, godzi się na jego warunki. I to otwiera pole dla wykonawców do tego, żeby troszkę odwrócić siły, które do tej pory na tym rynku obowiązywały. Czyli że tą silniejszą stroną był zamawiający. W negocjacjach czy w umowach, które my prowadzimy, udaje się negocjować takie warunki, nawet z dużymi zamawiającymi, które kilka lat temu byłyby nie do pomyślenia. I moim zdaniem to wynika z braku tych programistów na rynku, którzy z tego czynią jakąś broń i są w stanie pracować z ciekawymi klientami na równiejszych warunkach.

Co możemy ująć w ramę umów, które są niedoprecyzowane pod kątem efektu końcowego, są bardziej zwinne? Czy to łączny budżet, czy to sposób pracy, czy może jakieś kamienie milowe, które po drodze powstają? Jak w takim przypadku można podejść do tworzenia umowy?

Takie klasyczne umowy agile’owe to są takie umowy, w których ich przedmiotu nie mamy sprecyzowanego. Takie klasyczne umowy agile’owe to są umowy o świadczenie usług. Nie znamy w ogóle efektu końcowego. Wobec tego ciężko jest nam budżetować i przewidywać koszty tych poszczególnych etapów. I to są zazwyczaj umowy, które są rozliczane godzinowo. Najważniejszą rzeczą w takiej umowie jest opisanie sposobów współpracy stron i realizacji poszczególnych etapów realizacji poszczególnych sprintów.

Kolejnym ważnym postanowieniem w takiej umowie jest odbiór tych prac. I te wszystkie kwestie związane z własnością intelektualną, czy to przeniesienie autorskich praw majątkowych, czy to udzielenie licencji. Natomiast bezapelacyjnie najważniejszy jest dobry opis sposobu realizacji projektu i współdziałania stron.

Prześledźmy sobie pokrótce proces, przyjmując, że jesteśmy wykonawcą przymierzającym się do realizacji jakiegoś zlecenia dla zamawiającego. Czy zawsze potrzebujemy umowy? Czy zawsze ta umowa musi być spisana? – bo mamy coś takiego jak umowy ustne. I czy zawsze potrzebujemy prawnika, czy dopiero przy jakichś większych projektach? Jakie przesłanki ewidentnie wskazują na to, że potrzebujemy profesjonalnie przygotowanej, spisanej umowy? Dlaczego właśnie jest to lepiej i jakie daje nam to korzyści w stosunku do sytuacji, w której robimy to po uścisku dłoni kogoś, kogo powiedzmy znamy?

Jako prawnik będę się upierał w tym, że tego prawnika potrzebujemy może nie zawsze, ale prawie zawsze. Natomiast to wynika też z faktu, że koszt przygotowania tej umowy, analizy i modyfikacji jej przez prawnika jest niewspółmierny do tego, co może się stać, w przypadku gdy ten projekt IT nie wyjdzie, do tych kosztów, które trzeba będzie ponieść w przypadku porażki. A niestety prawdopodobieństwo, że dany projekt technologicznie nie wyjdzie, jest wysoki. I sporo tych projektów nie wychodzi z racji tego, że często strony nie wiedzą dokładnie, czego chcą. Na poziomie ogólnym się dogadują, natomiast na poziomie bardziej szczegółowym średnio. I w sytuacji, w której nie mamy wszystkiego doprecyzowanego w umowie, może dojść do dużego konfliktu. Więc ja będę upierał się w tym, że dobrze jest mieć u swego boku prawnika, bo to po prostu oszczędza koszt.

Jeśli chodzi o to, czy powinniśmy mieć umowę, to oczywiście umowa ustna obowiązuje w obrocie gospodarczym i takie umowy są na rynku IT bardzo często zawierane. Co tu dużo mówić. Niestety, na tym rynku często dochodzi do sytuacji, w której nie ma umowy. Albo dochodzi do sytuacji, w której umowa jest negocjowana w trakcie realizacji projektu. Sam w kilku takich sytuacjach brałem udział. I taka sytuacja jest zawsze lepsza dla wykonawcy, bo jak zamawiający jest w procesie realizacji projektu, a nie ma jeszcze umowy i zależy mu na tym, żeby ta umowa była podpisana, to jest bardziej skory do tego, żeby ustępować wykonawcy. Natomiast z umowami ustnymi jest ten problem, że ciężko jest czasem udowodnić, na co tak naprawdę strony się umówiły. Skoro umówiliśmy się ustnie, to łatwo takie ustalenia, słowo przeciwko słowu, podważyć. W obrocie gospodarczym funkcjonuje także tzw. forma dokumentowa oświadczeń woli. I możemy w ten sposób umówić się z kimś na realizację projektu IT, np. poprzez maila. Nie ma z tym żadnego problemu, i tak też się często dzieje. Natomiast w umowach IT jest szereg takich postanowień, które muszą być dokładnie określone, żeby były skuteczne, np. zasady współdziałania stron czy zasady realizacji projektu, zasada odbioru, testów, kwestia odpowiedzialności, kar umownych itd. Ciężko to wszystko zmieścić w jakiejś tam umowie ustnej czy mailowej. Więc pierwsza kwestia to to, że te umowy muszą być precyzyjne.

Drugą kwestią jest to, że niektóre czynności w tych umowach IT wymagają formy pisemnej – papierowej. Mam tu przede wszystkim na myśli przeniesienie autorskich praw majątkowych. Tutaj duże pole do popisu mają zamawiający. Dlatego że często jak dostaję umowę od zamawiającego, reprezentując wykonawcę, widzę klauzulę przeniesienia autorskich praw majątkowych na trzy, cztery zdania, co nie jest rzadkie, to wiem, że ten zamawiający niespecjalnie zna się na rzeczy w tym zakresie. Te klauzule przeniesienia autorskich praw majątkowych zazwyczaj są dużo dłuższe niż te kilka linijek. I zamawiający powinien zwrócić uwagę na moment przeniesienia autorskich praw majątkowych, na to, jakie utwory są przenoszone. Być może wykonawca wskaże, że korzysta z jakiegoś oprogramowania standardowego, co do którego tych autorskich praw majątkowych nie może przenieść czy nie przenosi, bo wykorzystał to także w innych projektach IT, ale także czy wykonawca udziela zezwoleń na wykonywanie praw zależnych, kwestie modyfikacji tego utworu i przede wszystkim kwestie tego, czy ta klauzula określa, na jakich polach eksploatacji ten utwór jest przenoszony.

To, co często widzę w umowach przesłanych przez zamawiających, to takie zdanie: „Utwór jest przenoszony na wszelkich możliwych polach eksploatacji” – to jest też bardzo duży błąd. Więc tutaj dużo więcej do stracenia ma zamawiający niż wykonawca. Bo tak naprawdę wykonawcy w takiej umowie powinno zależeć na tym, żeby ten moment przeniesienia autorskich praw majątkowych był dobrze określony. A czy reszta będzie zrobiona poprawnie, czy nie, to wykonawcy zazwyczaj już na tym nie zależy. Więc jeżeli zamawiający nie sformułuje precyzyjnie takiej klauzuli, to wykonawca mu w tym nie pomoże, bo to nie jest w jego interesie.

Czyli kwestia przeniesienia autorskich praw majątkowych musi mieć formę pisemną, bo inaczej jest nieważna.

Tylko forma pisemna. Nie można tego zrobić w żadnej innej firmie. To wynika po prostu z ustawy o prawie autorskim i prawach pokrewnych. Częstą praktyką – dużo moich klientów tak podpisuje umowy, także z klientami polskimi – jest korzystanie z jakichś systemów do zdalnego podpisywania, np. HelloSign, DocuSign czy polski produkt Autenti. To dla wykonawców jest superwygodne. Natomiast jeśli umowa oparta jest na prawie polskim i taka umowa została podpisana właśnie w taki sposób, to ta klauzula przeniesienia nie jest skuteczna. I na to zamawiający powinni zwracać szczególną uwagę.

To wydaje się superważne w kontekście IT, na ile mamy tu do czynienia z jakimś łańcuszkiem przenoszenia tych praw autorskich. Bo jeśli my jesteśmy software house’em i zatrudniamy programistów, to teraz musimy zadbać o to, żeby programiści przenosili prawa majątkowe na nas.

To jest szerszy problem. Dobrze, że poruszyłeś kwestie tego łańcuszka przenoszenia praw autorskich z podwykonawcami, bo to jest bardzo duży obszar, który jest zaniedbywany przez wykonawców. Na tym rynku software house’y zatrudniają w oparciu o umowę o współpracy. Czyli z punktu widzenia prawa to nie są ich pracownicy, tylko ich podwykonawcy. To jest niezależny przedsiębiorca, który świadczy usługi dla danego software house’u. I często jest tak, że software house ma superklauzulę przeniesienia autorskich praw majątkowych zamawiającym. Natomiast wobec swoich podwykonawców już w ogóle takich kwestii nie porusza albo porusza je w węższym zakresie niż ma to określone w swojej umowie z klientem końcowym. I to przekłada się także na inne postanowienia czy na sposób współpracy. Ale przede wszystkim powinno się przekładać na zakres odpowiedzialności, na kary umowne za opóźnienie, tak, żeby wykonawca miał jakieś roszczenie regresowe do swojego podwykonawcy, w przypadku gdy jego klient będzie dochodził jakichś roszczeń. Bo chodzi o to, żeby nie zamykać sobie drogi do tego, żeby te roszczenia odzyskać od swojego podwykonawcy. I to jest też bardzo częsty błąd, na który zwracam uwagę. Ta umowa z podwykonawcą powinna być bliźniacza do umowy z klientem końcowym.

Zostając jeszcze przy tym software housie, który ma pracowników, jakkolwiek rozumianych, to najczęstszym przypadkiem będzie umowa o dzieło i wtedy ona przenosi te autorskie prawa majątkowe.

Umowa o dzieło niekoniecznie musi wiązać się z przeniesieniem autorskich praw majątkowych. Żeby te przeniesienie nastąpiło, to musi być to wprost wskazane w umowie. Ale wyobraźmy sobie najprostszy przykład z możliwych: stworzenie strony internetowej. Takie stworzenie strony internetowej to jest część programistyczna, trzeba to wszystko zaprogramować, oraz graficzna. I można wyobrazić sobie sytuację, że wykonawca nie przenosi tych autorskich praw majątkowych. Wtedy zamawiający ma prawo do korzystania z tego egzemplarza, nie może go specjalnie modyfikować, odsprzedać dalej tego szablonu itd.

Natomiast rzeczywiście tych umów trochę jest. Idąc od początku: jest umowa o dzieło, taka klasyczna umowa wdrożeniowa. Jest umowa o świadczenie usług, do których stosuje się przepisy o zleceniu. Są to różnego rodzaju umowy utrzymaniowe, umowy na rozwój systemu, umowy SLA, które zasadniczo są też umowami zlecenia. Na tym rynku działają stricte takie umowy jak np. umowa o przeniesienie autorskich praw majątkowych do danego utworu czy umowa licencji dotycząca danego utworu. Najczęściej jest tak, że w jednej umowie mamy pomieszane kilka umów i wtedy trzeba rozróżnić, do której części umowy jakie przepisy w ogóle stosujemy. Bo często tak jest, że mamy umowę wdrożeniową, do której zasadniczo stosuje się przepisy dotyczące dzieła. Natomiast w tej umowie wdrożeniowej mamy wskazane kwestie dotyczące właśnie SLA. I do tych usług związanych z SLA raczej będziemy stosowali już przepisy o zleceniu, a do całości umowy, pozostałej części umowy – przepisy dotyczące dzieła.

Wrócę jeszcze do tego pracownika software house’u, z którym możemy mieć klasyczną umowę o pracę. Czy musimy w niej zadbać o to, żeby te prawa były przenoszone, czy to jest już w automacie?

Nie. Przy klasycznej umowie o pracę to jest już automat. Wynika to po prostu z kodeksu pracy. Te autorskie prawa majątkowe wykonane w ramach stosunku pracy przechodzą na pracodawcę. Więc tu pracodawca pod tym kątem, przy tej formie umowy jest zabezpieczony w najlepszy sposób.

I w przypadku umowy B2B, czyli ktoś ma działalność gospodarczą i współpracuje z firmą, to wtedy w tej umowie współpracy musimy te kwestie poruszyć.

Dokładnie.

Wiemy już, że umowa się często przydaje, że warto pracować z prawnikiem. A co w sytuacji, w której pojawia się jakiś konflikt między jedną i druga stroną umowy? Z czego możemy tu skorzystać, żeby ta umowa faktycznie nam pomogła w tym konflikcie?

W zależności od tego, jaki to jest rodzaj umowy, bo jeżeli mam standardową umowę i świadczenie usług, to taką umowę, co do zasady, możemy sobie wypowiedzieć. Natomiast sytuacja komplikuje się momencie, w którym jest to raczej umowa wdrożeniowa, czyli umowa o dzieło, a takich sytuacji jest mimo wszystko jeszcze najwięcej. Ja nie bez powodu na początku podałem taki przykład z odstąpieniem i wypowiedzeniem, dlatego że właśnie wypowiedzenie mamy w umowie zlecenie, a odstąpienie w umowie o dzieło. Więc często widzę umowę o dzieło na rynku IT, w której mamy wskazane wypowiedzenie. I też jest to głośny sygnał, który mówi, że ta umowa zazwyczaj będzie w całości do przerobienia, bo jest to po prostu bardzo duży błąd.

Powiedz, na czym polega ta różnica.

W momencie, w którym jedna ze stron odstępuje od umowy, to model jest taki, jakby ta umowa była niezawarta. I strony powinny zwrócić to, co sobie nawzajem świadczyły. W przypadku software house’u i jego klienta będzie to sytuacja, w której software house powinien zwrócić to, co do tej pory otrzymał, czyli były to pieniądze, wynagrodzenie. A zamawiający nie ma prawa do tego, żeby z tego korzystać i powinien formalnie wszystko zwrócić. I w sytuacji, gdy mamy umowę o świadczeniu usług programistycznych, nawet gdy mamy tam przeniesienie autorskich praw majątkowych, to to wypowiedzenie nie wpływa na tę sytuację, która była w przeszłości.

Natomiast przy umowach wdrożeniowych, takich bardziej standardowych, powinniśmy określić kwestie związane z odstąpieniem od umowy. Oczywiście możemy ich nie określać, bo kodeks cywilny przewiduje sytuacje, w których czy to wykonawca, czy zamawiający może odstąpić od umowy. Natomiast nie warto tej kwestii pozostawiać wyłącznie tym przepisom ogólnym kodeksu cywilnego, dlatego że te przepisy są względniejsze dla zamawiającego. To, co powinno się zrobić w takiej klasycznej umowie wdrożeniowej, to opisanie zasad odstąpienia, co w tej branży prawniczej i w branży IT nazywa się exit planem, czyli takim planem na to, co będzie w sytuacji, gdy strony przestaną się dogadywać, będzie jakiś konflikt, a już duża część projektu będzie zrobiona. I chodzi o to, żeby ustalić, że co do zasady to wynagrodzenie bezsporne – ta część bezsporna – zostaje u wykonawcy, należy się wykonawcy. Natomiast autorskie prawo majątkowe do tej części bezspornej, która została wykonana, przysługuje zamawiającemu. Chodzi o to, żeby strony mogły się rozstać, żeby umowa przewidywała taki sposób. Bo jeśli nie przewiduje, to zostaje nam tylko tak naprawdę sąd i walka sądowa. Natomiast jeśli przewiduje, to jedna ze stron, wykonawca, jest spokojny, bo zostało mu zapłacone za jakąś, często dużą, część prac, natomiast zamawiający jest spokojny, bo może wziąć te prace, które zostały wykonane, i kontynuować prace z innym. Nie traci czasu. A często to, co jest ważne na tym rynku, to czas, bo chodzi o to, aby szybko wdrożyć jakieś rozwiązanie u siebie w organizacji i uzyskać przez to jakąś przewagę konkurencyjną. Więc w sytuacji, w której to odstąpienie nie będzie uregulowane w tym modelu, o którym mówię, to tak naprawdę obie strony są przegrane – zamawiający pod kątem biznesowym, a wykonawca pod kątem finansowym.

Czy to oznacza, że umowy o dzieło w takim ujęciu są niekorzystne głównie dla wykonawcy, ale w zasadzie dla obu stron, bo zawsze mamy to odstąpienie?

Nie. Jeżeli ta umowa o dzieło jest skonstruowana w sposób lakoniczny i w ogóle nie reguluje kwestii odstąpienia czy tej procedury exit planu, to wtedy rzeczywiście te przepisy są korzystniejsze dla zamawiającego. Natomiast po to pisze się tę umowę, przygotowuje się ją w bardziej kompleksowy sposób, żeby te ryzyka zmitygować.

Powiedzieliśmy o odstąpieniu. Przy wypowiedzeniu jest tak, że nie ma tej konieczności zwrotu wzajemnego.

Nie. Wypowiedzenie ma tylko skutek na przyszłość. Więc po prostu strony rozstają się z zachowaniem jakiegoś tam okresu, na który się umówiły. I tyle, i sprawa jest zakończona.

A kiedy można skorzystać z odstąpienia, a kiedy z wypowiedzenia?

Wypowiedzenie ma zastosowanie przy umowach zlecenie, a odstąpienie przy umowie o dzieło. Więc raczej rodzaj umowy determinuje, z której instytucji możemy skorzystać.

Załóżmy, że mamy taki przypadek, w którym faktycznie się pokłóciliśmy. Wykonawca z zamawiającym nie mogą się dogadać. I oczywiście można zrobić to, co mówisz, czyli w tej umowie jest przewidziany exit plan, możemy odstąpić od umowy, wypowiedzieć, ale jeśli jedna ze stron ewidentnie czuje, że jej oczekiwania nie zostały spełnione, to co może zrobić? Czy wtedy idziemy do sądu, czy są tu jeszcze pośrednie opcje?

Nie mamy tych opcji pośrednich zbyt wiele, bo to tak naprawdę są negocjacje, ewentualnie można podjąć próbę mediacji w jakimś ośrodku mediacyjnym. Ale te mediacje prowadzone są z różnym skutkiem, szczególnie w bardziej skomplikowanych branżach. Bo to wymaga od mediatora wiedzy z danej branży. Natomiast jeśli któraś ze stron czuje się poszkodowana i uważa, że druga strona nie wypełnia umowy w taki czy inny sposób albo łamie postanowienia umowy, to pierwszą taką formalną kwestią powinno być wezwanie do usunięcia naruszeń. Zazwyczaj takie umowy przewidują, że zanim nastąpi jakiś skutek, czyli np. zanim dana ze stron będzie mogła skorzystać z prawa do odstąpienia albo też żądać zapłaty jakiejś kary umownej, to takie umowy przewidują obowiązek wezwania kogoś do usunięcia naruszeń i wyznaczenia mu do tego odpowiedniego terminu. Więc to jest pierwszy krok. Potem zawsze strony mogą usiąść i po prostu rozmawiać.

Natomiast problem w tym, że jeżeli umowa jest dobra, to przynajmniej mamy się do czego odwołać. I nawet jak sprawa skończy się w sądzie i nawet gdy będzie to trwało długo, to jeżeli umowa jest jasna, to sprawa jest prostsza. Problem pojawia się wtedy, kiedy tej umowy nie ma, umowa jest lakoniczna, kilkustronicowa, na bardzo duży projekt. I kiedy się nie dogadamy, to pozostaje nam sąd. I do tych rzeczy, które nie są uregulowane w tej umowie, będą miały wprost zastosowanie przepisy kodeksu cywilnego. I w zależności od tego, którą jesteśmy stroną, taki będziemy mieli arsenał do wykorzystania.

Czy to oznacza, że wtedy sąd dłużej będzie dochodził, kto ma rację, analizując różne pośrednie dowody?

Tak. Ogólnie postępowania sądowe w Polsce nie należą do najkrótszych. Ja też celowo w trakcie tej rozmowy nie za bardzo wgłębiałem się w te kwestie związane z Agile’em, Waterfallem itd., dlatego że o tym można długo dyskutować. Natomiast jak już poruszyłeś te kwestie sporów sądowych, to sądy również mają problem z odróżnieniem albo ze wskazaniem, która umowa to jest waterfallowa, a która agile’owa. Czy umowa agile’owa to też jest umowa o dzieło. Trzeba to wszystko przed sądem tłumaczyć i to też zajmuje trochę czasu. Te umowy IT są często tak pomieszane, mają taki mieszany charakter, że trudno się dziwić sądom, że mają problem z klasyfikowaniem tych umów jako umów o dzieło czy jako umowy zlecenia. I w konsekwencji mają problem z tym, które przepisy w jaki sposób zastosować. Natomiast jest już trochę orzeczeń, które wskazują, w jakiej sytuacji przy realizacji projektów IT jakie przepisy zastosować. I te terminy związane z metodykami zwinnymi też się do sądu jakoś przebijają. Natomiast problem polega na tym, że mało jest takich umów w stu procentach agile’owych. Raczej ten Agile na naszym rynku ma wiele odcieni, ma wiele wymiarów. I te wymiary są bliższe umowom o dzieło. To są takie umowy o dzieło z elementami agile’owymi.

Jak wiele spraw kończy się w sądzie? Czy znasz statystyki?

Nie. Muszę przyznać, że sam na przestrzeni tych kilku lat wcale tych spraw sądowych związanych z realizacją projektów IT nie było tak dużo, co nie znaczy, że one się w ogóle nie zdarzają. Ja osobiście sam brałem udział w bardzo wielu negocjacjach związanych z rozwiązywaniem sporów i akurat w tych przypadkach, które prowadziłem, duża część oczywiście kończyła się polubownie. Sam teraz prowadzę kilka postępowań sądowych związanych z realizacją czy z brakiem dopełnienia umowy.

Czyli jednak większość osób stara się to załatwić negocjacyjnie.

Tak. Nie wiem, czy to wynika ze specyfiki branży, natomiast rzeczywiście poziom przynajmniej u tych małych i średnich wykonawców, z którymi ja mam najczęściej styczność, poziom spraw, które udaje się załatwić polubownie, jest stosunkowo wysoki.

Na zakończenie, powiedz osobom, które chciałyby dowiedzieć się czegoś więcej o umowach w IT, czy to przedstawicielom firm wykonawczych, czy zamawiających, czy jest tu taka przestrzeń, żeby więcej dowiedzieć się samodzielnie? I czy w ogóle warto? Czy może po prostu trzeba iść do prawnika i to jemu zdelegować? Choć dobrze jest wiedzieć, o czym ten prawnik do nas mówi.

Przede wszystkim ja na miejscu osób działających w branży IT, osób technicznych, spróbowałbym zgłębić te modele kontraktowe. Źródeł nie ma zbyt wiele, dlatego że to jest po prostu kodeks cywilny, który wielu tych kwestii, o których my dziś powiedzieliśmy, nie precyzuje, nie porusza. To są kwestie, które trzeba sobie uregulować w umowie. I co za tym idzie, trzeba zbudować swoją świadomość, swoją wiedzę w zakresie tego, co w tej umowie powinno się znaleźć z punktu widzenia specyfiki tych projektów, które my realizujemy. Bo może zdarzyć się tak, że niektórych elementów do umowy specjalnie nie wrzucimy, bo będziemy uważali, że te przepisy zawarte w kodeksie cywilnym będą dla nas akceptowalne i umyślnie nie będziemy czegoś umieszczali w umowie. Oczywiście zapraszam też na swój blog: umowywit.pl, w którym staram się dzielić tą wiedzą i publikować tam troszkę większe artykuły, które tę tematykę przybliżają. Warto też pójść sobie na szkolenie z umów IT. Tych szkoleń jest coraz więcej. Nawet u was takie szkolenie z umów IT ostatnio się pojawiło.

Nie ukrywajmy, że je prowadzisz.

Tak. Mam tę przyjemność, że prowadzę to szkolenie.

Wielkie dzięki za rozmowę.

Dzięki.