Определить состав и версию продукта
Проверка начинается не с названия компании и не с одной папки исходного кода, а с описания конкретного программного продукта. Нужно установить версию, архитектуру, модули, интерфейсы, базы данных, документацию, инфраструктуру, внешние сервисы и материалы, без которых продукт не может использоваться по назначению.
Коммерческий продукт обычно включает несколько правовых слоёв: код, базы данных, дизайн, контент, документацию, обозначения и договорные доступы. Право на один элемент не означает автоматического контроля над остальными.
Версию фиксируют потому, что авторы, компоненты и лицензии меняются. Нужны карта модулей, история релизов и связь между юридическими документами и фактически используемым кодом.
Отдельно описывают, что разворачивается на стороне клиента, а что остаётся на серверах правообладателя. Доступ к SaaS-сервису не всегда означает предоставление экземпляра программы или передачу исходного кода. Договорная модель может включать удалённый доступ, услуги, лицензионные элементы, хранение данных и техническую поддержку.
| Компонент | Возможный создатель или источник | Какое право или основание нужно проверить | Основное доказательство | Типичное ограничение |
|---|---|---|---|---|
| Собственный исходный код | Работники, подрядчики, учредители | Исключительное право и личные права авторов | Трудовые и гражданские договоры, задания, акты, история репозитория | Неопределённый объект или отсутствующая передача права |
| База данных | Разработчики, аналитики, поставщики данных | Права на структуру, материалы и право изготовителя базы при наличии условий | Схема базы, источники данных, договоры, подтверждение затрат | Права третьих лиц и персональные данные |
| Интерфейс и дизайн | Дизайнер или агентство | Авторское право и допустимые способы переработки | Техническое задание, исходные файлы, договор и акт | Передан макет, но не исключительное право |
| Сторонняя библиотека | Внешний правообладатель или сообщество | Лицензия на конкретную версию | Текст лицензии, уведомления, перечень зависимостей | Условия распространения и совместимость лицензий |
| Облачная платформа или API | Поставщик сервиса | Договор доступа и правила использования | Условия сервиса, аккаунт, платёжные документы | Зависимость от внешней платформы и запрет передачи аккаунта |
Установить авторов и правообладателя
Автором программы является человек, творческим трудом создавший код или иной охраняемый элемент. Юридическое лицо не становится автором, но может приобрести или получить исключительное право по закону или договору.
Для каждого автора устанавливают период работы, статус, конкретный вклад и основание, по которому право должно принадлежать компании. Должность «разработчик», корпоративный ноутбук и выплата зарплаты сами по себе недостаточны. Проверяются трудовая функция, должностные обязанности, служебное задание, дата создания, передача результата и действия работодателя после получения результата.
Правила о служебном произведении применяются только при наличии трудовых отношений и связи создания результата с трудовыми обязанностями или конкретным заданием. Исключительное право работодателя и право автора на предусмотренное законом вознаграждение являются разными вопросами. Нельзя закрывать оба вопроса одной ссылкой на заработную плату без анализа применимой нормы и обстоятельств.
По подрядчикам сначала определяется вид договора и цель создания программы. Для произведения, созданного по заказу, и результата, появившегося при выполнении договора, который прямо не предусматривал его создание, действуют разные специальные нормы. Формула «все права принадлежат заказчику» не помогает, если невозможно определить код, версию, документацию, сторонние компоненты и момент перехода.
Нужно учитывать субподрядчиков и прежних работодателей разработчиков. Исполнитель не может передать заказчику больше прав, чем имеет сам. Если часть кода создана третьим лицом без надлежащего оформления, последующий договор с основной студией не исправляет этот разрыв автоматически.
Проверить договоры и момент перехода права
В договорной цепочке разграничивают отчуждение исключительного права, лицензию, создание программы по заказу, разработку в составе работ или услуг и предоставление доступа к сервису. У этих моделей разные предметы и правовые последствия.
По договору об отчуждении исключительное право переходит к приобретателю в полном объёме; объект и момент перехода определяются с учётом специальных правил. По лицензионному договору правообладатель сохраняет исключительное право и предоставляет только прямо согласованные способы использования. При простой (неисключительной) лицензии лицензиар может выдавать лицензии другим лицам; при исключительной — не вправе предоставлять другим лицам право использования в пределах выданной лицензии, если договором не предусмотрено иное. Коммерческое слово «эксклюзивный» не заменяет юридическое определение вида лицензии.
В документах описывают программу или модуль, версию и состав материалов; авторов и сторонние компоненты; исходный и объектный код; документацию; способы использования; территорию и срок лицензии; право на модификацию; вознаграждение; момент перехода; порядок передачи репозитория и доступов; гарантии по правам третьих лиц; последствия претензий и дальнейшие доработки.
Для возмездного отчуждения и лицензии вопрос вознаграждения проверяется по специальным требованиям ГК РФ. Общая цена проекта не всегда позволяет определить плату за распоряжение исключительным правом. Формулировка должна соответствовать выбранной модели и не создавать риск незаключённости договора.
Акт приёмки подтверждает передаваемые результаты в пределах своего содержания, но не заменяет условие о переходе права. Передача файла или репозитория не равна отчуждению исключительного права. Обратная ситуация также возможна: договор предусматривает переход права, но заказчик не получил необходимые доступы, ключи, инструкции и среду для эксплуатации.
| Документ или событие | Что оно может подтвердить | Что оно не подтверждает автоматически |
|---|---|---|
| Договор разработки | Предмет, обязанности, распределение прав и условия передачи | Фактическое создание каждого модуля и отсутствие сторонних компонентов |
| Акт | Приёмку перечисленных результатов и дату передачи | Переход права, если это не следует из закона и условий договора |
| Оплата | Исполнение денежной обязанности | Отчуждение исключительного права без надлежащего основания |
| Доступ к репозиторию | Техническую возможность получить код | Авторство, правообладание и полноту переданных компонентов |
| Лицензионный договор | Разрешённые способы использования | Право пользователя отчуждать программу как собственную |
Подтвердить технический контроль и доказательства
Юридические документы сопоставляют с фактической разработкой. Репозиторий, история коммитов, системы задач, релизы, переписка и переданные файлы помогают установить вклад авторов и состав продукта, но каждый источник имеет границы доказательственной силы.
Репозиторий показывает техническую историю, если доступны исходные данные о пользователях, времени и изменениях. Ник в системе не всегда идентифицирует автора, а один коммит может включать чужой код или автоматическую сборку. Поэтому историю сопоставляют с трудовыми документами, заданиями, перепиской и показаниями систем контроля доступа.
Компания должна контролировать аккаунты, домены, сертификаты, облачную инфраструктуру, сборку и выпуск обновлений. Формальное право на код не гарантирует возможность поддерживать продукт, если технические средства остались у исполнителя.
Документация важна и как часть результата, и как средство эксплуатации. Проверяются архитектурное описание, инструкции по развёртыванию, зависимости, схема базы, резервное копирование, требования к среде и порядок обновления. Отсутствие документации может не лишать права на код, но снижает управляемость продукта и усложняет доказательство его состава.
При передаче продукта фиксируют контрольные суммы или иные идентификаторы версии, перечень файлов и зависимостей, дату передачи, состояние репозитория и доступы. Эти меры не создают исключительное право, но связывают юридический документ с определённым техническим объектом.
Разобрать сторонние компоненты и open source
Open source означает использование по условиям открытой лицензии, а не отсутствие правообладателя. Для каждой зависимости проверяются название, версия, источник, текст лицензии, способ включения в продукт, распространение, модификация, уведомления и совместимость с другими условиями.
Сторонние компоненты не ограничиваются библиотеками. В продукт могут входить коммерческие SDK, шрифты, изображения, карты, модели машинного обучения, API, контейнеры, операционные системы и код из публичных репозиториев. Разработчик не вправе передать заказчику исключительное право на такие элементы, если сам его не имеет.
Условия открытых лицензий различаются. Одни требуют сохранить уведомления и текст лицензии, другие связывают распространение модифицированной или производной версии с предоставлением исходного кода на определённых условиях. Вывод зависит от конкретной лицензии, версии компонента и способа технического взаимодействия. Нельзя делать общий вывод по словам «бесплатная библиотека» или «используется только внутри сервера».
Практический результат проверки — реестр зависимостей, который связывает компонент, версию, источник, лицензию, место использования и выполненные обязанности. Автоматический сканер помогает найти зависимости, но не заменяет правовую проверку и может пропустить вручную добавленные материалы.
Для реестра российского ПО иностранное происхождение отдельной библиотеки не означает автоматический отказ. Проверяются действующие критерии, роль компонента, права на него, возможность модификации и эксплуатации продукта, выплаты иностранным лицам и дополнительные требования к соответствующему классу программного обеспечения.
Отделить регистрацию программы в Роспатенте
Государственная регистрация программы для ЭВМ или базы данных в Роспатенте является добровольной процедурой. Авторское право возникает в силу создания программы, а запись в реестре не создаёт авторство и не заменяет документы о законном переходе исключительного права.
При подаче заявитель сообщает сведения о программе, авторах и правообладателе и представляет предусмотренные материалы. Ведомство не проводит патентную экспертизу новизны кода и не восстанавливает отсутствующие договоры с работниками или подрядчиками. Если заявитель не приобрёл право законно, регистрационная запись не устраняет возможность разногласия.
Регистрация может использоваться как один из элементов фиксации сведений о программе и правообладателе, в сделке, лицензировании или доказательственной системе. Её полезность зависит от того, соответствует ли запись актуальной версии продукта и непротиворечива ли она остальным документам.
Программа для ЭВМ и техническое решение, реализованное программными средствами, не являются одним объектом охраны. Код охраняется авторским правом. Возможность патентования технического решения оценивается по отдельным критериям и не сводится к регистрации «идеи приложения».
Перед подачей проверяются действующая форма, требования к материалам, пошлины и способ взаимодействия с Роспатентом. Эти параметры изменяются и не должны переноситься из старой инструкции без актуализации.
Проверить требования реестра российского ПО
Единый реестр российских программ для ЭВМ и баз данных создаётся по правилам постановления Правительства РФ № 1236 и решает регуляторную задачу, отличную от регистрации программы в Роспатенте. Включение в реестр не создаёт исключительное право и не подтверждает автоматически отсутствие прав третьих лиц.
Подготовка начинается с выбора категории программного обеспечения и проверки действующих критериев к правообладателю, корпоративной структуре, исключительному праву, выплатам иностранным лицам, компонентам, документации, установке, эксплуатации, обновлению и иным параметрам. Для отдельных классов могут действовать дополнительные требования.
Правила изменяются. Постановление Правительства РФ от 28 ноября 2025 года № 1937 изменило регулирование реестров и предусмотрело поэтапное применение отдельных требований. Поэтому вывод о готовности продукта нельзя основывать на старом чек-листе: перед подачей сверяются действующая редакция постановления № 1236, документы оператора, классификатор и требования именно к выбранному классу.
Сайт, документация и демонстрация должны описывать тот же продукт и версию, что указаны в заявлении.
Включение в реестр не означает автоматического получения налоговой льготы, государственной IT-аккредитации, допуска к любой закупке, сертификата информационной безопасности или права работать с государственной тайной. Каждая мера имеет самостоятельные условия, а закупочные ограничения зависят от конкретного режима и предмета закупки.
| Проверяемая зона | Что подтвердить перед подачей | Почему требуется актуализация |
|---|---|---|
| Категория ПО | Функциональность и выбранный класс по действующему классификатору | Классификатор и дополнительные требования меняются |
| Правообладатель | Статус, структура контроля и исключительное право | Критерии относятся к конкретному заявителю и могут включать специальные условия |
| Компоненты | Состав продукта, лицензии, иностранные зависимости и выплаты | Оценка зависит от роли компонента и действующей редакции правил |
| Документация | Установка, эксплуатация, обновление, поддержка и описание функций | Требования различаются по классу и процедуре |
| Последующие изменения | Новая версия, правообладатель, компоненты и существенные свойства | Включённый продукт требует поддержания актуальных сведений и соответствия |
Нужна помощь по теме «Интеллектуальная собственность»?
Связанная услуга: Юрист по интеллектуальной собственности и IT
