Уволился разработчик и забрал код продукта — что делать, если без доступа к репозиторию остановились релизы, поддержка клиентов и вы рискуете потерять права на ключевой актив бизнеса? В таких историях время работает против компании: чем позже фиксируются факты и ограничиваются доступы, тем проще оппоненту сформировать удобную версию событий.
Опасность не только в том, что «код унесли». Возникают параллельные риски: утечка коммерческой тайны, блокировка инфраструктуры, спор о том, кому принадлежат исключительные права, а также зависимость от одного лица при передаче прав и исходников инвестору или покупателю бизнеса.
Кратко по сути: Уволился разработчик и забрал код продукта — что делать
- Срочно восстановите контроль доступа: смена паролей, ключей, токенов, прав в Git/CI/CD, облаках, админках, доменах.
- Зафиксируйте цифровые следы: логи, историю коммитов, права доступа, переписку, задачи, выдачу оборудования, акты передачи.
- Определите правовой режим кода: служебное произведение/ПО, договор отчуждения или лицензия, режим коммерческой тайны.
- Проведите инвентаризацию результата: где «истина» — в репозитории, на ноутбуке, на сервере, в бэкапах; обеспечьте резервное копирование.
- Запустите претензионный контур: требование о передаче исходников и прекращении использования, параллельно готовьте судебные обеспечительные меры.
Тактика и стратегия в ситуации: Уволился разработчик и забрал код продукта — что делать
Здесь важна не эмоция, а квалификация правоотношений: был ли разработчик сотрудником (служебный результат), подрядчиком или совладельцем. От этого зависит, что доказывать и какие требования заявлять. Параллельно выстраивается доказательственная база с учетом допустимости доказательств: скриншоты, выгрузки логов, копии репозиториев должны быть получены законно и воспроизводимо, иначе оппонент будет спорить их надежность.
Вторая ось — ваша позиция защиты бизнеса: показать непрерывность разработки внутри компании, оплату труда/работ, постановку задач и контроль результата, а также режим охраны коммерческой тайны (доступ по необходимости, NDA, маркировка, локальные акты). В спорных случаях заранее планируется судебная экспертиза по тождеству кода, авторству и объему заимствований. И наконец, важно соблюдать процессуальный порядок коммуникаций: не провоцировать «самоуправство» и не создавать признаков давления на бывшего сотрудника.
Нормативное регулирование и правовые институты
В РФ исходный код обычно защищается как программа для ЭВМ и как результат интеллектуальной деятельности. Ключевые институты: исключительные права и их принадлежность, служебные результаты (когда код создан в рамках трудовой функции), договоры отчуждения и лицензирования, а также режим конфиденциальности/коммерческой тайны. Отдельно работают правила о доказательствах и обеспечительных мерах в гражданском процессе: суд может запретить использование кода, обязать сохранить данные и обеспечить доступ к носителям, если вы докажете риск утраты или изменения информации.
Как это работает на практике
Сценарий 1: Репозиторий на личном аккаунте разработчика
Ситуация: разработка велась в личном Git-аккаунте, админ — у разработчика. Риск/ошибка: пытаться «взломать» доступ или договориться устно без фиксации. Верное решение: зафиксировать переписку и историю разработки, направить письменное требование о передаче админских прав и бэкапа, параллельно подготовить обеспечительные меры и собрать документы о служебном характере работ.
Сценарий 2: Код в инфраструктуре компании, но разработчик удалил ветки/бэкапы
Ситуация: после увольнения обнаружены удаления и «чистки». Риск/ошибка: перезапускать серверы и «чинить» без сохранения логов, теряя следы. Верное решение: немедленно заморозить изменения, сделать форензик-образ (в пределах законных полномочий владельца систем), выгрузить логи, зафиксировать регламенты доступа и назначить экспертизу по восстановлению.
Сценарий 3: Разработчик заявляет «код мой, я автор»
Ситуация: бывший сотрудник требует деньги за «передачу» или угрожает релизом конкурента. Риск/ошибка: подписывать задним числом документы, признающие его исключительные права, или платить без юридической конструкции. Верное решение: доказывать служебный характер и оплату, предъявлять требования о прекращении использования и передаче экземпляров, а спор об авторстве решать через документы и экспертизу, учитывая презумпцию принадлежности исключительного права работодателю при служебном результате при выполнении условий закона и договора.
Типичные ошибки в данной ситуации
- Отсутствие в трудовых/подрядных документах четкого описания результата: «разработка ПО» без передачи прав и исходников.
- Разработка в личных аккаунтах и на личных устройствах без регламента и контроля доступа.
- Нет локальных актов о коммерческой тайне, NDA и перечня конфиденциальной информации.
- Попытка «быстро договориться» без фиксации требований и сроков, что ухудшает доказательственную картину.
- Сбор доказательств «как получится»: скриншоты без источника, выгрузки без хэшей, утрата логов.
- Затягивание с обеспечительными мерами, когда код уже перемещен, переработан или опубликован.
Что важно учитывать для защиты прав
Суду нужно показать связку: кто ставил задачи, кто контролировал, за чей счет велась разработка, где хранился код, кто имел доступ, как оформлялась передача результатов. Строится логика доказательств: трудовой договор/должностная инструкция, ТЗ и таск-трекер, акты/отчеты, платежи, политика доступа, журнал выдачи техники, переписка, логи репозитория и CI/CD. Важно заранее решить, что вы доказываете: принадлежность исключительных прав, незаконное использование, нарушение режима конфиденциальности, обязанность передать исходники и доступы, а также необходимость срочных обеспечительных мер.
Практические рекомендации адвоката
- Остановите утечку: смените доступы, отзовите токены, отключите интеграции, зафиксируйте права пользователей.
- Сделайте контрольный бэкап всего, что есть у компании: репозитории, артефакты сборок, документацию, базы, конфиги.
- Соберите пакет документов: трудовые/подрядные договоры, локальные акты, NDA, задачи и отчеты, подтверждение оплаты.
- Зафиксируйте факты: логи, коммиты, удаление данных, переписку; при необходимости — нотариальный осмотр веб-страниц/переписки.
- Направьте претензию с конкретными требованиями: передать исходники/доступы, прекратить использование, подтвердить удаление копий, срок и способ передачи.
- Оцените судебную стратегию: иск о защите исключительных прав и/или о понуждении к передаче, обеспечительные меры, экспертиза по тождеству кода.
Вывод
Когда разработчик уволился и забрал код, выигрывает не тот, кто громче требует, а тот, кто быстрее возвращает контроль над инфраструктурой, фиксирует доказательства с учетом допустимости и правильно квалифицирует режим прав на ПО. Грамотная стратегия обычно позволяет либо вернуть исходники и доступы, либо юридически «обнулить» риск использования кода против компании.
Какая у вас ситуация ближе: репозиторий был корпоративный или личный, и есть ли у компании документы о передаче исключительных прав?
Информация актуальна по состоянию на июнь 2026.