1. Чітко визначте, який саме результат щодо прав на код потрібен
Перш ніж писати хоча б один пункт, вирішіть, що саме замовник купує. Повна передача прав, ліцензія чи право власності лише після остаточної оплати — це не одне й те саме, і договір має відповідати тій бізнес-схемі, яка вам справді потрібна. Якщо замовник очікує отримати права на вихідний код уже в перший день, так і напишіть. Якщо фрилансер зберігає права до закриття останнього рахунка, це теж треба зазначити. Одна нечітка фраза може спричинити місяці суперечок.
Саме тут тема «як скласти фриланс-контракт на право власності на вихідний код» стає по-справжньому практичною, а запит на кшталт «як оформити передачу прав на вихідний код» допомагає сфокусуватися на головному. Засновник стартапу може хотіти повністю передати репозиторій, а невелике агентство — лише широку ліцензію на запуск застосунку. Це різні угоди. Якщо в договорі їх змішати, незадоволеними залишаться обидві сторони, і жодна не буде повністю захищена.
Використайте договір, щоб відповісти на три прямі запитання: кому належить код, коли право власності переходить і чи може замовник змінювати або перепродавати роботу. Якщо відповідь — «після остаточної оплати», прямо вкажіть, що до моменту надходження коштів передача не відбувається. Якщо відповідь — «повна передача від моменту створення», напишіть це чітко й без зайвих ускладнень. Короткі речення тут допомагають.
Для корисного порівняння уважного підходу до вибору платформи дивіться як безпечно найняти фрилансера. Та стаття про те, як розумно обирати людей; ця — про те, як зафіксувати домовленості після вибору.
2. Укажіть конкретні кодові активи, що входять до обсягу робіт
Не дозволяйте словосполученню «вихідний код» висіти в повітрі як приємна, але нечітка фраза. Назвіть активи. Якщо проєкт включає код застосунку, скрипти, репозиторії, файли збірки, конфігурації розгортання, документацію та будь-який перероблений або похідний код, створений під час проєкту, перерахуйте їх. Договір, у якому написано лише «код», пізніше неминуче дає підстави для спорів. Двох слів замало.
Думайте папками й файлами, а не абстракціями. Наприклад, обсяг робіт може охоплювати основний репозиторій застосунку, окремий репозиторій адмінпанелі, CI-скрипти, файли міграцій бази даних, API-обгортки та README з описом локального налаштування. Якщо фрилансер створює виправлену версію наявного модуля під час проєкту, вирішіть, чи входить цей патч до результату. Така деталь має значення.
Ось простий спосіб сформулювати обсяг: «Увесь вихідний код і пов’язані файли проєкту, створені для Проєкту X, включно з кодом, написаним у Репозиторії A, та будь-яким похідним або переробленим кодом, створеним протягом строку дії цієї угоди». У цьому реченні немає витонченості. Воно працює, бо називає місце, тип роботи та часові рамки.
Якщо в проєкті кілька репозиторіїв, додайте нумерований список. Один репозиторій — один рядок. Два репозиторії — два рядки. Договір не має змушувати когось здогадуватися, чи входить пакет мобільного застосунку до вихідного коду, чи це лише експортований артефакт.
3. Додайте чіткий пункт про передання прав інтелектуальної власності
Пункт про передання прав інтелектуальної власності — це серце договору. У ньому має бути сказано, що фрилансер передає замовнику всі права, титул і інтереси щодо створеного коду. Якщо передання відбувається під час створення — так і пишіть. Якщо після оплати — зазначте саме це. У пункті не повинно бути прихованих припущень.
Практичний варіант формулювання може звучати так: «Після повної оплати всіх сум, належних за цією угодою, Фрилансер передає Замовнику всі права інтелектуальної власності на результати, створені спеціально для Замовника в межах цього проєкту, за винятком попередньо наявних матеріалів, перелічених у Додатку A». Таке формулювання дає момент передання, умову оплати та виняток. Три елементи в одному реченні.
Деякі договори також зазначають, що передання діє у всьому світі та на весь строк охорони, включно з поновленнями й продовженнями, якщо це дозволено. Така мова поширена, бо програмне забезпечення може жити роками, і ніхто не хоче переукладати угоду про права, коли застосунок уже працює в продакшені. Одного короткого пункту про передання може бути замало, якщо право в конкретній юрисдикції вимагає більше деталей.
Для пов’язаного погляду на умови та правила платформи сторінка правила сайту 24freelance.pro. freelance стане корисним фоном. Вона не напише пункт за вас, але нагадує, що офіційні правила й текст договору не повинні суперечити одне одному.
4. Відокремте попередньо наявні інструменти, шаблони та повторно використовувані компоненти
Фрилансери часто приносять на проєкт власні допоміжні напрацювання. Шаблон, кастомна утиліта, приватна API-обгортка або скрипт збірки можуть існувати ще до початку робіт. Договір має захищати ці попередньо наявні напрацювання, але водночас давати замовнику права на фінальний результат. Без такого розмежування замовник може вирішити, що купив увесь інструментарій.
Найкращий спосіб — перелічити виключені матеріали в додатку або розкладі. Назвіть його Додаток A, Додаток B або Додаток 1. Перелічіть кожен попередньо наявний інструмент, шаблон чи компонент, який фрилансер не передає. Якщо замовник може використовувати один із цих елементів у межах результату, зазначте, чи таке використання є ліцензійним, а також чи ліцензія виключна або невиключна. Невеликі позначки запобігають великим конфліктам.
Приклад: фрилансер будує платіжний флоу з використанням приватної бібліотеки валідації, створеної два роки тому. Договір може передбачати, що бібліотека залишається у власності фрилансера, а замовник отримує безстрокову ліцензію на її використання лише вбудованою у доставлений застосунок формою. Це захищає попередню роботу фрилансера й водночас залишає замовнику придатний до використання продукт. Межа між «належить» і «ліцензується» має бути видимою.
Це той випадок, коли текст у додатку кращий за розпливчасті обіцянки. Якщо фрилансер каже: «У мене є деякий повторно використовуваний код», — цього недостатньо. Внесіть назви до розкладу. Запишіть винятки. І зазначте номер розкладу в основному тексті, щоб ніхто не забув відкрити його пізніше.
5. Встановіть вимоги до передачі, доступу до репозиторію та хендоверу
Пунктів про право власності недостатньо, якщо замовник фактично не може отримати файли. Договір має охоплювати доступ до Git, історію комітів, передачу гілок, передачу облікових даних, документацію та положення про те, що всі фінальні файли вихідного коду передаються під час приймання. Гарний юридичний текст — це добре; відсутній пароль до репозиторію — ні.
Чітко визначте, що означає доставка. Чи пушить фрилансер фінальний код до репозиторію, який належить замовнику? Чи надає zip-архів усього проєкту? Чи входять до передачі нотатки щодо схеми бази даних, змінні середовища та кроки розгортання? Якщо проєкт залежить від приватного сервісного акаунта, у договорі слід сказати, коли ці облікові дані переходять до замовника або коли їх потрібно замінити. Один пропущений токен може зупинити запуск.
Тримайте умови щодо репозиторію конкретними. Наприклад: «Фрилансер надасть Замовнику адміністраторський доступ до репозиторію проєкту до дати здачі, збереже історію комітів, якщо Замовник не попросить про чисту передачу, і передасть контроль над усіма гілками, які використовувалися для робіт у продакшені». Така мова охоплює доступ, історію та право на гілки в одному місці. Якщо замовнику потрібна окрема staging-гілка, назвіть і її.
Хороші умови передачі також зменшують суперечки в стилі «я ж усе надіслав». Якщо приймання залежить від передачі фінальних файлів вихідного коду, вкажіть, які саме це файли. Якщо фінальна документація включає нотатки з налаштування, перерахуйте їх. Якщо проєкт охоплює хмарне розгортання, то навіть облікові дані до цього середовища можуть вимагати окремого кроку передачі, і тут хмарні обчислення можуть впливати на практичний бік доставки.
6. Додайте правила щодо конфіденційності, open source та коду третіх сторін
Питання власності на вихідний код може швидко ускладнитися, якщо в проєкт потрапляє сторонній код. Договір має обмежувати неузгоджені бібліотеки, вимагати погодження для використання open source і зобов’язувати розкривати компоненти або залежності третіх сторін, які можуть вплинути на право власності. Якщо фрилансер додає пакет із ліцензією, що обмежує комерційне використання, замовник має знати про це до релізу, а не після звернення в підтримку.
Встановіть правило для матеріалів open source. Наприклад, фрилансер може використовувати open-source-код лише за письмового погодження замовника і лише якщо умови ліцензії не суперечать очікуванням замовника щодо власності. Це означає, що фрилансер має ідентифікувати будь-який компонент GPL, LGPL, MIT, Apache чи подібний, використаний у проєкті, і пояснити практичний ефект. Назви мають значення.
Код третіх сторін заслуговує на таку саму чесність. Платний SDK, скрипт із попереднього місця роботи або фрагмент, скопійований із публічного репозиторію, можуть ускладнити питання власності. Договір має вимагати розкриття будь-якого такого компонента до його включення. Якщо потрібне погодження, зробіть процес погодження окремим кроком, а не повідомленням у чаті. Запис у Slack легко загубити.
Конфіденційність також має охоплювати вміст репозиторію, облікові дані, нотатки щодо архітектури та бізнес-логіку. Це не просто юридична формальність. Конкурент, який побачить процес збірки або схему розгортання, може отримати більше, ніж замовник планував розкрити. Якщо проєкт передбачає публічні кейси або використання в портфоліо, у договорі слід зазначити, чи може фрилансер показувати скриншоти після запуску.
7. Визначте приймання, оплату та момент переходу прав
Передання прав часто залежить від оплати. Це нормально. У договорі слід зазначити, чи тригером для переходу прав є погодження етапу або остаточна оплата, а також що відбувається, якщо проєкт завершується раніше. Якщо передання відбувається під час приймання, приймання потрібно визначити чітко. Якщо воно настає після оплати фінального рахунка, напишіть це простими словами.
Не покладайтеся на пам’ять щодо строків. Пункт може передбачати, що результати вважаються прийнятими після письмового затвердження або після визначеного строку на перевірку, якщо не надійшло повідомлення про відхилення. Потім прив’яжіть передання прав або до цього моменту приймання, або до отримання оплати після приймання. Одна подія — один наслідок. Така структура не дає сторонам сперечатися про порядок дій.
Дострокове припинення потребує окремого правила. Уявімо, що замовник скасовує проєкт після другого етапу. Чи стає замовник власником коду, за який уже заплатив? Чи зберігає фрилансер права на незавершені модулі? Чи отримує замовник ліцензію на використання часткової роботи, чи лише копію для внутрішнього перегляду? Договір має відповісти на всі три запитання ще до початку кодування.
Для більш ризикових проєктів деякі команди розділяють оплату і право власності. Фрилансер може отримувати часткову оплату на кожному етапі, а право власності на завершений код переходить лише після закриття останнього етапу. Це може працювати, але лише якщо в договорі пояснено, чи дозволено частково оплачений код використовувати внутрішньо під час проєкту. Якщо ні — так і скажіть.
8. Додайте чеклист перед відправленням договору на підпис
Перед тим як надсилати договір, пройдіться по чеклисту. Використовуйте назви, шляхи та дати. Назва проєкту, розташування репозиторію, пункт про право власності, виключені матеріали, обов’язки щодо передачі та будь-яка юридична перевірка для формулювань, що залежать від юрисдикції, мають бути на місці. Якщо чогось не вистачає, спочатку виправте це. Поспішний підпис усе одно несе ризики.
Ось практичний список перед відправленням:
- Назва проєкту відповідає технічному завданню.
- Розташування репозиторію вказано за URL або точним шляхом.
- Пункт про право власності описує, коли відбувається передання.
- Виключені матеріали перелічені в додатку.
- Обов’язки щодо передачі включають вихідні файли, документацію та доступ.
- Правила щодо open source та коду третіх сторін прописані.
- Строки приймання та оплати пов’язані між собою.
- Формулювання, що залежать від юрисдикції, перевірені юристом.
Якщо договір готується для команди, яка також цінує публічну репутацію, варто переглянути відгуки про фрилансера перед тим, як доручати йому більше роботи. Договір може захистити право власності на код, але він не виправить поганих звичок під час передачі або повторних зривів дедлайнів. Два запобіжники кращі за один.
І ще одна практична нотатка: якщо проєкт прив’язаний до специфічного робочого процесу на платформі, договір не має суперечити правилам самого сайту, послідовності платежів або шляху погодження. Саме тому багато клієнтів тримають короткий внутрішній чеклист поруч із чернеткою договору. Це звучить просто. Простота — це добре. Для тих, хто готує фриланс контракт право власності на код, корисно також заздалегідь звірити, чи не бракує окремого пункту про передачу репозиторію. А якщо потрібна більш формальна назва, то доречним орієнтиром буде «договір на передачу прав на програмний код».
