To jest 162.  odcinek podcastu  Porozmawiajmy o IT, w którym z moim gościem rozmawiam o prawnych aspektach umów IT.

Przypominam, że w poprzednim odcinku rozmawiałem o deweloperze Blockchain. Wszystkie linki oraz transkrypcję dzisiejszej rozmowy znajdziesz pod adresem porozmawiajmyoit.pl/162

Ocena lub recenzja podcastu w twojej aplikacji jest bardzo cenna, więc nie zapomnij poświęcić na to kilku minut. Od niedawna można wystawiać oceny podcastom w Spotify. Będzie mi bardzo miło, jeśli w ten sposób odwdzięczysz się za treści, które dla ciebie tworzą. Dziękuję.

Ja się nazywam Krzysztof Kempiński, a moją misją jest poszerzanie horyzontów ludzi z branży IT. Środkiem do tego jest między innymi ten podcast. Zostając patronem na platformie Patronite, możesz mi w tym pomóc już dziś. Wyjdź na porozmawiajmyoit.pl/wspieram i sprawdź szczegóły. Jednocześnie bardzo dziękuję moim obecnym patronom. A teraz życzę ci już miłego słuchania!

Odpalamy!

Cześć!

Mój dzisiejszy gość to adwokat, Wspólnik Kancelarii Creativa Legal, wiceprezes Fundacji Creative Education, mentor i twórca internetowy. Specjalizuje się w prawie nowych technologii oraz prawnym wsparciu biznesu w tym firmom technologicznym. Ekspert w zakresie prawnych aspektów technologii Blockchain, podcaster prowadzący audycję „Okiem prawnika kreatywnych”. 

Moim i Waszym gościem jest Arkadiusz Szczudło.

Cześć Arku, bardzo mi miło gościć Cię dziś w podcaście. 

Cześć, cześć, witam Ciebie, witam wszystkich słuchaczy.

Z Arkiem będę dzisiaj rozmawiał o prawnych aspektach umów IT, pod kątem osób, które zarówno pracują w IT, jak i tych, którzy takie osoby zatrudniają. Ostatnio mamy dużo zmian prawnych, a także zmian trendów na rynku, więc myślę że jest to temat, który warto poruszyć, warto o tym rozmawiać, bo tak na koniec dnia, nie możemy o tych aspektach zapominać.

Standardowo, chciałbym rozpocząć podcast od pytania do Ciebie Arku, czy słuchasz podcastów oprócz ich tworzenia? Jeśli tak, to może masz jakieś swoje ulubione audycje, o których warto tutaj powiedzieć?

Ja mam zapisanych aktualnie na spotify 40-50 podcastów. Słucham tak naprawdę wiele różnego rodzaju kategorii: czasami to są kulturalne, czasami to są właśnie podcasty IT, żeby poznać tę branżę od środka. Mimo tego, że byłem programistą przez chwilę, to już nie jestem. Jestem prawnikiem, adwokatem.

Słucham „Przygody przedsiębiorców”, różnego rodzaju podcastów marketingowych NSM Szymona Negacza. Także jest tego trochę. 

Według WHO „podcastoholizm” nie jest jednostką chorobową, i widzę, że nie tylko ja na nią cierpię, aczkolwiek jest to przyjemne uzależnienie.

Śledzę sobie od pewnego czasu różnego typu raporty i wyniki badań społeczności IT, nie tylko pod kątem takiego spojrzenia jakie technologie obecnie są teraz na topie, ale żeby zobaczyć też jak wyglądają formy zatrudnienia. Nie da się tutaj nie zauważyć w Polsce pewnego wzrostu osób, które właśnie pracują na zasadzie kontraktów B2B.

Ty współpracujesz z takimi osobami, konsultujesz aspekty prawne z firmami, które zatrudnia tego typu osoby. Czy ty też widzisz taką tendencję? Z czego to może wynikać?

U mnie w praktyce wygląda to tak, że najczęściej reguluję te kwestie B2B. Umowy o pracę są naprawdę bardzo małym odsetkiem.

Powiem szczerze, miałem z kilkudziesięciu klientów tylko kilku, którzy od początku chcieli i twardo szli, w kierunku umowy o pracę. Ale to było też trochę podyktowane tym, że po pierwsze, ten podmiot (akurat ten jeden który mam na myśli) ostatnio był z zagranicy, więc troszeczkę ta kultura organizacyjna pracy też może wyglądać inaczej niż w Polsce. Nie chcę wskazywać kto to, bo jest to dość znany software house. 

Druga rzecz, na którą myślę, warto zwrócić uwagę, to jest oczywiście kwestia tego przy umowach o pracę, że mamy masę dodatków które jednak programiści chcą otrzymywać. Są to: urlopy, urlopy macierzyńskie itd.

Myślę, że tutaj ten trend zależy od osoby, którą spotkamy na swojej drodze jako software house, czyli kto jest programistą, na co zwraca uwagę.

Myślę, że B2B zdecydowanie będzie teraz więcej i w moim przypadku jest teraz najwięcej.

No właśnie ten rynek pracy się zmienia pod wieloma względami. Duże zapotrzebowanie na osoby z IT powoduje że mają one silniejszą kartę przetargową, są w stanie sugerować, że tego typu forma współpracy jest pożądana dla nich. 

Ostatnio też słyszałem, że te nowe pokolenia siłą rzeczy będą bardziej skłonne do tego, żeby pracować na część etatu, czyli kilka godzin u jednego pracodawcy, kilka u innego. Jest to jednak temat na inną rozmowę.

Powiedzmy szczerze, B2B jest bardzo zbliżony do umów pracy aktualnie. Tak, tam też są urlopy przecież uwzględniane, tam też jest określony sposób wykonywania pracy. Tutaj  przez pracę i pracodawcę, przyjmijmy drodzy słuchacze, że będziemy myśleli o B2B i umowach o pracę. 

W umowach B2B jest wiele elementów, które mają normalne umowy o pracę, albo wynikają z kodeksu pracy. Tak więc myślę, że tutaj może bardziej będą wchodziły w grę kwestie podatkowe. Ewentualnie jeszcze takie rzeczy, których nie można spotkać w B2B, a w umowie o pracę, czy też w kodeksie pracy, są z góry uwzględniane. 

No własnie, bo taki kontrakt B2B najczęściej jest bardziej elastyczny i możemy zawrzeć tu takie elementy które „nie przeszłyby” w umowie o pracę. Kontrakt B2B jest bardziej pojemny i możemy te rzeczy swobodniej umieścić.

No tak, mamy przecież coś takiego jak swoboda umów przy B2B i w większości aspektów możemy dowolnie wszystko modyfikować, regulować itd.

Gorzej, jeśli umowa B2B wygląda jak umowa o pracę. Po prostu trzeba umieć to rozgraniczyć.

Osoby, które mają tego typu wątpliwości mogą poradzić się ciebie lub też innych osób, które zajmują się kwestiami prawnymi branży  IT.

Jak najbardziej takie analizy się wykonuje. Najczęściej jednak, gdzie ja występuję, ja stoję po stronie software house’u, gdzie trzeba sporządzić taką umowę i wtedy muszę, albo „wybić z głowy” albo zaproponować rozwiązanie, które będzie bardziej zgodne z prawem. 

Ja wychodzę z założenia, że ta umowa powinna być bardziej dopasowana do pracy, jaka ma być wykonywana, a nie odwrotnie. Umowa powinna regulować to, co rzeczywiście będzie się działo.

Ja wychodzę z założenia, że ta umowa powinna być bardziej dopasowana do pracy, jaka ma być wykonywana, a nie odwrotnie. Umowa powinna regulować to, co rzeczywiście będzie się działo.

No właśnie, mógłbyś ten temat rozwinąć? Bo jest to ciekawa rzecz. Nie spotkałam się nigdy jeszcze z takim podejściem żeby formy zatrudnienia dobierać do typu pracy. możesz przez chwilkę coś na ten temat powiedzieć?

Jasne, tutaj mam na myśli to, że jeżeli będzie to np. osoba która będzie pracowała wewnątrz organizacji i będzie przychodziła do biura codziennie od 8 do 18 (są tacy programiści, którzy pracują na takim typowym etacie), to nie ma to sensu, oprócz oczywiście podatkowego sensu, wciskać umowy B2B, skoro ewidentnie wszystkie czynności, które będzie on wykonywał, sposób ich wykonywania, będą wskazywały na umowę o pracę.

Na koniec dnia to klient podejmuje biznesowe ryzyka. To on decyduje jaką chce umowę. Ja muszę wskazać mu to ryzyko, że to co będzie wykonywał i sposób, w jaki będzie to wykonywał pracę programista jednak wskazuje na stosunek pracy a nie cywilnoprawny (P2B).

Ja akurat wolę B2B, to jest moja działka, a nie właśnie prawo pracy, więc jeżeli mogę to oczywiście robię tylko i wyłącznie B2B. To jest najciekawsze z tego wszystkiego, bo tam można być bardziej swobodnym i uregulować sporo rzeczy. 

Spora część osób  pracujących w IT preferuje tego typu kontrakty z wielu różnych powodów podatkowych, swobody itd.

Ale jak na to patrzy ta druga strona (software house), który najczęściej zatrudnia programistów. Zwłaszcza, że Polska słynie  trochę z tych software house’ów i takiego zaplecza świadczenia tego typu usług, nawet dla firm zagranicznych. Jak software House’y do tego podchodzą? Czy są zmuszone rynkiem pracownika, żeby faktycznie decydować się na ten kierunek, czy też może mają jakieś korzyści z tego wynikające?

W moim odczuciu, a jestem prawnikiem, nie prowadzą software house’u, co prawda kilkanaście software house’ów obsługiwałem i kilkadziesiąt firm technologicznych, które zatrudniały software house’y. Powiem szczerze, B2B wydaje mi się jest korzystniejszy. No bo, tak jak powiedziałem, mamy kwestie podatkowe. Różnica w kwotach może być nawet kilka tysięcy. Pamiętajmy, że są jeszcze ukryte koszty w umowach o pracę. Przy umowach B2B mamy wprost VAT i dochodowy. I ewentualnie ZUS.

Programista może sobie zrobić koszty, może kupować rzeczy na swoją własną firmę itd. i może sobie, że tak powiem „dorobić sobie kosztami” dodatkowo. 

A patrząc z drugiej strony mamy jednak te urlopy, w kodeksie pracy one są ograniczone, a w umowach B2B jest wprost np. często wskazywane, że ktoś ma 26 dni urlopu, niezależnie od stażu. Więc my jesteśmy w stanie, w ramach umów B2B, tego typu rzeczy jednak regulować i wydaje mi się, że dla software housu korzystniejsza będzie jednak umowa B2B, chociażby patrząc tylko w tym wąskim zakresie, jak kwestie podatkowe. A z drugiej strony, na pewno oprócz podatków, znajdzie się trochę argumentów jednak za tym, żeby to było B2B. 

No właśnie to jest też kwestia takiego trochę przekonania się pracodawców czy software housu do tej formy współpracy. Taka obawa, z którą się często spotykam to jest to, że taka osoba będzie trochę niby w firmie, ale tak naprawdę trochę z boku, że de facto nic jej nie trzyma, że to będzie ktoś taki, kto nie w pełni jest zintegrowany z firmą. Ale w praktyce z kolei,  jak obserwuję jak to działa, to właściwie tam, tak jak powiedziałeś, nie ma zbyt dużej różnicy.

De facto ta osoba która bardzo często jest na wieloletnim kontrakcie, ta osoba jest pełnoprawnym, pod każdym względem, względem zaangażowania, pod względem obowiązków itd. pracownikiem, czy też członkiem zespołu tej firmy. Często te obawy software housow nie pokrywają się z rzeczywistością. Ale trzeba się do tego faktycznie przekonać. 

I myślę sobie, że ta sytuacja pandemiczna trochę przyspieszyła ten proces. Również, z racji na to, że rynek pracy stał się niesamowicie globalny, w tym momencie takie kontrakty B2B  są furtką, możliwością łatwej współpracy z kimś, kto jest na drugim końcu świata.

No właśnie, my mówimy tutaj o polskich programistach i polskich software house’ach. Ale powiedzmy sobie szczerze, kwoty wynagrodzenia za granicą dla Polaków (polskich programistów) są znacznie wyższe. Więc nie wyobrażam sobie teraz żeby nagle na umowie o pracę ktoś pracował dla Wielkiej Brytanii, albo coś takiego, pracując z Polski. To jest przeważnie kontrakt B2B.

Zresztą polskie software house’y też zatrudniają osoby z zagranicy. Były sytuacje, że trzeba było sprowadzać programistów z Białorusi ze względu na aktualną sytuację. I im się nie oferuje umów o pracę. Mogą pracować ze swoich krajów, po prostu pracować zdalnie. 

Wspomniałeś kwestie, że B2B nie jest do końca dobrze postrzegane. No tak, mogą one być tzw. umowami śmieciowymi. Ja staram się żeby umowy, o które klienci mnie proszą, nie były umowami śmieciowymi.

Wspomniałeś też kwestię programistów, którzy nie do końca będą czuli się jak tacy wewnętrzni pracownicy. Myślę, że to wszystko zależy od kultury organizacyjnej danego software housu. Jeżeli nie ma tej kultury, no to oczywiście nawet na umowie o pracę pracownik nie będzie czuł się związany z daną firmą. Myślę, że tutaj forma zatrudnienia bez tej kultury organizacyjnej, bez fajnego flow w firmie itd. niezależnie jaka to będzie umowa, tak naprawdę nikt nigdy nie będzie czuł się przywiązany do do danej firmy.

Myślę, że to wszystko zależy od kultury organizacyjnej danego software housu. Jeżeli nie ma tej kultury, no to oczywiście nawet na umowie o pracę pracownik nie będzie czuł się związany z daną firmą. Myślę, że tutaj forma zatrudnienia bez tej kultury organizacyjnej, bez fajnego flow w firmie itd. niezależnie jaka to będzie umowa, tak naprawdę nikt nigdy nie będzie czuł się przywiązany do do danej firmy.

Ja powiem ci szczerze, że lubię takie zestawienia zatrudnienia na umowę o pracę vs. B2B. Lubię to odnosić do rozwiązań informatycznych, gdzie wszystko zależy od konkretnej sytuacji, czy tego typu narzędzie jest lepsze w tej sytuacji czy inne.

Myślę że podobnie jest z formą zatrudnienia. 

Oczywiście B2B może mieć wiele różnych pozytywnych efektów, aspektów i benefitów, z których warto korzystać. Ale potrafię sobie też łatwo wyobrazić sytuację kobiet, które są w okresie poszerzania rodziny, gdzie umowa o pracę może być swego rodzaju łagodniejszym powrotem do tej pracy. 

Jak najbardziej, takich rzeczy jak macierzyński czy tacierzyński nie reguluje się w umowach B2B. Są urlopy czy też wydłużone urlopy, chociaż ja się osobiście z tym akurat nie spotkałam. 

Macierzyńskie, tacierzyńskie i tego typu rozwiązania, gdzie po pewnym czasie państwo przejmuje „płacenie” tego wynagrodzenia, przy umowach B2B nie istnieje, tu się z tym nie spotykamy.

Za to powinniśmy się spotkać z prawami autorskimi, jako aspekcie, który jest regulowany. Nie jestem ekspertem i poproszę cię o dopowiedzenie jeśli coś źle mówię, ale jeśli chodzi o umowę o pracę, to mniej lub bardziej te kwestie praw autorskich są uregulowane w przypadku IT. Jeśli chodzi o B2B, te kontrakty, z którymi ja się spotkałam, zawsze takie paragrafy związane z tymi prawami miały. 

No właśnie, gdybyśmy mogli porównać umowę o pracę i B2B pod kątem praw autorskich

to jakby to mogło wyglądać?

Trzeba tu zrobić wstęp do praw autorskich i mam nadzieję, że słuchacze będą to rozróżniali. Mamy tu majątkowe i osobiste prawa autorskie. Majątkowe to rozporządzanie, korzystanie itd. a osobiste to np. oznaczenia autorstwa utworu.

Jest to istotne ponieważ my musimy zawsze uregulować w umowie osobiste prawa autorskie. Bo na koniec dnia może się okazać, że programista będzie chciał po roku czasu żeby nagle w oprogramowaniu znalazła się informacja o tym że on był współtwórcą danego oprogramowania.  Więc tutaj trzeba zobowiązać do nie wykonywania tych osobistych praw autorskich w każdej sytuacji. Po prostu jedno zdanie. 

Natomiast prawa majątkowe to jest główna rzecz, którą musimy regulować w mniejszym lub większym stopniu. Bo to jest to, co pozwala na dalsze rozpowszechnianie, zarabianie, sprzedaż. 

Jeżeli pracujemy dla software housu to ta ścieżka jest od programisty do software housu, a od software housu do klienta docelowego.

Więc tutaj ta ścieżka jest zdecydowanie powinno się o to zadbać. I myślę że zarówno programista, który jest profesjonalistą, jak i software house, oboje powinni mieć w tym interes żeby te rzeczy po prostu uregulować.

I teraz tak, przy umowie o pracę, mamy taką sytuację, że jeżeli ktoś jest zatrudniony na stanowisko programisty, to nie ma problemu, że tak powiem, te prawa z automatu przechodzą na software house. Przy B2B trzeba to już uregulować.

Co najwyżej możemy uznać, że mamy coś takiego jak licencję niewyłączną, ale tak naprawdę to nie mamy nic. Bo przy licencji  niewyłącznej to ja mogę sobie iść i sprzedać dalej gdzieś ten program i nikt mi tego nie zabroni.

Przy umowach B2B zdecydowanie trzeba to uregulować, przy umowach o pracę, ja osobiście,  też to reguluję, bo wtedy szerszy zakres regulujemy, niż to jest w kodeksie pracy (chociażby te osobiste prawa autorskie). Natomiast jeżeli ktoś nie ma tego uregulowanego, to może spać przynajmniej jednym okiem spokojnie. No bo kodeks pracy i ustawa o prawie autorskim i prawach pokrewnych będzie to po prostu uwzględniała. Także te prawa będą przeniesione na pracodawcę bezpośrednio, od razu. Gorzej, jeżeli słucha nas osoba, która dorabia sobie dla danego pracodawcy jako programista. Bo takie osoby, oczywiście, też się zdarzają. Nie są w 100% programistami tylko robią coś innego i dodatkowo coś tworzą dla tego pracodawcy.

Miałem kiedyś taką abstrakcyjną sytuację, że ktoś był marketingowcem i po prostu tworzył jakieś tam drobne kody na stronę internetową. No to nie jest praca marketingowca. Wtedy ten kod nie będzie przenoszony na tego pracodawcę, mimo tego, że ten marketingowiec stworzył go dla tego  pracodawcy. Zakres umowy nie obejmował tego typu działań w ogóle. Jest to rzadkość, ale myślę że jest to „ciekawa ciekawostka”.

Myślę, że coraz częściej będziemy mieć do czynienia z takim przycinaniem się branż. Mówisz tu o tzw. martechu, czyli połączeniu, przecięciu marketingu i technologii. Myślę, że teraz będzie coraz więcej tego typu przypadków krańcowych.

Ale to też działa w drugą stronę. no bo programista, on nie zawsze tworzy tylko kod. On bierze udział w spotkaniach, tworzy prezentacje, tworzy różnego rodzaju dokumentację techniczną, ale taką, która nie jest programem komputerowym w myśl praw autorskich, tylko jest po prostu jakąś tam dokumentacją, jakimś briefem, współtworzy makiety, pokazuje jak te funkcjonalności będą działały itd. To, de facto, nie jest program komputerowy, ale należałoby to uwzględnić. A to nie do końca zawsze się dzieje. Ktoś reguluje sobie w umowie przekazywanie czy przenoszenie praw do kodu a nie reguluje rzeczy, które na około się dzieją. A przecież w większości przypadków jednak się dzieją. To nie jest tak, że ktoś tylko siedzi i tworzy ten kod. 

No tak, będąc, nazwijmy to, kontraktorem B2B, który chciałby rozpocząć tę formę współpracy, z dajmy na to, software housem, co byś poradził takiej osobie pod kątem przeniesienia praw autorskich? Na co zwrócić uwagę, w tym kontrakcie, żeby swoje interesy też zabezpieczyć?

Powiem tak, ja tutaj nie widzę jakichś takich ryzykownych rzeczy, na które szczególnie warto byłoby zwrócić uwagę. Z tego względu, że jeśli wyjdę z takiego założenia,  że my pracujemy dla tego jednego podmiotu, dla jednego pracodawcy, na umowie B2B pracodawcy, no to tak naprawdę my tworzymy coś co on nam zleca cały czas. 

Więc z zasady, nawet tak patrząc po prostu ludzko,  my nie powinniśmy dalej korzystać z tego oprogramowania do jakichś innych celów. Inaczej by było, gdybyśmy pracowali na B2B dla kilku  podmiotów i korzystali z tego kodu wielokrotnie. Tutaj, oczywiście nie mam na myśli jakichś otwartych bibliotek  GITa czy innych kwestii. Bo oczywiście my nie możemy przenosić prawa w zakresie, w którym my sami tych praw nie mamy. Wtedy mamy licencję. Ale przyjmijmy na razie taką bazową sytuację idealną. Wtedy nie widzę żadnego ryzyka. Po prostu przenosimy prawa na wszystkich polach eksploatacji, wskazujemy te pola eksploatacji, uzgadniamy ewentualnie z naszym zamawiającym/pracodawcą czy rezygnujemy z tych osobistych praw autorskich czy nie. Oczywiście ustalamy wynagrodzenie, czy to za prawa autorskie, czy to po prostu za całość tego comiesięcznego wynagrodzenia albo dzieła, które stworzymy itd. 

Ewentualne kwestie, gdzie może być problematycznie to kwestia portfolio. To jest sytuacja, gdzie chcemy wykorzystać dany materiał w portfolio i po prostu nie możemy nawet wykorzystać znaku towarowego, bo de facto nie mamy do tego praw (znaku towarowego naszego pracodawcy). Wtedy musimy doregulować kwestie wykorzystania takiego znaku i w ogóle informowania o tym, że z kimś współpracowaliśmy.Tak ale to też musimy to uregulować w zakresie chociażby NDA, zachowania poufności. Bo to może być złamanie zakazu poufności. 

Same prawa autorskie nie są problematyczne, jeśli zatrudnia nas jeden software house i dla niego pracujemy. To są raczej standardowe klauzule, standardowe rzeczy. Więcej się dzieje naokoło praw autorskich niż w samych prawach autorskich.

Oczywiście jest jeszcze ta kwestia, kiedy przynosimy prawa, a kiedy udzielamy licencji. To niestety w wielu branżach, nie tylko IT, spotykam się z tym, że mówimy naszemu zamawiającemu (klientowi), że przenosimy na niego prawa autorskie do rzeczy, do których my nie posiadamy żadnych praw albo mamy licencję, która nie pozwala jakby nawet na zrobienia cesji. 

O takie rzeczy trzeba zadbać, czyli korzystać z tego gotowego kodu, z gotowych materiałów, co do których mamy prawa albo te prawa możemy przenieść. Myślę, że to jest taka bolączka, która mogłaby być w zakresie praw autorskich, z którymi ja się akurat spotykam. Pamiętajmy też, że do prawnika zwracamy się najczęściej jednak jak jest problem, a problem właśnie jest.

Ok, myślę że pobieżnie przeszliśmy przez fragment praw autorskich. Inną częścią umów, która często  się przewija jest zakaz  poufności oraz zakaz konkurencji. Firmy starają się w jakiś sposób zabezpieczyć swoje interesy właśnie poprzez wprowadzanie tego typu zapisów. No bo wiadomo, IT jest branżą, w której powstają innowacje, te innowacje są tworzone przez osoby, przez te talenty, które pracodawcy chcieliby przynajmniej przez jakiś czas utrzymać w firmie, żeby z ich kreatywności korzystać.

Na co w tym aspekcie zachowania poufności oraz zakazu konkurencji zwrócić uwagę z tych dwóch stron, tego umownego pracodawcy i pracownika?

Myślę, że z każdej strony to co teraz powiem będzie do zastosowania. Czyli zakres, w jakim będziemy chcieli chronić te nasze poufne dane, musimy opisać. Myślę, że im najbardziej szczegółowo, tym lepiej akurat w tym przypadku, przy NDA, czyli zachowaniu poufności, jak i zakazie konkurencji. Przy zakazie konkurencji też powinniśmy wskazać czego ten zakaz będzie dotyczył, kto jest dla nas konkurencją. Tutaj może być problem w sytuacji, w której ten zakaz będzie zbyt szeroki bo on wtedy będzie po prostu nieważny. Tutaj jest to dosyć spory problem. Można natomiast przy zakazie konkurencji wskazać wprost firmy, dla których ktoś nie może pracować.

Na pewno czegoś takiego nie można powiedzieć programiście, że teraz nie będzie mógł pracować dla branży IT  lub branży e-commersowej. Czegoś takiego robić nie można, bo nie można komuś zabrać możliwości zarabiania i możliwości świadczenia pracy itd. 

Zdecydowanie dla pracodawcy, zamawiającego jak i dla programisty, to ustalenie tego szczegółowego zakazu konkurencji oraz tych kwestii przy zachowaniu poufności będzie zdecydowanie istotne. No bo na koniec dnia programista nie będzie wiedział czego nie może robić a pracodawca, czy software house, nie będzie mógł dochodzić roszczeń związanych właśnie z takim zakazem czy zachowanie poufności. 

Przy zachowaniu poufności NDA nie jest jedyną rzeczą jaką my powinniśmy wykonać żeby wdrożyć taką tajemnicę przedsiębiorstwa wewnątrz swojej organizacji. Powinniśmy jeszcze informować o tej tajemnicy swoich pracowników, swoich podwykonawców, powinniśmy wysyłając informacje poufne wskazywać w mailu np. w stopce, że ta informacja jest poufna. Oprócz NDA powinniśmy wskazać, że coś jest dla nas poufne. To jest taki wyższy poziom świadomości. To jest takie istotne bo NDA często wskazują, że wszystkie informacje organizacyjne, finansowe, administracyjne są poufne. 

Przy zachowaniu poufności NDA nie jest jedyną rzeczą jaką my powinniśmy wykonać żeby wdrożyć taką tajemnicę przedsiębiorstwa wewnątrz swojej organizacji. Powinniśmy jeszcze informować o tej tajemnicy swoich pracowników, swoich podwykonawców, powinniśmy wysyłając informacje poufne wskazywać w mailu np. w stopce, że ta informacja jest poufna. 

No ale co to znaczy? Trzeba to dodatkowo gdzieś jeszcze dopisać, np: zasady wysyłania informacji. A jeśli takich zasad nie mamy, to i tak dajemy w stopce że coś jest dla nas poufne. 

Dobrze, rozumiem. Wspomniałeś kilka minut temu, że do prawnika się idzie kiedy coś złego się dzieje. W IT te złe czasy,  to może być nie wywiązywanie się z ustaleń wynikających z umowy, ale to też mogą być rzeczy niezamierzone, różnego rodzaju wpadki, fuckupy. Słyszy się czasami, że programista, administrator, przypadkowo usunął jakieś bazy danych. Na co tutaj zwróciłbyś uwagę w umowie pod kątem tego typu sytuacji?

Wspomnę, że do prawników zwracamy się gdy jest problem, bolączka. Ja osobiście lubię pracować wtedy kiedy mam umowę albo jest sytuacja jeszcze przed problemem i możemy przewidzieć ewentualnie ten problem. 

Powiem tak: umowa może załatwić wiele rzeczy. Jest wiele takich aspektów przy wykonaniu, przy niewykonaniu, de facto, albo przy wadliwym wykonywaniu danego zlecenia, które my możemy przewidzieć w umowie i w jakimś stopniu to ograniczyć, to ryzyko, że coś się niedobrego stanie dla jednej i dla drugiej strony. 

Oczywiście nie jesteśmy w stanie każdej sytuacji  przewidzieć, no bo co człowiek to inna sytuacja może być. Nigdy nie jesteśmy w stanie przewidzieć tego co człowiek może zrobić.

Są takie elementy, na które na pewno przy sporządzaniu, czy przy zawieraniu umowy jesteśmy w stanie wskazać, które mogą nas zabezpieczyć przed taką wadliwością, przed niewykonaniem. A to jest jednak spory procent. Co chwilę słychać, że jakiś software house czegoś nie wykonał, programista zawalił, firma technologiczna nie dostarczyła materiałów w terminie, więc wszystko się posypało dla software housu itd.

To nie są często błędy samego software housu czy programisty, tylko to są błędy, oczywiście, tej drugiej strony, samych klientów. Więc na pewno, kwestia taka podstawowa, idąc od góry, jak sobie wyobrażam umowę, forma pisemna umowy to jest mus żeby mieć dowód, że umowa została w ogóle zawarta. 

Przy przeniesieniu praw autorskich to już w ogóle musi być forma pisemna, nie ma innej opcji, żeby ta umowa była ważna.

Idąc w dół też się spotykam z tym problem: poprawne oznaczenia stron umowy. Jeżeli pracujemy ze spółką, obojętnie czy to jest klient, czy to jest software house itd. (bo to bez znaczenia) to może się zdarzyć tak, że to nie prezes zarządu będzie podpisywał umowę tylko ktoś inny.

I teraz dowiedzmy się, czy taka osoba ma w ogóle prawo podpisać taką umowę. Bo lepiej sądzić się z software housem później, który będzie miał większe budżety niż z jakąś osobą, która udawała albo członka zarządu.

To jest taka błaha rzecz i jest pomijana. Po prostu wpisuje się takie dane i nikt tego nie sprawdza w ogóle. Więc zachęcam do sprawdzania tego.

Kolejna kwestia już bardziej rozbudowana (to zależy od tego czy idziemy w Edge Isle czy Water Fall czy inny miks umów) to na pewno zalecam oznaczanie harmonogramu prac, etapy. Jesteśmy wtedy w stanie uniknąć tego, że coś zostanie zaakceptowane, a nagle nam klient powie, albo software house, że jednak chce jakieś zmiany w tym pierwszym etapie. No i co wtedy? No mamy to zaakceptowane już.

Jeżeli mamy podział na etapy, to jesteśmy w stanie uniknąć takiego problemu. A jeżeli ktoś będzie chciał zmiany np. w etapie pierwszym, to nie zamykamy się na to, tylko ewentualnie regulujemy kwestię poprawek, albo kwestię dodatkowych godzin pracy. Jak nie mamy tego uregulowanego, to jest problem. Nie wiadomo w którym kierunku trzeba iść i trzeba się zastanawiać. A tak, dwoma, trzema zdaniami w umowie, jesteśmy w stanie to uregulować i nie są to klauzule nie wiadomo jak długie.

Jest też kwestia np. dołączania, tutaj już zdanie może być podzielone oczywiście, briefu, dokumentacji do umowy. Czy idziemy w szczegółowość? Czy idziemy w ogólność? To już jest kwestia dyskusyjna. Tutaj z różnymi zdaniami się spotykam.

Ja preferuję żeby to było szczegółowe, przynajmniej na jakimś etapie. To nie musi być już zawarte w samej umowie. Ale jeśli np: pierwszy etap współpracy to jest analiza pomysłu biznesowego klienta i przełożenie go na dokumentację techniczną, na stworzenie konsultacji itd, w wyniku których wyjdzie ten brief czy też dokumentacja, no to jestem za tym, żeby to już była wiążąca dokumentacja. To po to, żeby jednak nie wprowadzać już dalszych modyfikacji, które nie będą wynikały z ekosystemu lub nie będą wynikały z tego, że można by coś zrobić inaczej. To też lepiej takie rzeczy też dołączyć. I to bywa różnie, bo każdy argument jest dobry.

Z etapami wiąże się też kwestia wynagrodzenia i problem w płatności tego wynagrodzenia. Im więcej etapów tym więcej części wynagrodzenia, tym szybciej dostaniemy pieniądze na bieżącą działalność operacyjną firmy, czy też życiową, jeśli mówimy o programiście. Również będzie trudniej nam zabrać te pieniądze. No bo łatwiej jest nam nie zapłacić, niż zapłacić a potem dochodzić zwrotu tych pieniędzy. To już tak czysto praktycznie. Więc tutaj też jesteśmy w stanie uniknąć takiego problemu w razie niewykonania, czy też wadliwego wykonania. 

Czy zawinione, czy niezawinione, to obojętne oczywiście, ale my mamy już te pieniądze na koncie. Więc mamy, że tak powiem, kartę przetargową trochę lepszą.

Więc tutaj warto już tego typu rzeczy uregulować.

Przy wynagrodzeniu, przy Agile, można iść w kierunku tego, że każdy Sprint będzie poprzedzony wyceną, do której będzie mógł się odnieść klient. Dla niektórych może to być oczywiste, ale powiem szczerze, że w niektórych Edge Islach nie ma takich rzeczy uregulowanych. Jest to po prostu gdzieś tam w domyśle. Edge Isle ma sam w sobie coś takiego, że zaufanie jest tutaj istotne, ale sposób rozliczania, myślę, że to nie jest kwestia zaufania, czy nie, to powinno się tam znaleźć.

Powiem ci ja przez 8 godzin mogę o tym gadać. 

To jest kwestia siły wyższej, patrząc na to jaka sytuacja teraz jest. Jeżeli nie mamy określonej siły wyższej to może być problem z przesunięciem terminów. A to z kolei jest niewykonanie umowy. Czy z winy software house to jest? No nie do końca. No ale nie ma tej kwestii siły wyższej uregulowanej i jest to kwestia problematyczna. A dałoby się z tego wyjść czterema zdaniami.

Bardzo ci dziękuję za te praktyczne porady. 

Chciałbym na chwilę jeszcze przeskoczyć do innego aspektu, którego się jeszcze uczymy, mianowicie RODO. Wiadomo, że firmie IT, która najczęściej, albo w 99,9% przypadków, tymi danymi obraca i są tam osoby, które tych danych dotykają, to jest istotny zapis. 

Czy to w przypadku tych kontraktów B2B, zasad współpracy na B2B, RODO działa jakoś inaczej? Musimy na coś jeszcze zwrócić uwagę, czy jest ono jednolite i nie ma znaczenia jaka jest forma zatrudnienia?

Jeżeli mówimy o software housie to tak naprawdę zakres dokumentacji, de facto, zawsze będzie ten sam. Ja tutaj od razu powiem i drodzy programiści, drodzy właściciele software house’ów, że polityka prywatności i umowa powierzenia z programistą to nie jest tylko i wyłącznie to co trzeba wdrożyć w ramach RODO. Tych dokumentów jest od kilku do kilkunastu więcej. Zależy to od ilości klientów wielkości i zakresu działań.  Natomiast te dwa dokumenty to nie jest tylko i wyłącznie to, co wymaga RODO. Oczywiście programista musimy mieć umowę powierzenia zawartą tak jak zawsze, jeżeli mówimy o B2B oczywiście. Natomiast tego jest znacznie więcej, np.: polityka usuwania danych osobowych, albo wewnętrzne rejestry, które musimy prowadzić zarówno dla klientów jako podmiot przetwarzający, jak i dla dla siebie, jako administratora, względem np.: pracowników swoich.

Nie będę tu wchodził w szczegóły, bo to jest temat taki gdzie jest tego sporo, musiałbym wyjaśniać co to jest podmiot przetwarzający albo kto jest administratorem. Natomiast w stosunku do umowy o pracę nie mamy wtedy umowy powierzenia tylko po prostu nadajemy upoważnienia danemu pracownikowi. To jest po prostu pół strony A4 gdzie zobowiązujemy do zachowania poufności i wskazujemy mu zakres danych albo baz, do których będzie miał dostęp.To jest ta różnica pomiędzy B2B a umową o pracę. 

Przy B2B umowę powierzenia znamy, podpisujemy ją z Googlem, podpisujemy za AWSem, z wieloma różnymi firmami. Upoważnienia są troszkę mniej znane, a trzeba je w ramach umów o pracę zawrzeć po prostu z tym programistą.

Natomiast po stronie programisty umowa o pracę pod kątem RODO, myślę że będzie bardziej korzystniejsza, bo przy B2B programiści mają własne firmy, własne działalności. Tak więc obowiązki wynikające z RODO, które ma software house, nagle musi mieć też programista.  Oczywiście najczęściej nie ma, powiedzmy sobie szczerze, ale jednak powinien mieć, zgodnie z prawem. Oczywiście zakres tych dokumentów, obowiązków będzie mniejszy niż przy software housie, który ma 50 klientów i zatrudnionych 100 programistów. Programista jest jeden i ma jednego klienta, którym jest software house. Natomiast programista przy B2B też musi pamiętać, że on RODO powinien mieć wdrożone u siebie.  Przy umowie o pracę nie musi mieć bo jest jakby pracownikiem i wszystkie obowiązki są po stronie software house. Natomiast jeżeli jest to programista B2B to powinien mieć z zasady te rzeczy wdrożone również u siebie. 

Natomiast programista przy B2B też musi pamiętać, że on RODO powinien mieć wdrożone u siebie.  Przy umowie o pracę nie musi mieć bo jest jakby pracownikiem i wszystkie obowiązki są po stronie software house. Natomiast jeżeli jest to programista B2B to powinien mieć z zasady te rzeczy wdrożone również u siebie. 

Powiem szczerze, że może kilku takich programistów znam, którzy mają takie dokumenty i przykładają do tego wagę.

Tak, zgadza się. No i właśnie to co teraz powiedziałeś jest takim dowodem na to, że nie ma co się opierać na darmowych szablonach umów znalezionych w Google, tylko lepiej w takich sytuacjach zwrócić się do osoby, która jest kompetentna, która  ma też wiedzę osadzoną w IT. Ty nie tylko wspierasz programistów, ale także software house’y w tych działaniach. W czym tego typu osoby, podmioty mogą się zwrócić do ciebie o pomoc?

Jeśli chodzi o programistów to tutaj głównie są to  kwestie zmiany umów, które dostają ci programiści, kwestie konsultacji tych umów, kwestie pomocy w negocjacjach, kwestie RODO, jak najbardziej. Natomiast po stronie software house to tak naprawdę od A do Z. Sprowadzamy z zagranicy do Polski software house’y, które chcą mieć oddziały w Polsce, swoje własne, żeby tutaj, na polskich warunkach zatrudniać, mimo tego, że sami są z innego kraju. Z drugiej strony regulujemy te wszystkie kwestie, które są niezbędne do tego, żeby ten software house prowadzić w miarę bez ryzyka, albo żeby jak najwięcej tych ryzyk przewidzieć, czyli w zakresie umów z klientami, jak i podwykonawcami swoimi. To jest dosyć szeroki zakres natomiast popularne jest 360 i my robimy 360 dla software house’ów.

Rozumiem. Arkadiusz Szczudło z kancelarii Creativa Legal był moim gościem, rozmawialiśmy o prawnych aspektach umów IT. Jarku  bardzo Ci dziękuję za poświęcony czas, za podzielenie się wiedzą.

Ja również dziękuję bardzo.

Powiedz gdzie można Cię znaleźć w internecie, gdzie można odesłać słuchaczy.

Jako Arkadiusz Szczudło znajdziecie mnie w każdym medium społecznościowym, jestem nawet na TikToku i tam także obserwuję programistów. Jak najbardziej moje imię i nazwisko wpiszecie w Googlu, na Facebooku, na Linkedina, dodajcie mnie, zapraszam, oczywiście każdego przyjmę. Czy teraz będzie jakaś potrzeba, czy w przyszłości, warto budować relacje i swoją sieć. 

Te linki oczywiście dodam do odcinka. Jeszcze raz bardzo Ci Arku dziękuję i życzę udanego dnia. Do usłyszenia.

Dzięki wielkie, Tobie też.

I to na tyle z tego co przygotowałem dla Ciebie  na dzisiaj.  Po więcej wartościowych treści zapraszam Ciebie do wcześniejszych odcinków.  A już teraz z tym co czujesz, wystaw ocenę, recenzję, komentarz w aplikacji, w której słuchasz lub w social mediach.  Zawsze możesz się ze mną skontaktować pod adresem krzysztof@porozmawiajmyoit.pl lub przez media społecznościowe. 

Ja się nazywam Krzysztof Kempiński a to był odcinek podcastu Porozmawiajmy o IT, o prawnych aspektach umów IT.  Zapraszam do kolejnego odcinka już wkrótce.

Cześć!