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

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

В этой статье я подготовила план, как не попасть в ситуацию, когда вы зарплату разработчику заплатили, а он ушел вместе с вашим приложением. Инструмент защиты тут на самом деле один — система служебных результатов интеллектуальной деятельности. Я клянусь, что для нее вам понадобится минимум документов, давайте разбираться!

На связи София Залуцкая, юрист по сопровождению сделок с ИТ-активами. Расскажу подробнее о ситуации (это, кстати, реальный кейс: Дело № А40-202764/2018, постановление Суда по интеллектуальным правам от 01.08.2019 № С01-446/2019).

Один разработчик написал мобильное приложение. Не на коленке в выходные, а на работе, в рабочее время, будучи в штате. Компания приложение получила, использовала и считала своим. Логично: человек в штате, значит, всё, что он написал, принадлежит работодателю.

А потом работник и работодатель поссорились. И в ходе конфликта выяснилось, что права на приложение работодателю-то и не принадлежат.

Дальше следите за руками:

1. Работник заявляет о том, что приложение его и начинает его использовать.

2. Компания идёт в суд доказывать, что приложение - служебное произведение.

3. Суд спрашивает: покажите трудовой договор и служебное задание.
   А такого задания нет.

4. Суд спрашивает: покажите, что программа создана в рабочее время.
   Доказательств нет.

5. Суд спрашивает: покажите документы о том, что это входило в трудовые обязанности.
   Не показали.

Апелляция согласилась – Кассация согласилась – Исключительное право на ПО осталось за бывшим сотрудником.

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

Когда РИД становится служебным?

Результаты интеллектуальной деятельности (или РИД) — это закрытый список из статьи 1225 ГК, в котором 16 позиций. В IT регулярно встречаются четыре из них:
- программы для ЭВМ,
- базы данных,
- произведения (сюда падают дизайн, тексты, документация, макеты)
- секреты производства aka ноу-хау.
- иногда еще изобретения и полезные модели, если вы патентуете алгоритм или железо. 

В статье 1295 ГК указано, что если работник создал результат в пределах установленных для него трудовых обязанностей, он признается служебным, а исключительное право по умолчанию принадлежит работодателю.

Но есть два душных подвоха: 

• если работодатель в течение трех лет со дня, когда произведение поступило в его распоряжение, не начнет его использовать, не передаст исключительное право другому лицу и не сообщит автору о сохранении произведения в тайне — исключительное право возвращается работнику. Для IT это в основном теоретический риск: код обычно начинают использовать сразу. Но если у вас в компании лежит неиспользуемая наработка трехлетней давности - вопрос перестает быть теоретическим;

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

🤗 Лирическое ворчливое отступление

Я давно работаю с IT-бизнесом, и меня искренне раздражает, когда коллеги-юристы выстраивают систему служебных РИД, убеждая клиента, что абсолютно необходимо раз в отчётный период подписывать с каждым разработчиком акт с перечислением всех созданных РИД и какую-то еще кипу бумаг.

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

Пленум Верховного Суда в постановлении от 23.04.2019 № 10 (пункт 104) объяснил, как вообще определяется служебность. До 2008 года служебными считались произведения, созданные в порядке выполнения служебных обязанностей или служебного задания. Статья 1295 в действующей редакции говорит только о произведении, созданном в пределах установленных для работника трудовых обязанностей. Задания в определении больше нет. Более того, Пленум развернул логику: чтобы понять, является ли служебным произведение, созданное по конкретному заданию работодателя, надо исследовать, входило ли это задание в пределы трудовых обязанностей. Если не входило - исключительное право остается у работника и использовать его можно только по отдельному соглашению, за вознаграждение.

Читаем ещё раз: задание не делает произведение служебным. Служебным его делает трудовая функция. Задание, акт, тикет – это доказательства того, что вы поручили работу, которая в эту функцию входит.

В описанном выше кейсе компания проиграла не потому, что не подписала акты, а потому, что у неё вообще ничего не было: ни задания, ни следов рабочего времени, ни описания трудовой функции. Акты – один из способов оставить след, но не единственный и не лучший.

Моя позиция: система служебных РИД должна облегчать бизнесу жизнь, а не добавлять головняков. Хорошая система – та, которая работает сама, из существующих процессов. Плохая  –  та, ради которой раз в квартал ловят разработчиков с распечаткой и ручкой, потом полгода не ловят, а потом в суде выясняется, что за третий квартал акта нет и всё зря.

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

Как сделать так, чтобы права остались у компании: 7 шагов

Шаг 1. Найдите, где у вас создаются РИД

Это самый главный шаг. Надо сесть и выписать все информационные ресурсы, в которых у вас появляются РИД: трекер задач, репозитории, дизайн-инструменты, вики, диски, мессенджеры. Это важно, потому что при споре о том, является ли произведение служебным, содержание трудовых обязанностей работника и факт создания произведения в пределах этих обязанностей доказываются работодателем. Сам по себе факт использования работником материалов работодателя не делает произведение служебным. То есть «он писал на нашем ноутбуке» как аргумент не засчитывается)

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

Обратите внимание, если разработчик коммитит в личный GitHub, ведёт задачи в своём Notion, а вам присылает архив в телеграм – хороших доказательств у вас нет. Поэтому выписали список систем и дальше строим всё вокруг него.

Шаг 2. Превратите обычные тикеты в доказательства

Не надо заводить отдельный документооборот, ваши тикеты – это и есть служебные задания. Они должны быть с описанием, исполнителем, датой и связано с трудовой функцией.

И выглядеть примерно так:

• Исполнитель: Иванов И.И., должность из трудового договора

• Задача: реализовать модуль авторизации через OAuth 2.0 для веб-приложения «Название»

• Срок: до 30.09.2026

• Где сдаётся: ветка feature/oauth репозитория company/product в корпоративном GitLab

Шаг 3. Свяжите это с трудовой функцией

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

3.1. Есть ли у вас условие о том, какие именно РИД вы признаёте служебными? 

Хорошая формулировка: 

«Все программы для ЭВМ, созданные Работником в порядке выполнения его трудовых обязанностей перед Работодателем, признаются служебными произведениями (ст. 1295 Гражданского кодекса РФ). Все иные результаты интеллектуальной деятельности, созданные Работником в порядке выполнения его трудовых обязанностей перед Работодателем, признаются соответствующими служебными результатами интеллектуальной деятельности (соответственно служебными произведениями (ст. 1295 ГК РФ), служебными исполнениями (ст. 1320 ГК РФ), служебными изобретениями, служебными полезными моделями, служебными промышленными образцами (ст. 1370 ГК РФ), служебными секретами производства (ст. 1470 ГК РФ) и пр.).»

Она должна закрыть весь спектр объектов, а не только код. Разработчик по ходу дела пишет документацию, дизайнер – макеты, аналитик — базы данных. Прям все пропишите. Каждый вид РИД живёт по своей статье ГК, поэтому только максимальное исключение всех процессов избавляет от спора о том, на что именно должны вам перейти права. 

3.2. Где сотрудник узнает о необходимости создания РИД и где сдаётся результат? 

Хорошая формулировка: 

«Служебные задания Работодателя на разработку, доработку, создание, модификацию, адаптацию программ для ЭВМ и иных служебных произведений, иных служебных результатов интеллектуальной деятельности могут доводиться до Работника любым способом, в том числе посредством электронных платформ и систем, в том числе, но не ограничиваясь: _______. (здесь вписываете обнаруженные в п.1 сервисы.)»

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

3.3. В полном ли объеме у вас установлен переход исключительного права?

Тут предельно соберитесь, это самая важная часть! Отвечаем на 3 вопроса:

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

• в каком объеме. Право должно принадлежать работодателю в полном объеме, без ограничения территории и срока. Это важно, например, при продаже компании, регистрации ПО или выходе продукта на зарубежные рынки;

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

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

Готовые формулировки для этого блока я включила в шаблон дополнительного соглашения — его можно будет скачать в конце статьи.

3.4. Гарантии и заверения

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

Хорошая формулировка: 

«Работник гарантирует Работодателю и заверяет его:

- что служебные произведения, иные служебные результаты интеллектуальной деятельности будут созданы Работником лично, без привлечения других лиц;

- что при создании служебных произведений, иных служебных результатов интеллектуальной деятельности и при передаче их Работодателю не будут нарушены права третьих лиц;

- что Работник не передаст служебные произведения, иные служебные результаты интеллектуальной деятельности и (или) права на них третьим лицам;

- что Работник обеспечит порядок создания служебных произведений, иных служебных результатов интеллектуальной деятельности и их надлежащую передачу Работодателю, обеспечивающие отсутствие у третьих лиц каких-либо личных или имущественных прав на такие результаты интеллектуальной деятельности, а также обеспечивающие отсутствие у кого бы то ни было иной правовой возможности ограничить исключительные права Работодателя на служебные произведения, иные служебные результаты интеллектуальной деятельности, создаваемые Работником, или ограничить возможность использования Работодателем таких служебных произведений, иных служебных результатов интеллектуальной деятельности»

Шаг 4. Закрепите предыдущие шаги документом

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

Еще один вариант — принять локальный нормативный акт (ЛНА), то есть внутреннее положение компании о работе со служебными РИД. В нем можно установить единые правила: как ставятся задачи, где создаются и передаются результаты и как фиксируется их создание. При этом ЛНА не всегда заменяет дополнительное соглашение. Если нужно изменить или дополнить условия самого трудового договора конкретного работника, это оформляется отдельно.

Шаг 5. Запретите личные аккаунты

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

За чем точно жестко нужно следить:

1. Никакой работы в личных аккаунтах. Личный GitHub, личный аккаунт в дизайн-инструменте, личный диск - минус вайб.

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

3. Все вышеуказанные правила работают только в совокупности. Если вы перевели всех на корпоративный github, но не легализовали его в договоре или, например, результат работы сдается вам в личные сообщения - система будет защищать вас только на 20%. Так не надо. 

Важно: к подрядчикам и фрилансерам эта схема не применима, там статья 1296 и договор. Обязательно об этом тоже напишу!

Шаг 6. Фиксируйте состояние кода 

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

Бандл, снятый на дату и подписанный, закрывает все три пункта одним файлом: вот коммиты, вот учётки авторов, вот даты, вот привязка к вашей корпоративной системе. Еще это важно для трёхлетнего срока из п. 2 ст. 1295. Помните, если работодатель не начал использовать произведение в течение трёх лет с момента, когда оно поступило в его распоряжение, право возвращается работнику. А с какой даты считать это «поступило в распоряжение»? Подписанный документ с хешем даёт вам точку отсчёта, зафиксированную в момент, а не восстановленную задним числом в суде.

При увольнении кстати бандл вас тоже очень защитит, чтобы доказать, что было написано "до и "после".

В будущем, когда вы будете продавать компанию, регистрировать ПО в Роспатенте или заходить в реестр отечественного ПО, у вас на руках будут все доказательства, что код ваш и только ваш.

Инструменты фиксации

Шаг 7. Отдельно оформите авторское вознаграждение

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

Верховный Суд в определении от 05.06.2020 № 78-КГ20-1 указал, что вознаграждение автора носит гражданско-правовой характер, а не трудовой, и потому не может рассматриваться как часть заработной платы. Подменять одно другим недопустимо, и условие о том, что вознаграждение «учтено в зарплате», не признается надлежащим соглашением о порядке выплаты, если из него невозможно определить размер, условия и порядок.

Сумма может быть символической, но она должна быть отдельной и определимой. 

Как всегда, поможет только работающая система

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

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

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

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

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

Если было полезно, интересно, подписывайтесь на мой тг-канал, там больше шаблонов и кейсов из моей практики! До встречи!