Код ≠ доступ ≠ исключительное право

Разработчик не передаёт исходный код и доступы: что требовать заказчику

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

Актуализировано 06.09.2026

Сначала разделяем три разных вопроса

1

Кому принадлежат права

Определяется законом и условиями договора. Сам факт оплаты разработки не заменяет анализ правовой конструкции.

2

Что обязан передать подрядчик

Исходный код, исполняемый результат, документация, репозиторий и инфраструктура могут быть описаны по-разному.

3

Можно ли реально продолжить проект

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

Разбор типовой ситуации

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

Смоделированный пример · не является историей клиента ПравДок

B2B‑кабинет стоимостью 720 000 ₽

GitHubорганизация подрядчика
VPSего личный кабинет
DBрезервной копии у заказчика нет
APIключи оформлены на разработчика

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

Юрист проверяет

  • предмет и момент перехода прав;
  • обязанность передать результат и документацию;
  • акты и факт оплаты;
  • доказательства фактической эксплуатации заказчиком.

Технический специалист проверяет

  • что требуется для независимой сборки;
  • какие сервисы привязаны к подрядчику;
  • есть ли резервная копия БД;
  • какие секреты нельзя просто «скопировать» без ротации.
Цель: не получить один ZIP‑файл, а добиться управляемого состояния проекта: заказчик контролирует репозиторий, инфраструктуру и данные. После этого, если требуется, наша техническая команда может воспроизвести систему в новом контуре, стабилизировать её и продолжить разработку без старой команды.

Что проверять кроме исходного кода

АктивЧто должно быть понятноТипичный риск
Git‑репозиторийвладелец, история, ветки, теги, CIпередан ZIP без истории и актуальной версии
База данныхдамп, структура, миграции, резервированиекод есть, данных и схемы нет
Сервер/облаковладелец аккаунта, конфигурация, deploymentподрядчик может остановить production
Домен/DNSрегистратор, владелец, доступдомен оформлен на физлицо исполнителя
ИнтеграцииAPI‑аккаунты, webhook, токены, OAuthпосле смены исполнителя сервисы перестают работать
Документациякак собрать, развернуть и восстановитьновая команда тратит недели на reverse engineering

Реальная практика: исходный код и GitHub стали предметом отдельного спора

Дело А45‑26234/2022

Суды исследовали репозитории Android, iOS и серверной части, факт принадлежности исключительных прав и то, был ли исходный код фактически передан заказчику. Представленные скриншоты переписки не позволили подтвердить передачу конкретного исходного кода. Постановление Суда по интеллектуальным правам от 18.07.2023.

Практический вывод: при передаче проекта нужен не абстрактный акт «работы выполнены», а понятная опись цифровых активов и способ передачи, который можно доказать.

Как выглядит реестр передачи проекта

ПозицияСтатусПодтверждение
Git‑организация / основной repoпередан / нет / только readаккаунт владельца, приглашение, скрин, экспорт
Production serverпередан / переноситсякабинет провайдера, root/admin, backup
Databaseдамп получен / неизвестноконтрольная копия + дата
Домен и DNSу заказчика / у подрядчикаданные регистратора
API и токеныротация требуетсяперечень сервисов без публикации секретов
Инструкция сборкиработает / отсутствуетпроверка на чистом окружении

Частые вопросы об исходниках и доступах

Если сайт работает, обязан ли разработчик отдать GitHub?

Не всегда именно GitHub как сервис. Нужно смотреть, какой результат и способ передачи согласованы, кому принадлежат права и достаточно ли переданного комплекта для использования и дальнейшей разработки.

Достаточно ли получить ZIP с исходным кодом?

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

Что делать, если домен оформлен на подрядчика?

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

Можно ли новому разработчику пользоваться полученным кодом?

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

Заберём контроль юридически и проверим, как продолжить проект технически

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

Заявка за минуту

Опишите вопрос — юрист разберётся

Напишите, что произошло, когда узнали и какой результат нужен. Остальное уточнит специалист.

Индикатор описания: начните с пары слов
0

Не знаете юридических терминов — пишите обычными словами. Юрист уточнит детали при связи.

Это не обязательство. Так юрист понимает, реагировать сразу или планово.

Телефон нужен только для связи по заявке. Если начнёте с 8, номер приведётся к +7.

Заявка принята

Перенаправляем на страницу подтверждения.