Сотрудник IT-подразделения сахарного завода написал на 1С программу для автоматизации весовой. Разработка получила название "Грузовая проходная 3.01".
Когда программу обнаружили на другом предприятии группы, её автор потребовал компенсацию за использование.
Казалось бы, какие могут быть вопросы? Программу создал сотрудник завода. Она появилась во время работы в компании и использовалась для автоматизации производственной задачи предприятия.
Но в ноябре 2025 года Тамбовский областной суд взыскал в пользу разработчика 760 тыс. рублей.
Если сотрудник IT-отдела написал программу для предприятия, как вообще получилось, что исключительное право осталось не у работодателя?
И насколько легко повторить эту историю?
Рабочий компьютер ещё ничего не значит
Компания платит зарплату, даёт компьютер, серверы, лицензии. Человек всё это использует в рабочее время. Значит, результат тоже компании. С кодом так получается не всегда.
В статье 1295 ГК РФ формулировка следующая: служебным считается произведение, созданное в пределах установленных для работника трудовых обязанностей.
То есть смотреть придётся прежде всего не на наклейку с инвентарным номером на ноутбуке, а на то, чем человек вообще должен был заниматься по работе.
Пленум Верховного Суда в 2019 году указал: одного использования материалов работодателя для признания произведения служебным недостаточно.
Рабочая техника может помочь одной из сторон в споре, но ни один из этих фактов сам по себе не отвечает на вопрос, кому принадлежит исключительное право.
Представим бухгалтера, который каждый месяц вручную собирает одни и те же данные. В какой-то момент ему надоедает и он пишет небольшую обработку.
Компьютер рабочий. 1С рабочая. База тоже.
Но если разработка программ в его обязанности вообще не входила - это другой разговор.
Теперь вместо бухгалтера берём штатного разработчика 1С, у которого в должностной инструкции прямо записана разработка и доработка механизмов автоматизации.
Вот здесь положение работодателя уже лучше.
Причём отдельного ТЗ именно на эту обработку может и не быть.
Без ТЗ код не обязательно становится личным
Можно подумать, что если нет ТЗ, то значит код принадлежит сотруднику, но на практике всё не так просто.
Это хорошо видно по спору вокруг "ПК Парадигма".
Разработчик работал инженером отдела перспективных разработок НПП "ЭКРА". Уже после увольнения он зарегистрировал программу в Роспатенте на своё имя и стал отстаивать права на неё.
Но суды стали смотреть, чем занимался отдел и что входило в работу самого сотрудника.
В документах предприятия было указано, что подразделение занимается разработкой программных модулей. Сам работник рассказывал, что делал программные решения по устной просьбе руководителя.
Этого массива обстоятельств было достаточно, чтобы программу признали служебной. В 2022 году кассация оставила результат в силе.
Иными словами, отдельного письменного ТЗ на "ПК Парадигма" суду не понадобилось. Служебность программы может подтверждаться и без него, если из трудовых документов и самой истории разработки было понятно, что подобные программы человек должен был создавать по работе.
Автор - сотрудник. Правообладатель - работодатель
Есть ещё одна путаница. Если программа служебная, работодателя иногда начинают называть её автором.
Так нельзя.
Автор - человек, который создал программу. ООО автором кода стать не может. А вот исключительное право вполне может принадлежать компании.
Хорошо разница видна в споре, который позднее попал в обзор судебной практики Верховного Суда.
Сотрудник государственного предприятия с 1989 года работал инженером автоматизированной системы управления, а затем больше двадцати лет возглавлял отдел АСУ. За это время он разрабатывал программы для предприятия и сам внедрял их в работу своего подразделения.
Позже сотрудник обратился в суд. Он требовал признать его автором созданных программ и взыскать с предприятия компенсацию за нарушение исключительного права: программы использовались работодателем, а отдельной оплаты за это разработчик не получал.
С первой частью требования суд согласился.
Программы действительно создал он - значит, автором является сотрудник.
А вот компенсацию не взыскали.
Суд поднял трудовые документы и посмотрел, чем инженер должен был заниматься по работе. В его обязанности входили внедрение аппаратно-программных решений, участие в подготовке технических заданий на автоматизированные системы, развитие и совершенствование АСУ.
Кроме того, программы создавались для самого предприятия, с использованием его технических ресурсов, а разработчик затем самостоятельно внедрял их в работу возглавляемого отдела.
Поэтому суд пришёл к выводу: программы служебные, а исключительное право на них принадлежало работодателю. Апелляция этот результат не изменила.
Почему тогда разработчик "Грузовой проходной" получил 760 тысяч?
Теперь вернёмся к сахарному заводу.
"Грузовая проходная 3.01" была сделана на базе "1С:Предприятия 8.2" для автоматизации работы весовой - пункта, где на предприятии взвешивали грузовой транспорт.
Автор работал в IT-подразделении предприятия. Позднее возник спор из-за использования программы на другом предприятии группы.
Работодатель настаивал на служебном характере разработки. Но убедить суд не получилось.
В деле как раз появляется позиция Верховного Суда о том, что использование материалов работодателя само по себе ещё не делает произведение служебным.
Разработчик первоначально просил 1,52 млн рублей. Суд взыскал 760 тыс.
Работодателю недостаточно сказать, что программа появилась внутри его IT-службы. Нужно ещё доказать, что создание именно такого результата находилось в пределах работы конкретного сотрудника.
В 2013 году Рытов уже работал начальником отдела информационных технологий, но действующего на тот момент трудового договора работодатель суду не представил. Старый договор относился к другой должности и другому периоду. Сам разработчик утверждал, что как руководитель IT-отдела занимался административной работой, а программирование в его обязанности не входило. Письменного задания на "Грузовую проходную" тоже не нашлось. Поэтому рабочее место и корпоративная 1С не могли доказать служебный характер программы.
Medsenger: программа появилась внутри компании, но этого было недостаточно
Похожая проблема возникла вокруг медицинского мессенджера Medsenger.
ООО "Амедико" считало, что права на продукт принадлежат ему: над проектом работали сотрудники компании.
Когда спор дошёл до суда, рассматривались следующие вопросы:
- Кто именно написал программу?
- Когда?
- Что в этот момент входило в его трудовые обязанности?
- Как результат был передан работодателю?
На часть этих вопросов у "Амедико" не нашлось достаточно убедительных документов.
Суды изучали трудовые документы, переписку, показания, сведения о регистрации программы. Но восстановить цепочку возникновения исключительного права у работодателя из этого не получилось.
Арбитражный суд Москвы отказал в иске. Апелляция решение не изменила. В августе 2019 года тот же результат оставил Суд по интеллектуальным правам.
А если обработку разработчик придумал сам?
Никто ничего не просил. Разработчик увидел, что пользователи каждый день делают двадцать одинаковых действий, и сам написал обработку.
Ею начали пользоваться.
Чья она?
Здесь собственная инициатива сразу не даёт ответа.
Если сотрудника наняли именно для автоматизации, вполне может оказаться, что самостоятельно придумать такой инструмент - это часть его работы.
Не каждое служебное произведение рождается после требования:
"Прошу разработать обработку до пятницы".
Иногда разработчик сам видит проблему и решает её именно потому, что за это ему и платят. Но если созданный продукт явно выходит за пределы трудовой функции, условия в споре меняются.
Своя библиотека, которую разработчик принёс с собой
Разработчик написал HTTP-клиент или обработку Excel ещё до трудоустройства.
Потом устроился в компанию, подключил её к рабочему проекту и несколько лет дорабатывал.
Само трудоустройство не передаёт работодателю задним числом права на старый код.
А вот дальше возникают вопросы.
- Какая версия существовала до работы?
- Какие строки появились уже после?
- Кто их добавил?
- Что менял сам первоначальный автор, а что коллеги?
Если исходное состояние библиотеки нигде не сохранили, через несколько лет доказать что-либо будет сложно.
Git очень полезен. Но у него есть один недостаток
С историей происхождения кода сейчас всё-таки проще, чем двадцать лет назад.
Есть Git.
Можно поднять старый commit, посмотреть файл до правки, автора изменения, дату, ветку, историю слияний. Репозиторий, резервные копии и нотариальный осмотр таких материалов уже могут стать серьёзными доказательствами.
Но у Git есть один недостаток. Он не знает Гражданский кодекс.
Строка:
Author: Ivan Ivanov
говорит о конкретной учётной записи и конкретном изменении.
С вопросом "кому принадлежит исключительное право" Git помочь напрямую не может.
Для этого опять придётся доставать трудовой договор, должностную инструкцию, задачи и переписку. Поэтому самый полезный Git - тот, который не остаётся единственным доказательством.
После увольнения код внезапно не становится своим
Разработчик несколько лет пишет программу, увольняется и решает:
Я её написал, значит могу взять с собой.
Если программа служебная и исключительное право уже принадлежит работодателю, увольнение ничего обратно не переключает.
Компания может продолжать использовать продукт. А бывший сотрудник не получает право продавать ту же программу, выкладывать исходники или переносить код на новое место только потому, что именно он когда-то его написал.
Это хорошо видно в деле Barsum / Mentol Pro.
ООО "Барсум" разрабатывало программный комплекс Barsum Bill Works - систему биллинга и контроля качества услуг связи.
Позже на рынке появился другой продукт - Mentol Pro, зарегистрированный в 2017 году на ООО "Инлайн Про".
У "Барсум" возникли вопросы не только потому, что продукты решали похожие задачи. К созданию Mentol Pro имели отношение бывшие сотрудники "Барсум", которые раньше имели доступ к исходному коду и базе клиентов компании. Один из них, ставший руководителем "Инлайн Про", во время работы в "Барсум" сам участвовал в разработке исходного кода Barsum.
Бывший работодатель заявил: новый продукт не разработан независимо. При его создании использовали исходный код Barsum, структуру базы данных и другие элементы старой программы.
"Инлайн Про" отвечало, что Mentol Pro - самостоятельная разработка, созданная своей командой. В подтверждение компания ссылалась в том числе на регистрацию программы в Роспатенте. Спор дошёл до компьютерно-программно-технической экспертизы.
В декабре 2020 года первая инстанция отказала "Барсум" в иске и признала исключительное право на Mentol Pro за "Инлайн Про". Суд не увидел достаточных доказательств того, что новая программа является переработкой старой.
Но в апелляции назначили дополнительную экспертизу и получили другой результат.
Эксперт сравнил материалы исходного кода обеих программ и пришёл к выводу, что Mentol Pro содержит часть исходного кода Barsum. Были обнаружены также заимствования элементов структуры базы данных и совпадения в работе программ. Barsum при этом существовал раньше: в функциональном виде его разработали к 2013 году, Mentol Pro появился позднее.
В совокупности это позволило эксперту сделать вывод: Mentol Pro не является полностью независимой разработкой, а представляет собой производную от Barsum программу.
После этого апелляция развернула дело.
Регистрацию Mentol Pro признали недействительной, программу постановили исключить из реестра, "Инлайн Про" запретили её использовать и распоряжаться ею. Кроме того, с компании взыскали 2 млн рублей компенсации.
На этом история не закончилась. Суд по интеллектуальным правам отменил постановление апелляции и снова вернул результат первой инстанции - в пользу "Инлайн Про".
Тогда дело дошло до Верховного Суда.
В ноябре 2022 года Верховный Суд отменил постановление Суда по интеллектуальным правам и оставил в силе решение апелляции.
Сам Верховный Суд заново исходники не сравнивал. Для него важным оказался и процессуальный вопрос: апелляция имела право назначить дополнительную экспертизу и оценить полученные результаты, а кассационная инстанция не должна была фактически заново переоценивать доказательства.
В итоге устоял вывод о нарушении прав "Барсум".
Опыт можно унести с собой. Чужой исходный код - нет.
А поверх авторского права в конкретной ситуации могут дополнительно работать коммерческая тайна, конфиденциальность и защита данных.
Роспатент тоже не ставит последнюю точку
Программу для ЭВМ можно зарегистрировать. Но свидетельство не создаёт авторское право с нуля и не отменяет того, что происходило раньше.
Та же "Парадигма" это хорошо показывает. Бывший сотрудник зарегистрировал программу на себя, а работодатель потом доказал её служебное происхождение.
Так что Роспатент - хороший документ. Просто не последний аргумент в споре.
И есть ещё правило трёх лет
У статьи 1295 есть одна норма, про которую разработчики обычно узнают уже сильно позже.
Допустим, программа точно служебная и право изначально у работодателя. После того как произведение передано ему в распоряжение, начинает иметь значение трёхлетний срок.
Если за это время работодатель не использовал произведение, не передал исключительное право и не сообщил автору о сохранении результата в тайне, исключительное право возвращается автору.
Что проверять до того, как возник спор
Полезно заранее понимать:
-
Что было написано в трудовом договоре и должностной инструкции на момент создания программы.
-
Можно ли связать конкретную разработку с работой сотрудника: задачей, письмом, ТЗ, протоколом, отчётом.
-
Сохранилась ли история разработки в репозитории.
-
Понятно ли, когда результат оказался у работодателя.
-
Не было ли внутри продукта старого личного кода сотрудника или сторонних библиотек с отдельной историей.
-
Нормально ли оформлены права на код тех, кто вообще не является штатным сотрудником.
В итоге всё снова упирается в довольно простой вопрос:
Что входило в работу этого человека в тот момент, когда появился код?
И второй, не менее важный:
Можно ли это сегодня доказать?