Кому принадлежат права на код: заказчику, разработчику или сотруднику

Автором кода всегда остаётся человек, который создал его творческим трудом. Компания не становится автором, даже если оплатила работу. Зато исключительное право — то есть возможность использовать код и распоряжаться им — может принадлежать компании.

По общему правилу исключительное право первоначально возникает у автора, а затем переходит по договору или по основанию, установленному законом (статья 1228 ГК РФ). Отсюда разные ответы для разных маршрутов:

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

Поэтому вопрос «чей код?» корректнее задавать так: у кого исключительное право на определённую версию и какими документами подтверждён каждый переход.

Ниже — редакционная модель проверки, а не термин из закона. Она помогает не подменять право собственности на сервер или долю в компании правом на программу.

1. Люди. Какие физические лица вносили творческий вклад? Директор, заказчик и владелец аккаунта GitHub не становятся авторами только потому, что организовали работу.
2. Версия. Какой именно код проверяется: ранний прототип, ядро, клиентская надстройка, отдельная ветка или текущий production? Документы на первую версию могут ничего не говорить о последующих доработках.
3. Основание перехода. Почему исключительное право оказалось у следующего участника цепочки: служебный характер, авторский заказ, отчуждение, договор на создание программы или лицензия? Когда именно произошёл переход — при создании, оплате, приёмке или подписании отдельного акта?
4. Компоненты и контроль. Какие части написаны специально, какие существовали раньше, какие взяты по open-source или коммерческой лицензии? У кого находятся репозитории, исходники, ключи, документация и резервные копии?

Если хотя бы одна связь не подтверждается, утверждение «все права у компании» требует проверки.

Для сотрудника полезно отдельно проверить документы о служебных произведениях, для физлица-исполнителя — правила договора авторского заказа. Это разные правовые маршруты, и одна универсальная оговорка их не заменяет.

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

1. TeamJet: работодатель связал кадровые документы с историей кода

В деле № А40-144779/2022 две стороны спорили о правах на близкие программные продукты TeamJet и Teamatix. Работодатель представил не один пункт трудового договора, а набор взаимосвязанных доказательств: приказ о начале разработки, трудовые договоры и должностные инструкции, документы о составе команды, оплате труда и историю репозиториев. Экспертиза сопоставляла код спорных продуктов.

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

Источники: официальная карточка дела № А40-144779/2022, постановление 9-го ААС от 11 октября 2024 года № 09АП-55254/2024 (копия судебного акта для чтения).

Что это меняет для бизнеса. Сильная позиция возникает, когда юридическая история совпадает с технической: конкретные люди, их обязанности и даты должны соединяться с ветками, коммитами и версиями. Название должности «разработчик» и доступ к корпоративному Git сами по себе такую связь не создают.

2. Medsenger: трудовых отношений и ресурсов компании оказалось недостаточно

В деле № А40-202764/2018 прежний работодатель пытался доказать права на медицинскую информационную систему Medsenger, в создании которой участвовал его бывший сотрудник вместе с другими разработчиками. Суды исследовали, было ли создание программы конкретной служебной работой и перешёл ли результат работодателю.

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

Источник: официальный PDF постановления СИП от 1 августа 2019 года по делу № А40-202764/2018.

Что это меняет для бизнеса. TeamJet и Medsenger дают противоположные результаты не потому, что в одном случае программист был сотрудником, а в другом — нет. Разница в доказуемости маршрута конкретного кода. Верховный Суд отдельно разъяснил: работодатель доказывает и содержание трудовых обязанностей, и создание произведения в их пределах; использование материалов работодателя само по себе не делает произведение служебным (пункт 104 постановления Пленума ВС РФ № 10).

3. GRACE: право на клиентскую надстройку не обязательно охватывает старое ядро

В деле № А40-148486/2022 заказчик требовал компенсацию, полагая, что разработчик передал третьему лицу созданную для него CRM-систему GRACE. В договоре и материалах спора разграничивались программные решения, разработанные специально для заказчика, и ранее существовавшая часть решения, которую разработчик мог использовать повторно.

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

Источники: официальная карточка дела № А40-148486/2022, постановление 9-го ААС от 10 августа 2023 года № 09АП-40821/2023 (копия судебного акта для чтения).

Что это меняет для бизнеса. Фраза «все права на программу переходят заказчику» не отвечает на вопрос, что стороны назвали программой. Готовое ядро, библиотеки и специальные доработки нужно перечислить в техническом приложении: версия, репозиторий, ветка или релиз, контрольная сумма, назначение компонента и режим прав. Иначе даже экспертиза сходства может не показать, чьё именно право нарушено.

4. Boom Boom: исключительное право перешло, но исходники остались у подрядчика

В деле № А45-26234/2022 подрядчик разработал мобильное приложение Boom Boom. Работы считались принятыми, а исключительное право перешло заказчику. При этом исходный код заказчик не получил: он оставался в репозиториях GitHub, которыми управлял разработчик.

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

Источники: официальная карточка дела № А45-26234/2022, постановление СИП от 18 июля 2023 года № С01-1130/2023 (копия судебного акта для чтения), определение ВС РФ от 15 ноября 2023 года № 304-ЭС23-21662.

Что это меняет для бизнеса. Переход исключительного права и передача рабочего комплекта — разные события. В договоре и акте стоит отдельно перечислять исходный код, историю коммитов, зависимости, документацию, сборочные инструкции, ключи, учётные записи, экспорт и резервную копию. Вывод суда о GitHub нельзя переносить на любое закрытое хранилище: значение имели условия конкретного договора, доказательства доступа и оценённые судом правила сервиса.

Четыре спора дают не четыре разрозненных совета, а одну модель.

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

Именно поэтому качественный аудит начинается не с поиска договора с фразой «все права переданы», а с карты продукта:

автор → конкретная версия → основание перехода → текущий правообладатель → место хранения и режим компонентов.

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

Если код создавали разные люди или команды

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

Оплата разработки

Оплата подтверждает расчёты, но момент перехода права определяется законом и условиями договора. Иногда суд признаёт переход и без последней подписи, если доказаны предусмотренные договором оплата и передача результата — такой вывод, например, сделан по обстоятельствам дела № А72-7169/2017. Но превращать это в правило «акт никогда не нужен» нельзя.

Владение репозиторием или сервером

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

NDA

Соглашение о конфиденциальности запрещает раскрывать определённую информацию. Оно не заменяет условие об отчуждении права, лицензию или правила о служебном произведении.

Акт без идентификации результата

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

Свидетельство о регистрации программы

Государственная регистрация программы для ЭВМ проводится по желанию правообладателя. Сведения реестра важны для доказательств и сделок с зарегистрированным объектом, но не устраняют спор о том, кто фактически создал код и как право перешло. Регистрация программы в Роспатенте — отдельный шаг, а не замена цепочки.

Статус основателя, участника или директора

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

За полчаса нельзя дать полноценное юридическое заключение, но можно понять, где искать разрыв.

0–5 минут: зафиксируйте объект. Запишите production-версию, основные репозитории, релиз или commit hash, мобильные сборки, серверную часть и документацию. Не используйте только внутреннее название продукта.

5–10 минут: выгрузите участников. Составьте список людей из истории коммитов, проектных чатов и актов. Отдельно отметьте основателей до создания компании, бывших сотрудников, фрилансеров и субподрядчиков.

10–15 минут: присвойте каждому основание. Сотрудник, физлицо по ГПХ, автор по договору заказа, сотрудник подрядчика, субподрядчик. Если статус неизвестен, это уже пробел.

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

20–25 минут: отделите компоненты. Отметьте готовое ядро, open-source-библиотеки, платные SDK, код клиента, приобретённые модули и элементы, созданные с использованием генеративных инструментов. Для сторонних компонентов нужна не передача исключительного права, а понятная лицензия и соблюдение её условий.

25–30 минут: проверьте контроль. У компании должны быть административные доступы, экспорт репозитория, сборочные инструкции, ключи и резервные копии. Результат экспресс-проверки — не ответ «права есть», а таблица разрывов с приоритетом.

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

Обычно восстановление цепочки состоит из нескольких честно датированных действий:

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

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

Если вид разрыва уже понятен

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

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

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

Та же цепочка документов нужна перед включением в реестр российского ПО: заявитель должен подтвердить право на продукт в требуемом объёме.

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

• продукт создавался до учреждения компании или переходил между несколькими юрлицами;
• среди авторов есть бывший сооснователь, сотрудник, фрилансер или неизвестный субподрядчик;
• договоры и акты нельзя связать с текущей production-версией;
• готовое ядро, заказные доработки и сторонние компоненты документально не разделены;
• исключительное право формально передано, но репозиторий, ключи или исходники остаются у другой стороны;
• предстоят инвестиции, продажа продукта, лицензирование или IP due diligence;
• уже возникли претензии об авторстве, копировании или повторном использовании кода.

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

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

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

Если отношения только оформляются и речь идёт об одном новом договоре, можно начать с автоматической проверки:

• внутренняя команда — трудовой договор и IP-условия;
• фрилансер или подрядчик — договор подряда;
• заказная разработка продукта — договор разработки ПО.

Если продукт уже создан несколькими участниками, содержит прежнее ядро или готовится к инвестициям либо продаже, проверка отдельного договора не даст полного ответа. В этом случае нужен IP-аудит: сопоставить авторов, правообладателей, версии, договоры, акты, сторонние компоненты и фактический контроль над исходниками. Результат — реестр активов, карта рисков и дорожная карта оформления прав.

Обсудить IP-аудит цепочки прав на код

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