Как программисты уносят IT-бизнес в кармане: гайд по оформлению служебных произведений в 2026 году

Представьте классический кошмар фаундера: компания нанимает команду удаленщиков, они пишут ядро инновационной платформы. Через год проект взлетает, приходят инвесторы, готовится крупный раунд. И вдруг ведущий разработчик заявляет: "Вообще-то, весь исходный код написан мной. Права на него принадлежат мне. Хотите использовать дальше? Платите роялти или я забираю софт, увольняюсь и открываю точно такой же проект-конкурент".

Инвесторы в панике разворачиваются, раунд сорван, бизнес парализован. На языке закона этот ад называется отсутствием надлежащего оформления прав на служебные произведения (ст. 1295 ГК РФ).

Многие владельцы IT-компаний и онлайн-школ до сих пор живут в опасной иллюзии: "Я же плачу ему зарплату (или фикс по договору), значит, всё автоматически принадлежит мне". Вынуждена вас разочаровать - в интеллектуальном праве это так не работает. Давайте пошагово разберем, почему трудовой договор не защищает ваш код, и как выстроить железную систему безопасности, которую одобрит любой суд.

Главный миф бизнеса: "Я плачу деньги — код мой".

Российское законодательство по умолчанию стоит на стороне автора - то есть того, чьим творческим трудом создан софт (ст. 1257 ГК РФ). Чтобы исключительные права автоматически перешли от программиста к компании, объект должен получить статус служебного произведения.

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

Чтобы не остаться у разбитого корыта, вам нужно настроить внутренний документооборот из 4 обязательных шагов.

Шаг 1. Наводим порядок в трудовом договоре и должностной инструкции

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

Как надо: В трудовом договоре и должностной инструкции должно быть прямо и недвусмысленно зафиксировано: "В обязанности сотрудника входит создание программного обеспечения, написание исходного кода на языках (перечислить) и разработка архитектуры баз данных".

Шаг 2. Оформляем служебное задание.

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

• Как надо: Каждая задача должна иметь цифровой или бумажный след. Идеальный вариант - внедрить в компании локальный нормативный акт (ЛНА) о порядке создания служебных произведений.

• В этом ЛНА вы жестко прописываете, что постановка задач в вашем таск-трекере (Jira, Яндекс-трекер и т.д.) приравнивается к выдаче официального служебного задания. В таске должно быть четко видно: кто поставил задачу, кому, и какое техническое задание к ней прилагается.

Шаг 3. Фиксируем акт приема-передачи результатов.

Код написан, задача закрыта. Теперь права нужно физически "забрать" на баланс компании.

• Как надо: Разработчик должен официально передать результат работы. На практике это оформляется актом приема-передачи служебного произведения.

В акте нельзя писать размытые фразы вроде "программист передал результаты работы за сентябрь". Нужна жесткая конкретика: "Сотрудник передал, а Работодатель принял исключительные права на модуль ”название” (исходный код на языке (язык) в объеме Х строк, размещенный в корпоративном репозитории по адресу: .... "). Только такая связка намертво привязывает конкретный код к вашей компании.

Шаг 4. Взрывоопасный нюанс: Авторское вознаграждение (ст. 1295 ГК РФ).

Это самая частая и фатальная юридическая ошибка 90% молодых IT-компаний в России, на которой опытные юристы пачками топят фаундеров в судах.

Закон разделяет понятия "заработная плата" и "авторское вознаграждение". Зарплату вы платите за то, что человек выполняет трудовую функцию (сидит за компьютером с 9 до 18). А за то, что в процессе этого сидения родился ценный нематериальный актив (код, архитектура, дизайн), вы обязаны выплатить ему авторское вознаграждение сверх зарплаты.

Как НЕ надо: Если вы включите эту сумму внутрь оклада (например, напишете в трудовом договоре: ”оклад 200 000 рублей, включая авторское вознаграждение”), суд с высокой долей вероятности признает это условие ничтожным, так как невозможно выделить конкретную стоимость созданного объекта интеллектуальных прав.

Правильное решение: При передаче кода по акту (Шаг 3) издается приказ о выплате авторского вознаграждения. Это может быть любая фиксированная сумма, которая проходит в расчетном листке отдельной строкой: "Авторское вознаграждение за создание служебного произведения по приказу №...". Наличие этих выплат полностью лишает программиста возможности оспорить переход прав в будущем.

Вывод:

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

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

Успехов в бизнесе!

Об авторе: Юрист по интеллектуальной собственности (IP/IT Law). Экс-руководитель судебной практики. Старший юрист в международной консалтинговой компании. Специализируюсь на аудите нематериальных активов и судебной защите IT-бизнеса.