1) различия регистрации (ссылка на четвертую статью)
2) Рассматриваем использование open-source компонентов
3) Рассмотрим так же ()
Практически ни один современный программный продукт не создаётся с нуля. Фреймворки, библиотеки, сторонние модули — всё это давно стало нормой разработки. И когда речь заходит о включении в реестр, разработчики закономерно задают вопрос: если в продукте используются open-source компоненты, не станет ли это препятствием?
Короткий ответ — нет, само по себе использование open-source не является препятствием для включения в реестр. Но на практике всё гораздо интереснее.
Экспертиза смотрит не на сам факт использования открытого кода, а на характер зависимости от него. Есть большая разница между тем, когда библиотека используется как вспомогательный инструмент, и тем, когда ключевая функциональность продукта фактически построена на основе стороннего решения, которое находится под контролем вне российской юрисдикции.
В форме заявки есть блоки, которые косвенно раскрывают этот вопрос: описание архитектуры, состав программного обеспечения, сведения о разработке. И если в этих разделах видно, что продукт критически зависит от внешнего open-source компонента, возникает вопрос: насколько этот продукт можно считать самостоятельным и контролируемым российским решением.
Ещё один важный аспект — лицензии. Open-source — это не только про код, но и про юридические условия его использования. Разные лицензии накладывают разные ограничения: где-то требуется раскрытие исходного кода, где-то — указание авторства, где-то — ограничения на коммерческое использование. И все эти нюансы нужно учитывать при подаче заявки.
На практике часто возникает ситуация, когда разработчики используют популярные библиотеки, не задумываясь о лицензиях, а на этапе подачи заявки начинают разбираться, какие обязательства это накладывает.
Ещё одна зона внимания — инфраструктура и обновления. Если ключевые компоненты продукта зависят от внешних репозиториев или сервисов, которые находятся вне российской юрисдикции, это также может вызвать вопросы в рамках требований к управляемости и безопасности.
Это не означает, что open-source нельзя использовать. Но это означает, что его нужно правильно описать и обосновать в заявке, показать, что продукт остаётся самостоятельным и контролируемым.
Всё это напрямую связано с темой архитектуры, которую мы разберём в одной из следующих статей, потому что именно архитектурное описание показывает, какую роль играют сторонние компоненты в системе.
Можно ли включить SaaS в реестр российского ПО
Вопрос про SaaS возникает практически у каждого второго продукта, который приходит к идее включения в реестр. И это неудивительно — большая часть современного ПО уже давно не распространяется в виде установочного файла. Всё работает через облако, доступ предоставляется по подписке, данные обрабатываются на стороне разработчика. И в этот момент у команды появляется логичный вопрос: если продукт не устанавливается у клиента, а работает как сервис — можно ли его вообще включить в реестр?
И тут, как и в предыдущей статье, появляется короткий ответ — да, можно. Но дальше начинается то, о чём редко говорят в общих статьях: SaaS-модель сама по себе не является препятствием, но она резко повышает требования к тому, как вы описываете продукт и инфраструктуру.
В классическом ПО «из коробки» экспертиза оценивает сам программный продукт и то, как он поставляется пользователю. В SaaS история другая: пользователь фактически работает с удалённой системой, а ключевая логика, обработка данных и хранение информации находятся на стороне правообладателя. Поэтому экспертиза начинает смотреть на две вещи одновременно — на программное обеспечение и на инфраструктуру, на которой оно работает.
Особенности SaaS
И вот здесь возникает первая зона риска. Если ваш сервис размещён на зарубежных облачных платформах, использует инфраструктуру, которая полностью находится вне российской юрисдикции и не контролируется правообладателем, это может вызвать серьёзные вопросы на этапе экспертизы. Потому что требования реестра — это не только про код, но и про управляемость и доступность системы в российских условиях.
Это не означает, что использование облаков запрещено. Но это означает, что вы должны чётко понимать и уметь объяснить: где физически размещаются ваши серверы, кто управляет инфраструктурой, где хранятся данные пользователей и как обеспечивается контроль над системой.
Вторая важная особенность SaaS — это способ описания продукта в заявке. Очень часто команды начинают описывать свой сервис как услугу: «мы предоставляем доступ», «мы обрабатываем данные», «мы даём интерфейс». Но экспертиза рассматривает именно программное обеспечение как объект включения в реестр. Поэтому в описании нужно выделить сам программный продукт, его функциональные возможности, архитектуру, состав компонентов — и только потом описывать модель доступа к нему.
Интересный момент: один и тот же продукт можно описать так, что он будет выглядеть как онлайн-сервис, а можно — как полноценная программная система с определённой архитектурой, функциями и модулями. И от того, как вы это сделаете, напрямую зависит восприятие заявки.
Ещё один слой — это вопрос обновлений и развития продукта. SaaS-платформа постоянно обновляется, развивается, добавляются новые функции. В рамках реестра важно понимать, как это отражается в заявке: что именно включено в состав программного обеспечения, как фиксируется версия, как описываются изменения. Мы подробнее разберём этот вопрос в статье про включение модулей и обновлений.
В итоге SaaS — это не проблема, а просто другой формат продукта, который требует более внимательной подготовки заявки. И на практике большинство сложностей возникает не из-за самой модели, а из-за того, что команды не до конца понимают, как правильно описать архитектуру, инфраструктуру и функциональность.
Именно поэтому следующим логичным шагом становится разбор архитектурного описания. Мы уже начали об этом говорить, но в следующей статье более подробно разберем вопрос описания архитектуры ПО для реестра.