Z tego odcinka dowiesz się, jakie kwestie są istotne w umowach, które software house podpisuje ze
zleceniodawcą.
Powiem Ci w szczególności:
- od czego można uzależnić przeniesienie praw autorskich,
- czy zawsze warto przenosić prawa autorskie do kodu źródłowego,
- czy kara umowna zawsze zabezpieczy wszystkie Twoje umowne interesy,
- jakie rozliczenia umowne można wprowadzić w umowie w IT
i wiele, wiele innych rzeczy, które będą dla Ciebie przydatne, niezależnie od tego czy jesteś software
housem czy zleceniodawcą!
Zapraszam do słuchania oraz do pobrania bezpłatnego niemal 200 stronicowego ebooka Prawo dla Biznesu. IT, w którym znajdziesz prawie 200 stron informacji na temat najważniejszych aspektów prawnych w IT!
- Zapisz się na newsletter -> https://mailchi.mp/cc5a6cdc6fb8/newsletter-dla-biznesu
- Ebook Prawo dla Biznesu. IT – http://bityl.pl/YLATo
- Prawo dla Biznesu. E-commerce – https://bit.ly/3dKZWy7
Słuchaj podcastu
Cześć,
Z tej strony Piotr Kantorowski, a to kolejny odcinek podcastu „Prawo dla biznesu”.
Ostatnio moim gościem był mój wspólnik Paweł Głąb, który opowiadał Wam o RODO. W zasadzie mogę powiedzieć, że to nie pierwszy raz, kiedy opowiada Wam Paweł o RODO, bo mówiąc krótko, w dzisiejszym świecie specjalizacji, trudno oczekiwać od kogokolwiek żeby znał się na wszystkim, a może lepiej nie oczekiwać od niego takich rzeczy, no i mamy ten komfort w ramach kancelarii, że jest nas większa ilość, więc nie każdy musi się na wszystkim znać, a Paweł ewidentnie, w przeciwieństwie do mnie, zna się bardzo dobrze na RODO, dlatego właśnie o tym wam opowiadał. Dzisiaj kontynuujemy temat IT, bo Paweł mówił o RODO w IT. Kolejne kwestie, które chcę poruszyć, będą w pewnej mierze powrotem do tematyki skonstruowania umów w IT, a pewnej mierze będą nawiązaniem do RODO, bo miałem w zasadzie ten odcinek poświęcić czemuś innemu, a o kwestiach, o których chcę dzisiaj powiedzieć, być może już nie mówić, ale Paweł tyle razy poruszył kwestię umów o zachowaniu poufności, że pomyślałem, że dobrze byłoby skupić się jeszcze na kilku aspektach dotyczących tego, w jaki sposób powinniśmy finalnie zabezpieczyć swoje wzajemne interesy, dotyczące realizacji umów IT. Trochę tak może bez większego przełożenia czy są to umowy zwinne czy jest to waterfall czy jest to jakaś inna forma współpracy czy zwykła umowa o dzieło, której przedmiotem będzie program komputerowy. Pytaniem otwartym pozostaje czy w tym przypadku będzie to program komputerowy w rozumieniu ustawy o prawie autorskim czy bardziej oprogramowanie komputerowe. Innymi słowy czy będzie tu element twórczy czy go nie będzie, no to zostawiam to już na marginesie.
W pierwszej kolejności chciałbym powiedzieć, że często w trakcie współpracy między software house’m a zamawiającym, pojawia się temat udostępnienia software house’owi pewnych, określonych informacji dotyczących firmy, przekazania pewnej ilości danych, bo choćby zlecenie może dotyczyć stworzenia bazy danych to niekoniecznie muszą być dane osobowe, które mają być zawarte w bazie danych. Mogą to być dane w głównej mierze dotyczące jakiś informacji handlowych z taką segmentacją, która nie będzie odnosiła się do danych osobowych, chociaż te dane osobowe mogą się gdzieś pojawić, ale o tym mówił Paweł, nie będę do tego wracał. Może się nam pojawić temat tego rodzaju, że zlecenie wykonania danej aplikacji, danego oprogramowania, będzie dotyczyło czegoś, czego jeszcze na rynku nie ma i będziemy się chcieli zabezpieczyć przed tym, że finalnie wdrożenie nie nastąpi ze strony zamawiającego, a ze strony software house’u. Pewnie w niektórych sytuacjach może być też tak, że na etapie weryfikacji ofert złożonych przez software house, zamawiający będzie chciał zapoznać się z już wcześniej wykonywanymi aplikacjami, wykonywanymi zleceniami przez software house i z tego powodu będzie chciał poznać kod źródłowy dotyczący tych rozwiązań, które już wcześniej się w pojawiły w ramach danego software house’u. To wszystko wymusza zabezpieczenie przekazywanych sobie wzajemnie informacji i oczywiście wrócę do czegoś, o czym wspominałem w poprzednich odcinkach dotyczących prawa w IT, oczywiście będziemy tu mieli ustawę o zwalczaniu nieuczciwej konkurencji, i będziemy tu mogli na podstawie tej ustawy chronić tajemnicę naszego przedsiębiorstwa. Będziemy tu mieli patenty, prawa autorskie i to wszystko oczywiście nas chroni i broni, natomiast czasem chcemy się zabezpieczyć dodatkowo umową, która w pewien sposób da jasność stronom, co tak konkretnie będą sobie udostępniać, na jakich zasadach będzie to mogło być wykorzystywane, co mogą w ramach tego zrobić, do czego mogą dane rzeczy wykorzystać, czasem powiedziałbym tak – jasność pewnych rozwiązań jest wyżej ceniona niż sankcja i jej wysokość, bo to, że nad którąś ze stron umowy będzie „wisieć miecz”, który może spaść w określonej sytuacji, tzn. kiedy dopuści się takiego czy innego naruszenia. Może miało wizualizować jej to, czego realnie robić nie może, czy robić nie powinna, a gdy zapiszemy to w umowie to staje się to bardziej jasną i klarowną kwestią. Do tego służą najczęściej umowy o zachowaniu poufności, w Polsce często tak obiegowo określane, jako NDA i tu będę się często takim sformułowaniem potocznym zupełnie posługiwał, natomiast ci, którzy się z tym sformułowaniem nie spotkali, to od tego momentu wiedzą, że umowa o zachowaniu poufności to będzie NDA, nie będę używał tego skrótu po angielsku, bo wydaje się, że on dostatecznie zadomowił się w naszym rodzimym systemie prawnym, że troszeczkę się spolszczył. Wiadomo, że zależy na jaką grupę prawników się trafi, pewnie gdzie indziej będzie to totalnie od strony języka angielskiego odczytywane, ja przyjmuję takie moje prawo. Wracając do meritum podpisując taką umowę możemy w sposób precyzyjny określić, które informacje uważamy za poufne, które uważamy za tajemnicę przedsiębiorstwa, na jakich zasadach wszystkie te informacje możemy przekazywać osobom trzecim, jakim osobom trzecim, do kogo nie mogą te informacje dotrzeć, możemy też przewidzieć sankcję za naruszenie tej umowy o zachowaniu poufności. I na to ostatnie chciałbym zwrócić szczególną uwagę, bo myślę, że to jest jakby pierwsza rzecz, od której należy rozpocząć czytanie takiej umowy, mianowicie bardzo często w takich umowach pojawia się kwestia kar umownych, które czasem są, powiedziałbym, z dużą fantazją określane kwotowo, bo przy kontraktach np. na 10 tys. złotych, bez znaczenia czy netto czy brutto, potrafią pojawić się kary umowne idące w kwoty pół miliona złotych, miliona złotych i teraz pytaniem otwartym jest, nawet mając najlepsze intencje i nie chcąc naruszyć jakichkolwiek praw drugiej strony, jakichkolwiek kwestii związanych z jej tajemnicą przedsiębiorstwa, czy taką umowę na pewno chcemy podpisać. Innymi słowy czy chcemy zaryzykować, że dajmy na to, któryś z naszych pracowników pozwoli sobie bezprawnie skorzystać z wiedzy przekazanej przez kontrahenta, ryzykując zapłatą 100 tys. złotych czy 500 tys. złotych, mając w perspektywie do zarobienia te wspomniane 10 tys. złotych. Tu myślę, że jest się nad czym zastanowić, i dlatego tu rekomendowałbym zacząć analizować umowy NDA właśnie od kwestii dotyczącej tego, czy są w nich zastrzeżone kary umowne, bo jeśli tak, no to trzeba się zawsze zastanowić nad kwotą, nad którą opiewa ta kara umowna. Czy ona jest adekwatne do tego, co na danym kontrakcie realnie i finalnie zyskać. Jeżeli nie jest adekwatna to polecam negocjować albo poważnie przemyśleć czy daną umowę podpiszemy, no bo to przecież na tym polega, że jeżeli umowę uważamy za nierentowną biznesowo to nie jest powiedziane, że powinniśmy ją podpisywać i tutaj podkreślę, że co prawda sąd ma możliwość zmiarkowania kary umownej, ale czy funkcjonowanie, jako firma z procesem na kilkaset tysięcy czy na kilka milionów przez rok czy dwa, wpłynie korzystnie na nasze osiągnięcia biznesowe? Wydaje mi się, że wpłynie jednak nie najlepiej na osiągnięcia biznesowe, dlatego na to zwróciłbym uwagę od strony osoby, na którą jest nakładana kara umowna, natomiast od strony osoby, na rzecz której jest nakładana kara umowna, zwróciłbym w szczególności uwagę na to, czy w tego typu umowie jest możliwość dochodzenia odszkodowania na zasadach ogólnych. Jeśli okaże się, że sytuacja jest tego typu, że szkoda, którą ponieśliśmy jednak jest większa od kary umownej, która na ten wypadek została zastrzeżona. Jeżeli ta szkoda większa nie jest, no to oczywiście nie będzie problemu, ale problem pojawi się jeśli ta szkoda będzie większa i jeśli finalnie okaże się, że wyszliśmy na tym wszystkim trzy razy do tyłu, bo brak postanowienia uniemożliwia nam dochodzenia odszkodowania, przewyższającego karę umowną. To są kwestie podstawowe w kontekście umów o zachowaniu poufności. W drugą stronę też rzeczą do przemyślenia jest zawsze przy zawieraniu jakichkolwiek umów, nie będę ograniczał tego tylko do IT, ale w kontekście IT to powiem, że są to kwestie dotyczące z perspektywy kontraktu B2B tego czy w jaki sposób chcemy uregulować sytuację związaną z potencjalnym przejęciem naszych pracowników przez naszego kontrahenta, w przypadku, gdyby uznał on, że jednak taniej mu wyjdzie zatrudnienie nawet za wyższą kwotę niż zlecanie nam dalej poszczególnych czynności, no takie potencjalne ryzyko będzie przy umowach body leasingowych, gdzie no ci pracownicy niejednokrotnie będę przebywać właśnie w siedzibie wręcz zleceniodawcy, więc to jest kwestia, na którą zwróciłbym uwagę. Czy takie postanowienia chcemy wprowadzić, jak je wprowadzamy, takie postanowienia dotyczące przejęcia pracowników i tutaj też kara umowna byłaby wskazanym rozwiązaniem, jako swoiste zabezpieczenie ewentualnych, potencjalnych problemów, które mogą wyniknąć. Od strony software house’u do rozważenia jest też kwestia zakazu konkurencji dla deweloperów i innych uczestników całego procesu programistycznego czy całego procesu związanego z tworzeniem oprogramowania, natomiast wydaje mi się, nie jest tak, że się obawiam, bo to nie jest moja branża, ale tu wydaje mi się i na obserwację tak jest, zakaz konkurencji w ramach IT na rok 2020 jest mało możliwym rozwiązaniem. Być może przy jakichś bardziej specyficznych projektach jest możliwe wprowadzenie tego rozwiązania, ale jeżeli chodzi o typowego programistę to raczej mała na to szansa, jeżeli mówimy o typowych powtarzających się na rynku kwestiach związanych z działalnością w zakresie IT. Warto o tym wspomnieć, że w przypadku programistów czy innych osób zatrudnionych w software house’ie, którzy działają w ramach B2B, to pole manewru w zakresie zakazów konkurencji jest znacznie wyższe, a w przypadku umów o pracę no to tutaj kodeks pracy nam to znacząco ogranicza, można bez odszkodowania zawrzeć zakaz konkurencji w trakcie stosunku pracy, natomiast po ustaniu stosunku pracy można taki zakaz konkurencji podpisać jedynie z osobami, które mają dostęp do ważnych i istotnych z perspektywy firmy, informacji. One mogą być handlowe, marketingowe, mogą być programistyczne, ale muszą być ważne i z drugiej strony jest też tak, że taki zakaz po ustaniu stosunku pracy może być tylko i wyłącznie za zapłatą stosownego odszkodowania, które nie może być niższe niż 25% wynagrodzenia, które utrzymywał deweloper w okresie odpowiadającym czasowi, przez który będzie go obowiązywał zakaz konkurencji, czyli np. pół roku, jeśli ten zakaz konkurencji ma obowiązywać przez pół roku. Finalnie tu warto też wiedzieć, że ten zakaz konkurencji nie musi być wypłacony jednorazowo, a w zasadzie to odszkodowanie za zakaz konkurencji nie musi być wypłacany jednorazowo, może być wypłacany w ratach. To jest kwestia zabezpieczenia się w trakcie wykonywania umowy, natomiast moim zdaniem jest jeszcze jedna mega istotna rzecz związana z zabezpieczeniem się w ramach umów IT, mianowicie chodzi o kwestię dotyczącą zapłaty wynagrodzenia. Szczególnie chodzi o software house’y i w jaki sposób do tego tematu podchodzić. Ja już sporo mówiłem na ten temat. W szczególności będzie tu kwestia tego za co jest płacone, czy jest płacone za robienie czy za zrobienie, bo to w ogóle zmienia nam postać rzeczy. Jeżeli jest płacone za robienie to co do zasady to wynagrodzenie będzie przysługiwać, no chyba, że sposób wykonywania umowy był sprzeczny z zasadami programowania, no to wtedy trudno mówić, że się płaci za czas spędzony przed komputerem, a nie za czas programowania, to jednak jest w ten sposób, że zapłata w ramach IT należy się za programowanie, a nie za siedzenie przed komputerem. Natomiast często pojawia się problem, jeżeli mamy do czynienia z sytuacją, która jednak sprowadza się do zlecenia wykonania określonego oprogramowania i wadami, które mogą się pojawić, a wręcz IT nie odbiega od standardów, że jakieś wady tego oprogramowania mogą się pojawiać. I tutaj trochę sytuacja wygląda tak, że dobrze jest, jeżeli uregulujemy to w sposób precyzyjny w umowie, bo tak zawsze jest najlepiej, bo prowadzimy do tego, że mamy jasną i czytelną sytuację i postanowienia zgodne z intencjami stron, a nie takie jak narzuca nam kodeks. Kodeks powinien mieć zastosowanie bardziej w optyce przeoczenia czegoś, a nie regulowania założenia pewnych kwestii, natomiast jest tu pewien haczyk. Często, jeżeli umowy są narzucane przez zamawiających dochodzi do wprowadzania w nich zapisów postanowień idących w kierunku takim, że do momentu bezusterkowego odbioru, no w zasadzie w ogóle nie ma mowy o tym, żeby móc oczekiwać jakiekolwiek wynagrodzenia i tutaj warto odwołać się do orzecznictwa, które jednak nie podziela zgodności z prawem tego typu postanowień. Jest w orzecznictwie często mowa, o tym, że jasne, jeżeli finalnie wykonane, będzie tu jednak umowa o dzieło i dzieł o usługach, bo usługi to są właśnie wynagrodzenie za robienie, a nie za zrobienie, że finalnie wykonane dzieło jest wadliwe w stopniu, który co najmniej znacząco utrudnia wykorzystanie tego dzieła do przeznaczonych celów. Taka sytuacja może faktycznie prowadzić do braku zapłaty, natomiast orzecznictwo podkreśla wyraźnie, że jeżeli wady są nieistotne, są drobne, nie może to stanowić podstawy odmowy zapłaty, że tego typu wady mogą być i powinny być usuwane, ale w ramach rękojmi, ewentualnie gwarancji. Krótko powiem o różnicy – rękojmia przysługuje z mocy samych przepisów, można ją co najwyżej wyłączyć, znaczy w przypadku umów B2B, bo z konsumentami takiej możliwości nie ma, ale najrzadziej programuje się jednak dla konsumentów, najczęściej jednak dla firm. Z drugiej natomiast strony gwarancja jest tylko o tyle, o ile zostanie ona przyznana danej firmie. Nie musi być w osobnym dokumencie, mimo, że przepis tak realnie stanowi, ale z drugiej strony może być wprowadzona w takim osobnym dokumencie, albo w samej umowie. To są kwestie ważne w kontekście zabezpieczenia się na wypadek braku zapłaty, żeby wiedzieć o tym, że nie samo wystąpienie jakiejkolwiek wady może być przyczyną do odmowy uiszczenia na naszą rzecz płatności, przy czym jednak niestety w IT, jak i w każdej innej branży, istnieje sytuacja tego typu, no jednak brak płatności może się często skończyć w sądzie. Tu pewnym rozwiązaniem byłoby wprowadzenie takich postanowień umownych, o których zaraz powiem i one mogą często ochronić software house, poprzez nie tyle wymuszenie płatności, co stworzenie takiej sytuacji, że brak płatności prowadzi do odwrotności sytuacji win-win, nie wiem jak to nazwać, sytuacją luz-luz czy software house nie dostaje nic a zamawiający także nic. Chodzi o to, że można w umowie wprowadzić postanowienia, zgodnie z którymi przeniesienie, jeżeli w ogóle mówimy o takim rozwiązaniu, że software house przenosi wyjątkowe prawa autorskie na zamawiającego, to można wprowadzić postanowienia, zgodnie z którymi przeniesienie tych majątkowych praw autorskich na zamawiającego nastąpi dopiero z chwilą dokonania zapłaty należnego wynagrodzenia, albo dokonania zapłaty wynagrodzenia w jakimś tam procencie, albo za daną część wykonanych prac. Jeżeli nawet mamy do czynienia z licencją wyłączną to tak samo można to do tego odnieść. Tu będziemy mieli sytuację tego rodzaju, że brak zapłaty pozbawi możliwości zamawiającego do korzystania z oprogramowania, które zostało dla niego wytworzone, a korzystanie z takiego oprogramowania może być w pewnych sytuacjach uznane nawet za przestępstwo, więc tu jednak będzie taka sytuacja wzajemnego ścierania się tych roszczeń i przez to będzie obu stronom zależeć na tym, żeby jednak gdzieś ugodowo i polubownie się porozumieć, bo nawet jeżeli racje ma zamawiający, że program ma pewne wady, to może być tak, że będzie mu lepiej ponegocjować kwotę ostatecznie do zapłaty niż odmawiać zapłaty w całości, ryzykując wprowadzeniem tego oprogramowania na rynek dopiero np. za dwa czy trzy lata po procesie sądowym, bo ten proces sądowy może tyle przed sądem własności intelektualnej trwać, może trwać też dłużej, bo na ten moment, gdzie nagrywam podcast, czyli blisko lipca, to żadna sprawa jeszcze się w tym sądzie nie skończyła. W zasadzie nie mogę wykluczyć, że jakaś się zaczęła, bo na pewno tego nie potwierdzę.
Na dzisiaj to już chyba wszystkie informacje. Będę powoli kończył cykl o IT, natomiast są jeszcze pewne kwestie, które chciałbym poruszyć. Ja wiem, że był odcinek z Łukaszem Gągałą IT, podatków w IT, ale chyba jednak chciałbym jeszcze raz do tego wątku wrócić, mniej „rozmowowo”, a bardziej „wykładowo” go przedstawiać, bo to jest bardzo ważny temat, więc chyba pokuszę się jeszcze na ten temat. Chciałbym jeszcze powiedzieć coś o blockchainie, może o sztucznej inteligencji, chociaż to chyba tematy mogą być tematy na tyle z wyższej półki, że do ich przeprowadzania nie będziemy się opierać wiedzą, którą można nabyć poprzez podcast, ale przynajmniej blockchain chciałbym omówić, jak to wygląda ze strony prawnej.
Pozwolę sobie przypomnieć, zrobić reklamę naszej najnowszej książki, pierwszej książki „Prawo dla Biznesu. E-commerce”, myślę, że jest to pozycja warta polecenia dla wszystkich, którzy działają w e-commerce oraz dla tych, którzy działają z podmiotami działającymi w e-commerce. Krótko mówiąc, sytuacja przedstawia się w ten sposób, że mówiąc najprościej jest to po prostu pigułka wiedzy przedstawiająca wszystkie najważniejsze zagadnienia związane z e-commerce, z procedurami, wzorami umów i objaśnieniami. Krótko mówiąc jeżeli masz mały budżet na obsługę praw i miałbyś wybrać jedną rzecz, która pozwoli Ci przejść przez e-commerce od strony prawnej, także ogromną ręką i suchą nogą to myślę, że nasza pozycja jest na pewno dobrym wyborem.
