Prawo w projektach e-commerce B2B – umowy, prawa autorskie i kontrola nad platformą

Wyobraź sobie taką sytuację. Wydałeś kilkaset tysięcy złotych na platformę B2B. Projekt trwał miesiącami. Klienci zaczęli kupować. Platforma zaczęła działać nowocześnie i przynosić pierwsze pieniądze, a potem chcesz rozwinąć swoją platformę, chcesz ją rozwijać dalej, chcesz zmienić agencję, chcesz wprowadzić nowy model sprzedaży, nowy kanał sprzedaży, chcesz zwyczajnie chociażby przenieść ją na własny serwer, jeżeli to było rozwiązanie open source i nagle słyszysz, że nie możesz, bo nie masz prawa do kodu, bo nie jesteś właścicielem UI, czyli szablonu wyglądu tej swojej platformy, bo agencja nie przeniosła majątkowych praw autorskich na ciebie, bo nie masz dostępu do repozytorium kodu, bo cóż, całość została zaprojektowana tak, że bez dostawcy twoja platforma nie działa. Brzmi jak absurd. To nie jest absurd. To jest rzeczywistość w wielu firmach i w wielu wdrożeniach. Dlatego dziś opowiem nie o technologii, a o kwestiach, które blokują tak naprawdę rozwój firmy, i błędach, które nie dotyczą systemów, dotyczą aspektów prawnych, które są bardzo ważne, jeśli chodzi o wdrożenia platform B2B. No żeby się nie okazało, że nie jesteś właścicielem, tylko wynajmujesz tę platformę. A to jest duża różnica, kiedy na początku myślisz, że jesteś właścicielem, a potem się okazuje, że wcale tak nie jest. To nie jest kwestia tylko i wyłącznie prawa. To nie są rzeczy nudne. To są rzeczy ważne, bo to jest bezpieczeństwo twojego biznesu. Dzisiejszy odcinek poświęcony kwestiom prawnym.

 

 

Dlaczego prawo decyduje, czy platforma jest naprawdę Twoja?

 

Zacznijmy od tematu, kluczowego wątku. Dlaczego prawo decyduje o tym, czy platforma jest naprawdę twoja. Mówię tu o założeniu wynikającym z wdrożenia na podstawie platformy dedykowanej albo platformy open source. Jeżeli wdrażasz rozwiązanie SaaS, od razu z automatu wiesz, że jesteś wynajmującym. Jesteś w roli wynajmującego i wiesz, że płacisz za dostęp do platformy, za jej używanie. Płacisz abonamentowo. Dopóki płacisz abonament, to możesz z tej platformy korzystać. Trzeba być świadomym właśnie też tej kwestii, chociaż czasami w tym przypadku wychodzi później, że klient nie był świadomy, że wybrał rozwiązanie SaaS. Myślał, że skoro zapłacił za realizację, to to rozwiązanie jest jego. Także nie tylko w przypadku open source albo dedykowanych platform potrafi się okazać, że inaczej myśleliśmy, a inaczej wyszło w praktyce.

 

Ale żeby nie było, wracamy do wątku. Dlaczego prawo, to prawo decyduje, że ta platforma jest naprawdę twoja? To niektórzy powiedzą: „Jak to możliwe, skoro ja za coś płacę?”. Tak, płacę, to jest moje. No nie do końca płacisz, ale teraz płacisz za co? Płacisz właśnie za to, że coś jest twoje, że dostaniesz to na własność. Czy płacisz za realizację czegoś dla ciebie, ale to coś, co będzie wyprodukowane, należy do kogoś innego. To znaczy możesz z tego korzystać dopóki płacisz, czyli wynajmujesz.

 

Możesz ewentualnie w tym przypadku negocjować, żeby to kosztowało trochę mniej. Zazwyczaj się tak robi. Jeżeli jesteś w ogóle świadomy tego, że w takim modelu to działa, to jeżeli na przykład dostawca SaaS zamierza to włączyć do swojego produktu, taką funkcjonalność, za którą ty płacisz, to możesz negocjować, żeby uproduktowić też wycenę, to znaczy, żeby dostawca pokrył częściowo albo pół na pół pokrył koszt takiego rozwiązania. Wtedy ty otrzymujesz je w ramach abonamentu. Częściowo płacisz za wyprodukowanie, bo jednak było wyprodukowane początkowo tylko dla ciebie, ale dostawca ma prawo do kodu tej funkcjonalności i może ją sprzedawać dalej, jeżeli uzna, że jest to coś, co może po prostu sprzedać swoim innym klientom. Więc w tym przypadku można tutaj negocjować to podejście, ale jeśli jesteś tego świadomy.

 

Natomiast wracając, to, że zapłaciłeś za coś nie znaczy, że to jest twoje. To dopiero zapisy umowne, czyli to na co się umawiacie, co sobie dajecie, przekazujecie w zamian za te pieniądze, dopiero to decyduje o tym, czy coś jest twoje. Realizacja projektu oznacza, właściwie może w drugą stronę, nie oznacza z automatu przeniesienia praw autorskich, majątkowych praw autorskich do tego, co zostanie wytworzone. Nie oznacza z automatu zmiany, możliwości zmian w kodzie tej platformy, w ogóle dostępu do tego kodu, dostępu do takiego technologicznego administrowania platformą, czyli na przykład dostępu do serwerów. Nie oznacza też na przykład kontroli nad domeną, bo może się okazać, że domena też należy do dostawcy albo do agencji.

 

Więc tu trzeba bardzo mocno na to uważać, bo można zapłacić za platformę B2B, ale nie mieć prawa używać jej i rozwijać w taki sposób, jakbyśmy chcieli, poza agencją, czyli bez zgody agencji, która dla nas to wyprodukowała, bo to właśnie kwestie prawne decydują o tym, czy będziesz właścicielem tej platformy, która została wyprodukowana, czy będziesz mógł ją rozwijać, czy będziesz mógł coś w niej zmieniać, czy będziesz mógł zmienić wykonanie w ogóle, czyli agencję, która obsługuje ciebie jako firmę. Czy twoje dane będą bezpieczne? To jak są przechowywane, kto ma do nich dostęp, kto ma do nich prawo de facto. Czy nie utkniesz tak naprawdę z jednym dostawcą na lata, który będzie ci dyktował cenę za korzystanie właśnie z platformy, za korzystanie z platformy, bo platforma będzie należała do niego.

 

NDA – pierwsza ochrona Twojego know-how

 

Jak się zatem ochronić, tak? Jak się zabezpieczyć w tej sytuacji? Pierwszą ochroną jest tak zwany NDA, czyli umowa o zachowaniu poufności. Jest to ochrona twojej firmy, ochrona twojego know-how, czyli wszystkich informacji kluczowych dla twojego biznesu, dla jego prowadzenia, dla utrzymania przewagi rynkowej. NDA nie uchroni przed samym dostawcą, czyli przed tymi zapisami, co jest czyje, bo ta umowa tego nie dotyczy. Nie dotyczy przekazania praw do platformy i nie sprawi, że będziesz jej właścicielem.

 

Jest to pierwsza umowa, którą podpisujemy wchodząc w projekt z dostawcą. Umowa, która mówi o zachowaniu poufności, czyli która strzeże twoje know-how, twoje dane, informacje o tym, jak wyglądają procesy w twojej firmie, jak wyglądają dane, jakie ty masz dane w firmie. Więc to jest umowa, która ma ciebie ochronić przed tym, żeby te dane nie wyciekły, przed tym, żeby dostawca, widząc chociażby zakres analizy przedwdrożeniowej, nie zrealizował takiego projektu u innego klienta, bo przecież jeżeli nie ma żadnych zastrzeżeń, to może to zrobić. Więc jest to pierwszy krok, żeby kontrola była po twojej stronie i żeby się zabezpieczyć, zanim ktokolwiek zobaczy, co masz, że tak powiem, kolokwialnie w środku.

 

I kiedy podpisujemy umowę NDA, czyli tą umowę o zachowaniu poufności. Zawsze przed rozmowami o danych, przed przekazaniem jakichkolwiek danych, przed analizą procesów, żeby ktoś zobaczył jak wyglądają procesy w twojej firmie, przed przekazaniem dostępów do systemów wewnętrznych firmy. Jeżeli masz obecnie jakąś platformę e-commerce B2B, czy do systemu RP, czy do jakichkolwiek innych systemów, to wtedy też musimy się zabezpieczyć taką umową przed jakimiś warsztatami analitycznymi wdrożeniowymi, podczas których będziesz mówił o szczegółach tego, jak pewne rzeczy wyglądają w twojej firmie, udostępnisz jakiekolwiek analizy i tak dalej, przed też wymianą jakichkolwiek dokumentów, dokumentacji, które mówią na temat twojej firmy. Powiedziałam tak ogólnie, bo to mogą być różnego rodzaju dokumenty, ale przed wymianą jakichkolwiek plików, dokumentów też warto podpisać tą umowę.

 

Po co się podpisuje tą umowę? Podpisuje się ją po to, żeby chronić know-how swojej firmy, żeby chronić dane klientów i swoich partnerów, żeby chronić też to, co jest właśnie poufne, czyli procesy, cenniki, do których w B2B jest bardzo trudno dotrzeć. Więc każdy chciałby mieć do tego dostęp, żeby chronić wrażliwe informacje finansowe, żeby też chronić dostępy do systemów, z których można wyczytać dużo więcej o twojej firmie. Na co zwracać uwagę przy takiej umowie o zachowaniu poufności? Na zakres ochrony, czyli co dokładnie obejmuje ta umowa o zachowaniu poufności, jakie dane, jakie pliki chronimy i są chronione zgodnie z tą właśnie umową. Czas obowiązywania tej umowy, czas zazwyczaj dłuższy niż czas współpracy nawet z dostawcą, czy czas w ogóle rozmów chociażby na temat tej współpracy, w których trzeba ujawnić pewne informacje. To musi być odpowiednio długi czas, w którym te dane mogą się, że tak powiem, zdezaktualizować i jakby wypłynęły, to nie zaszkodzą de facto twojemu biznesowi. Już również trzeba zwrócić uwagę na zakres odpowiedzialności za naruszenia, na sposób rekompensaty, czyli tak zwane kary umowne, które wpisujemy za naruszenia zasad poufności. I pamiętamy o tym, że to NDA działa w dwie strony, czyli ty jako klient się zabezpieczasz, ale z drugiej strony możesz otrzymywać informacje i know-how od dostawcy, który też ma doświadczenie w różnych projektach, które realizował. Może coś podpowiedzieć, jeżeli ma taką możliwość. Więc to know-how i jakby te zasady poufności w ogóle obowiązują też w drugą stronę. Ta umowa to jest bezpieczeństwo całego projektu i tego, że nic nie wypłynie, podczas gdy na przykład twoja konkurencja może robić dokładnie to samo co ty.

 

Umowa na analizę przedwdrożeniową – dlaczego musi być osobno?

 

Skoro jesteśmy przy umowach, to idźmy po kolei fazami projektu i umowami, jakie trzeba podpisać na kolejnych etapach takiego projektu. Byliśmy na samym początku, czyli mamy tą umowę NDA o zachowaniu poufności. To jest etap, w którym przystępujemy do rozmów z dostawcą. Zaczynamy opowiadać o swojej firmie. Przekazujemy informacje. Jeżeli podpisujemy z tym dostawcom umowę na analizę przedwdrożeniową, jakieś warsztaty analityczne, jeżeli analizę przedwdrożeniową robi ci zewnętrzny konsultant w twojej firmie, jeżeli to nie jest część, powiedzmy, pracy z dostawcą, tylko jest to inna osoba, ta kwestia dotyczy wszystkich.

 

Na analizę przedwdrożeniową podpisujesz umowę, w której regulujesz wszystkie kwestie związane właśnie chociażby z poufnością. Jeżeli wcześniej nie była podpisywana umowa, tylko dogadaliście się od razu, ta umowa NDA, tylko dogadaliście się od razu na analizę przedwdrożeniową, to wystarczy w takiej umowie na analizę zawrzeć odpowiedni paragraf, który też będzie regulował kwestie poufności. Nie jest wtedy potrzebna dodatkowa umowa, chociaż warto podpisać osobną umowę NDA, która będzie miała na przykład dłuższy czas obowiązywania niż umowa na analizę, bo ta jest zazwyczaj sporo krótsza.

 

I teraz umowa na analizę powinna być osobną umową podpisaną celowo na analizę. Trzeba w niej zadbać też o przekazanie majątkowych praw autorskich, a o nich za chwilę jeszcze trochę więcej powiem. Natomiast często może się zdarzyć tak, szczególnie u dostawców rozwiązań e-commerce, platformy, czyli de facto oprogramowania. Może być tak, że analiza przedwdrożeniowa będzie połączona już z wdrożeniem, czyli de facto podejmujesz decyzję o tym, że wdrażasz dane oprogramowanie, jeszcze do końca w sumie nie wiedząc, czy ono spełnia twoje wymagania, bo jeszcze tej analizy nie było. Tak więc w tym przypadku dostawcy często chcą podpisać jedną umowę na analizę, już na wdrożenie. Z mojej perspektywy i z perspektywy, myślę, biznesu, lepiej jest podpisać osobne umowy.

 

Musisz się liczyć z tym, że wtedy, jeżeli robisz taką analizę u dostawcy, czego nie zalecam. Mówiłam o tym w poprzednim odcinku, warto go obejrzeć i posłuchać, ale jeżeli robisz to w taki sposób, że robisz tę analizę u dostawcy, to warto to rozdzielić. Musisz się liczyć z tym, że wtedy tam pierwsza umowa za tą analizę może to kosztować więcej. Albo możesz się też spotkać z tym, że dostawca odmówi wtedy przeprowadzenia samej analizy, podpisania tej umowy, dlatego że mu się to nie kalkuluje. On zarabia przede wszystkim na wdrożeniu oprogramowania, a nie na przeprowadzaniu analiz biznesowych. Dlatego właśnie też między innymi dlatego zalecam zrobienie tej analizy wcześniej u siebie i podpisanie osobnej umowy na tą analizę.

 

Dlaczego podpisujemy umowę na tą analizę? Dlatego, że analiza opisuje zakres całego projektu. Opisuje wymagania funkcjonalne. Tu trzeba bardzo mocno wejść w procesy w firmie, bardzo mocno wejść w dane, w to jak działają, funkcjonują klienci. Trzeba zdefiniować architekturę całego ekosystemu związanego z oprogramowaniem w danej firmie, czyli de facto stworzyć strategię nie tylko sprzedażową, marketingową, ale też strategię technologiczną. Ona też określa wymagania procesowe tak, jak one będą zmienione w przyszłości. Czy ona już wybiega w przyszłość, w te plany, w to co dopiero u ciebie będzie, o czym jeszcze twoja konkurencja nie ma pojęcia. Więc są to rzeczy tajne. Ona też przygotowuje grunt do wyceny. Jest zakresem projektu, który jest podstawą właśnie wyceny. To jest dokument, który można pokazać różnym dostawcom i na podstawie którego oni pracują. To jest całe twoje know-how i przyszłość twojej firmy zaprojektowana właśnie w tym dokumencie. Więc warto, żeby chronić go i powstanie tego dokumentu umową, chronić to poufnością przede wszystkim i zawrzeć też jako część tej umowy, przekazanie majątkowych praw autorskich do tego dokumentu, żeby ta dokumentacja była w pełni twoja, żeby się nie okazało, że też dokumentacja należy do kogoś innego. Jest to de facto dowód własności twojego projektu przed pójściem po wycenę, przed zakupieniem i zrealizowaniem de facto tak tego projektu, przed wyprodukowaniem takiej platformy.

 

To co mówiłam o łączeniu z umową wdrożeniową warto zapamiętać, że nie do końca dobry pomysł. Jak tuż to robisz, to po prostu przeczytaj dokładnie obydwie umowy. Natomiast zalecam własną umowę osobną, tak, odrębną umowę na tą analizę, bo ona jest osobnym de facto etapem projektu. Ona nie jest połączona stricte z projektem. Po analizie może się okazać, że ty musisz jeszcze wiele rzeczy zmienić w swojej firmie, przygotować, że one będą trwały czasami tygodniami, a czasami miesiącami, że de facto nie jesteś wcale jeszcze gotowy na wdrożenie. Agencja zacznie realizować jakiś zakres, który wyszedł i zrealizuje go we wdrożeniu, dokona często po wdrożeniu jednostronnie odbioru tej platformy i zacznie pobierać od ciebie opłaty utrzymaniowe, czyli abonament. Na przykład w rozwiązaniach SaaS zaczniesz płacić abonament, a może się okazać, że w ogóle nie jesteś gotowy do sprzedaży i ta platforma jest jeszcze nieuruchomiana sprzedażowo. Nikt jeszcze nie złożył ani jednego zamówienia, a ty już płacisz abonament. Zapłaciłeś za wdrożenie i płacisz abonament. Więc naprawdę po analizie przedwdrożeniowej czasami potrzeba jest sporo czasu na to, żeby przygotować firmę i nie jest dobrym pomysłem łączenie tych dwóch etapów. No i de facto łączenie tutaj dwóch umów. Więc weź pod uwagę to, żeby jednak rozdzielić te etapy, żeby też zadbać o kluczowe elementy w tej analizie przedwdrożeniowej.

 

Umowa wdrożeniowa – miejsce, w którym firmy tracą kontrolę

 

Omówiłam umowę oraz etap analizy przedwdrożeniowej, a teraz najważniejsze rzeczy związane z umową wdrażeniową. Umowa wdrożeniowa to jest właśnie ta kluczowa umowa, w której jest informacja o tym, czy będziesz właścicielem, czy tym właścicielem nie jesteś. Jeśli masz umowę wdrożeniową na rozwiązanie SaaS, bądź też na jakieś elementy produktowe, które stworzyła agencja do rozwiązania open source, to powinieneś też mieć licencję, czyli umowę licencyjną na korzystanie z tego rozwiązania. Czasami są to po prostu regulaminy, ale w takich już platformach B2B, w większych rozwiązaniach, które się stosuje, oprogramowaniach pod kątem takich platform, zazwyczaj jest to osobna umowa licencyjna. Forma jest wtórna. Tutaj doradzi ci prawnik. Ja prawnikiem nie jestem, natomiast mówię o tym, co jest istotne.

 

Tak, to jest ta umowa, w której coś dla ciebie będzie robione konkretnie w danym oprogramowaniu. Całe oprogramowanie, jakieś elementy tego oprogramowania, moduły i tak dalej. W związku z tym to jest ta umowa, w której właśnie widać, czy za chwilę staniesz się właścicielem tej platformy, czy będziesz tylko wynajmującym, jakie prawa ci przysługują do tej platformy. Właśnie będzie mowa też chociażby o licencjach.

 

Kluczowe elementy tej umowy wdrożeniowej to jest po pierwsze zakres, czyli czarno na białym wypisane, co będzie realizowane. Często takim zakresem jest po prostu załącznik z analizy przedwdrożeniowej, który mówi nam o tym, jaki zakres będzie realizowany. Może to być załącznik zaktualizowany przez ciebie po wycenie, gdzie sobie to podzielisz na etapy, zdecydujesz co w którym etapie, ale cały zakres może być właśnie załącznikiem z analizy przedwdrożeniowej.

 

Dalej zasady zmian, żeby uniknąć ewentualnych dopłat, tak? Czyli mówimy sobie, co się będzie działo, jeśli postanowisz zmienić ten zakres, czy to może wpłynąć na wydłużenie harmonogramu, czy właśnie wtedy dostawca ma prawo przesunąć realizację innych funkcjonalności, ma prawo zażądać dodatkowego wynagrodzenia za takie zmiany i za realizację w inny sposób. Też te zasady trzeba przeczytać. Kolejna rzecz to harmonogram. Harmonogram, który mówi co i kiedy będzie realizowane oraz jak będziesz za to płacić. Czy będziesz za to płacić w transzach po realizacji jakiejś większej całości, czy będziesz za to płacić właśnie w modelu time and material, czyli będziesz płacić po prostu co miesiąc za liczbę godzin przepracowanych przez agencję w danym miesiącu. To jest też ważne, bo to wpływa na to, jak sobie rozłożysz budżet i płatności w projekcie. Dostosujesz do innych systemów, które wdrażasz, do zmian w swojej firmie. Dasz harmonogram pod kątem czasu, jest bardzo istotny w związku z harmonogramem wdrożeniowym całego projektu e-commerce, czyli też tymi działaniami wewnętrznymi, żebyś wiedział, że zepkniecie się na koniec w czasie i będziecie wewnętrznie również ze wszystkim gotowi na ten etap uruchomienia, czyli w określonym konkretnym czasie przewidzianym na to uruchomienie.

 

Kolejna rzecz to obowiązki po twojej stronie, bo pamiętaj, że ta umowa to nie tylko obowiązki dostawcy, obowiązki agencji IT, ale również obowiązki klienta. Więc sprawdź w jakich ile macie czasu na to, żeby informować się o tym, że coś nie zostało zrobione, jakie ty masz obowiązki, co ty musisz dowieźć w harmonogramie. De facto, jeżeli będą rzeczy, które będą po twojej stronie, też powinny być wpisane, też powinna być wpisana strona odpowiedzialna i też powinien być uwzględniony klient. Więc dobrze przeczytaj i sprawdź jakie są twoje obowiązki, żebyś czegoś nie zaniedbał, bo jak zaniedbasz, to znów może to być powodem tego, że harmonogram się nie zepnie i dostawca będzie miał prawo przedłużyć czas realizacji oraz zmienić datę uruchomienia de facto. I może się okazać, że planujesz sobie platformę do uruchomienia na sezon, a będzie uruchomiana dopiero po sezonie. Więc to może być bardzo duża różnica dla tego projektu, bardzo duża zmiana dla twojej firmy, więc warto to też sprawdzić.

 

Sprawdź również kary. Sprawdź kary za opóźnienia, za złamanie zasad poufności, złamanie RODO i tak dalej. Jeśli dopuszczasz agencję do systemów, w których będą dane klientów, no to też musisz mieć osobną umowę RODO, bądź też zapisy w tej umowie wdrożeniowej dotyczące RODO. Jeżeli projekt ma być testowany, warto też uwzględnić kwestię testów chociażby w harmonogramie albo w zapisach umownych, żeby mieć pewność, że zostanie dowieziona taka jakość, jakiej oczekujesz.

 

Ta umowa to jest umowa, która decyduje o przebiegu całego projektu. I tutaj ważne też, żeby sprawdzić sobie te zapisy dotyczące majątkowych praw autorskich, żeby się dowiedzieć czyja ta platforma jest i w jakiej roli jesteś ty jako klient. Czy jesteś właścicielem, czy jesteś wynajmującym i jakie masz do tego prawa. Jeżeli są licencje, to też jaki rodzaj licencji otrzymałeś i czy ta licencja zabezpiecza cię w taki sposób, w jaki chcesz korzystać w przyszłości z tej platformy, czy ona zabezpiecza po prostu twoje interesy.

 

Po co jest ta umowa wdrożeniowa? No ona reguluje po prostu cały proces wdrożenia, reguluje też obowiązki odpowiedzialności. Ustala harmonogram i trzymamy się tak tego harmonogramu już później. Ona ustala też budżet, bo mamy też wycenę za jaką kwotę zostanie zrobione to wdrożenie. Ona ustala też zasady zmian oraz wsparcia dostawcy w całym tym procesie. Najważniejsze elementy to jest, tak jak powiedziałam, zakres tych prac, to jest model rozliczeń, czy to będzie właśnie fixed price, jakieś transze, czy to będzie rozliczenie time and material, harmonogram, kamienie milowe w tym harmonogramie, czyli kiedy będziemy sobie odbierać poszczególne części realizacji zakresu projektu, odbiór właśnie tego projektu, czy też etapów w tym projekcie, oraz testy, zasady zmian w tym zakresie, na co one wpływają, jakie mają konsekwencje dla projektu. Jeżeli chciałbyś dokonać tych zmian w trakcie wdrożenia, czyli w trakcie trwania takiego projektu, jakie są obowiązki po obydwu stronach, szczególnie po swojej stronie też przeczytaj te obowiązki, oraz jakie są kary umowne.

 

Ta umowa często jest lekceważona przez firmy. No bo przecież na wszystko się dogadaliśmy. No to tam na pewno jest tak, jak się dogadaliśmy. Nie do końca tak bywa. Naprawdę warto skrupulatnie czytać wszelkie regulaminy, umowy, żeby być pewnym na co się decydujecie.

 

Majątkowe prawa autorskie – sekcja podporządkowana tytułowi

 

Teraz przejdziemy do kluczowych zapisów, jeżeli chodzi o umowy. Zarówno umowę na analizę przedwdrożeniową, jak i umowę wdrożeniową już stricte na wdrożenie danego rozwiązania. A są to majątkowe prawa autorskie. Prawa autorskie dzieli się na prawa osobiste i na prawa majątkowe. Teraz prawa osobiste, jeżeli chodzi o Polskę, są niezbywalne. Są to prawa, które przysługują twórcy, który może powiedzieć, że dane dzieło stworzył. Oczywiście można tutaj stosować różnego rodzaju ograniczenia do korzystania z tych praw, natomiast one są niezbywalne, to znaczy nie można kogoś pozbawić praw tych osobistych.

 

Natomiast majątkowe prawa autorskie to są prawa, które można zbyć, to znaczy można je sprzedać, można je przekazać innej osobie, można się nimi podzielić. Więc tutaj zależy to od zapisów. Natomiast to są prawa do rozporządzania, do komercjalizowania i do zyskiwania korzyści majątkowych, materialnych z danego wytworu, z danego dzieła, bo kod programistyczny też jest dziełem. To nie tylko dzieło sztuki, takie jak wisi za mną chociażby, ale dzieło to też kod programistyczny. To też na przykład dokumentacja przypadków testowych, jaka jest pisana po stronie dostawcy. Naprawdę wiele dokumentów jest dziełem i z tym musisz się liczyć, że o te prawa majątkowe trzeba zadbać, żeby one były tobie przekazane. A jeżeli tobie przekazywane nie są, to też warto to wiedzieć. Na przykład jeżeli chodzi o rozwiązania SAS-owe, warto to wiedzieć, bo wtedy jesteś w pozycji wynajmującego, a nie w pozycji właściciela danej platformy i to może zmieniać całkowicie perspektywę tego, co możesz dalej zrobić z tym oprogramowaniem. Więc warto mieć tę świadomość już na samym początku tej współpracy.

 

I teraz czy jeśli zapłaciłeś za platformę, to oznacza, że automatycznie masz te prawa majątkowe? Nie. Musisz mieć odpowiednie zapisy w umowach. Jeżeli tych zapisów nie ma, to pomimo że zapłaciłeś, to zapłaciłeś za realizację czegoś, ale nie zapłaciłeś za to, żeby mieć prawo do tego, prawo do rozporządzania, modyfikowania i tak dalej. Czyli szereg praw, które się zazwyczaj wypisuje w takim paragrafie, które dotyczą właśnie tych majątkowych praw autorskich.

 

I teraz co musi być twoje? Nazwijmy to tak, co musi być twoje, jeśli platforma ma być rzeczywiście twoja. Twój powinien być kod źródłowy, czyli przeniesienie praw na kod źródłowy, do kodu źródłowego, żebyś mógł na przykład ten kod modyfikować, żebyś mógł rozwijać tę aplikację tak jak chcesz, żebyś mógł zmienić agencję na przykład, czyli firmę, która będzie ingerowała w ten kod i będzie coś zmieniała, dopisywała, żebyś mógł poprawiać błędy chociażby albo przenieść na przykład ten system na jakiś inny hosting, jeżeli to jest system, do którego potrzebne były serwery.

 

Kolejna rzecz to layout i design, czyli ten szablon tak zwany, o którym mowa. Jeśli nie masz do niego praw, to może się okazać, że w jakichś innych materiałach, na przykład marketingowych, nie możesz używać jakichś ikonek albo jakichś elementów tego layoutu, bo po prostu nie masz prawa do rozporządzania tym dziełem, bo to też jest dzieło, dzieło wizualne akurat, więc trochę mu bliżej do takiego rozumienia dzieła jak jakie mamy potocznie. Dalej prawo do integracji jakichś customowych modułów. O tym trochę mówiłam. Jeżeli coś zostało wyprodukowane stricte dla ciebie, ale na przykład jest to w rozwiązaniu SAS-owym, to jakby nie masz prawa do tego modułu customowego. Po prostu zapłaciłeś sto procent albo mniej, w zależności jak się dogadaliście, za realizację dla ciebie i żebyś coś takiego miał w platformie, mógł z tego korzystać. Natomiast po prostu nie jest to twoje.

 

Tak samo integracja. Jeżeli do integracji trzeba napisać aplikację integracyjną, czyli znów jakiś kawałek kodu programistycznego, to też się może okazać, że nie masz praw do tego kodu, że to należy do kogoś innego. Masz licencję, jeszcze zależy czy ją w ogóle masz, a jak ją masz, to jeszcze zależy w jakim zakresie, bo też czasami niewiele możesz tak naprawdę z tym zrobić. Dalej prawo do wszelkiego rodzaju modyfikacji, zmian. Jeśli nie masz prawa do tego, to pozostaje ci tylko konfiguracja tego systemu w takim zakresie, w jakim dopuścił to po prostu dostawca tej platformy i w zasadzie więcej nic nie jesteś w stanie zrobić, bez udziału tego dostawcy, bez jego aprobaty albo bez wyprodukowania przez niego, bo de facto nie za bardzo możesz to wyprodukować przez kogoś innego.

 

Kolejna rzecz to dostęp do repozytorium kodu. Jeżeli coś nie jest twoje, to nie dostaniesz też dostępu do repozytorium kodu. Nie możesz go sprawdzać, nie możesz dokonywać w nim zmian. Jeżeli coś jest twoje, to powinieneś mieć przekazany kod albo dostęp do tego repozytorium kodu. A jeżeli dana agencja utrzymuje później po uruchomieniu twoją platformę, to powinieneś mieć możliwość na żądanie mieć dostęp, wgląd do tego kodu. Powinieneś mieć zabezpieczone kopie zapasowe, też dostęp do tych kopii zapasowych, do miejsca, gdzie one są przechowywane. Powinieneś mieć po prostu pełną kontrolę nad swoją platformą. I właśnie w tym celu służą zapisy dotyczące majątkowych praw autorskich. Do tego służą chociażby też licencje.

 

Umowa utrzymaniowa i SLA – gwarancja, że platforma działa

 

Jesteśmy już po wdrożeniu. Zrobiliśmy analizę, dokonaliśmy wdrożenia i teraz przechodzimy do etapu tak zwanego utrzymania, etapu serwisowego. I tu w tym etapie podpisujemy z dostawcami, czy to są dostawcy SAS, wtedy zawsze obowiązkowo, czy to są agencje open source, wtedy nie do końca obowiązkowo, bo możesz utrzymywać je wewnątrz własnej firmy. Możesz wybrać inną agencję niż ta, która produkowała dla ciebie platformę, albo możesz zostać w tej samej agencji. I wtedy podpisujemy właśnie tak zwaną umowę utrzymaniową, czasami inaczej się nazywa umową serwisową.

 

I teraz jeśli masz rozwiązanie SAS, to zazwyczaj tę umowę utrzymaniową podpisujesz od razu już z umową wdrożeniową, dlatego że nie da się de facto wdrożyć tego oprogramowania, a potem utrzymywać przez inną firmę. Jeżeli to jest rozwiązanie SAS i dostawca jest właścicielem kodu, to on utrzymuje całą tę platformę, czyli on utrzymuje serwery, przeprowadza testy, ogarnia całe to zaplecze technologiczne, o co ty się już nie musisz martwić. Ty po prostu płacisz abonament i korzystasz. Natomiast wtedy najczęściej, jeżeli są jakieś konfiguracje, jakieś dedykowane zmiany dla ciebie wprowadzane w tym oprogramowaniu, to masz umowę wdrożeniową, ale od razu z nią proponowana jest i podpisywana druga umowa, umowa utrzymaniowa, która określa właśnie warunki świadczenia tej usługi utrzymaniowej oraz wysokość abonamentu, jaki będziesz płacił.

 

Jeżeli mówimy o rozwiązaniach open source albo dedykowanych, tych umów nie trzeba podpisywać jednocześnie. Można pod koniec wdrożenia przysiąść sobie do negocjacji tej umowy wdrożeniowej z tym, z kim chcesz ją podpisać. Nie jest powiedziane, że z tą samą agencją, ale podpisujesz umowę na właśnie takie wsparcie techniczne i utrzymanie tej platformy. I teraz ta sytuacja, że nie masz tych praw majątkowych do platformy, może to bardzo skomplikować i utrudnić, bo czasami w utrzymaniu są przewidziane jakieś pakiety godzin na przykład na rozwój. Może to utrudnić, bo możesz nie móc na przykład sam dokonać takiego rozwoju i takich modyfikacji, jeszcze w zależności co jest wpisane w ramach tej umowy utrzymaniowej, czyli co wchodzi w zakres tak naprawdę utrzymania.

 

Umowa utrzymaniowa, czyli ta umowa serwisowa, reguluje tak szeroko powiedziawszy tę opiekę nad platformą. Zapewnia jej stabilność, zapewnia jej dostępność. Mamy różny zakres parametrów i tutaj też warto te umowy utrzymaniowe porównywać, kiedy wybierasz dostawcę, kiedy masz już tę wycenę w ręku i decydujesz się, kto będzie to realizował, dlatego że te zakresy też się między sobą różnią i warto sprawdzić, jaki masz zakres ochrony, jaki masz zakres wsparcia ze strony agencji, bo co powinno obejmować de facto takie wsparcie. Takie wsparcie powinno obejmować na przykład poprawki błędów, powinno obejmować aktualizację oprogramowania chociażby pod względem bezpieczeństwa, żeby nadal to oprogramowanie było bezpieczne. Powinno obejmować monitoring wszelkich procesów, wszystkiego co się dzieje, żeby wychwytywać właśnie błędy i awarie. Powinno zawierać wsparcie techniczne również, czy trzeba będzie coś zmodyfikować, przenieść na inne serwery i tak dalej. Tu powinieneś mieć wsparcie techniczne właśnie firmy, która będzie utrzymywała taką platformę. Czasami są też tam wpisywane właśnie małe zmiany i rozwój, czyli jest jakiś pakiet godzin właśnie na tak zwany development, czyli na wyprodukowanie dla ciebie jakichś określonych funkcjonalności oraz oczywiście powinna mieć opisane, w jaki sposób reaguje na twoje zgłoszenia, czyli w jakim czasie i jak szybko reaguje, jak szybko rozwiązuje w ogóle tego typu problemy.

 

W ramach tej umowy utrzymaniowej, serwisowej, jest podpisywane często tak zwane SLA, czyli service level agreement, czyli jest to stopień dostępności systemu, de facto stopień obsługi serwisowej i zakres tej obsługi serwisowej, który trzeba między stronami ustalić. I teraz taki dokument może być elementem umowy utrzymaniowej, na przykład załącznikiem, ale taki dokument też może być zupełnie osobną umową, osobnym dokumentem zupełnie. To już odsyłam do prawników, jaka opcja będzie lepsza, jaka będzie zastosowana w twoim przypadku. Natomiast co musi określać takie SLA, tak zwane w skrócie, musi określać czas reakcji na zgłoszenia, musi określać co jest błędem, co jest awarią, co jest na przykład awarią krytyczną, jakie są rodzaje tych błędów, opisywać jakie są konsekwencje tego, że mamy taki a nie inny błąd i wtedy jakie mamy właśnie czasy reakcji na takie zgłoszenia, jakie mamy czasy usunięcia awarii czy błędów, jaki mamy poziom dostępności tej platformy, często wyrażony w procentach, na przykład 99,77%. Mamy też określone w takiej umowie na przykład godziny pracy supportu. Tu was może zaskoczyć, bo e-commerce działa 24 na 7, ale wiele firm ma na przykład support tylko od poniedziałku do piątku, 8:00 do 16:00. No i wtedy po tych godzinach jakby się coś stało, były jakieś awarie, błędy, po prostu oni nie są dostępni, więc trzeba czekać do następnego dnia do rana, żeby te awarie usunąć. To może być bardzo kosztowne, szczególnie jeżeli wasz biznes jest sezonowy i coś takiego by się zdarzyło w sezonie, to może być bardzo kosztowne dla was, a całościowo w dostępności na przykład rocznej dostawca może się tutaj zmieścić w limicie, który zaproponował. Kolejna rzecz to procedury awaryjne, zasady komunikacji, zasady monitorowania tych błędów i awarii. Także takie rzeczy powinny być rozpisane. Nie bójcie się bardzo skomplikowanych wzorów, które czasami widać w tych umowach. Warto je prześledzić, warto je przeanalizować, przeczytać to dokładnie ze zrozumieniem, żeby wiedzieć tak naprawdę, co podpisujecie, co dostajecie w zamian, bo tak naprawdę bez tego SLA to nie macie żadnych gwarancji poprawnego działania waszej platformy.

 

Jak nie oddać firmy w ręce dostawcy?

 

W tej części opowiem o tym, co powinniście mieć u siebie, jeżeli chcecie, żeby platforma była wasza, czyli chcecie mieć tę własność kodu i chcecie mieć pełną kontrolę. Nie będziecie mieli tego oczywiście w rozwiązaniach SAS-owych, bo już sobie powiedzieliśmy, że tam właścicielem kodu jest ktoś inny i ktoś inny za to odpowiada. Natomiast jeżeli wybierzecie dwa pozostałe rodzaje technologiczne, takie wdrożenia platform, czyli silniki open source albo rozwiązania customowe, czyli dedykowane platformy, tam już możecie o takie rzeczy zadbać. Czyli ta część dotyczy tych dwóch rodzajów rozwiązań.

 

I tutaj musicie zwrócić uwagę na to, że technologia może być świetna, platforma może działać perfekcyjnie. Natomiast jeśli domena jest na przykład na agencję i agencja wykupiła ją, bo tak było lepiej, wygodniej, nie musieliście się tym zajmować, kupować, było fajnie i oni wszystko załatwili, to się może okazać, że macie problem. A jeżeli hosting, serwery też są na agencję, jeżeli repozytorium kodu też jest na koncie agencji, do którego nie macie dostępu, jeżeli ten kod rzeczywiście nie jest wasz, nie macie dostępów w ogóle do tego kodu, nie widzicie backupów, to tak naprawdę można zaryzykować stwierdzenie, że ten biznes nie jest wasz po prostu, bo to wszystko należy do kogoś innego.

 

I ja byłam świadkiem takiej sytuacji. Miałam taki przypadek, że klient przyszedł i opowiadał o tym, że co zrobić, przyszedł zapytać co zrobić, ale opowiadał o tym, że właśnie nie zadbał o przekazanie tych majątkowych praw autorskich do kodu. I po dwóch latach, kiedy platforma już tak się rozwinęła, rozhulała dosyć dobrze, mieli fajne przychody, chcieli coraz bardziej już rozwijać jakieś dodatkowe dedykowane zmiany robić, wtedy agencja przyszła do nich i z kilku tysięcy złotych opłaty utrzymaniowej powiedzieli im pięćdziesiąt tysięcy złotych miesięcznie. No i było wielkie dziwienie. No ale jak to? Przecież nie mogłam czegoś takiego zrobić. A nawet jak? No to odrzucimy te propozycje, weźmiemy sobie inną agencję do utrzymania tej platformy. No i okazało się, że nie ma takiej możliwości, ponieważ nie zostały przekazane majątkowe prawa autorskie do kodu i kod de facto nie należał do klienta, tylko należał do agencji. Okazało się, że ten sklep należy do agencji, a nie do sprzedawcy, do klienta, więc w tym momencie mieli wyjście albo całkowicie z tego zrezygnować i budować od nowa, co zrobili zresztą, albo płacić te pięćdziesiąt tysięcy miesięcznie. Nie było to opłacalne, przeholowali tam, nie było to opłacalne.

 

Natomiast jest to zagrożenie, ponieważ zaczynasz wszystko od zera. Musisz od nowa wyłożyć pieniądze na realizację tej platformy. Jak udostępnią ci dane, to musisz to wszystko zmigrować. Jeżeli było pozycjonowanie, to stracisz pozycjonowanie, które zostało wypracowane przez ten czas. Naprawdę to są ogromne straty i ogromne koszty, a wystarczyło jeden paragraf dodać do umowy, który zabezpieczałby ten interes. Więc pamiętajcie, że te najważniejsze rzeczy, o które musicie zadbać, które musicie mieć u siebie, jeżeli chcecie być właścicielem tej platformy, to są te konta hostingowe na siebie, nie na agencję, czyli te serwery. Dostęp tak samo, żeby mieć dostęp do repozytorium kodu, żeby mieć kontrolę nad domeną. Najlepiej samemu wykupić domenę. Często się kupuje tam, gdzie są te serwery, gdzie hosting, bo serwerownie też sprzedają domeny, żeby mieć zabezpieczony fakt, że są robione kopie zapasowe, że są te backupy i że też macie do tego dostęp, że znacie lokalizację tych backupów, że macie dostęp do paneli konfiguracyjnych, również paneli konfiguracyjnych serwerowych, czyli też do tych kwestii technicznych, nie tylko do CMS-a platformy, w którym możecie sobie skonfigurować funkcjonalności, żebyście mieli dokumentację projektu, dokumentację techniczną też, żeby ona była przekazana, żeby była w ogóle procedura, jasne zasady przekazywania takiej dokumentacji, też procedura zakończenia współpracy, co się dzieje później, w jakim czasie są dane wam przekazane, ile dostawca może jeszcze przechowywać te dane po tym, jak rozwiążecie umowę oraz wszelkiego rodzaju gwarancje dotyczące tych danych, ochrony tych danych, bezpieczeństwa tego systemu, dbania o ten system. To są właśnie elementy, które odróżniają właściciela platformy od jej użytkownika i to są też elementy, które potrafią uratować firmę. Albo z drugiej strony, jeżeli nie dopatrzyliście tej kwestii, to mogą tę firmę po prostu zablokować.

 

W jakiej kolejności podpisywać umowy?

 

Omówiliśmy już wszystkie rodzaje umów oraz etapy takiego projektu wdrożeniowego współpracy z agencją tudzież zewnętrznymi konsultantami. W tej części krótko zbiorę i podsumuję, jakie po kolei powinniście podpisywać umowy.

 

Więc na początku współpracy z kimkolwiek, jeżeli macie mówić o swoim projekcie, z jakąkolwiek agencją, konsultantem, kimkolwiek, kto będzie coś dla was robił i musi poznać szczegóły projektu, podpisujecie umowę NDA, czyli umowę o zachowaniu poufności, żeby chronić dane swojej firmy i swoje know-how. Druga umowa to umowa na analizę przedwdrożeniową. Może być z dostawcą, może być z konsultantem, jeżeli robicie ją wewnętrznie po swojej stronie, zanim pójdziecie do dostawcy. Polecam, żeby to był odrębny dokument, jeżeli robicie ją u dostawcy, a nie dokument połączony z kolejną umową, czyli z umową wdrożeniową. Jest to najważniejsza umowa, która mówi o tym, w jaki sposób będzie wykonany wasz projekt, w jaki sposób będzie wykonana platforma, w jakim zakresie, w jakim czasie, czyli harmonogram i w jakim budżecie i w jaki sposób będziecie też za to płacić, w jakich cyklach i w jakich kwotach.

 

Kolejna umowa to umowa utrzymaniowa, umowa serwisowa. Jest to umowa ważna, szczególnie jeżeli bierzecie rozwiązanie SAS, czyli bierzecie od dostawcy oprogramowania, który jest właścicielem kodu. Jest to umowa, która reguluje kwestie wsparcia, kwestie utrzymania, zakresu świadczonych usług w tym czasie, tego co właśnie agencja czy też dostawca będą robić w ramach płaconego im abonamentu tudzież opłaty utrzymaniowej. I ostatnia kwestia to jest właśnie SLA. To jest element, który może być załącznikiem do poprzedniej umowy, czyli tej utrzymaniowej serwisowej, albo może być odrębną umową, właśnie taką umową serwisową, która przewiduje kwestie związane z dostępnością platformy, z reakcją na zgłoszenia, na awarie, błędy, z czasem usunięcia takich błędów i awarii. Więc ona zabezpiecza po prostu prawidłowe, nieprzerwane działanie waszej platformy.

 

To jest kolejność, w jakiej powinniśmy podpisywać te umowy oraz katalog umów, które powinniśmy podpisywać, z gwiazdką jeszcze na końcu umowa dotycząca RODO, czyli powierzenia przetwarzania danych osobowych. Szczególnie ważna, jeżeli podpisujecie i dalej przechodzicie w utrzymanie z agencją IT albo jeżeli bierzecie produkt SAS, to tam też dostawca będzie miał dostęp do danych osobowych, czasami do danych wrażliwych, więc powinniście mieć również dobrze zabezpieczone kwestie związane z przetwarzaniem danych osobowych, z powierzeniem przetwarzania tych danych osobowych podmiotom trzecim, z terenem, na którym te dane są przetwarzane, bo są inne regulacje w Unii Europejskiej oraz poza nią. Więc o tych kwestiach pamiętajcie, żeby to wszystko uwzględnić i żeby te umowy mieć podpisane w brzmieniu, jakie najbardziej wam odpowiada do waszego projektu.

 

Nie rozumiesz? Nie podpisuj.

 

Skoro mówimy o umowach i mówimy o prawie w kontekście bezpieczeństwa waszego biznesu, waszej platformy, tego co tworzycie, to na koniec ważny komunikat, ostatni, ale nie najmniej ważny, powiedziałabym, że najważniejszy. Pamiętajcie, że w tym odcinku nie chodziło o to, żeby dać wam konkretne wskazówki dotyczące jakichś zapisów prawnych. Ja nie jestem prawnikiem i absolutnie nie silę się na tego typu doradztwo. Musicie wziąć specjalistę w tym zakresie, kancelarię, która się zajmuje takimi kwestiami i która was w tym wesprze.

 

Ja pokazuję tylko pewne obszary i aspekty, na które biznes powinien zwrócić szczególną uwagę. Powinno was to zainteresować i powinniście sobie tych kwestii dopilnować. To są takie tak zwane red flagi, takie czerwone, pomarańczowe lampki, jakkolwiek to sobie tam nazwiecie, które powinny wam się zapalić, jeżeli czytacie umowy i czegoś nie ma albo jakiejś umowy w ogóle nie ma. Nikt wam nie daje, nie proponuje takiej umowy. Jeżeli jakichś zapisów brakuje w tych umowach, to tu powinno wam się zaświecić ta czerwona lampka i powinniście zwrócić na to uwagę.

 

A w przypadku szczegółowych zapisów zainwestujcie w kancelarię, w prawnika. Naprawdę to nie są źle wydane pieniądze. Powiedziałabym, że to są najlepiej wydane pieniądze, bo umowy robi się na tak zwane złe czasy, na czas, jak to mówią niektórzy, wojny. Więc te umowy potrafią naprawdę dużo zmienić w waszym biznesie, zabezpieczyć wasz biznes, chociażby też w takim zakresie, żebyście nie mieli vendor lock-in, żeby was ktoś nie uzależnił od siebie i żeby się nie okazało później, że kluczowej jakiejś funkcjonalności albo na przykład integracji, które są ważne, żeby cały wasz ekosystem e-commerce, czyli wszystkie systemy połączone ze sobą działały, żeby się nie okazało, że to w ogóle nie jest wasze, nie macie do tego dostępu, jesteście uwiązani jak na smyczy u dostawcy. Takie sytuacje też się zdarzają. Trzeba o to zadbać, żeby wasz biznes, który zamierzacie wpompować mnóstwo pieniędzy jako inwestycje, był odpowiednio chroniony.

 

Więc zawsze konsultujcie te zapisy o prawach autorskich, o jakichś ograniczeniach na przykład w licencjach, o karach, o tych parametrach SLA, czyli dostępności, o danych i RODO, o przetwarzaniu danych, bo to też potrafią być wysokie kary za to, jeżeli nie mamy tego dobrze ogarniętego, i o kwestiach odpowiedzialności. Generalnie zapamiętajcie taką prostą zasadę: jeśli czegoś nie rozumiesz, nie podpisuj. Jeśli ktoś cię pogania z podpisaniem jakiejś umowy, to podpisuj ją jeszcze wolniej, a na pewno zweryfikuj u prawnika.

 

I jako podsumowanie tego dosyć długiego odcinka kilka rzeczy wartych zapamiętania. Po pierwsze to, że zapłaciłeś za platformę, nie oznacza wcale, że jesteś jej właścicielem. Po drugie, bez praw autorskich, tych majątkowych praw autorskich i dostępu do kodu i kontroli nad tym kodem, twój biznes tak naprawdę zależy od dostawcy. Tak naprawdę nie jesteś panem tej sytuacji, jesteś bardzo mocno uzależniony od innej firmy. Kolejna kwestia to pamiętaj o właściwej kolejności umów i o przede wszystkim łączeniu tudzież niełączeniu różnych umów. To znaczy pamiętaj, co można łączyć, które umowy ze sobą można łączyć, a których nie powinieneś łączyć dla własnego bezpieczeństwa, dla bezpieczeństwa swojego biznesu i żeby utrzymać kontrolę nad całym procesem i nad całym projektem wdrożenia. W projektach B2B prawo i te aspekty prawne są tak samo ważne jak technologia, jak procesy, jak inne kwestie. Także nie ustawiaj na kwestiach prawnych jakiegoś niższego priorytetu. Wręcz powiedziałabym, że ten priorytet powinien być wysoki i powinieneś dobrze się orientować w tym i wiedzieć, co potrzebujesz zabezpieczyć w takich umowach. Najważniejsze umowy to jeszcze raz NDA, umowa na analizę przedwdrożeniową, umowa wdrożeniowa, umowa utrzymaniowa, serwisowa i SLA oraz plus prawa autorskie, czyli RODO. Do tego jeszcze dorzucamy prawa autorskie, czyli te majątkowe prawa autorskie oraz RODO jako wisienka na torcie, jeżeli mamy do czynienia z przekazywaniem danych osobowych klientów. Kolejna rzecz, zawsze zabezpiecz te swoje prawa, prawa do kodu, jeżeli to jest open source albo platforma dedykowana, i możliwość zmian w kodzie oraz zmiany agencji, która będzie zajmowała się twoją platformą. I złota zasada, nie podpisuj niczego, czego nie rozumiesz. Bądź w kontakcie i skonsultuj się z prawnikiem w tej kwestii.