Покупатель готов обсуждать внедрение, но просит номер программы в реестре российского ПО. У разработчика есть свидетельство Роспатента, команда в России и работающий продукт. Кажется, осталось загрузить несколько документов. На практике это три разных задачи: подтвердить права, описать продукт так, чтобы его можно было проверить, и выполнить требования реестра.
Мы в GLS Expert начинаем с самого продукта и состава правообладателей. Подача через кабинет Минцифры — заключительный этап подготовки, а не способ выяснить по ходу, кому принадлежит код. Ниже разбираем маршрут для самостоятельного программного продукта. Для программно-аппаратного комплекса действуют дополнительные требования: механически переносить на него этот список нельзя.
Как объяснить происхождение ПО через проверяемую цепочку
Разберите четыре вопроса отдельно: кто владеет правами; из чего состоит продукт; как его установить и проверить; кто обеспечивает сопровождение. Российская регистрация компании сама по себе не отвечает на остальные вопросы.
Для каждой существенной функции свяжите описание с реальной демонстрацией. Эксперт должен пройти сценарий по вашей инструкции и увидеть заявленный результат. Если нужны особые данные, роли или настройки, подготовьте безопасный способ проверки без доступа к клиентским секретам.
Отдельно составьте перечень сторонних компонентов и оснований использования. Наличие зарубежного компонента не оценивают по общему лозунгу: проверяют применимые требования к конкретному классу и архитектуре ПО. Документы о правах, сведения о продукте и версия для проверки должны относиться к одному объекту.
Что меняется после включения в реестр
Реестровая запись подтверждает российское происхождение программы в предусмотренном правилами порядке. Это важно для закупок, где заказчик применяет национальный режим, и для отдельных мер поддержки. Но запись сама по себе не заключает контракт, не заменяет ИТ-аккредитацию компании и не даёт универсального освобождения от налогов.
Мы предлагаем заранее назвать коммерческую цель: участие в определённых закупках, выполнение требования клиента или применение конкретного положения налогового законодательства. Тогда можно проверить, помогает ли включение именно в вашей ситуации. Налоговый эффект разбирается отдельно с учётом вида операции и ограничений: наш материал об ИТ-льготах помогает не смешивать эти вопросы.
| Документ или статус | На какой вопрос отвечает | Чего не подтверждает |
|---|---|---|
| Свидетельство Роспатента | Какие сведения о программе зарегистрированы | Соответствие требованиям реестра Минцифры |
| Реестр российского ПО | Включён ли конкретный продукт в российский реестр | Аккредитацию всей компании и право на любую льготу |
| ИТ-аккредитация | Имеет ли организация соответствующий статус | Российское происхождение каждого её продукта |
| Лицензионный договор | Как покупатель вправе использовать программу | Наличие записи в реестре без отдельной проверки |
Шаг 1. Определите, что именно вы включаете
Начните с одной страницы описания. Укажите название, назначение, основные функции, состав модулей, способ поставки, поддерживаемую среду и правообладателя. Название должно совпадать в документах, на сайте, в дистрибутиве и в заявлении либо иметь понятное объяснение различий.
Например, у компании есть платформа управления производством и отдельный модуль планирования. Если модуль невозможно установить и использовать без платформы, нужно разобраться, является ли он самостоятельным продуктом. Десять маркетинговых названий не обязательно означают десять объектов для реестра.
Полезная проверка: дайте описание коллеге, который не участвовал в разработке. Сможет ли он понять, что нужно установить и какой результат получить? Если нет, техническую документацию рано считать готовой.
Шаг 2. Соберите цепочку прав
Для каждой существенной части продукта сводим происхождение к документам. У штатных авторов проверяем трудовые отношения, задания и передачу результатов. У подрядчиков — условия договора, акты, состав переданного кода и режим использования. У приобретённых компонентов — условия лицензии.
Составьте рабочую таблицу:
- компонент и версия;
- кто его создал;
- на каком основании компания использует результат;
- документ, который это подтверждает;
- ограничения на изменение, распространение и передачу заказчику;
- действие, необходимое до подачи.
Открытый исходный код не означает отсутствие условий. Одни лицензии разрешают коммерческое использование с сохранением уведомлений, другие требуют дополнительных действий при распространении производного продукта. Мы проверяем конкретную лицензию и способ использования, а не сам факт наличия библиотеки.
Если часть прав ещё принадлежит основателю или подрядчику, пригодится разбор передачи исключительного права. Одно свидетельство о регистрации программы не устраняет разрывы в договорах.
Шаг 3. Проверьте компанию и зависимости
Правила формирования реестра утверждены постановлением Правительства РФ №1236. Они устанавливают требования к правообладателям, контролю, законности использования программы, иностранным выплатам и техническим условиям. Проверяется реальная структура, включая косвенное участие, а не только адрес регистрации юридического лица.
Базовые условия закреплены также в статье 12.1 закона №149-ФЗ. Для российской коммерческой организации контроль означает право прямо или косвенно распоряжаться более чем 50% голосов со стороны предусмотренных законом российских лиц. Ровно 50% этому условию не соответствует. Исключительное право должно принадлежать допустимому правообладателю на весь мир и весь срок его действия; одной лицензии на чужой продукт недостаточно.
Второй числовой фильтр — связанные с программой выплаты иностранным лицам и контролируемым ими организациям: менее 30% выручки от реализации этой программы, включая предоставление прав, за календарный год. Например, при соответствующей выручке 20 млн рублей выплаты 5 млн дают 25%, а 6 млн — уже 30% и не проходят условие «менее». В расчёт попадают не только роялти: закон охватывает и определённые работы и услуги по разработке, адаптации и модификации. Поэтому состав платежей проверяем по договорам.
Отдельно готовим сведения о выплатах иностранным лицам и связанным с ними организациям в отношении продукта. Не подменяйте предусмотренную правилами выручку от предоставления прав всей выручкой компании. Для сверки нужны расшифровки договоров и бухгалтерских данных за требуемый период, а не оценка «почти всё делаем сами».
Техническую независимость проверяем на практике. Составьте список операционных систем, СУБД, облачных сервисов, средств сборки и внешних API. Для каждого компонента ответьте: что произойдёт, если он станет недоступен? Требования к совместимости и зависимости различаются по классу ПО; обещание «работает везде» без испытаний не помогает.
Шаг 4. Сделайте проверку воспроизводимой
Эксперт должен получить доступ к работающей версии и документации. Ссылки, которые открываются только у разработчика в локальной сети, не решают эту задачу.
- Подготовьте инструкцию установки с версиями зависимостей.
- Опишите вход в систему и тестовые роли без реальных персональных данных.
- Дайте сценарий проверки каждой заявленной функции.
- Проверьте комплект на чистой машине или новом тестовом окружении.
- Зафиксируйте результат, ограничения и контакт технического специалиста.
- Сверьте сведения на публичном сайте: функции, стоимость или порядок её определения, документацию и поддержку.
Допустим, в описании указаны 12 функций, а демонстрационный контур позволяет проверить только 8. Это не «готовность на 67%»: четыре функции остаются без доказательства. Мы составляем перечень недостающих сценариев и закрываем их до подачи, а не рассчитываем объяснить всё на созвоне.
SaaS и устанавливаемая программа: как подготовить проверку
Для облачного продукта важно заранее описать, что именно заявляется в реестр. Веб-интерфейс, серверная часть и сторонние сервисы могут выполнять разные функции. Название SaaS не отвечает на вопросы о правообладателе, составе программы и допустимых зависимостях. Условия реестра проверяем по конкретному продукту и классу ПО.
Ниже — наш порядок подготовки демонстрации. Он помогает собрать материалы для проверки, но не заменяет официальный комплект заявки.
| Вопрос | Облачный продукт | Устанавливаемая версия |
|---|---|---|
| Как начать проверку | Адрес тестового контура, порядок доступа и роли | Дистрибутив, требования к среде и инструкция установки |
| Где выполняются функции | Схема серверной части, размещение и перечень внешних сервисов | Компоненты, СУБД, ОС и настройки окружения |
| Что увидит проверяющий | Тестовые данные и сценарии каждой заявленной функции | Проверяемая сборка и сценарии запуска на чистом окружении |
| Что может помешать | Недоступный API, закрытая роль, истёкший доступ | Отсутствующая лицензия компонента, зависимость или неверная версия |
| Как связать с правами | Правообладатели всех существенных частей и условия использования | Та же проверка прав, включая распространяемые компоненты |
Для тестирования используйте обезличенные или специально созданные данные. Назначьте технического ответственного, который может восстановить доступ и объяснить сценарий. Не включайте пароли, ключи и данные реальных клиентов в публичное описание программы.
Если документация обещает функцию, работающую только через внешний сервис, покажите эту зависимость прямо. Самостоятельно объявлять её допустимой по реестру без проверки требований нельзя. При уже полученном решении начните с разбора отказа во включении, чтобы дорабатывать причину замечания, а не весь комплект наугад.
Как организовать подготовку без бесконечных исправлений
Разделите работу между тремя ответственными. Юрист или специалист по правам собирает договоры; технический руководитель отвечает за дистрибутив и инструкции; финансовый специалист — за структуру владения и необходимые расчёты. Один редактор сверяет итоговые сведения между документами.
Заведите журнал замечаний: вопрос, документ, ответственный, решение, версия. Если изменили состав модулей, проверьте одновременно заявление, описание функций, инструкцию и список зависимостей. Иначе исправление одного файла создаст противоречие в другом.
Срок подготовки зависит от готовности этих блоков. Мы не обещаем включение за фиксированное число дней: отдельно существуют работа команды, рассмотрение заявления, экспертиза и ответы на замечания.
Сколько стоит включение в реестр российского ПО
На 5 октября 2026 года подготовка и сопровождение заявки в GLS Expert стоят от 100 000 ₽. Это стоимость наших работ; она не означает покупку записи в реестре или гарантированное положительное решение. Точную цену определяем после просмотра продукта и имеющихся документов.
| Что влияет на стоимость | Что проверяем до договора |
|---|---|
| Продукт и его модули | Какие функции и компоненты входят в заявляемую программу |
| Документы о правах | Есть ли непрерывная цепочка от разработчиков к правообладателю |
| Технические материалы | Можно ли доработать существующее описание или его нужно готовить с нуля |
| Проверка функциональности | Готова ли среда, в которой можно проверить заявленные возможности |
| Объём сопровождения | Кто подаёт заявление и какие ответы на запросы входят в работу |
Если документы и продукт готовы, а согласованный объём оценён в 100 000 ₽, именно эта сумма составит бюджет сопровождения. При обнаруженных пробелах к ней добавятся только отдельно согласованные работы. Разработка документации с нуля, изменение программы, оформление прав и налоговый анализ автоматически в базовую стоимость не входят. Самостоятельно назначать им цену до проверки материалов было бы неточно.
На странице включения в реестр российского ПО указаны состав услуги и исходные сведения для оценки. Для сравнения подрядчиков запросите одинаковый перечень результатов: проверку готовности, подготовленные документы, заявку и согласованный объём ответов. Отдельно зафиксируйте, кто устраняет технические и юридические замечания.
Частые вопросы
Можно подать заявку без свидетельства Роспатента?
Свидетельство — один из возможных документов, подтверждающих сведения о правах, но не замена всей доказательной базе. Комплект нужно сверять с текущими правилами и формой заявления: договоры и внутренние документы часто важнее наличия красивого сертификата.
Российский сервер автоматически делает программу российской?
Нет. Место размещения — лишь одна характеристика. Проверяются правообладатель, происхождение прав, зависимости и остальные условия.
Что делать после включения?
Сохранить решение и реестровый номер, проверить корректность записи, поддерживать актуальность сведений. Изменение правообладателя, названия, состава продукта или условий предоставления может потребовать уведомления и обновления документов.
Для уже включённой программы отдельно разберите порядок изменения сведений в реестре российского ПО: у переименования, сведений о правообладателе и ежегодного уведомления разные процедуры и сроки.
С чем прийти к нам
Для первого разбора достаточно описания продукта, структуры владения, списка разработчиков и подрядчиков, перечня зависимостей и имеющихся документов. Мы поможем составить карту недостающих подтверждений и порядок подготовки. Начать можно с подготовки заявки в реестр российского ПО, а техническую и договорную части затем вести по одному согласованному списку.
На какие документы мы опираемся
Параметры и формулировки проверены 28 сентября 2026 года: Минцифры: реестр и официальная инструкция; Статья 12.1 закона №149-ФЗ, действующая редакция с 01.09.2026. Суммы и сроки относятся к указанной программе или редакции документа. Перед заявкой сверяем действующие условия и конкретную ситуацию компании.
Практический состав технической части разобран отдельно: как подготовить документацию для реестра российского ПО. Материал помогает описать запуск, функции, поддержку, сборку и проверить согласованность с экземпляром программы.
