5 лайфхаков: как защитить РИД в IT-компании через таск-трекеры и Git

IT-предприниматели ошибочно полагают, что достаточно включить в трудовой договор фразу «все права на код сотрудника принадлежат компании». Разберемся, как превратить User Stories в Jira/Trello или коммиты в Git в работающий юридический код вашего проекта на примерах и реальных кейсах.

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

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

Меня зовут Давид Замирович и я - тот самый юрист с IT-бэкграундом, который помогает технологическим компаниям и стартапам превращать их рабочие процессы в юридический код, веду телеграм канал «Юрист без багов» и сейчас разложу все по полочкам.

Для удобства, я структурировал этот материал, сделал удобный FAQ и оглавление. А на телеграм канале разместил "Чек-лист для IT-фаундера: оформление РИД от найма до сделки" с примерами:

Нематериальные активы (или "НМА") являются ключевыми в IT-секторе. Стоимость многих технологических компаний напрямую зависит от их портфеля интеллектуальной собственности (ИС или IP). Без защиты эти активы могут быть легко скопированы, использованы конкурентами или, что еще хуже, могут быть оспорены бывшим сотрудникам. В этом материале я приведу примеры реальных кейсов на эту тему.

Результаты интеллектуальной деятельности (или "РИД") являются базой для ключевых налоговых льгот:

Таким образом, юридическая «обвязка» является не просто формальностью, а основой для создания и увеличения капитализации, привлечения инвестиций и устойчивого роста бизнеса.

Хорошая новость в том - что благодаря международным соглашениям законодательство об интеллектуальной собственности в большинстве стран мира гармонизировано. Это значит, что отличия в основном состоят в процедурных моментах. Все что написано в данном материале на 100% применимо не только к России, но и к Кипру, ОАЭ, странам общего права или США.

Одной из самых распространенных проблем является устойчивое заблуждение о том, что "если я плачу сотруднику зарплату - то все, что он сделал автоматически принадлежит компании".

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

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

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

Это означает, что закон устанавливает презумпцию перехода прав к компании, что, на первый взгляд, кажется надежным механизмом защиты. Но это не совсем так.

Российское законодательство ничем не отличается от европейской практики, подкрепленной решениями Суда Европейского союза (CJEU). Например, дело National Orchestra of Belgium v. Royal Decree (C-575/23), о котором будет рассказано подробнее в следующем разделе, четко демонстрирует также как и российская судебная практика, что в рамках трудовых отношений для передачи прав на творческие результаты требуется явное согласие автора и справедливое вознаграждение.

Как этого добиться, если разработка идет в Git, а задания и статус их выполнения фиксируется в Trello, Jira или Redmine? На самом деле просто, поехали дальше!

Как же доказать, что ваш код - это служебное произведение, созданное по конкретному заданию, которое вы выдавали в Jira или Redmine?

Ответ находится именно в тех инструментах, которыми ваша команда пользуется каждый день. Цифровые следы в таск-трекерах и Git-репозиториях - это не просто внутренняя документация, а ценная доказательная база, которая может спасти ваш бизнес. Только нужен небольшой юридический код, чтобы она была понятна судьями или проверяющим.

User Stories (пользовательские истории) - это стандартный инструмент в IT-разработке для описания функциональных требований.

Но с юридической точки зрения, грамотно оформленная User Story - это идеальное «конкретное задание работодателя», о котором говорится в ГК РФ. Так как же оформить права на код в Jira?

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

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

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

Если Jira задает цель, то Git-репозиторий создает неопровержимую хронику ее достижения. Каждый коммит - это задокументированное изменение, которое содержит три ключевых элемента:

Эти данные являются классическим примером "опосредованных цифровых следов". Они формируются автоматически и их крайне сложно подделать.

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

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

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

Что должно быть указано в таком акте?

Акт приема-передачи (отчет) завершает «трилогию» документации. Он превращает факт выполнения задания (фиксируемый в Jira) и сам процесс создания (фиксируемый в Git) в юридически значимый документ. Отсутствие этого акта создает серьезный пробел в доказательной базе.

Мы можем также структурировать во внутренних политиках и трудовом договоре, что подтверждением факта передачи прав является сам Merge соответствующего коммита уполномоченным сотрудником.

Но так как документы о создании РИД читает и наша любимая бухгалтерия, а также проверяющие и налоговые органы - рекомендуется создать систему автоматической выгрузки таких актов (отчетов) и оформления их на бумажных носителях или с ЭЦП.

Выплата авторского вознаграждения за служебное произведение - это не просто прихоть или "добрая воля" компании - а законодательно закрепленная обязанность работодателя (п. 2 ст. 1295 ГК РФ).

Законодательство говорит о том, что размер вознаграждения (которое должно быть выплачено сверх и отдельно от заработной платы) должно быть установлено в отдельном договоре в отношении каждого отдельного РИД и если согласия по этому поводу не достигнуто - размер определяется судом.

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

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

Давайте разберемся какие конкретно кейсы являются знаковыми и определяющими в рамках тематики материала (оформление исключительных прав на ПО для ЭВМ между работодателем и работником):

Постановление Конституционного Суда РФ от 16.06.2022 № 25-П по делу Мамичева о котором я писал в 2022 году на VC стало фундаментальным для всей российской IT-индустрии.

Суть спора заключалась в следующем:

Иными словами, Суд подтвердил, что авторские права на производные произведения (куда входит ПО, использующее open-source) должны защищаться, а использование открытых библиотек не нарушает прав их авторов и работодатель не может присваивать себе результаты труда разработчика при отсутствии документов с ним на этом основании.

В деле National Orchestra of Belgium v. Royal Decree (C-575/23) бельгийский указ, который автоматически передавал авторские и смежные права от музыкантов к оркестру в обмен на фиксированную годовую компенсацию, был оспорен. Музыканты утверждали, что это нарушает их права, гарантированные Директивами ЕС, включая Директиву о едином цифровом рынке (DSM Directive).

Суд ЕС (CJEU) вынес решение в пользу музыкантов, заявив, что национальное законодательство не может автоматически передавать права без явного согласия и справедливого и пропорционального вознаграждения. Это решение обязывает компании в ЕС пересмотреть свои трудовые договоры и системы вознаграждения.

Дело о Medsenger (дело № А40-202764/2018) четко показало: именно работодатель обязан доказывать, что в служебные обязанности работников в принципе входило создание каких-то программ и на этот счет у него должны иметься все необходимые документы.

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

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

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

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

Я действительно полагаю, что успешный IT-бизнес строится на двух столпах:

Чтобы помочь вам правильно выстроить все процессы, я подготовил детальный, пошаговый "Чек-лист для IT-фаундера: оформление РИД от найма до сделки".

Скачайте чек-лист, чтобы избежать ошибок и пройти Due Diligence инвестора без единого красного флага. Он уже доступен в моем телеграм-канале "Юрист без багов".

Нет, User Stories сами по себе не имеют юридической силы. Это краткое и емкое описание желаемой функции с точки зрения пользователя. Но корректное юридическое описание их роли в процессе разработки в трудовом договоре и внутренних политиках позволит в любой момент времени связать ваши реальные инструменты разработки и "цифровые следы" в них с конкретным автором и продуктом также как бумажное техническое задание (ТЗ) или служебное задание.

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

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

Да, согласно Гражданскому кодексу РФ (ст. 1295), работодатель обязан выплатить вознаграждение за служебное произведение, если использует его или распоряжается им. Размер и порядок выплаты определяются договором между сторонами. Отсутствие такой выплаты может стать основанием для оспаривания прав на РИД со стороны автора или как минимум он сможет требовать выплатить это вознаграждение и установить его "справедливый" размер в судебном порядке.

Акт приема-передачи (или отчет о выполнении служебного задания) - это двусторонний документ, который фиксирует факт перехода прав на РИД. Он должен содержать название документа, индивидуальные признаки РИД, ссылку на служебное задание или договор, в рамках которого был создан РИД, а также подписи уполномоченных лиц и разработчиков. В случае, если вы сконструировали свои документы таким образом, что в качестве служебных заданий у вас используются "цифровые следы" из реальных средств разработки - акт приема-передачи (отчет) может быть привязан к merge в них. Однако, рекомендуется параллельно дублировать этот документ на бумажном носителе для нужд бухгалтерской службы и проверяющих органов.

#ip #служебноепроизведение #стартапы #интеллектуальнаясобственность