Jak napisać umowę freelancerską na własność kodu źródłowego

1. Zdefiniuj dokładny wynik własności kodu

Zanim napiszesz jakikolwiek zapis, zdecyduj, co klient tak naprawdę kupuje. Pełne przeniesienie, licencja lub własność dopiero po ostatecznej płatności to nie to samo, a umowa powinna odpowiadać rzeczywistemu układowi biznesowemu, którego naprawdę chcesz. Jeśli klient oczekuje, że będzie właścicielem kodu źródłowego od pierwszego dnia, powiedz to. Jeśli freelancer zachowuje prawa do momentu, gdy ostatnia faktura zostanie opłacona, powiedz to również. Jedno niejasne zdanie może spowodować miesiące napięć.

Tutaj zaczyna się praktyczna część "jak napisać umowę freelancerską na własność kodu źródłowego". Założyciel startupu może chcieć przenieść całe repozytorium, podczas gdy mała agencja może potrzebować tylko szerokiej licencji na uruchomienie aplikacji. To różne umowy. Umowa, która je miesza, może pozostawić obie strony zirytowane, a żadna strona nie będzie w pełni chroniona.

Użyj umowy, aby odpowiedzieć na trzy bezpośrednie pytania: kto jest właścicielem kodu, kiedy własność przechodzi w ręce, i czy klient może modyfikować lub odsprzedawać dzieło. Jeśli odpowiedź brzmi „po ostatecznej płatności”, wyraźnie zaznacz, że żadne przeniesienie nie następuje przed zaksięgowaniem płatności. Jeśli odpowiedź brzmi „pełne przeniesienie od momentu stworzenia”, napisz to jasno i bez dramatów. Krótkie zdania są tutaj pomocne.

Dla dobrego porównania ostrożnego korzystania z platformy, zobacz jak bezpiecznie zatrudnić freelancera. Ten artykuł dotyczy mądrego wyboru ludzi; ten dotyczy spisania umowy, gdy już ich wybierzesz.

2. Zidentyfikuj konkretne zasoby kodu w zakresie

Nie pozwól, aby „kod źródłowy” krążył jako fraza poprawiająca samopoczucie. Nazwij zasoby. Jeśli projekt obejmuje kod aplikacji, skrypty, repozytoria, pliki budowy, konfiguracje wdrożeniowe, dokumentację oraz wszelki refaktoryzowany lub pochodny kod stworzony w trakcie projektu, wymień je. Umowa, która mówi tylko „kod”, zaprasza do późniejszych sporów. Dwa słowa to za mało.

Myśl w folderach i plikach, a nie w abstrakcjach. Na przykład, zakres może obejmować główne repozytorium aplikacji, osobne repozytorium panelu administracyjnego, skrypty CI, pliki migracji bazy danych, opakowania API oraz README, które wyjaśnia lokalną konfigurację. Jeśli freelancer stworzy poprawioną wersję istniejącego modułu w trakcie projektu, zdecyduj, czy ta poprawka jest częścią dostarczanego materiału. Ten szczegół ma znaczenie.

Oto prosty sposób na sformułowanie zakresu: „Wszystkie kody źródłowe i związane z projektem pliki stworzone dla Projektu X, w tym kod napisany w Repozytorium A oraz wszelki pochodny lub refaktoryzowany kod wyprodukowany w trakcie obowiązywania tej umowy.” To zdanie nie jest wyszukane. Działa, ponieważ nazywa miejsce, rodzaj pracy i okres czasu.

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

3. Dodaj jasny zapis dotyczący przeniesienia praw własności intelektualnej

Klauzula dotycząca przeniesienia praw własności intelektualnej jest sercem umowy. Powinna stwierdzać, że freelancer przenosi na klienta wszystkie prawa, tytuł i interes w stworzonym kodzie. Jeśli przeniesienie następuje w momencie stworzenia, powiedz to. Jeśli następuje w momencie płatności, powiedz to zamiast tego. Klauzula nie powinna opierać się na ukrytym założeniu.

Praktyczna klauzula może brzmieć tak: „Po pełnej płatności wszystkich kwot należnych na mocy niniejszej umowy, Freelancer przenosi na Klienta wszystkie prawa własności intelektualnej do dostarczonych materiałów stworzonych specjalnie dla Klienta w ramach tego projektu, z wyłączeniem wszelkich materiałów istniejących przedtem wymienionych w Załączniku A.” Taki zapis daje punkt przeniesienia, warunek płatności i wyjątek. Trzy ruchome elementy, jedno zdanie.

Niektóre umowy mówią również, że przeniesienie jest skuteczne na całym świecie i przez cały okres ochrony, w tym odnawiania i przedłużenia, gdzie to dozwolone. Tego rodzaju język jest powszechny, ponieważ oprogramowanie może funkcjonować przez lata, a nikt nie chce renegocjować własności, gdy aplikacja jest już w produkcji. Przeniesienie w jednej linii może być zbyt ogólne, jeśli prawo w danej jurysdykcji oczekuje większej szczegółowości.

Aby uzyskać powiązany przegląd warunków i zasad platformy, zasady strony 24freelance.pro. freelance strona jest przydatnym tłem. Nie napisze klauzuli za Ciebie, ale przypomina, że formalne zasady i język umowy nie powinny być sprzeczne.

4. Oddziel istniejące wcześniej narzędzia, szablony i komponenty wielokrotnego użytku

Freelancerzy często przynoszą swoich pomocników do pracy. Szablon, niestandardowa biblioteka narzędziowa, prywatny wrapper API lub skrypt budujący mogą już istnieć przed rozpoczęciem projektu. Umowa powinna chronić tę istniejącą pracę, jednocześnie dając klientowi prawa do ostatecznego produktu. Bez tego podziału klient może uwierzyć, że kupił całe narzędzie.

Najczystsza metoda to wymienienie wykluczonych materiałów w załączniku lub harmonogramie. Nazwij to Harmonogram A, Harmonogram B lub Załącznik 1. Wymień każde istniejące narzędzie, szablon lub komponent wielokrotnego użytku, którego freelancer nie przypisuje. Jeśli klient ma prawo używać jednego z tych elementów w dostarczonym produkcie, powiedz, czy to użycie jest na podstawie licencji, i czy licencja jest wyłączna czy niewyłączna. Małe etykiety zapobiegają dużym kłótniom.

Przykład: freelancer buduje proces płatności, używając prywatnej biblioteki walidacyjnej stworzonej dwa lata wcześniej. Umowa może stwierdzić, że biblioteka pozostaje własnością freelancera, podczas gdy klient otrzymuje wieczystą licencję na używanie biblioteki tylko jako wbudowanej w dostarczoną aplikację. To chroni wcześniejszą pracę freelancera i nadal pozostawia klientowi użyteczny produkt. Granica między „własnością” a „licencjonowaniem” musi być widoczna.

To jest jeden z obszarów, w którym język załącznika przewyższa niejasne obietnice. Jeśli freelancer mówi: „Mam trochę kodu wielokrotnego użytku”, to nie wystarczy. Wpisz nazwy w harmonogramie. Wpisz wyjątki na piśmie. Umieść numer harmonogramu w głównym tekście, aby nikt nie zapomniał go otworzyć później.

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

Klauzule dotyczące własności nie są wystarczające, jeśli klient nie może faktycznie uzyskać plików. Umowa powinna obejmować dostęp do Gita, historię commitów, przekazanie gałęzi, transfer poświadczeń, dokumentację oraz oświadczenie, że wszystkie ostateczne pliki źródłowe są dostarczane przy akceptacji. Dopieszczona klauzula prawna jest miła; brak hasła do repozytorium nie jest.

Wyjaśnij, co oznacza dostawa. Czy freelancer przesyła ostateczny kod do repozytorium należącego do klienta? Czy freelancer dostarcza archiwum zip z całym projektem? Czy przekazanie obejmuje notatki dotyczące schematu bazy danych, zmienne środowiskowe i kroki wdrożenia? Jeśli projekt zależy od prywatnego konta serwisowego, umowa powinna określać, kiedy te poświadczenia przechodzą do klienta lub są zmieniane. Jeden pominięty token może opóźnić uruchomienie.

Utrzymuj warunki dotyczące repozytorium konkretne. Na przykład: „Freelancer przyzna Klientowi dostęp administratora do repozytorium projektu do daty dostawy, zachowa historię commitów, chyba że Klient zażąda czystego przekazania, i przekaże kontrolę nad wszystkimi gałęziami używanymi do pracy produkcyjnej.” Taki język obejmuje dostęp, historię i własność gałęzi w jednym miejscu. Jeśli klient chce osobnej gałęzi stagingowej, nazwij ją również.

Dobre warunki przekazania również redukują spór „Wysłałem wszystko”. Jeśli akceptacja zależy od dostarczenia finalnych plików źródłowych, powiedz, które to pliki. Jeśli finalna dokumentacja zawiera notatki dotyczące konfiguracji, wymień je. Jeśli projekt obejmuje wdrożenie w chmurze, to nawet dane logowania do tego środowiska mogą wymagać osobnego kroku przekazania, co jest miejscem, gdzie technologii chmury obliczeniowej może kształtować praktyczną stronę dostawy.

6. Uwzględnij zasady dotyczące poufności, open-source i kodu stron trzecich

Własność kodu źródłowego może szybko stać się skomplikowana, gdy do projektu wchodzi kod zewnętrzny. Umowa powinna ograniczać nieujawnione biblioteki, wymagać zatwierdzenia do użycia open-source oraz wymagać ujawnienia komponentów lub zależności stron trzecich, które mogą wpłynąć na własność. Jeśli freelancer wprowadzi pakiet na licencji, która ogranicza użycie komercyjne, klient powinien o tym wiedzieć przed wydaniem, a nie po przybyciu zgłoszenia wsparcia.

Ustal zasady dotyczące 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 wtedy, gdy warunki licencji nie kolidują z oczekiwaniami klienta dotyczącymi własności. Oznacza to, że freelancer musi zidentyfikować wszelkie komponenty GPL, LGPL, MIT, Apache lub podobne użyte w projekcie i wyjaśnić ich praktyczny wpływ. Nazwy mają znaczenie.

Kod osób trzecich zasługuje na tę samą uczciwość. Płatne SDK, skrypt od poprzedniego pracodawcy lub fragment skopiowany z publicznego repozytorium mogą skomplikować kwestię własności. Umowa powinna wymagać ujawnienia każdego takiego komponentu przed jego włączeniem. Jeśli potrzebna jest akceptacja, proces akceptacji powinien być krokiem, a nie wiadomością czatu. Notatka w Slacku jest łatwa do zgubienia.

Poufność powinna również obejmować zawartość repozytoriów, dane uwierzytelniające, notatki architektoniczne i logikę biznesową. To nie tylko prawne porządki. Konkurent, który zobaczy proces budowy lub przepływ wdrożenia, może zyskać więcej, niż klient zamierzał ujawnić. Jeśli projekt obejmuje publiczne studia przypadków lub wykorzystanie w portfolio, umowa powinna określać, czy freelancer może pokazywać zrzuty ekranu po uruchomieniu.

7. Zdefiniuj czas akceptacji, płatności i przeniesienia własności

Przeniesienie własności często zależy od płatności. To normalne. Umowa powinna określać, czy zatwierdzenie kamienia milowego lub ostateczna płatność uruchamia przeniesienie własności, i powinna mówić, co się stanie, jeśli projekt zakończy się wcześniej. Jeśli przeniesienie następuje przy akceptacji, zdefiniuj akceptację jasno. Jeśli następuje po opłaceniu ostatecznej faktury, zapisz ten warunek w prostym języku.

Nie zostawiaj czasu na pamięć. Klauzula może stwierdzać, że dostarczone materiały są uznawane za zaakceptowane po pisemnej akceptacji lub po określonym okresie przeglądu, jeśli nie wpłynie powiadomienie o odrzuceniu. Następnie powiąż transfer własności z tym zdarzeniem akceptacji lub z otrzymaniem płatności po akceptacji. Jedno zdarzenie, jedna konsekwencja. Taka struktura zapobiega sporom o kolejność działań.

Wczesne rozwiązanie umowy potrzebuje własnej zasady. Co jeśli klient anuluje po kamieniu milowym 2? Czy klient posiada kod, za który już zapłacono? Czy freelancer zachowuje prawa do niedokończonych modułów? Czy klient otrzymuje licencję na używanie częściowej pracy, czy tylko kopię do wewnętrznego przeglądu? Umowa powinna odpowiedzieć na te trzy pytania, zanim ktokolwiek zacznie kodować.

W przypadku projektów o wyższym ryzyku niektóre zespoły oddzielają płatność od własności. Freelancer może otrzymywać częściową płatność przy każdym kamieniu milowym, podczas gdy własność ukończonego kodu przechodzi dopiero po zamknięciu ostatniego kamienia milowego. To może działać, ale tylko jeśli umowa wyjaśnia, czy częściowo opłacony kod jest licencjonowany do użytku wewnętrznego w trakcie projektu. Jeśli odpowiedź brzmi nie, powiedz nie.

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

Zanim wyślesz umowę, przeprowadź kontrolę. Użyj nazw, ścieżek i dat. Nazwa projektu, lokalizacja repozytorium, klauzula własności, materiały wyłączone, obowiązki dostawy i wszelkie przeglądy prawne potrzebne do języka specyficznego dla jurysdykcji powinny być obecne. Jeśli jeden z tych elementów jest brakujący, napraw to najpierw. Pośpieszny podpis to wciąż ryzyko.

Oto praktyczna lista przed wysyłką:

• Nazwa projektu odpowiada opisowi pracy.
• Lokalizacja repozytorium jest określona przez URL lub dokładną ścieżkę.
• Klauzula własności mówi, kiedy następuje transfer.
• Wyłączone materiały są wymienione w harmonogramie.
• Obowiązki dostawy wspominają o plikach źródłowych, dokumentach i dostępie.
• Zasady dotyczące kodu open-source i kodu stron trzecich są zapisane.
• Czas akceptacji i płatności jest powiązany.
• Język specyficzny dla jurysdykcji przeszedł przegląd prawny.

Jeśli umowa dotyczy zespołu, który również ceni reputację publiczną, warto to przejrzeć opinie freelancerów przed przydzieleniem większej ilości pracy. Umowa może chronić własność kodu, ale nie naprawia złych nawyków przekazywania pracy ani powtarzających się opóźnień. Dwie zabezpieczenia są lepsze niż jedno.

Ostatnia praktyczna uwaga: jeśli projekt jest związany z pracą na niszowej platformie, umowa nie powinna kolidować z własnymi zasadami działania strony, sekwencją płatności ani ścieżką zatwierdzania. Dlatego wielu klientów trzyma krótką wewnętrzną listę kontrolną obok projektu umowy. Brzmi prosto. Prosto jest dobre.