Один из самых болезненных сценариев в IT-бизнесе: ключевые разработчики увольняются, открывают собственную компанию и выпускают продукт, подозрительно похожий на ваш. Или обратная ситуация — вы сам разработчик, который ушёл строить своё, а бывший работодатель уже звонит юристам.
Разберёмся, как работает закон, почему «я сам написал этот код» — недостаточный аргумент, и что нужно прописать в договоре заранее.
$500 млн за утечку кода: кейс ZeniMax vs Oculus
В 2014 году Джон Кармак — легендарный разработчик Doom и Quake — перешёл из ZeniMax Media в Oculus VR. Вместе с ним, по мнению ZeniMax, утекли технологии виртуальной реальности, которые компания разрабатывала годами.
ZeniMax подала в суд, обвинив Oculus в нарушении авторских прав и краже конфиденциальной информации. В 2017 году суд встал на сторону истца и присудил компенсацию в 500 миллионов долларов.
Показательно, что речь шла не о буквальном копировании строк кода. ZeniMax доказывала, что Кармак передал в Oculus знания, методы и подходы, которые были коммерческой тайной работодателя.
Для российского рынка этот кейс — не экзотика. Подобные конфликты случаются регулярно, просто в меньших масштабах и без публичной огласки.
Что говорит российское право
В основе — режим служебного произведения (ст. 1295 ГК РФ).
Если разработчик создал программу в рамках трудовых обязанностей или по конкретному заданию работодателя — исключительное право по умолчанию принадлежит работодателю. Автором при этом остаётся сам разработчик, но распоряжаться кодом коммерчески может только компания.
Три ключевых условия, при которых код считается служебным:
Сотрудник находился в трудовых отношениях с компанией в момент создания.
Программа создавалась в рамках его должностных обязанностей или по прямому заданию работодателя.
«Правило трёх лет»: работодатель в течение трёх лет начал использование произведения, передал на него права либо письменно уведомил автора о сохранении произведения в тайне. Если ничего из этого не произошло — исключительное право возвращается автору.
Если хотя бы одно условие не выполнено — ситуация становится спорной.
Когда код всё-таки останется у разработчика
Суд по интеллектуальным правам в деле № А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.