Кому принадлежат права на программу для ЭВМ: работодателю, заказчику или разработчику

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

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

Почему вопрос о правах на код нельзя оставлять «на потом»

Программа для ЭВМ часто становится ядром бизнеса: обеспечивает работу мобильного приложения, CRM-системы, личного кабинета, онлайн-платформы, внутреннего сервиса или производственного процесса. Если исключительное право не оформлено, компания рискует потерять управляемость продуктом.

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

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

Автор, правообладатель и пользователь: в чём разница

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

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

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

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

Кому принадлежат права на программу для ЭВМ в разных ситуациях

Программу создал штатный сотрудник

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

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

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

Программу разработал подрядчик по договору заказа

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

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

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

ПО появилось при оказании услуг или выполнении работ

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

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

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

Программу написал фрилансер или сам автор

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

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

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

Над продуктом работали несколько разработчиков

В сложном IT-проекте одна программа редко создаётся одним человеком. Над продуктом могут работать штатные сотрудники, студия разработки, отдельные фрилансеры, специалисты по интерфейсу, DevOps-инженеры и консультанты. У каждого из них может быть свой вклад — а значит, и отдельный вопрос о правах.

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

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

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

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

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

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

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

Какие условия нужно включить в договор на разработку ПО

Договор на разработку ПО должен отражать не только сроки, стоимость и порядок оплаты, но и судьбу каждого значимого результата проекта. Универсального шаблона здесь нет: условия зависят от модели работы, числа участников, типа продукта, используемых технологий и дальнейших планов бизнеса.

Как описать результат разработки

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

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

Как закрепить передачу исключительных прав

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

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

Как оформить передачу исходного кода и доступов

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

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

Как урегулировать использование прежних наработок и open source

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

В договоре стоит разделить новые результаты, созданные специально для проекта, и прежние наработки исполнителя. Для вторых необходимо определить объём лицензии: какие права получает заказчик, может ли он передавать продукт, дорабатывать его и продолжать использование после прекращения договора.

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

Как подтвердить права на программу для ЭВМ

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

В такой архив обычно входят:

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

Регистрация программы для ЭВМ добровольна, но позволяет зафиксировать сведения о программе и правообладателе в официальном реестре. При этом она не заменяет договоры: Роспатент не устанавливает бесспорное авторство и не проверяет всю цепочку перехода исключительных прав. Поэтому сначала стоит привести в порядок документы, а затем решать вопрос о регистрации.

Что делать, если права на код не оформлены

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

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

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

Как URVISTA помогает оформить права на ПО

У каждого IT-проекта своя история: часть кода могли создать сотрудники, часть — подрядчики, а ранняя версия продукта могла появиться ещё до учреждения компании. Поэтому работа с правами на программу для ЭВМ должна начинаться с тщательного и конфиденциального анализа, а не с шаблонного договора.

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

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