Как мы включили HConfig в реестр российского ПО: опыт Энсайн

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

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

Так мы решили включить HConfig в Единый реестр российских программ для электронных вычислительных машин и баз данных, который обычно называют реестром российского ПО или реестром Минцифры.

Первую заявку мы подали 24 октября 2025 года. Дальше последовали 2 отказа, доработка юридической документации, проверка архитектуры и несколько месяцев работы. 17 апреля 2026 года HConfig был включен в реестр российского ПО под номером 32983.

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

 

Зачем мы решили включить HConfig в реестр российского ПО

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

На практике процесс оказался значительно глубже.

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

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

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

 

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

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

Заявку отклонили.

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

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

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

 

Вторая попытка: проблема с правообладателями

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

Причиной стала структура прав на HConfig.

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

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

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

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

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

 

Какие документы пришлось дорабатывать

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

Специалист помог разобрать заявку и указал, каких сведений не хватает.

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

У HConfig появилась полноценная документальная история: от создания программного обеспечения и оформления прав до постановки на учет и эксплуатации.

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

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

 

Техническая проверка HConfig

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

Одним из важных вопросов стал используемый стек. Нам пришлось подробно описывать применение Python и отдельных модулей, работу с репозиториями операционной системы и зависимости продукта. Часть компонентов потребовала пересмотра.

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

Для нас здесь было важно нативное взаимодействие с РЕД ОС 8. Эксперту требовалось понимать, как продукт устанавливается и функционирует именно в заявленной конфигурации.

 

Что происходит с программой без доступа в интернет

Еще один практический вопрос касался эксплуатации в изолированной инфраструктуре.

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

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

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

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

 

Почему README оказалось мало

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

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

Для внешней проверки такой подход не подходит.

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

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

Если ответ отрицательный, документация еще не закончена.

 

Сколько работы занимает подготовка к реестру

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

При этом значительная часть времени ушла именно на устранение разрывов между разными слоями информации о продукте.

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

Для подачи заявления эту информацию приходится собирать в единую систему.

В этом смысле подготовка к реестру стала для нас своеобразной инвентаризацией продукта.

 

Результат: HConfig в реестре российского ПО

После нескольких попыток и доработки заявки HConfig был включен в реестр российского ПО. Номер реестровой записи — 32983.

Для нас результат важен прежде всего с продуктовой точки зрения.

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

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

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

При этом сама запись в реестре не заменяет техническую оценку продукта заказчиком. Архитектура, поддержка, совместимость и качество внедрения по-прежнему остаются отдельными вопросами.

 

Что проверить перед подачей заявления в реестр российского ПО

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

1. Проверить правообладателей и права на код. Нужно восстановить всю цепочку возникновения исключительных прав и заранее разобраться со случаями, когда правообладателей несколько.
   
   
2. Проверить домены и публичную документацию. Ресурсы продукта должны быть оформлены корректно и соответствовать сведениям, указанным в заявлении.
   
   
3. Собрать юридическую и бухгалтерскую историю ПО. Документы о создании программы, правах и учете продукта лучше готовить как единую систему.
   
   
4. Описать архитектуру и зависимости. Нужно понимать, какие внешние компоненты используются и насколько от них зависит работа продукта.
   
   
5. Проверить автономность. Если ПО предполагается использовать в изолированных контурах, этот сценарий необходимо протестировать и задокументировать.
   
   
6. Подготовить инструкцию для независимой установки. Эксперт должен иметь возможность развернуть экземпляр продукта без участия разработчиков.
   
   
7. Проверить пакет целиком до отправки. Несогласованность между техническими, юридическими и бухгалтерскими документами может привести к дополнительным итерациям.
   
   
8. Использовать поддержку реестра для уточнения спорных требований. В нашем случае разбор конкретной заявки помог быстрее понять причины отказа и подготовить следующий комплект документов.

 

Какие ошибки при регистрации ПО мы считаем самыми дорогими

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

Исправить большинство таких проблем можно. Цена вопроса заключается во времени команды и дополнительных циклах подачи заявления.

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

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

 

Что в итоге дала нам регистрация HConfig

Главный результат для Энсайн оказался шире самой записи в реестре.

Мы получили более формализованный программный продукт. Были приведены в порядок права, документация и описание архитектуры. Отдельно проверили зависимости HConfig и сценарии автономной эксплуатации.

Все это пригодилось бы продукту независимо от регистрации.

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

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

Частые вопросы о включении ПО в реестр

Что такое реестр российского ПО?

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

Достаточно ли свидетельства Роспатента для включения программы в реестр?

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

Проверяется ли техническая часть программы?

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

Можно ли повторно подать заявление после отказа?

Да. Мы несколько раз дорабатывали комплект документов и повторно подавали заявление. В результате HConfig был включен в реестр под номером 32983.

Нужно ли готовить документацию по установке программного обеспечения?

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

 

Вывод

История HConfig показала нам, что регистрация в реестре российского ПО начинается задолго до заполнения формы на портале.

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

HConfig прошел этот путь после нескольких попыток. 17 апреля 2026 года продукт Энсайн был включен в реестр российского ПО под номером 32983.

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