Co należy do Państwa, gdy system jest gotowy: kod, dane i zależność od wykonawcy

System został przekazany, rachunek opłacony, a po pół roku firma postanawia zmienić wykonawcę, i właśnie wtedy pada pytanie, które do tej pory nikomu nie wydawało się pilne: do kogo należy to, za co zapłacono. Odpowiedź w Polsce zaskakuje niemal wszystkich, którzy słyszą ją po raz pierwszy, bo zapłata za wykonanie sama z siebie nie daje zamawiającemu praw autorskich do powstałego programu komputerowego, i to nie jest prawniczy niuans, tylko stan domyślny, który działa za każdym razem, gdy w umowie nie zapisano niczego innego.

Ten artykuł jest o tym, co zostaje w Państwa rękach po przekazaniu, i to nie jest to samo pytanie, które rozważaliśmy, porównując gotowy produkt z oprogramowaniem dedykowanym. Tam chodziło o to, co wybrać; tutaj chodzi o to, co trzymają Państwo w ręku, gdy wybór już zapadł i system działa. Odpowiedź dzieli się na trzy części: kod i prawa do niego, dane wraz z miejscem, w którym leżą, oraz zależność od ludzi, którzy system znają.

Twórcą jest zawsze człowiek, nie firma

W rozumieniu ustawy o prawie autorskim i prawach pokrewnych prawo autorskie przysługuje twórcy, o ile ustawa nie stanowi inaczej, a to znaczy, że firma sama z siebie twórcą nie jest: twórcami są programiści, projektanci i autorzy tekstów, którzy przy systemie pracowali. Programy komputerowe podlegają ochronie jak utwory literackie, tak samo jak w dyrektywie 2009/24/WE, i prawo autorskie powstaje z chwilą ustalenia utworu, bez rejestracji, bez oznaczenia i niezależnie od tego, czy utwór jest ukończony.

Prawo autorskie dzieli się na dwie części, które polska ustawa nazywa autorskimi prawami osobistymi i autorskimi prawami majątkowymi, i w praktyce to jest najważniejszy podział w całym tym temacie, bo tylko jedna z nich w ogóle może trafić do firmy. Część majątkowa jest tą, którą można przenieść na kogoś innego, i w przypadku programu komputerowego obejmuje trwałe lub czasowe zwielokrotnienie, tłumaczenie, przystosowywanie i inne zmiany oraz rozpowszechnianie, w tym użyczenie lub najem. Część osobista jest nieograniczona w czasie i nie podlega zrzeczeniu się ani zbyciu, i właśnie dlatego żadna umowa nie może zapisać, że firma staje się twórcą.

Jest jeszcze jedna granica, którą rzadko się zauważa, i może się okazać kosztowna. Artykuł 74 ustęp 3, który oddaje prawa majątkowe do programu komputerowego pracodawcy, mówi tylko o programie, natomiast do wszystkiego innego, co projekt tworzy, czyli do projektu graficznego, dokumentacji, tekstów i instrukcji, stosuje się artykuł 12 ustęp 1, gdzie stan domyślny jest inny: pracodawca z chwilą przyjęcia utworu nabywa autorskie prawa majątkowe w granicach celu umowy o pracę i zgodnego zamiaru stron, a jeśli przez dwa lata nie przystąpi do rozpowszechniania utworu przeznaczonego do rozpowszechnienia, prawa mogą wrócić do twórcy. W praktyce znaczy to, że dwie rzeczy powstałe w jednym projekcie mogą siedzieć w dwóch różnych reżimach, i umowa, która mówi tylko o oprogramowaniu, projekt graficzny może zostawić w węższym reżimie artykułu 12, a nie w pełnym reżimie artykułu 74.

Z tego wynikają pierwsze praktyczne skutki, które warto zrozumieć przed resztą: gdy firma zamawia system w agencji, łańcuch praw ma co najmniej dwa ogniwa, bo najpierw programiści są twórcami, potem agencja nabyła albo nie nabyła od nich części majątkowej, i dopiero wtedy agencja może cokolwiek przenieść na Państwa. Jeśli któreś ogniwo brakuje, agencja obiecuje więcej, niż jej przysługuje, i widać to dopiero wtedy, gdy ktoś zaczyna sprawdzać.

Stosunek pracy i zamówienie to dwa różne stany domyślne

Tu leży trzon artykułu, i tu intuicja prowadzi w złą stronę. Artykuł 74 ustęp 3 ustawy o prawie autorskim stanowi, że prawa majątkowe do programu komputerowego stworzonego przez pracownika w wyniku wykonywania obowiązków ze stosunku pracy przysługują pracodawcy, o ile umowa nie stanowi inaczej. To jest polska odpowiedź na artykuł 2 ustęp 3 dyrektywy 2009/24/WE, i dotyczy wyłącznie stosunku pracy i wyłącznie programów komputerowych.

Przy zamówieniu stan domyślny jest odwrotny, i właśnie dlatego tych dwóch przypadków nie wolno mylić: żaden przepis nie przenosi praw majątkowych do programu na zamawiającego samym faktem zapłaty, bo artykuł 74 ustęp 3 dotyczy pracowników. Przeniesienie autorskich praw majątkowych wymaga formy pisemnej pod rygorem nieważności i obejmuje tylko pola eksploatacji wyraźnie wymienione w umowie. Umowa o dzieło z artykułu 627 Kodeksu cywilnego o prawie autorskim nie mówi nic, bo reguluje wykonanie i wydanie dzieła, a nie obrót prawami.

Złożone razem dają sytuację, w której typowa firma ląduje, nawet o tym nie wiedząc: klient zamawia system w agencji; programiści są pracownikami agencji, więc artykuł 74 ustęp 3 oddaje część majątkową agencji; umowa klienta z agencją jest umową o dzieło, która tego dalej nie przenosi. W rezultacie klient zapłacił za rezultat i rezultat dostał, ale część majątkowa została przy agencji, a jeśli w umowie nie ma wyraźnego przeniesienia, artykuł 65 każe uważać, że twórca udzielił licencji autorskiej, której treść bez wymienionych pól eksploatacji zostaje niejasna.

To przekonanie jest dość rozpowszechnione, żeby nazwać je wprost: mylne jest wyobrażenie, że prawa do programu komputerowego przysługują temu, kto zamówił i opłacił jego wykonanie, i że ustawa o prawie autorskim przewiduje automatyczne nabycie tych praw przez zamawiającego: nie przewiduje. Artykuł 74 ustęp 3 dotyczy pracowników, a zwykła umowa o dzieło praw majątkowych nie przenosi; żeby prawa przeszły na Państwa, trzeba je przenieść na piśmie, z wymienionymi polami eksploatacji. Ocena, którą sprzedają kancelarie piszące takie umowy, jest warta tyle, ile jej zderzenie z tekstem ustawy, i w tym przypadku tekst ustawy to potwierdza.

Otrzymanie plików to nie otrzymanie praw

Drugie założenie, które nie wytrzymuje sprawdzenia, polega na tym, że otrzymanie kodu cokolwiek rozstrzyga, ale artykuł 52 ustęp 1 ustawy o prawie autorskim stanowi, że jeżeli umowa nie stanowi inaczej, przeniesienie własności egzemplarza utworu nie powoduje przejścia autorskich praw majątkowych do utworu. W praktyce znaczy to, że archiwum z całym kodem źródłowym, dostęp do repozytorium i nawet pełna dokumentacja nadal nie są tym samym, co prawo do korzystania z tego kodu, do jego zmian i do przekazania innemu wykonawcy.

Działa to też w drugą stronę, i ta strona jest mniej znana, bo firma mogła nabyć autorskie prawa majątkowe dobrze napisaną umową, a kodu źródłowego i tak nie dostać, jeśli w umowie nie było osobnego obowiązku jego przekazania. Upoważnienie bez pliku jest tak samo nieużyteczne jak plik bez upoważnienia, dlatego w umowie potrzeba obu, i są to dwa samodzielne punkty, a nie jeden punkt, który drugi zawiera sam z siebie.

Gdy prawa są przenoszone porządnie, ustawa wymaga pewnej precyzji, i to nie jest formalność, bo autorskie prawa majątkowe można przenieść albo licencjonować, a umowa o przeniesienie albo licencja obejmuje tylko pola eksploatacji wyraźnie w niej wymienione. W polskiej ustawie nie ma reguły, że milczenie o terytorium znaczy państwo zawarcia umowy. Przy licencji, jeśli nie postanowiono inaczej, artykuł 66 ustęp 1 uprawnia do korzystania przez pięć lat na terytorium państwa, w którym licencjobiorca ma siedzibę albo miejsce zamieszkania, po czym prawo wygasa. Firmie, która działa w kilku państwach albo planuje tam działać, to jest bezpośredni powód, żeby terytorium i pola eksploatacji zapisać, bo sformułowanie o jednym polu pozostałych nie otwiera.

Jest jeszcze jedno zaskoczenie, które czeka firmę żyjącą na milczącej licencji i nigdy nie spisanej na piśmie. Artykuł 68 ustęp 1 stanowi, że jeżeli umowa nie stanowi inaczej, a licencji udzielono na czas nieoznaczony, twórca może ją wypowiedzieć z zachowaniem terminów umownych, a w ich braku na rok naprzód, na koniec roku kalendarzowego. Zrzeczenie się tego uprawnienia nie jest nieważne: zdanie zaczyna się od „jeżeli umowa nie stanowi inaczej”. Jeśli o terminie nie powiedziano nic, artykuł 66 ustęp 1 i tak traktował licencję jako pięcioletnią, po czym prawo wygasa. Firma, której jedyną podstawą korzystania z systemu jest niespisane porozumienie, nie żyje więc z sześciomiesięcznym wypowiedzeniem, którego nie da się wyłączyć umową.

Autorskie prawa osobiste i to, czego przy programach nie zakazują

W części osobistej mieszczą się autorstwo, oznaczenie nazwiskiem albo pseudonimem, nienaruszalność treści i formy oraz rzetelne wykorzystanie, decydowanie o pierwszym udostępnieniu publiczności i nadzór nad sposobem korzystania z utworu, i to wszystko zostaje przy twórcy, bo autorskie prawa osobiste są nieograniczone w czasie i nie podlegają zrzeczeniu się ani zbyciu. Firmie, która zamówiła system, brzmi to na początku groźnie, bo powstaje wrażenie, że były wykonawca może w pewnym momencie zażądać wstrzymania systemu.

W praktyce przy programie komputerowym tak nie jest, i powodem nie jest nowelizacja z 2023 roku, tylko artykuł 77 ustęp 1, który do programów komputerowych wyłącza artykuł 16 pkt 3–5, a więc nienaruszalność, pierwsze udostępnienie i nadzór, oraz artykuł 56, czyli odstąpienie twórcy od umowy ze względu na istotne interesy twórcze. Zostają prawa do autorstwa i do oznaczenia utworu nazwiskiem. To znaczy, że były programista nie zatrzyma ani zwykłej opieki, ani przeróbki na podstawie tych praw osobistych, i właśnie ta część wiązki byłaby dla firmy groźna.

W tym samym artykule 77 ustęp 1 jest jeszcze jedna norma, która firmie sprzyja i którą warto znać, bo w przeciwnym razie można jej oczekiwać od złej strony. Przepisów o godziwym wynagrodzeniu i o dalszym udziale twórcy, które przy innych rodzajach utworów pozwalają twórcy wrócić do kwestii zapłaty, do autorów programów komputerowych się nie stosuje: artykuł 77 ustęp 1 wyłącza między innymi artykuły 43, 44 i 47¹. To jest to samo wyłączenie unijne co artykuł 23 ustęp 2 dyrektywy 2019/790, a przepis, który wiąże polskiego czytelnika, jest w ustawie. Programista, który uzna, że system okazał się cenniejszy, niż obie strony zakładały, na tej podstawie dodatkowego wynagrodzenia żądać nie może.

Co zostaje, to możliwość bycia nazwanym twórcą, i to jest wyraźnie mniejsze ryzyko, z którym da się żyć. Ważne jest tylko, żeby nie pomieszać dwóch rzeczy: przeróbka jako sprawa praw osobistych przy programie nie jest już przeszkodą, ale przeróbka jako część majątkowa nadal wymaga zgody tego, komu ta część przysługuje, więc jeśli część majątkowa została przy agencji, do przeróbki systemu nadal potrzebna jest jej zgoda.

Co ustawa daje także bez dobrej umowy

Nawet firmie, która nie spisała niczego, ustawa daje kilka możliwości, i warto wiedzieć, które z nich umowa może zabrać, a których nie. Artykuł 75 ustęp 1 ustawy o prawie autorskim pozwala, jeżeli umowa nie stanowi inaczej, zwielokrotniać, tłumaczyć, przystosowywać albo w inny sposób zmieniać program, jeżeli jest to niezbędne do korzystania z niego zgodnie z przeznaczeniem, w tym do poprawiania błędów przez osobę, która legalnie weszła w jego posiadanie: tę możliwość umowa może zabrać, i wiele umów to robi.

Sporządzenie kopii zapasowej jest innym przypadkiem, którego umowa zabrać nie może. Artykuł 75 ustęp 2 pkt 1 stanowi, że nie wymaga zezwolenia uprawnionego sporządzenie kopii zapasowej, jeżeli jest to niezbędne do korzystania z programu, i to odpowiada artykułowi 5 ustęp 2 dyrektywy 2009/24/WE. Artykuł 76 ustawy stanowi, że postanowienia umów sprzeczne z artykułem 75 ustęp 2 i 3 są nieważne, a artykuł 8 dyrektywy mówi to samo o postanowieniach sprzecznych z artykułem 6 albo z wyjątkami z artykułu 5 ustęp 2 i 3.

Tu warto być precyzyjnym, bo różnica jest cienka i łatwo ją przeciągnąć: polska ustawa nieważność sprzecznym z artykułem 75 ustęp 2 i 3 postanowieniom daje w osobnym artykule 76, a nie wewnątrz artykułu o dekompilacji, ale skutek jest ten sam. Dlatego jest poprawnie napisać, że polska ustawa przejmuje artykuł 8 dyrektywy dla kopii zapasowej i dla dekompilacji; niepoprawnie byłoby napisać, że w ustawie nie ma zdania o nieważności sprzecznej umowy. Kopii zapasowej umowa zabrać nie może, i nie może ważnie zakazać dekompilacji, która spełnia warunki artykułu 75 ustęp 2 pkt 3.

Dekompilacja z kolei jest dozwolona wąsko i pod warunkami: wolno zwielokrotnić kod albo przetłumaczyć jego formę, żeby uzyskać informacje konieczne do współdziałania niezależnie stworzonego programu z innymi programami, jeśli te informacje nie były uprzednio łatwo dostępne, czynności dokonuje licencjobiorca albo inna osoba uprawniona do korzystania z egzemplarza, i czynności odnoszą się do tych części oryginalnego programu, które do współdziałania są niezbędne. Uzyskanych informacji nie wolno użyć do innych celów, przekazać innym osobom, chyba że jest to niezbędne do współdziałania, ani użyć do rozwijania, wytwarzania lub wprowadzania do obrotu programu o istotnie podobnej formie wyrażenia. Ta droga wyjścia jest użyteczna, ale wąska, i żadna firma nie chce, żeby była jedyna.

W systemie jest dużo kodu, który nigdy nie będzie Państwa

System dedykowany prawie nigdy nie jest tylko tym kodem, który napisał wykonawca, bo większa część objętości pochodzi z bibliotek i frameworka, które już istniały. Ten kod nie staje się Państwa własnością nigdy i w żadnej umowie, bo otrzymują Państwo licencję od jego twórców, i ta różnica jest ważna właśnie wtedy, gdy ktoś obiecuje przenieść wszystkie prawa do systemu.

Licencje permisywne problemu nie robią, bo wymagają mało i nie ograniczają tego, jak gotowego systemu wolno używać w działalności gospodarczej. Licencja MIT pozwala używać, kopiować, zmieniać, łączyć, publikować, rozpowszechniać i sprzedawać, byle zachować informację o prawach autorskich i samą licencję, a oprogramowanie jest przekazywane takie, jakie jest, bez gwarancji, natomiast licencja Apache 2.0 dodaje do tego wyraźną licencję patentową i wymaga oznaczenia wprowadzonych zmian. Obie są zgodne z zamkniętym systemem komercyjnym, większość współczesnych frameworków stoi na jednej z nich, i właśnie dlatego ta część systemu zwykle nie wymaga żadnej rozmowy.

Licencje copyleft wymagają uwagi, ale nie paniki, i właśnie tutaj najczęściej opowiada się półprawdy, choć Fundacja Wolnego Oprogramowania na swojej stronie pytań o GPL pisze wprost, że firma, która uruchamia zmodyfikowany program GPL na własnej stronie internetowej, nie jest zmuszona publikować zmodyfikowanego kodu źródłowego, bo obowiązek copyleft powstaje przy przekazywaniu kopii innym, a nie przy używaniu programu u siebie. Wytwarzanie i używanie kilku kopii wewnątrz jednej organizacji nie jest rozpowszechnianiem, choć przekazanie kopii innym organizacjom, w tym wykonawcom do użytku poza firmą, już jest.

Wyjątkiem jest licencja Affero, i właśnie jej artykuł 13, klauzula interakcji sieciowej (AGPL §13), jest tym, co ludzi zaskakuje, bo jeśli program przerobią Państwo i przerobiona wersja pozwala użytkownikom porozumiewać się z nią zdalnie przez sieć komputerową, to tym użytkownikom trzeba zaoferować możliwość otrzymania odpowiedniego kodu źródłowego. Warunki są dwa i oba są potrzebne: przeróbka i zdalna interakcja użytkowników, dlatego nie jest poprawnie mówić, że każde użycie licencji Affero wymaga publikacji kodu źródłowego, i nie jest poprawnie mówić, że jedna taka biblioteka automatycznie poddaje cały system, bo to zależy od tego, jak komponenty są połączone.

Depozyt kodu źródłowego u strony trzeciej i co naprawdę daje

Depozyt kodu źródłowego (source code escrow) jest rozwiązaniem trójstronnym, w którym wykonawca składa kod źródłowy u neutralnego depozytariusza, a depozytariusz wydaje go zamawiającemu tylko wtedy, gdy nastąpi przypadek opisany w umowie, i typowe przypadki to upadłość, zaprzestanie działalności albo istotne niewykonanie obowiązków utrzymania po wezwaniu. W Polsce nie ma ustawy, która te przypadki wyznaczałaby albo choćby wyliczała, więc wszystko, co tu działa, jest tym, co strony same napisały, i dlatego umowę depozytu trzeba czytać równie uważnie jak samą umowę o wykonanie.

Depozyt daje dokładnie to, co złożono, i tylko wtedy, gdy nastąpi to, co opisano, ale sam z siebie praw autorskich nie przenosi, bo o tym znowu trzeba pamiętać artykuł 52 ustęp 1, i nie uczy systemu uruchamiać. Firma NCC Group, która tę usługę sprzedaje od dziesięcioleci, w swoich materiałach przyznaje sama: obecność kodu źródłowego w depozycie to jedna rzecz, a umiejętność jego skompilowania to inna, i właśnie dlatego ta sama firma sprzedaje też weryfikację złożonej zawartości. To jest ocena strony zainteresowanej, ale to jest przyznanie słabego punktu własnej podstawowej usługi, i dlatego da się z niego skorzystać.

Współczesne systemy mają też drugą lukę, która z prawną stroną nie ma nic wspólnego: jeśli system działa jako usługa na infrastrukturze wykonawcy, to kod źródłowy bez środowiska uruchomieniowego, konfiguracji i danych rozwiązuje mniejszą część problemu, bo odbiorcy zostaje archiwum, a nie działający system. Praktycy tę lukę zamykają, uzupełniając depozyt umową o to, kto przejmuje środowisko i co się dzieje, gdy rachunki za hosting zostają nieopłacone, i właśnie tych punktów w standardowych formularzach depozytu zwykle nie ma.

Jest też przeszkoda prawna, która siedzi w prawie upadłościowym, a nie w prawie autorskim: w postępowaniu upadłościowym przedmiot depozytu i jego wydanie mogą wejść w kolizję z masą upadłości, a więc właśnie w tym przypadku, dla którego depozyt najczęściej się kupuje. Praktyczny wniosek nie brzmi, żeby z depozytu rezygnować, tylko żeby nie uważać go za substytut pisemnego przeniesienia praw i regularnego przekazywania kodu źródłowego.

Gdzie leży repozytorium i gdzie leżą dane

Pytanie o to, gdzie leży kod i dane, rozstrzyga więcej niż pytanie o to, do kogo należą, bo prawa bez dostępu są wolnym problemem. Dokumentacja GitHuba opisuje jasno, że organizacja jest wspólnym kontem, do którego należą repozytoria, że do organizacji nie da się zalogować, bo ludzie logują się kontami osobistymi, i że właściciele organizacji zawsze mają dostęp do wszystkich repozytoriów; repozytorium może należeć i do konta osobistego, i do organizacji, i ten wybór jest ważniejszy, niż wygląda.

Jeśli repozytorium należy do osobistego konta wykonawcy, to dostęp klienta jest tylko dostępem współpracownika, który właściciel konta może odebrać w każdej chwili, a odchodząc z projektu zabiera ze sobą także sam adres. Jeśli repozytorium należy do organizacji klienta, w której wykonawca został zaproszony jako członek, to odejście oznacza zdjęcie jednego dostępu i nic więcej, i to jest jedna z nielicznych rzeczy w tym artykule, które da się naprawić w jeden dzień i bez prawnika.

Dane to osobne pytanie, i tu nie chodzi już o prawo autorskie: jeśli wykonawca przetwarza dane osobowe w Państwa imieniu, to znaczy obsługuje środowisko produkcyjne, ma dostęp do danych klientów albo pracowników albo sporządza kopie zapasowe, to są Państwo administratorem, a wykonawca podmiotem przetwarzającym w rozumieniu RODO. Artykuł 28 rozporządzenia wymaga pisemnej umowy z konkretnymi punktami: przedmiot i czas trwania przetwarzania, charakter i cel, rodzaje danych i kategorie osób, których dane dotyczą, oraz prawa i obowiązki administratora.

Czysta praca nad kodem bez dostępu do danych osobowych artykułu 28 nie uruchamia, więc nie każda umowa o wykonanie potrzebuje umowy powierzenia przetwarzania. Granica jest prosta i sprawdzalna: jeśli wykonawca może widzieć rzeczywiste dane klientów, to potrzeba, a jeśli wykonawca pracuje tylko na danych testowych i środowiska produkcyjnego nie widzi, to nie potrzeba, i to samo w sobie jest argumentem za tym, żeby środowisko testowe było osobne.

Co zyskują Państwo i co jednocześnie biorą na siebie

Logika tego artykułu była dotąd jednostronna, więc uczciwie jest powiedzieć też drugą stronę: pełna kontrola nad systemem dedykowanym to nie tylko zysk, ale i zespół obowiązków, które nie znikają. Przy gotowym oprogramowaniu utrzymanie, poprawki zabezpieczeń i zgodność z nowymi środowiskami zapewnia producent, i to jest wliczone w opłatę abonamentową, natomiast przy systemie dedykowanym to wszystko zapewnia właściciel, czyli Państwo, i to jest bezpośredni wydatek, który pojawia się co roku niezależnie od tego, czy w systemie cokolwiek się zmienia.

Drugie, co biorą Państwo na siebie, to starzenie się systemu, które zbiera się po cichu i nie objawia się w żaden sposób, dopóki ktoś tego nie szuka. System opiera się na wersjach języka i frameworka, dla których producenci wyznaczają terminy wsparcia, a po tych terminach nowe podatności nie są już łatane, choć system działa dalej dokładnie tak samo jak wcześniej i żaden ekran o tym nie ostrzega. To nie jest zakaz uruchamiania przestarzałego systemu, ale to jest chwila, w której ryzyko przejmuje właściciel, a konkretne daty dla PHP i Laravela zebraliśmy w artykule o tym, co znaczy wybrać PHP i Laravel, dlatego tutaj ich nie powtarzamy.

Trzecie jest rynek, i przy gotowej platformie specjalistę da się znaleźć stosunkowo łatwo, bo się ich uczy i jest ich kilku, natomiast system dedykowany znają tylko ci, którzy go budowali, i nowemu wykonawcy trzeba dać czas na poznanie, zanim będzie mógł cokolwiek zmieniać bezpiecznie. To nie znaczy, że przejęcie jest niemożliwe, ale znaczy, że kosztuje, i ten koszt pojawia się właśnie w chwili, gdy relacja z poprzednim wykonawcą już się skończyła.

Właśnie dlatego pytanie o to, co należy do Państwa, nie jest prawniczą formalnością, tylko pytaniem o to, ile będzie kosztował następny wybór. Firma z pisemnym przeniesieniem, kodem źródłowym we własnym repozytorium i listą użytych komponentów może szukać nowego wykonawcy w ciągu tygodnia, natomiast firma bez tego wszystkiego najpierw ustala, co w ogóle wolno jej robić, i dopiero potem zaczyna szukać, i to jest różnica między rozmową z pozycji a rozmową z potrzeby.

Co wpisać w umowie, dopóki jeszcze można

Wszystkie poprzednie części prowadzą do niewielkiego zestawu punktów, które warto wpisać w umowę przed rozpoczęciem prac, bo po przekazaniu pozycja negocjacyjna jest dużo słabsza. Pierwszy to pisemne przeniesienie autorskich praw majątkowych, z wymienieniem, które prawa przechodzą, na jakich polach eksploatacji, na jakim terytorium i na jaki czas, bo umowa obejmuje tylko pola wyraźnie wymienione, a milcząca licencja wpada w artykuł 66: pięć lat i terytorium siedziby licencjobiorcy. Drugi to oświadczenie, że agencja nabyła te prawa od swoich pracowników i podwykonawców, bo bez tego ogniwa samo przeniesienie może być puste.

Trzeci to regularne przekazywanie kodu źródłowego i wszystkiego, co potrzeba do jego skompilowania, a nie jednorazowe przekazanie na końcu projektu, i czwarty to to, że repozytorium od pierwszego dnia leży na koncie Państwa organizacji. Piąty to lista komponentów open source wraz z ich licencjami, bo bez tej listy nikt później nie będzie wiedział, co w systemie jest i na jakich warunkach; szósty to umowa powierzenia przetwarzania, jeśli wykonawca będzie widział rzeczywiste dane, i siódmy to porozumienie o tym, co dzieje się ze środowiskami, kluczami i dostępami na końcu współpracy.

Żaden z tych punktów nie wymaga długiego tekstu, żaden nie kłóci się z dobrą współpracą, i żaden uczciwy wykonawca się im nie sprzeciwia, bo zapisują dokładnie to, co obie strony i tak mają na myśli. Jedyna rzecz, którą zmieniają, jest to, że porozumienie nie zależy już od tego, czy konkretni ludzie po trzech latach nadal pracują w tej samej firmie i czy ktoś pamięta, co wtedy powiedziano ustnie. Te punkty warto żądać od każdego wykonawcy, także od nas, i wpisać je w umowę przed rozpoczęciem prac. Nasza strona tworzenia dedykowanych systemów biznesowych obiecuje obecnie przekazać kod źródłowy, dokumentację i konfigurację infrastruktury na końcu prac, i właśnie dlatego trzeci punkt tej listy, czyli regularne przekazywanie w toku prac, warto omówić osobno, a nie przyjąć, że jest oczywisty. Jeśli chcą Państwo, żebyśmy przejrzeli już istniejącą umowę, proszę do nas napisać.