Jak napisać umowę freelancerską o własności kodu

1. Określ dokładnie oczekiwany rezultat dotyczący własności kodu

Zanim napiszesz choćby jedno postanowienie, zdecyduj, co tak naprawdę kupuje klient. Pełne przeniesienie praw, licencja albo własność dopiero po finalnej płatności to nie to samo, a umowa powinna odpowiadać rzeczywistemu modelowi współpracy, którego chcesz. Jeśli klient ma oczekiwać, że będzie właścicielem kodu źródłowego od pierwszego dnia, powiedz to wprost. Jeśli freelancer zachowuje prawa do czasu opłacenia ostatniej faktury, też to zapisz. Jedno niejasne zdanie potrafi wywołać miesiące tarć.

To właśnie tutaj temat „jak napisać umowę freelancerską własność kodu źródłowego” staje się praktyczny. Założyciel startupu może chcieć przejęcia całego repozytorium, a mała agencja może potrzebować jedynie szerokiej licencji na uruchamianie aplikacji. To są różne ustalenia. Umowa, która je miesza, może zirytować obie strony i nie zabezpieczyć w pełni żadnej z nich.

W umowie odpowiedz na trzy proste pytania: kto jest właścicielem kodu, kiedy następuje zmiana właściciela i czy klient może modyfikować lub odsprzedawać efekt pracy. Jeśli odpowiedź brzmi „po finalnej płatności”, jasno napisz, że przed zaksięgowaniem płatności nie dochodzi do przeniesienia. Jeśli odpowiedź brzmi „pełne przeniesienie od momentu stworzenia”, zapisz to wyraźnie i bez zbędnych ozdobników. Krótkie zdania pomagają.

Dla dobrego porównania ostrożnego korzystania z platformy zobacz jak bezpiecznie zatrudnić freelancera. Tamten artykuł dotyczy rozsądnego wyboru wykonawcy; ten pokazuje, jak spisać ustalenia, gdy już go wybierzesz.

2. Wskaż konkretne zasoby kodu objęte umową

Nie pozwól, by „kod źródłowy” było tylko miłym, ale pustym określeniem. Nazwij zasoby. Jeśli projekt obejmuje kod aplikacji, skrypty, repozytoria, pliki builda, konfiguracje wdrożeniowe, dokumentację oraz wszelki kod przerobiony lub pochodny stworzony w trakcie prac, wymień je. Umowa, która mówi jedynie „kod”, prowokuje późniejsze spory. Dwa słowa nie wystarczą.

Myśl w kategoriach folderów i plików, a nie abstrakcji. Na przykład zakres może obejmować główne repozytorium aplikacji, osobne repozytorium panelu administracyjnego, skrypty CI, pliki migracji bazy danych, wrappery API oraz plik README opisujący lokalną konfigurację. Jeśli freelancer stworzy poprawioną wersję istniejącego modułu podczas projektu, zdecyduj, czy ta poprawka jest częścią rezultatu. Ten szczegół ma znaczenie.

Oto prosty sposób ujęcia zakresu: „Cały kod źródłowy i powiązane pliki projektu stworzone dla Projektu X, w tym kod napisany w Repozytorium A oraz wszelki kod pochodny lub przerobiony powstały w okresie obowiązywania niniejszej umowy.” To zdanie nie jest efektowne. Działa, bo wskazuje miejsce, rodzaj pracy i ramy czasowe.

Jeśli projekt obejmuje wiele repozytoriów, dołącz listę numerowaną. Jedno repozytorium, jedna linia. Dwa repozytoria, dwie linie. Umowa nie powinna zmuszać nikogo do zgadywania, czy paczka aplikacji mobilnej to kod źródłowy, czy tylko wyeksportowany artefakt.

3. Dodaj jasną klauzulę cesji praw własności intelektualnej

Klauzula cesji praw własności intelektualnej to serce umowy. Powinna mówić, że freelancer przenosi na klienta wszelkie prawa, tytuły i interesy do stworzonego kodu. Jeśli przeniesienie następuje w chwili stworzenia, napisz to. Jeśli następuje po zapłacie, zapisz to zamiast tego. Klauzula nie powinna opierać się na ukrytym założeniu.

Praktyczna klauzula może brzmieć tak: „Po uiszczeniu pełnej kwoty należnej na podstawie niniejszej umowy Freelancer przenosi na Klienta wszelkie prawa własności intelektualnej do rezultatów stworzonych specjalnie dla Klienta w ramach tego projektu, z wyłączeniem materiałów istniejących wcześniej, wymienionych w Załączniku A.” Takie brzmienie wskazuje moment przeniesienia, warunek zapłaty i wyłączenie. Trzy elementy w jednym zdaniu. To właśnie jest dobra cesja praw do kodu źródłowego umowa freelancer, bo łączy precyzję z prostotą.

Niektóre umowy doprecyzowują też, że przeniesienie obowiązuje na całym świecie i przez cały okres ochrony, w tym odnowienia i przedłużenia, o ile są dopuszczalne. Taki język jest częsty, bo oprogramowanie może funkcjonować latami i nikt nie chce renegocjować własności, gdy aplikacja jest już w produkcji. Sama zwięzła cesja może być zbyt skąpa, jeśli prawo właściwe wymaga większej szczegółowości.

Powiązane spojrzenie na warunki i zasady platformy znajdziesz na stronie zasady serwisu 24freelance.pro. freelance. To nie napisze klauzuli za ciebie, ale przypomina, że reguły formalne i język umowy nie powinny ze sobą kolidować.

4. Oddziel narzędzia, szablony i komponenty wielokrotnego użytku, które istniały wcześniej

Freelancerzy często przynoszą do projektu własne pomocne rozwiązania. Szablon, własna biblioteka narzędziowa, prywatny wrapper API albo skrypt builda mogły istnieć już przed rozpoczęciem projektu. Umowa powinna chronić tę wcześniejszą pracę, a jednocześnie dawać klientowi prawa do finalnego rezultatu. Bez takiego rozdzielenia klient może sądzić, że kupił całe narzędziownię.

Najczytelniej jest wymienić wyłączone materiały w załączniku lub harmonogramie. Nazwij go Załącznik A, B albo Aneks 1. Wypisz każde istniejące wcześniej narzędzie, szablon lub komponent wielokrotnego użytku, którego freelancer nie przenosi. Jeśli klient może korzystać z któregoś z tych elementów wewnątrz rezultatu, wskaż, czy odbywa się to na podstawie licencji oraz czy jest ona wyłączna, czy niewyłączna. Małe oznaczenia zapobiegają dużym sporom.

Przykład: freelancer buduje ścieżkę płatności z użyciem prywatnej biblioteki walidacyjnej stworzonej dwa lata wcześniej. Umowa może stanowić, że biblioteka pozostaje własnością freelancera, a klient otrzymuje wieczystą licencję na korzystanie z niej wyłącznie jako elementu osadzonego w dostarczonej aplikacji. To chroni wcześniejszą pracę freelancera, a klient nadal dostaje użyteczny produkt. Granica między „własnością” a „licencją” musi być widoczna.

To jeden z tych obszarów, w których załącznik działa lepiej niż mgliste obietnice. Jeśli freelancer mówi: „Mam trochę kodu wielokrotnego użytku”, to za mało. Wpisz nazwy do harmonogramu. Wpisz wyjątki na piśmie. Wpisz numer załącznika w treści głównej, żeby nikt nie zapomniał do niego wrócić.

5. Ustal wymagania dotyczące dostarczenia, dostępu do repozytorium i przekazania projektu

Klauzule o własności nie wystarczą, jeśli klient nie może faktycznie dostać plików. Umowa powinna obejmować dostęp do Git, historię commitów, przekazanie gałęzi, transfer danych logowania, dokumentację oraz zapis, że wszystkie finalne pliki źródłowe są przekazywane przy odbiorze. Dopracowana klauzula prawna jest dobra; brak hasła do repozytorium — nie.

Opisz dokładnie, co oznacza dostarczenie. Czy freelancer wypycha finalny kod do repozytorium należącego do klienta? Czy przekazuje archiwum zip z całym projektem? Czy przekazanie obejmuje notatki o schemacie bazy, zmienne środowiskowe i kroki wdrożenia? Jeśli projekt opiera się na prywatnym koncie usługowym, umowa powinna mówić, kiedy te dane trafiają do klienta albo zostają zmienione. Jedno pominięte hasło może zatrzymać start.

Uczyń zasady pracy z repozytorium konkretne. Na przykład: „Freelancer udzieli Klientowi dostępu administracyjnego do repozytorium projektu najpóźniej w dniu przekazania, zachowa historię commitów, chyba że Klient zażąda czystego przekazania, oraz przekaże kontrolę nad wszystkimi gałęziami używanymi do pracy produkcyjnej.” Taki zapis obejmuje dostęp, historię i własność gałęzi w jednym miejscu. Jeśli klient chce osobnej gałęzi staging, nazwij ją także.

Dobre warunki przekazania zmniejszają też spory typu „przesłałem wszystko”. Jeśli odbiór zależy od dostarczenia finalnych plików źródłowych, wskaż dokładnie, które to pliki. Jeśli końcowa dokumentacja obejmuje notatki konfiguracyjne, wymień je. Jeśli projekt zawiera wdrożenie w chmurze, to nawet dane dostępowe do tego środowiska mogą wymagać osobnego etapu przekazania — i właśnie tutaj technologia chmury obliczeniowej może wpływać na praktyczną stronę dostarczenia.

6. Uwzględnij poufność, open source i zasady dotyczące kodu osób trzecich

Własność kodu źródłowego szybko się komplikuje, gdy do projektu trafia kod z zewnątrz. Umowa powinna ograniczać nieujawnione biblioteki, wymagać zgody na użycie open source oraz nakazywać ujawnienie komponentów lub zależności stron trzecich, które mogą wpływać na własność. Jeśli freelancer doda pakiet na licencji ograniczającej użycie komercyjne, klient powinien wiedzieć o tym przed wydaniem, a nie po pojawieniu się zgłoszenia serwisowego.

Ustal zasadę dla materiałów open source. Na przykład freelancer może używać kodu open source tylko wtedy, gdy klient zatwierdzi to na piśmie i tylko jeśli warunki licencji nie kolidują z oczekiwaniami klienta co do własności. Oznacza to, że freelancer musi zidentyfikować każdy komponent GPL, LGPL, MIT, Apache lub podobny użyty w projekcie i wyjaśnić praktyczny skutek. Nazwy mają znaczenie.

Kod stron trzecich zasługuje na taką samą szczerość. Płatne SDK, skrypt z poprzedniego miejsca pracy albo fragment skopiowany z publicznego repozytorium mogą skomplikować własność. Umowa powinna wymagać ujawnienia każdego takiego elementu przed jego włączeniem. Jeśli potrzebna jest zgoda, zrób z niej formalny etap, a nie wiadomość na czacie. Notatkę w Slacku łatwo zgubić.

Poufność powinna obejmować także zawartość repozytorium, dane dostępowe, notatki architektoniczne i logikę biznesową. To nie tylko porządek prawny. Konkurent, który zobaczy proces builda albo przebieg wdrożenia, może zyskać więcej, niż klient zamierzał ujawnić. Jeśli projekt ma dotyczyć publicznych studiów przypadku lub wykorzystania w portfolio, umowa powinna wskazywać, czy freelancer może pokazywać zrzuty ekranu po uruchomieniu.

7. Określ moment odbioru, płatności i przeniesienia własności

Przeniesienie własności często zależy od płatności. To normalne. Umowa powinna wskazywać, czy akceptacja etapu albo finalna płatność uruchamia przeniesienie własności, i powinna opisać, co dzieje się, jeśli projekt kończy się wcześniej. Jeśli przeniesienie następuje po odbiorze, zdefiniuj odbiór jasno. Jeśli następuje po opłaceniu ostatniej faktury, napisz to prostym językiem.

Nie zostawiaj terminu pamięci. Klauzula może stanowić, że rezultaty uważa się za odebrane po pisemnej akceptacji albo po upływie wskazanego okresu weryfikacji, jeśli nie wpłynie żadne odrzucenie. Następnie powiąż przeniesienie własności z tym zdarzeniem albo z otrzymaniem płatności po odbiorze. Jedno zdarzenie, jeden skutek. Taka konstrukcja ogranicza spory o kolejność działań.

Wcześniejsze zakończenie współpracy wymaga własnej reguły. Załóżmy, że klient rezygnuje po etapie 2. Czy ma prawa do kodu, za który już zapłacił? Czy freelancer zachowuje prawa do niedokończonych modułów? Czy klient otrzymuje licencję na korzystanie z części pracy, czy tylko kopię do wewnętrznego przeglądu? Umowa powinna odpowiedzieć na wszystkie trzy pytania, zanim ktokolwiek zacznie kodować.

W projektach o większym ryzyku niektóre zespoły oddzielają płatność od własności. Freelancer może otrzymywać częściowe płatności po każdym etapie, a własność ukończonego kodu może przejść dopiero po zamknięciu ostatniego etapu. To może działać, ale tylko wtedy, gdy umowa wyjaśnia, czy częściowo opłacony kod jest licencjonowany do użytku wewnętrznego w trakcie projektu. Jeśli odpowiedź brzmi nie, napisz nie.

8. Dodaj checklistę gotową do podpisu przed wysłaniem umowy

Zanim wyślesz umowę, przejdź przez checklistę. Użyj nazw, ścieżek i dat. Nazwa projektu, lokalizacja repozytorium, klauzula własności, wyłączone materiały, obowiązki w zakresie dostarczenia oraz ewentualna weryfikacja prawna języka specyficznego dla jurysdykcji powinny być obecne. Jeśli brakuje któregokolwiek z tych elementów, najpierw to popraw. Pośpieszny podpis nadal wiąże się z ryzykiem.

Oto praktyczna lista przed wysłaniem:

• Nazwa projektu zgadza się z zakresem prac.
• Lokalizacja repozytorium jest wskazana adresem URL albo dokładną ścieżką.
• Klauzula własności mówi, kiedy następuje przeniesienie.
• Wyłączone materiały są wymienione w załączniku.
• Obowiązki dotyczące dostarczenia obejmują pliki źródłowe, dokumentację i dostęp.
• Zasady dotyczące open source i kodu stron trzecich są opisane.
• Moment akceptacji i płatności są ze sobą powiązane.
• Język właściwy dla danej jurysdykcji został sprawdzony prawnie.

Jeśli umowa dotyczy zespołu, który ceni też dobrą reputację publiczną, warto przed przydzieleniem większej liczby zadań przejrzeć opinie o freelancerze. Umowa może chronić własność kodu, ale nie naprawi złych nawyków przekazywania pracy ani powtarzających się opóźnień. Dwie zabezpieczające warstwy są lepsze niż jedna.

Jeszcze jedna praktyczna uwaga: jeśli projekt jest powiązany z niszowym procesem na platformie, umowa nie powinna kolidować z własnymi zasadami działania serwisu, kolejnością płatności ani ścieżką akceptacji. Dlatego wielu klientów trzyma krótki wewnętrzny checklist obok projektu umowy. Brzmi prosto. Prosto jest dobrze. Warto też pamiętać o formule umowa z freelancerem prawa do kodu źródłowego, bo to właśnie ona najczęściej porządkuje oczekiwania obu stron już na starcie.