Jira, Git, трудовой договор. Что из этого защищает права работодателя на код, а что нет

Jira, Git, трудовой договор. Что из этого защищает права работодателя на код, а что нет - 1

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

Такие истории заканчиваются не быстро. Судебные разбирательства по правам на ПО, это от года до трёх лет, экспертизы исходных кодов, пяти- и шестизначные суммы судебных расходов. Итог зависит от того, что компания успела сделать до конфликта, а не после.

Как закон защищает работодателя, и где эта защита не работает

Статья 1295 ГК РФ устанавливает простое правило. Если произведение создано в пределах трудовых обязанностей работника, исключительное право на него принадлежит работодателю. Для программ для ЭВМ действует та же логика, они охраняются как литературные произведения (ст. 1261 ГК РФ).

«Исключительное право на служебное произведение принадлежит работодателю, если трудовым или иным договором между работодателем и автором не предусмотрено иное» — ст. 1295 ГК РФ.

Звучит надёжно, но на практике, нет. Всё держится на четырёх словах, «в пределах установленных трудовых обязанностей». Если обязанности нигде не прописаны, это словосочетание превращается в точку входа для оспаривания.

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

Три истории из судебной практики

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

 История первая. Если документов нет, суд не поможет

АО «Вист Групп» занималась разработкой программного обеспечения для горнодобывающей отрасли. По заказу казахстанского клиента, АК «Алтыналмас», компания создала специализированную программу для диспетчеризации горной техники. Продукт написали, сдали, запустили.

Потом несколько разработчиков ушли. Вскоре появилась новая компания, В2-Групп, и новая программа с именем «АЛЬТАН» (ALTAN). Те же авторы, тот же функционал. В2-Групп успела зарегистрировать программу в Роспатенте на себя.

«Вист Групп» подала иск, потребовала признать регистрацию недействительной, запретить использование, взыскать 5 миллионов рублей компенсации. Казалось бы, очевидная ситуация. Сотрудники написали программу, находясь в штате, ушли и присвоили результат.

Но суды трёх инстанций отказали истцу. Суд по интеллектуальным правам, рассматривая дело в 2024 году, назвал ключевую проблему. В материалах дела не было ни одного документа, подтверждающего, что именно работодатель поставил задачу создать эту конкретную программу. Должностные инструкции в дело не попали вообще. Технического задания не существовало. Акта передачи программы работодателю не было..

Без этого суд не смог квалифицировать программу как служебное произведение. Де-юре, разработчики написали её как бы сами по себе, и только потом она оказалась в продуктах «Вист Групп» (дело № А40-90889/2021). Выводы судебной экспертизы были не в пользу истца, Ответчик же представил договоры авторского заказа от 2019 года, якобы на разработку этой программы.

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

История вторая. Когда бывший CTO основал конкурента

ООО «Тимджет» разработало корпоративный продукт TeamJet. Дата начала разработки зафиксирована приказом, 1 апреля 2019 года. Команда работала в штате, у каждого был трудовой договор с прямым условием о переходе прав на служебные РИД к работодателю.

В 2021 году CTO компании, Михайлов Г.Н., ушёл. Обычное дело. Но дальше события развивались нетривиально. Михайлов основал в Дубае компанию ООО «Тиматикс ФЗ-ЛЛСи» и зарегистрировал там программу под названием TEAMATIX. Более того, в маркетинговых материалах TEAMATIX позиционировался как «улучшенная версия TeamJet». То есть Михайлов открыто использовал связь с оригинальным продуктом как конкурентное преимущество.

«Тимджет» обнаружил нарушение и зафиксировал его через протокол осмотра доказательств. Компания обратилась в суд с иском о защите исключительных прав и потребовала запретить ответчику использовать программу.

Затем последовал встречный удар. Михайлов подал встречный иск и потребовал запретить «Тимджет» использовать собственный продукт, утверждая, что настоящим автором TeamJet является именно он, а не компания.

В суде ответчик представил договоры с разработчиками, по которым те якобы передали права Михайлову лично. Но несколько разработчиков принесли нотариально заверенные объяснения, договоры, представленные ответчиком, ими никогда не подписывались. В итоге ответчик был вынужден сам отозвать из дела 122 листа сомнительных документов.

Техническая экспертиза кодов дала однозначный ответ. 98% строк кода TEAMATIX совпадали с кодом TeamJet. Даты коммитов в репозиториях TEAMATIX точно совпадали с историей коммитов TeamJet вплоть до последнего. Эксперт отметил, что признаков изменения дат создания исходных кодов не обнаружено.

Оба иска, и первоначальный, и встречный, разрешены в пользу бывшего работодателя. Без приказа о начале разработки, трудовых договоров с условием об отчуждении прав, должностных инструкций и архива репозитория этот результат вряд ли получилось бы достичь (дело № А40-144779/2022).

История третья. Предательство изнутри и нотариус как спасение

ООО «НКС» (бывшая «Национальная консалтинговая служба») разрабатывала программный продукт «Сканер закупок», систему автоматизации работы с государственными контрактами на платформе 1С. Основным разработчиком был архитектор проектов Григорьев А.С., его непосредственным руководителем, заместитель генерального директора Дмитриченко С.С.

21 сентября 2020 года Григорьев отправил с корпоративного адреса griga@nks.su на корпоративный адрес своего руководителя ceo@nks.su письмо с презентацией продукта: 14 слайдов с описанием функционала «Сканера закупок». Рабочая переписка, никакой особой значимости.

Через два месяца, 20 ноября 2020 года, в Роспатент поступила заявка на регистрацию программы для ЭВМ «Анализ контрактов». Автором и правообладателем значилась некая Егорова Тамара Сергеевна. Описание в реестре совпадало с продуктом «НКС» до деталей. 27 ноября регистрация состоялась.

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

Как компания это доказала? Нотариус Явтух М.В. составил протокол осмотра корпоративной переписки и зафиксировал письма с вложенными файлами исходного кода. Этот протокол стал центральным доказательством. Судебная экспертиза сравнила исходный код из переписки с кодом, поданным Егоровой в Роспатент, и установила совпадение на 100%.

Суд признал программу служебным произведением, аннулировал регистрацию и запретил Егоровой использовать программу любым способом. Все три инстанции, вплоть до Суда по интеллектуальным правам в феврале 2025 года, поддержали НКС. Решение устояло, несмотря на попытки Егоровой оспорить его (дело № А84-7632/2021).

Здесь важен один нюанс. Компания не планировала заранее нотариально фиксировать переписку. Нотариуса привлекли уже после того, как обнаружилась чужая регистрация. Но переписка сохранилась, корпоративная почта не была удалена, и этого хватило.

Почему одного трудового договора мало

Стандартная ошибка выглядит так. Компания включает в трудовой договор фразу «работник обязан передавать результаты работы работодателю» и считает вопрос закрытым. Суды с этим не соглашаются.

Для квалификации кода как служебного произведения нужно одновременно доказать три вещи. Что создание этого конкретного объекта входило в трудовые обязанности работника. Что задание было получено от работодателя. И что оно исполнено в рамках трудовых отношений. Одна фраза в договоре всё это не покрывает. Нужна система взаимосвязанных документов.

Что входит в эту систему.

  • Трудовой договор или допсоглашение с разделом о служебных РИД, с прямым указанием, что исключительное право переходит работодателю с момента создания, и с условием об авторском вознаграждении (ст. 1295 ГК РФ требует его выплачивать).

  • Должностная инструкция, конкретные обязанности по разработке, тестированию, документированию, обязанность сообщать о созданных РИД.

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

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

  • Акт приёма-передачи результата, фиксирует факт передачи конкретного объекта работодателю с описанием программы, датой и подписями сторон. Без этого акта сложнее доказать, что передача состоялась, если другой порядок передачи и ее фиксации вы не описали в регламенте.

Отдельный нюанс, вознаграждение автора. Без него договор уязвим. На практике вопрос решается включением фиксированной суммы с ежегодной выплатой независимо от количества созданных РИД. Это обычно снимает возможные претензии по ст. 1295 ГК РФ.

Задачи в Jira, коммиты в Git. Где живут ваши доказательства

IT-компании работают в среде, где почти каждое действие оставляет след. Задача в Jira, коммит в Bitbucket, обсуждение в Confluence. Это одновременно угроза и возможность.

Угроза простая. Разработчик тоже имеет доступ к этой истории. В деле «Тимджет» бывший CTO скопировал репозиторий и сделал его ядром своей позиции в суде. В деле «НКС» заместитель директора использовал доступ к корпоративным файлам, чтобы передать их третьему лицу.

Возможность не менее очевидна. При правильном оформлении именно эта история становится вашей доказательной базой. В деле «НКС» нотариальный протокол корпоративной переписки с прикреплёнными файлами исходного кода оказался сильнее любых слов. В деле «Тимджет» история коммитов подвергла сомнению представленные документы, даты в репозитории TEAMATIX точно совпадали с TeamJet, и это нельзя было объяснить иначе, как копированием.

Что стоит прямо зафиксировать в Положении о РИД:

  1. использование корпоративных сервисов считается выполнением служебного задания;

  2. любое задание, поставленное через Jira, Trello, Confluence, Bitbucket или иной корпоративный инструмент, служебное независимо от формы постановки;

  3. результат разработки, размещённый в корпоративном репозитории, права на него считаются переданным работодателю.

Такая оговорка снимает вопрос о форме задания. И письменное ТЗ, и задача в трекере, и устное согласование на встрече с последующим тикетом в Jira становятся равнозначными основаниями.

Что делать с дистанционными сотрудниками и подрядчиками

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

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

С подрядчиками ситуация иная. Договор ГПХ не создаёт трудовых отношений, поэтому правила о служебном произведении здесь не работают. Права на код нужно определять по самому договору и максимально прямо. Если предмет договора именно создание программы для ЭВМ, по общему правилу исключительное право принадлежит заказчику, если стороны не согласовали иное. Но если программа создана в рамках подряда или иного договора, который прямо не предусматривал её создание, исключительное право по умолчанию может остаться у подрядчика, а заказчик получит лишь право использования в пределах целей договора. Поэтому безопасный вариант для бизнеса — прямо прописывать, кому принадлежит исключительное право, с какого момента оно переходит, сохраняется ли за подрядчиком какое-либо право использования и какие материалы считаются результатом работ.

Типичная ошибка выглядит так. Компания нанимает фрилансера для разработки отдельного модуля, договор ГПХ не содержит ни слова о РИД. Через год фрилансер регистрирует модуль в Роспатенте и приходит с лицензионными требованиями.

Чек-лист. Что проверить прямо сейчас

Пройтись по этому списку стоит до первого конфликта, а не после:

  • Трудовые договоры с разработчиками содержат раздел о служебных РИД с прямым переходом исключительного права работодателю и условием о вознаграждении автора.

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

  • Положение о РИД утверждено приказом, охватывает корпоративные сервисы и дистанционных сотрудников.

  • Приказы о начале разработки выпускаются при старте значимых проектов.

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

  • Периодическая фиксация скриншотами ключевых доказательств, переписки, истории репозитория.

Вопросы, которые задают чаще всего

Разработчик написал библиотеку в свободное время, но на рабочем ноутбуке и решил рабочую задачу. Чьё это?

Однозначного ответа нет, это один из самых спорных случаев в российской практике. Суды смотрят на совокупность факторов. Была ли задача поставлена работодателем, использовалась ли корпоративная инфраструктура, применяется ли результат в продукте компании. Рабочий ноутбук и рабочая задача, сильные индикаторы служебного произведения. Но если нет ни должностной инструкции с соответствующей обязанностью, ни задания, доказать это в суде сложно. Лучшая профилактика: в Положении о РИД прямо указать, что разработка на оборудовании компании или в рамках задач компании считается служебной.

Сотрудник уходит и хочет забрать свой open-source проект, который вёл параллельно с работой. Можно ли запретить?

Если проект явно не связан с деятельностью компании, создавался на личном оборудовании и не пересекается с продуктами работодателя, запретить сложно. Но если тематика пересекается, это уже зона риска. Практикующие специалисты рекомендуют при найме разработчиков фиксировать в документах перечень их внешних open-source проектов, тогда спор об авторстве будет закрыт заранее.

Компания хочет зарегистрировать программу в Роспатенте. Нужно ли это?

Регистрация программ для ЭВМ в России добровольная, она не создаёт права, оно возникает с момента создания. Но запись в реестре Роспатента с датой и составом авторов, это публичное доказательство, которое сложнее оспорить. История с НКС показывает обратное тоже. Именно регистрация на имя Егоровой выявила нарушение и стала отправной точкой спора. Регистрация имеет смысл для значимых продуктов, она создаёт дополнительную доказательную базу и снижает риск того, что кто-то зарегистрирует ваш код раньше вас.

Автор: Bizdroblenie

Источник

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