Когда бизнес заказывает сайт, приложение, личный кабинет, CRM, SaaS-сервис, Telegram-бот или внутреннюю IT-систему, кажется, что главный вопрос — чтобы продукт работал.
На практике этого мало.
Сайт может открываться, приложение может запускаться, сервис может принимать заявки, но заказчик все равно не контролирует продукт. Код находится у разработчика. Репозиторий оформлен на студию. Дизайн лежит в Figma на аккаунте подрядчика. Домен куплен на личную почту фрилансера. Хостинг оплачен с карты разработчика. Платные шрифты, иконки и плагины оформлены не на заказчика. Документации нет. Права на интерфейс не переданы. А в договоре написано только: «оказание услуг по разработке сайта».
В такой ситуации заказчик платит за цифровой продукт, но юридически и технически остается зависимым от подрядчика.
Права на код, дизайн и интерфейс нужно оформлять до начала разработки, а не после конфликта. В договоре должно быть понятно, какие результаты создаются, кому принадлежат исключительные права, когда они переходят, что именно передается заказчику, можно ли дорабатывать продукт другой командой, какие сторонние компоненты используются и какие материалы остаются у разработчика.
ZLATA LEGAL помогает предпринимателям, IT-проектам и компаниям во Владивостоке, Приморском крае, на Дальнем Востоке и дистанционно по России оформлять права на код, дизайн, интерфейс, базы данных, документацию, домены, аккаунты и другие активы при разработке сайтов, приложений, SaaS-сервисов, маркетплейсов, CRM, личных кабинетов и внутренних IT-систем.
Короткий ответ
Заказчику должны перейти не только «готовый сайт» или «работающее приложение», а весь набор активов, необходимых для самостоятельного использования, поддержки, изменения и развития продукта.
Минимально нужно закрепить переход исключительных прав на специально созданный код, дизайн, интерфейс, макеты, тексты, графику, базу данных, структуру сервиса, документацию и другие результаты разработки. Также заказчик должен получить исходный код, доступ к репозиторию, Figma-макеты, сборки, инструкции, документацию, домен, хостинг, админку, сервер, базу данных, API-ключи, аккаунты внешних сервисов и информацию о сторонних компонентах.
Главная ошибка — думать, что оплата разработки автоматически решает все вопросы. Закон действительно дает заказчику сильную позицию по произведениям, созданным по заказу, но договор может изменить эту логику. Если в договоре написано, что код остается у разработчика, а заказчик получает только ограниченную лицензию, заказчик может оказаться без полноценного контроля над продуктом.
Поэтому в договоре нужно прямо написать: что именно создается, какие права переходят заказчику, в каком объеме, в какой момент, на какие материалы, с правом изменения, доработки, коммерческого использования, передачи другой команде и предоставления доступа пользователям.
Что такое права на код
Код — это не просто технические файлы.
Для бизнеса код является основой продукта. Это backend, frontend, мобильное приложение, база, скрипты, API, интеграции, админка, логика работы сервиса, автоматизация, конфигурации, миграции, тесты, сборки и техническая документация.
Юридически программа для ЭВМ охраняется авторским правом. При этом важны и исходный код, и объектный код, и иные формы выражения программы.
Для заказчика это означает: нужно получить не только возможность пользоваться готовым продуктом, но и права и материалы, которые позволяют продукт поддерживать, менять, развивать, переносить и передавать другой команде.
Если заказчик получил только доступ к админке, но не получил исходный код и права, он контролирует не продукт, а только витрину.
Что такое права на дизайн
Дизайн — это не просто «красиво нарисовали».
В IT-проекте дизайн может включать макеты страниц и экранов, UI-kit, компоненты интерфейса, иконки, иллюстрации, баннеры, графику, цветовые схемы, типографику, анимации, презентации, шаблоны писем, дизайн личного кабинета и дизайн мобильного приложения.
Если дизайн создается специально для заказчика, права на него нужно передавать так же внимательно, как права на код.
Иначе может возникнуть странная ситуация: сайт заказчика работает, но макеты остались у дизайнера, повторно использовать интерфейс нельзя, доработать экраны другой командой сложно, а часть иконок или шрифтов вообще куплена на аккаунт подрядчика и не лицензирована для заказчика.
В договоре нужно указать, что заказчику передаются права на дизайн-макеты, графические элементы, интерфейсные решения в форме их конкретного выражения, исходные файлы и материалы, необходимые для дальнейшей работы.
Что такое права на интерфейс
Интерфейс — это то, как пользователь взаимодействует с продуктом: экраны, кнопки, формы, меню, карточки, личный кабинет, статусы, сценарии, визуальные компоненты, структура страниц и пользовательский путь.
Важно понимать: сама идея «сделать личный кабинет с заявками» обычно не защищается как авторское право. Защищается конкретное выражение: код, дизайн, макеты, графика, тексты, структура экранов, конкретные элементы интерфейса, если они обладают признаками результата творческой работы.
Для заказчика практический вывод простой: в договоре нужно передавать права не абстрактно на «интерфейс», а на конкретные результаты — UI/UX-макеты, дизайн-систему, графику, компоненты, тексты, прототипы, исходные файлы и код интерфейса.
Также нужно закрепить право заказчика изменять интерфейс и поручать его доработку другим разработчикам или дизайнерам.
Исключительное право или лицензия
Есть большая разница между переходом исключительного права и лицензией.
Если заказчику передается исключительное право, он становится правообладателем результата в согласованном объеме. Он может использовать продукт сам, дорабатывать его, передавать права, предоставлять доступ клиентам, развивать SaaS, продавать цифровой продукт, привлекать инвестора и менять команду разработки.
Если заказчику дают только лицензию, он получает право пользоваться результатом в определенных пределах. Например, только на одном сайте, только для своих внутренних нужд, без права модификации, без права передачи третьим лицам или без права коммерческого использования.
Для заказчика разработки обычно безопаснее добиваться перехода исключительных прав на специально созданный результат. Лицензия может быть нормальной моделью для готовой платформы, движка, CMS, библиотеки или SaaS-инструмента разработчика, но не для уникального продукта, который заказчик оплатил как собственную разработку.
Что должно перейти заказчику
Заказчику должны перейти права и материалы на все, что специально создано для проекта.
Это может включать программный код, дизайн, интерфейс, макеты, прототипы, графику, тексты, базы данных, структуру данных, документацию, технические схемы, пользовательские сценарии, API-документацию, тесты, настройки, конфигурации, шаблоны уведомлений, дизайн-систему, инструкции администратора и иные результаты.
Отдельно нужно передать технический контроль: репозиторий, исходный код, домен, хостинг, сервер, базу данных, админку, аккаунты внешних сервисов, ключи API, платежные кабинеты, аналитику, Figma, магазины приложений, облачное хранилище и другие инструменты, без которых продукт нельзя нормально поддерживать.
Юридические права без технического контроля — слабая защита. Технический доступ без прав — тоже риск. Заказчику нужно и то, и другое.
Исходный код
Исходный код должен быть прямо указан в договоре как передаваемый результат.
Нужно описать, где он хранится, когда передается, в каком состоянии, с какой документацией и кто имеет к нему доступ.
Для заказчика безопаснее, чтобы код велся в репозитории, который контролирует сам заказчик. Например, GitHub, GitLab или Bitbucket создается на аккаунте компании заказчика, а разработчику выдается доступ. Тогда заказчик видит историю изменений и не зависит от того, захочет ли подрядчик передать архив в конце проекта.
Если код хранится только у разработчика до финальной оплаты, заказчик рискует. При конфликте он может остаться без актуальной версии продукта.
Репозиторий
Репозиторий — это не просто удобство для программистов. Это доказательство и инструмент контроля.
В нем видна история разработки, структура проекта, ветки, коммиты, версии, авторы изменений, релизы и иногда технические настройки сборки.
В договоре стоит указать, что исходный код размещается в согласованном репозитории, заказчик имеет административный доступ, разработчик регулярно обновляет код, а передача результата включает актуальную версию кода, историю изменений, инструкции по сборке и запуску.
Если репозиторий оформлен на подрядчика, заказчик должен получить его передачу или полную копию с историей и всеми необходимыми материалами. Просто архив ZIP без истории и документации — хуже, чем полноценный репозиторий.
Дизайн-макеты и Figma
Если дизайн создавался в Figma, Sketch, Adobe XD или другой системе, заказчик должен получить не только картинки или экспорт в PNG.
Нужно передать исходные макеты, дизайн-систему, компоненты, стили, шрифты, иконки, прототипы, версии экранов и права на их дальнейшее использование.
Лучше, чтобы проект в Figma находился в рабочем пространстве заказчика или был передан заказчику после оплаты соответствующего этапа. Если макеты остаются в аккаунте дизайнера, заказчик зависит от него при каждой доработке.
В договоре нужно указать, что дизайн-макеты и исходные файлы являются частью результата и передаются вместе с правами.
UI-kit и дизайн-система
Для сложного продукта важно получить не только отдельные экраны, но и UI-kit или дизайн-систему.
Это набор кнопок, форм, карточек, цветов, шрифтов, сеток, компонентов, состояний, правил и визуальных элементов, из которых собирается интерфейс.
Если заказчик получает только финальные экраны, но не получает компоненты, дальнейшая разработка становится дороже и хаотичнее. Новая команда будет заново собирать систему.
Для SaaS, приложения, маркетплейса, CRM или личного кабинета дизайн-система может быть самостоятельным активом. Ее нужно прямо включать в состав передаваемых результатов.
Тексты, иллюстрации и графика
В IT-проекте могут создаваться тексты, описания, подсказки, письма, лендинги, инструкции, изображения, баннеры, иконки, презентации, схемы и иллюстрации.
Они тоже должны быть включены в передачу прав.
Если тексты писал копирайтер, иллюстрации делал дизайнер, а иконки покупались на стоке, разработчик должен подтвердить, что имеет право передать результат заказчику или что заказчик получает нужную лицензию.
Особенно важно проверять материалы, которые видны публично: лендинг, приложение, интерфейс, рекламные баннеры, презентации и база знаний. Именно по ним чаще возникают претензии о копировании.
База данных
Если в проекте создается база данных, ее тоже нужно учитывать.
База может включать структуру таблиц, справочники, записи пользователей, каталог товаров, контент, заявки, маршруты, документы, шаблоны, карточки исполнителей, объявления, отчеты, статистику и другие данные.
Нужно разделять права на структуру базы, права на программную часть, права на контент и права на данные, которые загружают пользователи или клиенты.
Для заказчика важно получить контроль над базой: доступ, резервные копии, формат выгрузки, структуру, документацию, права на использование и порядок передачи при смене подрядчика.
Если база остается на сервере разработчика или в его аккаунте, заказчик зависит от него не меньше, чем при отсутствии исходного кода.
Документация
Документация часто не воспринимается как отдельный результат, но без нее продукт сложно поддерживать.
Заказчику нужна хотя бы базовая документация: как развернуть проект, какие зависимости используются, как устроена база, какие переменные окружения нужны, какие интеграции подключены, как делать резервные копии, как работать с админкой, где находятся API-ключи, как собирать приложение, как обновлять продукт и как восстанавливать доступ.
Для сложного проекта нужны API-документация, описание ролей, пользовательские сценарии, схема архитектуры, описание интеграций, инструкции администратора и технические регламенты.
В договоре нужно указать, что документация является частью результата. Иначе разработчик может передать код, но не объяснить, как с ним работать.
Домен, хостинг и аккаунты
Домен, хостинг, облако, сервер, почта, аналитика, платежный агрегатор, магазины приложений, SMS-сервис, сервис рассылки, Figma, репозиторий и CRM должны быть оформлены так, чтобы заказчик имел контроль.
Если домен зарегистрирован на разработчика, это не актив заказчика. Если сервер оформлен на студию, заказчик зависит от студии. Если приложение опубликовано из аккаунта подрядчика, заказчик не контролирует собственный продукт.
В договоре нужно указать, какие аккаунты создаются на стороне заказчика, какие временно администрирует разработчик, какие доступы передаются, какие платные подписки оплачивает заказчик и что происходит после завершения проекта.
Для ключевых активов простое правило: аккаунт должен принадлежать заказчику, а разработчик получает доступ как исполнитель.
Права на доработку
Заказчику нужно право дорабатывать продукт.
Это значит, что он может сам изменять код, привлекать другую команду, передавать продукт на поддержку, создавать новые версии, менять дизайн, развивать функционал, подключать интеграции и использовать результат в своем бизнесе.
Если договор запрещает модификацию или допускает доработку только текущим разработчиком, заказчик оказывается в зависимости.
В договоре нужно прямо указать, что передаваемые права включают право переработки, модификации, адаптации, развития, интеграции с другими системами и передачи материалов третьим лицам для поддержки и доработки продукта.
Право коммерческого использования
Если заказчик планирует зарабатывать на продукте, это нужно закрепить отдельно.
Например, продавать подписку на SaaS, предоставлять доступ клиентам, использовать приложение для платных услуг, размещать рекламу, продавать цифровой продукт, подключать B2B-клиентов, давать доступ партнерам, передавать продукт в группу компаний или использовать его в инвестиционном проекте.
Если договор говорит только «заказчик вправе использовать результат для внутренних нужд», это может быть недостаточно для коммерческого продукта.
Для SaaS, маркетплейса, приложения и онлайн-сервиса нужно прямо указать право предоставлять доступ пользователям и клиентам, использовать продукт в предпринимательской деятельности и извлекать доход.
Право передачи третьим лицам
Заказчику может понадобиться передать продукт или права на него.
Например, инвестору, покупателю бизнеса, дочерней компании, партнеру, новой команде разработки, оператору сервиса или другой компании группы.
Если договор ограничивает передачу, это может снизить стоимость продукта и затруднить сделку.
Поэтому для серьезного IT-проекта лучше закреплять право заказчика передавать исключительные права, предоставлять лицензии, передавать материалы подрядчикам для поддержки и использовать продукт внутри группы компаний, если такая модель нужна бизнесу.
Личные неимущественные права автора
Даже если исключительные права переходят заказчику, у автора остаются личные неимущественные права: например, право авторства.
Это нормальная логика авторского права. Разработчик или дизайнер как авторы не перестают быть авторами результата. Но заказчик получает имущественный контроль, если исключительные права переданы правильно.
В договоре можно отдельно указать, как используется имя автора, можно ли разработчику показывать проект в портфолио, нужно ли согласие заказчика на публикацию кейса, скриншотов, кода или описания продукта.
Для конфиденциальных B2B-проектов лучше ограничить публичное использование кейса без согласия заказчика.
Портфолио разработчика
Разработчики часто хотят показывать проект в портфолио.
Для заказчика это может быть нормально, если сайт публичный и проект не чувствительный. Но если разработка связана с внутренней CRM, финтехом, ВЭД, платежами, логистикой, клиентской базой, личным кабинетом, бизнес-процессами или еще не запущенным продуктом, публикация кейса может быть нежелательной.
В договоре нужно указать, может ли разработчик использовать название заказчика, логотип, скриншоты, описание проекта, ссылку, код, дизайн или результаты в портфолио. Без согласия заказчика лучше не публиковать закрытые материалы.
Сторонние компоненты
Не все, что есть в продукте, создано разработчиком.
В проекте могут быть open source библиотеки, фреймворки, CMS, шаблоны, плагины, шрифты, иконки, стоковые изображения, карты, платежные SDK, аналитика, внешние API и готовые модули.
Это нормально, но заказчик должен знать, что именно используется и на каких условиях.
В договоре нужно указать, что разработчик гарантирует законность использования сторонних компонентов и то, что они не мешают заказчику использовать продукт по назначению. Для важных компонентов стоит получить перечень лицензий.
Особенно опасны компоненты, которые запрещают коммерческое использование, требуют раскрытия кода, ограничивают модификацию или привязаны к аккаунту разработчика.
Open source
Open source — это не «ничей код».
У open source есть лицензии. Одни лицензии достаточно мягкие, другие могут накладывать серьезные обязанности. Например, раскрытие исходного кода производного продукта, указание авторства, сохранение уведомлений, ограничения использования или совместимости лицензий.
Заказчику не нужно становиться экспертом по каждой библиотеке, но в договоре с разработчиком нужно закрепить обязанность использовать open source так, чтобы это не нарушало права третьих лиц и не ограничивало коммерческое использование продукта.
Для SaaS, мобильного приложения, финтеха, B2B-платформы или продукта под инвестора open source-проверка особенно важна.
Шрифты, иконки и изображения
Шрифты, иконки, фото и иллюстрации часто становятся неожиданным риском.
Дизайнер может использовать платный шрифт со своей лицензией, скачать иконки из набора, взять фото со стока, использовать изображение из интернета или шаблон без права коммерческого применения.
Заказчик потом получает претензию, хотя считал, что все материалы включены в разработку.
В договоре нужно указать, что разработчик использует материалы законно, передает заказчику права или необходимые лицензии, а также предоставляет сведения о платных или сторонних материалах. Если заказчик должен купить лицензию отдельно, это нужно сказать заранее.
Материалы заказчика
Иногда часть материалов предоставляет сам заказчик: логотип, тексты, фото, база товаров, документы, брендбук, коммерческие предложения, таблицы, клиентские данные.
В договоре нужно разделить: разработчик отвечает за материалы, которые создает или привлекает сам, а заказчик отвечает за материалы, которые передал разработчику.
Если заказчик дал логотип без прав или чужие фотографии, разработчик не должен отвечать за это как за свой результат. Но если разработчик сам взял чужие фото или иконки, ответственность должна быть на нем.
Сотрудники и субподрядчики разработчика
Если продукт делает команда, права должны быть очищены по всей цепочке.
Студия заключила договор с заказчиком. Но фактически код писал один фрилансер, дизайн делал другой, тексты — третий, а backend — субподрядчик. Если студия не получила у них права, она не сможет нормально передать их заказчику.
В договоре нужно указать, что разработчик отвечает за своих сотрудников и субподрядчиков, гарантирует наличие прав на все созданные результаты и обязан передать заказчику права без претензий третьих лиц.
Заказчику не обязательно видеть каждый внутренний договор студии, но гарантия и ответственность должны быть в договоре.
Момент перехода прав
В договоре нужно указать, когда права переходят заказчику.
Варианты могут быть разные: после полной оплаты проекта, после оплаты каждого этапа, после подписания акта, после передачи исходного кода или с момента создания результата.
Для заказчика часто удобнее, чтобы права на этап переходили после оплаты этого этапа. Тогда если проект остановится, заказчик сохраняет права на уже оплаченные результаты.
Если права переходят только после полной оплаты всего проекта, а проект сорвался на финальном этапе, заказчик может оказаться в сложной ситуации: часть работ оплачена, но права формально не перешли.
Поэтому момент перехода прав нужно связывать с этапами и оплатой, а не оставлять туманным.
Акт передачи прав
Передачу прав лучше фиксировать в договоре и актах.
Акт может подтверждать, что разработчик передал конкретный результат: код, дизайн, макеты, документацию, доступы, сборки, базы, инструкции и права на них. В акте можно указать ссылку на репозиторий, перечень файлов, версию продукта, этап, дату, состав материалов и отсутствие претензий по передаче.
Если акт говорит только «услуги оказаны», но не говорит, что именно передано, это слабее.
Для IT-проекта акт должен быть не бухгалтерской формальностью, а доказательством передачи результата и прав.
Приемка и права
Приемка результата и переход прав лучше связать, но не смешивать полностью.
Заказчик принимает результат по качеству и функционалу. Права переходят по условиям договора. Если результат не принят из-за недостатков, это один вопрос. Если результат принят и оплачен, права должны перейти в согласованном объеме.
Важно избегать ситуации, когда заказчик оплатил этап, но разработчик удерживает код и права до финала всего проекта. Это может быть допустимо как коммерческая модель, но для заказчика рискованно.
Безопаснее принимать и оплачивать этапы так, чтобы каждый оплаченный результат можно было использовать дальше.
Что не переходит заказчику
Не всё автоматически должно переходить заказчику.
У разработчика могут быть собственные библиотеки, шаблоны, фреймворки, внутренние инструменты, заготовки, административные панели, модули, которые он использовал до проекта и использует в других проектах.
Если разработчик использует свой pre-existing code, нужно описать модель: заказчик получает право использовать его в составе продукта, но исключительные права на сам универсальный модуль могут оставаться у разработчика.
Это нормально, если не мешает заказчику использовать, поддерживать и развивать продукт. Но если ключевая часть продукта остается закрытой и контролируется разработчиком, заказчик должен понимать этот риск до оплаты.
Конструкторы и low-code
Если продукт сделан на Tilda, Webflow, WordPress, Битрикс, Bubble, Make, Airtable, Notion, Retool, no-code или low-code платформе, права устроены иначе.
Заказчик может получить не исходный код в классическом смысле, а настройки, шаблоны, аккаунт, дизайн, контент, базу, интеграции и право использовать результат в рамках правил платформы.
Это нужно честно указать в договоре. Нельзя обещать заказчику «исходный код», если продукт фактически собран на чужой платформе и код не выгружается.
В такой модели особенно важно, чтобы аккаунт платформы принадлежал заказчику, а подрядчик передал настройки, доступы, документацию и объяснил ограничения платформы.
SaaS на базе чужой платформы
Иногда заказчик думает, что ему разрабатывают собственный SaaS, а фактически подрядчик настраивает свой сервис или white label-платформу.
Это может быть нормальной моделью, если заказчик понимает условия. Но в договоре нужно четко написать: заказчик получает собственный продукт или право пользоваться платформой подрядчика.
Если это платформа подрядчика, заказчик может не получить исключительные права на код. Он получает лицензию, настройку, дизайн, доступ, интеграции и данные. Тогда особенно важны условия экспорта данных, прекращения договора, переноса, брендинга, конфиденциальности и стоимости дальнейшей поддержки.
Главное — не путать индивидуальную разработку и использование готовой платформы.
Интерфейс и идеи продукта
Идея продукта сама по себе обычно не передается как объект авторского права.
Например, идея «сервис для учета заявок перевозчиков», «маркетплейс ремонтных услуг», «личный кабинет клиента», «CRM для ВЭД» или «бот для заявок» не является тем же самым, что код, дизайн и конкретная реализация.
Заказчику нужно защищать не абстрактную идею, а конкретные результаты: техническое задание, прототипы, дизайн, код, тексты, базу данных, документацию, бизнес-логику в форме документов, конфиденциальность и запрет использования материалов заказчика.
Если идея чувствительная, ее нужно защищать через NDA, конфиденциальность, режим коммерческой тайны и аккуратный доступ к материалам.
Запрет конкурентного использования
Если разработчик глубоко погружается в продукт заказчика, он может узнать бизнес-логику, базу, процессы, клиентов, тарифы, архитектуру и коммерческие планы.
Заказчик может захотеть запретить разработчику использовать эти материалы для конкурирующего проекта. Такой запрет нужно формулировать аккуратно.
Нельзя просто запретить разработчику «работать в IT» или «делать похожие сайты». Но можно запретить использовать конфиденциальную информацию, материалы заказчика, код, дизайн, базу, документацию и результаты проекта для третьих лиц или собственных конкурентных продуктов.
Для чувствительных B2B-сервисов это важный блок.
Передача проекта другой команде
Цель заказчика — не просто получить продукт, а иметь возможность сменить разработчика.
Для этого нужны права, код, документация, доступы, база, инструкции и информация о сторонних компонентах.
В договоре стоит прямо указать, что заказчик вправе передавать материалы и доступы третьим лицам для сопровождения, аудита, доработки, тестирования, безопасности и развития продукта.
Если такого права нет или оно ограничено, разработчик может спорить, что заказчик не вправе давать код другой команде.
Инвестор и due diligence
Если IT-продукт когда-нибудь будет показываться инвестору, покупателю бизнеса, банку или крупному партнеру, права на код и дизайн станут одним из первых вопросов.
Инвестор спросит: кому принадлежит код, есть ли договоры с разработчиками, переданы ли права, есть ли open source-риск, кто владеет доменом, где репозиторий, есть ли права на дизайн, кто автор, нет ли фрилансеров без договоров, можно ли коммерчески использовать продукт.
Если на эти вопросы нет документов, стоимость проекта снижается. Даже хороший продукт может выглядеть юридически грязным.
Поэтому права нужно оформлять не только «на случай суда», но и для будущей продажи, инвестиций, партнерства или масштабирования.
Что проверить в договоре
В договоре нужно проверить разделы о предмете, результате, интеллектуальных правах, исходном коде, дизайне, документации, сторонних компонентах, субподрядчиках, приемке, оплате, доступах, конфиденциальности, персональных данных и расторжении.
Особое внимание — формулировкам вроде «разработчик сохраняет права», «заказчик получает неисключительную лицензию», «использование только в рамках одного сайта», «модификация запрещена», «передача третьим лицам запрещена», «исходный код не передается», «доработка только силами исполнителя», «материалы могут использоваться в портфолио без согласия».
Иногда такие условия допустимы, если заказчик покупает настройку готовой платформы. Но если заказчик оплачивает собственную разработку, такие формулировки могут быть опасны.
Что должно быть в акте
Акт должен подтверждать не только факт оказания услуг, но и передачу конкретного результата.
В акте желательно указать: этап, наименование результата, ссылку на репозиторий, версию продукта, перечень переданных файлов, ссылку на Figma, переданные доступы, документацию, состав исходного кода, сборки, данные о сторонних компонентах и переход прав в соответствии с договором.
Если передаются права на дизайн, это тоже можно указать. Если передаются исходные файлы, макеты, иллюстрации, UI-kit, тексты, база данных или документация, их нужно перечислить или приложить реестр.
Чем конкретнее акт, тем проще доказать, что заказчик получил именно актив, а не просто «услугу».
Частые ошибки заказчика
Первая ошибка — оплатить разработку без раздела о правах. Вторая — не получить исходный код. Третья — оставить репозиторий на аккаунте разработчика. Четвертая — не получить Figma-макеты и исходники дизайна. Пятая — не проверить open source и сторонние компоненты. Шестая — не оформить права от субподрядчиков. Седьмая — не передать домен и хостинг на заказчика. Восьмая — не получить документацию. Девятая — подписать акт без перечня результата. Десятая — думать, что «если я оплатил, значит всё мое», хотя договор может говорить обратное.
Главный риск — остаться с работающей оболочкой, но без юридического и технического контроля над продуктом.
Как правильно оформить переход прав
Сначала нужно определить, что создается: сайт, приложение, SaaS, CRM, бот, интеграция, дизайн, интерфейс, база данных или внутренний сервис.
Затем нужно составить перечень результатов: код, дизайн, макеты, UI-kit, тексты, графика, база, документация, настройки, интеграции, доступы, репозиторий и аккаунты.
После этого в договоре закрепляется, какие исключительные права переходят заказчику, в какой момент, в каком объеме, с какими способами использования, на какой территории и с правом доработки, модификации, коммерческого использования и передачи третьим лицам.
Отдельно описываются сторонние компоненты, open source, шрифты, изображения, плагины, готовые модули, аккаунты, конфиденциальность и персональные данные.
На этапе приемки нужно подписывать не пустой акт, а акт с конкретным перечнем переданных результатов и ссылками на материалы.
Локальный аспект: Владивосток, Приморье и Дальний Восток
Во Владивостоке и Приморском крае бизнес часто заказывает прикладные IT-решения под реальные процессы: логистика, ВЭД, поставки из Китая, склады, заявки, морская отрасль, торговля, ремонт, сервисные работы, CRM, Telegram-боты, личные кабинеты, B2B-платформы и внутренние панели контроля.
Такие продукты могут начинаться как «простая разработка для себя», но быстро становятся частью бизнеса. Через них идут заявки, клиенты, документы, платежи, маршруты, статусы, отчеты и коммуникация с партнерами.
Если права на код, дизайн, интерфейс, базу и доступы не оформлены, компания зависит от конкретного разработчика. Для операционного бизнеса это риск: конфликт с подрядчиком может остановить не просто сайт, а часть продаж или внутреннего процесса.
Поэтому для региональных проектов важно сразу оформлять разработку как актив компании, а не как набор файлов у подрядчика.
Как ZLATA LEGAL помогает с правами на код, дизайн и интерфейс
ZLATA LEGAL помогает заказчикам IT-разработки оформить права на код, дизайн, интерфейс, базы данных, документацию и другие результаты цифрового продукта.
Мы готовим и проверяем договоры с разработчиками, веб-студиями, дизайнерами, фрилансерами, IT-командами и подрядчиками. Прописываем переход исключительных прав, передачу исходного кода, репозитория, Figma-макетов, UI-kit, документации, доступов, домена, хостинга, аккаунтов, open source-компонентов и сторонних материалов.
Анализируем, что должно перейти заказчику, какие материалы остаются у разработчика, как оформить готовые модули и сторонние библиотеки, как защитить заказчика при субподрядчиках, как принимать результат и как сохранить возможность сменить команду разработки.
Работаем с проектами во Владивостоке, Приморском крае, на Дальнем Востоке и дистанционно по России: сайты, приложения, SaaS-сервисы, CRM, маркетплейсы, платформы, личные кабинеты, Telegram-боты, интеграции и внутренние IT-системы.
Права на код, дизайн и интерфейс — это не юридическая формальность. Это вопрос контроля над цифровым активом. Если права, код и доступы оформлены правильно, заказчик может развивать продукт, менять команду, привлекать инвестиции и использовать сервис без зависимости от одного подрядчика.
Частые вопросы
Достаточно ли оплатить разработку, чтобы получить права на код?
Не всегда. По закону у заказчика есть сильная позиция по произведениям, созданным по заказу, но договор может предусмотреть иное. Поэтому переход прав нужно прямо прописывать в договоре.
Что лучше для заказчика: исключительное право или лицензия?
Для собственной разработки обычно лучше исключительное право. Лицензия подходит, если заказчик использует готовую платформу, модуль или сервис разработчика, но не получает продукт в собственность.
Нужно ли передавать исходный код заказчику?
Да, если заказчик хочет контролировать продукт, поддерживать его, менять разработчика и развивать сервис. Без исходного кода заказчик зависит от текущего подрядчика.
На чьем аккаунте должен быть репозиторий?
Лучше на аккаунте заказчика или компании заказчика. Разработчик получает доступ как исполнитель. Это снижает риск потери кода при конфликте.
Нужно ли передавать Figma-макеты?
Да. Заказчику нужны не только картинки или готовая верстка, но и исходные макеты, компоненты, UI-kit, стили и права на дальнейшее использование дизайна.
Права на интерфейс переходят автоматически?
Не стоит на это рассчитывать. Нужно прямо передавать права на конкретные результаты: дизайн-макеты, графику, UI-компоненты, тексты, код интерфейса, прототипы и документацию.
Можно ли разработчику оставить свои готовые модули?
Можно, если это прямо описано и не мешает заказчику использовать продукт. Заказчик должен получить право использовать такие модули в составе продукта.
Что делать с open source?
Нужно проверить, какие open source-компоненты используются и не ограничивают ли они коммерческое использование продукта. Разработчик должен гарантировать законность их использования.
Кто отвечает за иконки, шрифты и изображения?
Если их подбирает разработчик или дизайнер, он должен обеспечить законность использования и передачу нужных прав или лицензий заказчику. Если материалы дает заказчик, ответственность за них обычно на заказчике.
Можно ли другой команде дорабатывать продукт?
Да, если договор дает заказчику право модификации, переработки, передачи материалов подрядчикам и дальнейшего развития продукта. Это нужно прямо прописать.
Что должно быть в акте приемки?
Акт должен перечислять результат: код, репозиторий, версию, дизайн-макеты, документацию, доступы, сборки, базу, инструкции и переход прав в соответствии с договором.
На кого оформлять домен и хостинг?
На заказчика или его компанию. Если домен и хостинг оформлены на разработчика, заказчик не контролирует ключевые активы проекта.
Может ли разработчик показывать проект в портфолио?
Только если это разрешено договором или согласовано с заказчиком. Для закрытых B2B-проектов, внутренних систем и чувствительных сервисов лучше требовать отдельное согласие.
Что делать, если разработчик не передает код?
Нужно смотреть договор, акты, оплату, переписку и условия о правах. Поэтому лучше заранее закреплять обязанность вести код в репозитории заказчика и передавать результат по этапам.
Когда обращаться к юристу?
Лучше до начала разработки и оплаты аванса. На этой стадии можно закрепить права, код, дизайн, доступы и документацию, а не пытаться вернуть контроль над продуктом после конфликта.
Связанные материалы