Как оформить права на исходный код в договоре

1. Чётко определите, какой именно результат по правам на код нужен

Прежде чем писать хоть один пункт, решите, что на самом деле покупает клиент. Полная передача прав, лицензия или переход прав только после окончательной оплаты — это не одно и то же, и договор должен соответствовать той бизнес-схеме, которую вы действительно хотите. Если клиент ожидает, что исходный код станет его собственностью с первого дня, так и скажите. Если фрилансер сохраняет права до закрытия последнего счёта, это тоже нужно прямо указать. Одна расплывчатая фраза способна создать месяцы трений.

Вот здесь тема «как составить фриланс-контракт на право собственности на исходный код» становится по-настоящему практической. Основатель стартапа может хотеть получить весь репозиторий, а небольшой агентстве может быть достаточно широкой лицензии на запуск приложения. Это разные сделки. Договор, который их смешивает, способен оставить обе стороны недовольными и при этом не до конца защищёнными. В подобных ситуациях особенно важно заранее понять, нужна ли именно передача прав на исходный код по договору или достаточно лицензии с ограничениями.

Используйте договор, чтобы ответить на три прямых вопроса: кому принадлежит код, когда права переходят и может ли клиент изменять или перепродавать работу. Если ответ — «после окончательной оплаты», чётко укажите, что до поступления платежа перехода прав не происходит. Если ответ — «полная передача с момента создания», напишите это ясно и без лишней драматичности. Здесь помогают короткие предложения, а договор на разработку с передачей прав лучше всего работает, когда формулировки не оставляют пространства для догадок.

Для хорошего сравнения аккуратного использования платформы см. как безопасно нанять фрилансера. Та статья о том, как разумно выбирать людей; эта — о том, как зафиксировать договорённость после выбора.

2. Укажите конкретные активы кода, которые входят в объём работ

Не позволяйте слову «исходный код» звучать как удобная, но пустая формулировка. Называйте активы поимённо. Если проект включает код приложения, скрипты, репозитории, файлы сборки, конфигурации развёртывания, документацию и любой переработанный или производный код, созданный в ходе проекта, перечислите их. Договор, где сказано лишь «код», позже неизбежно вызовет споры. Двух слов недостаточно.

Думайте папками и файлами, а не абстракциями. Например, объём работ может охватывать основной репозиторий приложения, отдельный репозиторий панели администратора, CI-скрипты, файлы миграции базы данных, API-обёртки и README с описанием локальной настройки. Если фрилансер создаёт исправленную версию уже существующего модуля в рамках проекта, решите, входит ли эта правка в результат работ. Эта деталь важна.

Вот простой способ сформулировать объём работ: «Весь исходный код и связанные с проектом файлы, созданные для Проекта X, включая код, написанный в Репозитории A, и любой производный или переработанный код, созданный в течение срока действия настоящего соглашения». Формулировка некрасивая, зато работает: она называет место, тип работы и временные рамки.

Если у проекта несколько репозиториев, приложите нумерованный список. Один репозиторий — одна строка. Два репозитория — две строки. Договор не должен заставлять кого-то гадать, считается ли пакет мобильного приложения исходным кодом или просто экспортированным артефактом.

3. Добавьте чёткий пункт о передаче прав на интеллектуальную собственность

Пункт о передаче прав на интеллектуальную собственность — это сердце договора. В нём должно быть сказано, что фрилансер передаёт клиенту все права, титул и интерес в созданном коде. Если переход происходит при создании, так и пишите. Если при оплате — укажите именно это. Пункт не должен опираться на скрытые предположения.

Практическая формулировка может выглядеть так: «После полной оплаты всех сумм, подлежащих уплате по настоящему соглашению, Фрилансер передаёт Клиенту все права интеллектуальной собственности на результаты работ, созданные специально для Клиента в рамках данного проекта, за исключением любых ранее существовавших материалов, перечисленных в Приложении A». Такая формулировка задаёт момент передачи, условие оплаты и исключение. Три элемента в одном предложении.

В некоторых договорах также указывают, что передача действует по всему миру и на весь срок охраны, включая продления и пролонгации, где это допускается. Такой язык распространён, потому что программное обеспечение может жить годами, и никому не хочется пересматривать вопрос собственности, когда приложение уже работает в продакшене. Одной короткой оговорки может быть недостаточно, если закон в соответствующей юрисдикции требует большей детализации.

Для связанного обзора условий и правил платформы полезна страница правила сайта 24freelance.pro. freelance. Она не напишет пункт за вас, но напомнит, что формальные правила и текст договора не должны противоречить друг другу.

4. Отделите ранее созданные инструменты, шаблоны и переиспользуемые компоненты

Фрилансеры часто приносят на проект свои собственные инструменты. Шаблон, собственная утилитная библиотека, приватная API-обёртка или скрипт сборки могут существовать ещё до начала работы. Договор должен защитить это ранее созданное имущество и при этом дать клиенту права на итоговый результат. Без такого разделения клиент может решить, что купил весь ящик с инструментами.

Самый чистый способ — перечислить исключённые материалы в приложении или расписании. Назовите его Приложение A, Приложение B или Exhibit 1. Перечислите каждый заранее существовавший инструмент, шаблон или переиспользуемый компонент, который фрилансер не передаёт. Если клиенту разрешено использовать один из таких элементов внутри результата работ, укажите, делается ли это по лицензии и является ли лицензия исключительной или неисключительной. Мелкие пометки предотвращают большие конфликты.

Пример: фрилансер строит платёжный сценарий с использованием собственной библиотеки валидации, созданной два года назад. В договоре можно указать, что библиотека остаётся собственностью фрилансера, а клиент получает бессрочную лицензию на её использование только в составе поставленного приложения. Это защищает прежнюю работу фрилансера и при этом оставляет клиенту рабочий продукт. Граница между «в собственности» и «по лицензии» должна быть видимой.

Это как раз тот случай, когда текст приложения лучше расплывчатых обещаний. Если фрилансер говорит: «У меня есть немного переиспользуемого кода», этого недостаточно. Впишите названия в приложение. Впишите исключения письменно. Укажите номер приложения в основной части договора, чтобы потом никто не забыл его открыть. Если возникает вопрос, как оформить права на код фрилансеру, ответ почти всегда начинается с точного списка исключений.

5. Пропишите требования к сдаче, доступу к репозиторию и передаче результатов

Пункты о собственности бесполезны, если клиент фактически не может получить файлы. Договор должен охватывать доступ к Git, историю коммитов, передачу веток, передачу учётных данных, документацию и положение о том, что все финальные исходные файлы передаются при приёмке. Отполированный юридический пункт — это хорошо; отсутствующий пароль от репозитория — нет.

Подробно пропишите, что означает передача. Загружает ли фрилансер финальный код в репозиторий, принадлежащий клиенту? Предоставляет ли он zip-архив всего проекта? Включает ли передача заметки по схеме базы данных, переменным окружения и шагам развёртывания? Если проект зависит от приватной сервисной учётной записи, в договоре должно быть сказано, когда эти данные передаются клиенту или заменяются. Одного пропущенного токена достаточно, чтобы задержать запуск.

Сделайте условия по репозиторию конкретными. Например: «Фрилансер предоставит Клиенту административный доступ к репозиторию проекта к дате сдачи, сохранит историю коммитов, если Клиент не запросит “чистую” передачу, и передаст контроль над всеми ветками, используемыми для production-работ». Такая формулировка охватывает доступ, историю и владение ветками в одном месте. Если клиенту нужна отдельная staging-ветка, её тоже следует назвать.

Хорошие условия передачи также уменьшают споры уровня «я всё отправил». Если приёмка зависит от передачи финальных исходных файлов, укажите, какие именно это файлы. Если финальная документация включает заметки по настройке, перечислите их. Если проект включает облачное развёртывание, то даже доступы к этой среде могут потребовать отдельного шага передачи, и именно здесь технология облачных вычислений может влиять на практическую сторону сдачи проекта.

6. Добавьте правила по конфиденциальности, open-source и стороннему коду

Вопрос собственности на исходный код быстро усложняется, когда в проект попадает внешний код. Договор должен ограничивать нераскрытые библиотеки, требовать согласования использования open-source и обязывать раскрывать сторонние компоненты или зависимости, которые могут повлиять на права собственности. Если фрилансер подключает пакет с лицензией, ограничивающей коммерческое использование, клиент должен знать об этом до релиза, а не после обращения в поддержку.

Установите правило для open-source материалов. Например, фрилансер может использовать open-source-код только при письменном согласовании с клиентом и только если условия лицензии не противоречат ожиданиям клиента относительно собственности. Это значит, что фрилансер должен указать любой компонент GPL, LGPL, MIT, Apache или аналогичный, использованный в проекте, и объяснить его практическое значение. Названия имеют значение.

К стороннему коду нужен такой же честный подход. Платный SDK, скрипт с прошлого места работы или фрагмент, скопированный из публичного репозитория, могут осложнить вопросы собственности. Договор должен требовать раскрытия любого такого компонента до его включения. Если требуется одобрение, сделайте из него отдельный шаг, а не сообщение в чате. Запись в Slack легко потерять.

Конфиденциальность также должна охватывать содержимое репозитория, учётные данные, заметки по архитектуре и бизнес-логику. Это не просто юридическая формальность. Конкурент, увидевший процесс сборки или схему развёртывания, может получить больше, чем клиент изначально хотел раскрыть. Если проект предполагает публичные кейсы или использование в портфолио, в договоре нужно указать, может ли фрилансер показывать скриншоты после запуска.

7. Определите приёмку, оплату и момент перехода прав

Переход прав часто зависит от оплаты. Это нормально. В договоре должно быть указано, запускает ли переход прав одобрение этапа или финальная оплата, и что происходит, если проект завершается досрочно. Если переход происходит при приёмке, определите приёмку чётко. Если он происходит после оплаты финального счёта, напишите это условие простыми словами.

Не оставляйте сроки на память. Пункт может говорить, что результаты считаются принятыми после письменного одобрения или по истечении установленного срока проверки, если не поступило уведомление об отказе. Затем свяжите с этим событием либо переход прав, либо переход после получения оплаты. Одно событие — одно последствие. Такая структура помогает избежать споров о последовательности действий.

Досрочное расторжение требует отдельного правила. Допустим, клиент отменяет проект после этапа 2. Принадлежит ли клиенту код, за который уже заплачено? Сохраняет ли фрилансер права на незавершённые модули? Получает ли клиент лицензию на использование частично выполненной работы или только копию для внутреннего ознакомления? Договор должен ответить на все три вопроса до того, как кто-то начнёт кодить.

Для проектов с более высоким риском некоторые команды разделяют оплату и передачу прав. Фрилансер может получать частичную оплату на каждом этапе, а право собственности на завершённый код переходит только после закрытия последнего этапа. Это может работать, но только если в договоре объяснено, можно ли использовать частично оплаченный код внутри компании во время проекта. Если ответ «нет», так и скажите.

8. Добавьте чек-лист перед отправкой договора на подпись

Перед отправкой договора пройдитесь по чек-листу. Используйте названия, пути и даты. Название проекта, расположение репозитория, пункт о собственности, исключённые материалы, обязательства по передаче и любую юридическую проверку для формулировок, зависящих от юрисдикции, — всё это должно быть на месте. Если чего-то не хватает, сначала исправьте это. Спешная подпись всё равно остаётся риском.

Вот практичный список перед отправкой:

• Название проекта совпадает с техническим заданием.
• Расположение репозитория указано по URL или точному пути.
• Пункт о собственности говорит, когда происходит переход прав.
• Исключённые материалы перечислены в приложении.
• Обязательства по передаче включают исходники, документацию и доступы.
• Правила по open-source и стороннему коду изложены письменно.
• Сроки приёмки и оплаты связаны между собой.
• Формулировки, зависящие от юрисдикции, проверены юристом.

Если договор нужен команде, которая также ценит публичную репутацию, полезно перед выдачей новых задач посмотреть отзывы о фрилансере. Договор может защитить права на код, но он не исправляет плохую дисциплину передачи результатов или постоянные срывы сроков. Две защиты лучше, чем одна.

И последнее практическое замечание: если проект связан с нишевым рабочим процессом на платформе, договор не должен противоречить собственным правилам сайта, последовательности оплат или пути согласования. Поэтому многие клиенты держат рядом с черновиком договора короткий внутренний чек-лист. Звучит просто. Просто — это хорошо.