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

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

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

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

Юридическая природа отчуждения: почему передача кода не равна передаче прав

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

Здесь полезно разделить три режима.

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

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

Договор об отчуждении исключительного права регулируется статьёй 1234 ГК РФ. Его письменная форма обязательна. Счёт, платёжное поручение, акт выполненных работ или письмо «передаём все права» могут быть полезны как доказательства фактических отношений, но не всегда заменяют корректно сформулированное основание перехода права.

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

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

Договор об отчуждении исключительного права: обязательные условия и цена сделки

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

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

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

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

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

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

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

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

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

Специфика ПО, созданного по заказу: презумпция прав заказчика и лицензионные оговорки исполнителя

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

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

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

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

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

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

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

Поэтому заказчику стоит отдельно решить, что именно он хочет закрыть.

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

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

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

Регистрация перехода прав в Роспатенте: когда это необходимо и сколько стоит

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

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

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

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

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

Для зарегистрированной программы регистрация перехода — не декоративная публикация. Без записи в реестре смена правообладателя не завершена.

Технический периметр сделки: что, кроме кода, должно перейти к заказчику

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

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

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

Обычно в него включают:

• репозитории с исходным кодом, историей изменений, ветками и релизными тегами;
• инструкции по локальному запуску, сборке, тестированию и развёртыванию;
• архитектурную документацию, описание API, схемы интеграций;
• конфигурации CI/CD и права на изменение пайплайнов;
• инфраструктуру как код, если среда описана через Terraform, Pulumi, CloudFormation или аналогичные инструменты;
• базы данных, миграции, дампы и порядок восстановления;
• домены, DNS-зоны, TLS-сертификаты и почтовые настройки;
• учётные записи в облаках, системах мониторинга, аналитики, рассылок и CDN;
• дизайн-макеты, графику, иконки, тексты и иные ассеты;
• реестр внешних зависимостей и лицензий.

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

Репозиторий — не всегда весь исходный код

В Git-репозитории может лежать только прикладной слой. Сборка при этом зависит от закрытого пакета, приватного registry, внутреннего шаблона CI или скрипта, который никогда не попал в версионный контроль. Внешне передача выглядит полной, но новая команда получает проект, который не собирается.

Поэтому оформление передачи прав на исходный код стоит сопровождать проверкой воспроизводимости:

1. Заказчик или новая команда получает доступ в собственном контуре.

2. Разворачивает продукт по переданной инструкции.

3. Собирает релиз из переданного исходного кода.

4. Прогоняет согласованный набор критических сценариев.

5. Фиксирует обнаруженные исключения: отсутствующие секреты, закрытые зависимости, платные аккаунты, лицензии третьих лиц.

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

Облако, домены и внешние сервисы

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

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

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

Open source, дизайн и чужие права

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

В реестре зависимостей полезно отразить:

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

Отдельно нужно проверить дизайн и контент. Макеты в Figma, иллюстрации, фото, шрифты, тексты интерфейса и рекламные материалы — самостоятельные объекты. Если их создавали сотрудники подрядчика, субподрядчики или сторонние авторы, заказчику важно понимать цепочку прав. Общая фраза о передаче прав на «ПО» не обязательно охватывает весь визуальный и контентный слой продукта.

Где заказчики чаще всего теряют контроль

Самая распространённая ошибка — искать один универсальный документ, который автоматически решит все вопросы. Такого документа нет. Набор зависит от модели разработки, статуса программы в Роспатенте, состава команды, сторонних зависимостей и того, что именно заказчик хочет получить: правообладание, возможность эксплуатации или оба результата одновременно.

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

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

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

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