08
Май
2026

Команда ушла в стартап. Кому принадлежит код?

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

Разберёмся, как работает закон, почему «я сам написал этот код» — недостаточный аргумент, и что нужно прописать в договоре заранее.

$500 млн за утечку кода: кейс ZeniMax vs Oculus

В 2014 году Джон Кармак — легендарный разработчик Doom и Quake — перешёл из ZeniMax Media в Oculus VR. Вместе с ним, по мнению ZeniMax, утекли технологии виртуальной реальности, которые компания разрабатывала годами.

ZeniMax подала в суд, обвинив Oculus в нарушении авторских прав и краже конфиденциальной информации. В 2017 году суд встал на сторону истца и присудил компенсацию в 500 миллионов долларов.

Показательно, что речь шла не о буквальном копировании строк кода. ZeniMax доказывала, что Кармак передал в Oculus знания, методы и подходы, которые были коммерческой тайной работодателя.

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

Что говорит российское право

В основе — режим служебного произведения (ст. 1295 ГК РФ).

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

Три ключевых условия, при которых код считается служебным:

  1. Сотрудник находился в трудовых отношениях с компанией в момент создания.

  2. Программа создавалась в рамках его должностных обязанностей или по прямому заданию работодателя.

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

Если хотя бы одно условие не выполнено — ситуация становится спорной.

Когда код всё-таки останется у разработчика

Суд по интеллектуальным правам в деле № А40-256611/2017 сформулировал позицию, которую важно знать обеим сторонам: при квалификации произведения как служебного нельзя ограничиваться только формальными признаками — наличием трудового договора и перечнем обязанностей. Суд предложил учитывать целый ряд обстоятельств:

  • соотношение деятельности работодателя со сферой, в которой создан объект;

  • пределы трудовых обязанностей работника;

  • место выполнения работ;

  • источник оборудования и средств;

  • возможность работодателя контролировать работу;

  • цель создания произведения;

  • последующее поведение обеих сторон.

Это решение важно: суды смотрят на реальную картину, а не только на то, что написано в трудовом договоре.

Один из ключевых аргументов разработчика — отсутствие обязанности по разработке ПО в трудовом договоре. В деле Замоскворецкого районного суда от 01.12.2017 (№ 02-3793/2017) суд прямо указал: «ни ведение баз данных, ни установка программного обеспечения, ни программная поддержка сайтов не включают разработку программ для ЭВМ». Работодатель настаивал, что вправе давать работнику «любые задачи», — суд этот довод отклонил.

Ещё один важный нюанс — время создания кода. Судебная практика здесь неоднозначна:

  • создание в нерабочее время само по себе не делает программу неслужебной, если это входило в трудовые обязанности (Апелляционное определение Пензенского областного суда от 16.06.2015 по делу № 33-1578/2015);

  • но и создание в рабочее время не является автоматическим доказательством служебного характера произведения (Определение суда Чукотского АО от 12.11.2018 по делу № 33-140/2018).

Вывод: необходимо оценивать совокупность обстоятельств по делу.

Реальные дела из российской практики

Дело № 2-1110/2019: бывший сотрудник vs работодатель

Бывший работник подал иск о признании авторства на программы для ЭВМ, утверждая, что разрабатывал ПО по собственной инициативе без служебных заданий, значит, код его.

Суд встал на сторону работодателя. Ключевую роль сыграли свидетельские показания коллег: в компании сложилась практика выдавать устные поручения, все программы создавались силами коллектива с использованием корпоративных инструментов разработки. Апелляционное определение Санкт-Петербургского городского суда от 17.10.2019 № 33-24177/2019 оставило решение в силе.

При этом суд отдельно отметил: свидетельство о регистрации программы в Роспатенте, которое представил работник, не является неоспоримым доказательством его авторства.

Дело № 3-0292/2017 (Мосгорсуд): разработчик вернулся и запустил стартап

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

Иностранная компания обратилась в суды (и российский, и иностранный) с требованием защиты прав, ссылаясь на плагиат и недобросовестную конкуренцию.

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

Этот кейс важен: схожий функционал — это необязательно плагиат. Если код написан заново и самостоятельно — нарушения нет.

Дело А40-20743/2021: конкуренты и open source

Два IT-конкурента на специфичном рынке. Решения компаний схожи по функционалу и частично по дизайну. Были переходы сотрудников между компаниями. Истец был уверен в недобросовестном поведении. Назначили судебную экспертизу.

Итог: сходство функционала и дизайна объяснилось тем, что обе компании используют одно и то же open source ПО. Переход сотрудников суд счёл «нормальным явлением в IT-сфере».

Вывод для практики: если в основе вашего продукта лежат open source компоненты, готовьтесь к тому, что конкурент может использовать те же библиотеки — и это не будет нарушением.

Где размытая граница

Закон не даёт чёткого ответа на многие частные вопросы. Три типичных сценария.

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

Разработчик использовал корпоративный опыт, но создал принципиально новый продукт. Суды оценивают, насколько новый продукт пересекается с функционалом работодателя. Чем очевиднее сходство — тем выше риск. Но уникальный код, как в деле № 3-0292/2017, — весомый контраргумент.

Команда ушла и взяла с собой только «знания в голове». Алгоритм, архитектурный подход, методология — авторским правом как таковым не охраняются. Но если это коммерческая тайна компании и сотрудник подписал NDA — ситуация меняется кардинально.

Что нужно прописать в договорах — минимальный чек-лист

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

Для работодателя / основателя

В трудовом договоре:

  • Явно перечислить обязанности сотрудника в части разработки ПО — чем конкретнее, тем лучше.

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

  • Прописать ненормированный рабочий день (если применимо) — это снимает аргумент о создании кода «в нерабочее время».

  • Включить условие о выплате авторского вознаграждения за служебные произведения.

В NDA / соглашении о конфиденциальности:

  • Перечислить, что относится к коммерческой тайне: архитектурные решения, алгоритмы, технические задания, методологии.

  • Установить срок действия обязательства после увольнения (обычно 2–3 года).

  • Прописать запрет на использование конфиденциальной информации при разработке конкурирующих продуктов.

Дополнительно:

  • Оформлять служебные задания письменно — с указанием цели, перечня авторов, сроков и ответственного лица.

  • Запросить у нового сотрудника письменную информацию об интеллектуальной собственности, которая принадлежала ему до трудоустройства.

При увольнении:

  • Зафиксировать в акте приёма-передачи, что сотрудник передал все рабочие материалы: репозитории, документацию, доступы.

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

Для разработчика

До начала работы:

  • Убедиться, что договор чётко разграничивает служебные и личные проекты.

  • Зафиксировать в договоре собственные разработки как исключения из режима служебного произведения.

  • Если к моменту выхода на новую работу есть готовые ПО — зарегистрировать их в Роспатенте или задепонировать у нотариуса, чтобы зафиксировать дату создания.

Однако тут есть проблема: первые два пункта бывает сложно реализовать. Большинство работодателей используют типовые договоры и не готовы их менять. Поэтому можно действовать иначе.

Если договор не меняется — фиксируйте контекст самостоятельно. Напишите работодателю письмо на корпоративную почту в первые дни работы: перечислите свои личные проекты, которые существовали до трудоустройства, и укажите, что они создавались независимо от нынешней работы. Ответа не обязательно ждать — важен сам факт отправки с датой. Это не юридически обязывающий документ, но в суде такое письмо работает как косвенное доказательство.

Следите за тем, что написано в трудовом договоре про ваши обязанности. Если в договоре вы значитесь тестировщиком, аналитиком или devops-инженером — а не разработчиком — то созданный вами код формально не попадает под режим служебного произведения.

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

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

При уходе:

  • Не уносите корпоративный код — даже тот, который писали лично.

  • Сохраните переписку (если таковая есть), подтверждающую, что личные проекты создавались независимо.

Что доказывает нарушение в суде

Если дело дошло до суда, доказательная база строится вокруг нескольких вещей.

Прямые доказательства — сравнение исходных кодов. Вывод об использовании одной программы в другой, как правило, делается по результатам сопоставления исходных текстов. Если экспертиза установит высокий процент заимствования — например, 88% кода, как в деле № А56-21040/15 (Определение ВС РФ от 15.03.2017 № 307-ЭС17-959) — это сильный аргумент для суда.

Косвенные доказательства работают, когда ответчик отказывается предоставить свой код:

  • уникальные баги, воспроизводящиеся в обоих продуктах;

  • идентичная архитектура базы данных;

  • схожие нетипичные для отрасли паттерны взаимодействия с пользователем;

  • переписка сотрудников, обсуждающих использование чужих решений;

  • данные из систем управления задачами — Jira, Linear и подобных (Постановление 9-го ААС от 24.03.2022 № 09АП-9538/2022-ГК по делу № А40-175681/2021).

В деле ZeniMax именно совокупность косвенных доказательств — переписка, документы, показания свидетелей — помогла доказать передачу конфиденциальной информации даже без прямого сравнения кода.

Коротко о главном

Уход команды — это не автоматически кража кода. Но риски реальны, и они возникают там, где нет нормальных договоров.

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

Если вы разработчик: разграничьте личные и рабочие проекты до начала отношений, документируйте независимость своих разработок, не уносите корпоративный код.

И в обоих случаях — не ждите конфликта, чтобы разобраться в этих вопросах.

Если у вас уже есть похожая ситуация или хотите проверить свои договоры — пишите в комментариях или в личку tg @aveazazello.

Автор: aveazazello

Источник

Опубликовано в авторское право, интеллектуальная собственность, программы для ЭВМ, Разработка, служебное произведение, стартапы, судебная практика, трудовое право, трудовой договор

Оставить комментарий