Open Source в реестре российского ПО: как подтвердить права на программу со сторонними библиотеками

Open Source в реестре российского ПО — один из наиболее распространённых вопросов при подготовке программных продуктов к включению в реестр Минцифры. Многие российские разработчики используют сторонние библиотеки, программные фреймворки, базы данных и компоненты с открытым исходным кодом. Возникает закономерный вопрос: можно ли подтвердить российское происхождение программы, если часть её функциональности построена на чужом коде?

В 2026 году требования к включению программного обеспечения определяются статьёй 12.1 Федерального закона № 149-ФЗ и постановлением Правительства РФ от 16.11.2015 № 1236. Основное условие — наличие исключительного права на заявляемый программный продукт у правообладателя, соответствующего установленным требованиям. При этом законное использование сторонних компонентов по открытым лицензиям не означает автоматического перехода исключительных прав на эти компоненты к разработчику.

Компания «МинпромХелп» разбирает, как подготовить программное обеспечение с библиотеками MIT, Apache, GPL, LGPL и AGPL к реестровой экспертизе, какие документы подтверждают права на код и как избежать ошибок при оформлении заявки.

Можно ли включить Open Source-продукт в реестр российского ПО

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

Пункт 5 Правил, утверждённых постановлением № 1236, предусматривает, что исключительное право на программное обеспечение на территории всего мира и на весь срок действия права должно принадлежать предусмотренным российским правообладателям.

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

Собственный код и сторонние библиотеки: в чём различие

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

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

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

Компонент продукта	Какие права необходимо подтвердить
Программа, созданная штатными разработчиками	Возникновение исключительного права у компании в соответствии с законом и договорами
Модуль, разработанный подрядчиком	Наличие исключительного права у заявителя на основании применимого договора и закона
Библиотека с лицензией MIT	Правомерное использование и соблюдение условий открытой лицензии
Компонент под GPL	Возможность законного включения в продукт с соблюдением условий GPL
Сторонний коммерческий SDK	Договорное право использования и распространения в предусмотренных пределах

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

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

Можно ли использовать иностранный Open Source

Само иностранное происхождение библиотеки не означает автоматического запрета на её использование в российском ПО.

Однако необходимо проверить лицензию, условия распространения программы на территории России, зависимость от внешних сервисов и другие применимые требования постановления № 1236.

Кроме того, статья 12.1 закона № 149-ФЗ устанавливает ограничение на определённые выплаты иностранным лицам: их общая сумма должна составлять менее 30% выручки от реализации соответствующего программного продукта за календарный год.

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

Подробнее о зарубежных компонентах — в статье «Российское ПО с зарубежными библиотеками: что проверить перед подачей в реестр».

Лицензии MIT, Apache, GPL и LGPL: как они влияют на включение ПО в реестр

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

Статья 1286.1 ГК РФ предусматривает открытые лицензии, позволяющие правообладателям предоставлять другим лицам права использования произведений на заранее опубликованных условиях.

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

Сравнение распространённых Open Source-лицензий

Лицензия	Что важно учитывать разработчику	Основной риск
MIT	Допускает коммерческое использование, изменение и распространение при сохранении предусмотренных уведомлений	Удаление текста лицензии или сведений об авторских правах
Apache License 2.0	Допускает коммерческое использование, требует соблюдения условий о лицензии, изменениях и NOTICE при его наличии	Неполное выполнение условий распространения
GPL	При распространении объединённого произведения могут действовать требования к лицензированию всего произведения и предоставлению исходного кода	Несовместимость с закрытой моделью распространения
LGPL	Предусматривает специальные условия использования и модификации библиотек, включая требования, связанные с компоновкой	Невыполнение условий замены или изменения библиотечного компонента
AGPL	Дополнительно учитывает взаимодействие пользователей с модифицированной программой через компьютерную сеть	Невыполнение требований о доступе к исходному коду в применимых случаях

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

Использование GPL-компонента в составе распространяемого программного продукта требует более тщательного анализа. Значение имеют способ объединения программ, редакция лицензии и условия распространения.

Для LGPL необходимо учитывать особенности статической и динамической компоновки. AGPL может создавать дополнительные обязательства для сетевых сервисов.

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

Почему наличие исходного кода на GitHub недостаточно

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

Если проект опубликован без понятной лицензии, нельзя автоматически считать его Open Source.

При проверке рекомендуется установить:

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

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

Какие документы подтверждают права на программу со сторонними библиотеками

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

Пункт 11 постановления № 1236 предусматривает представление установленных документов и материалов, включая экземпляр программного обеспечения и документы, подтверждающие соответствие требованиям к правообладателю.

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

Документы на собственную разработку

Если программа создавалась сотрудниками компании, необходимо проверить требования статьи 1295 ГК РФ о служебных произведениях.

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

Если программный продукт создавался подрядчиками, проверяются договоры и применимость статей 1296 и 1297 ГК РФ. Особое значение имеют условия о принадлежности исключительного права и фактическом результате работ.

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

Подробнее — в статье «Юридическая проверка прав на ПО: исключительные права и доверенное ПО».

Реестр сторонних библиотек и лицензий

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

Поле реестра	Какие сведения указать
Наименование библиотеки	Точное название и версия
Источник	Официальный репозиторий или сайт проекта
Лицензия	MIT, Apache-2.0, GPL-3.0, LGPL либо иное точное обозначение
Назначение	Какую функцию компонент выполняет в программном продукте
Способ использования	Встраивание, компоновка, отдельный процесс или внешний сервис
Условия распространения	Необходимые уведомления, лицензии и другие обязательства
Подтверждающий материал	Текст лицензии, сведения о версии и происхождении компонента

Такой реестр можно подготовить в виде обычной таблицы либо использовать формат Software Bill of Materials (SBOM) с идентификаторами лицензий SPDX.

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

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

Как подготовить Open Source-продукт к экспертизе Минцифры

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

Пошаговая подготовка доказательной базы

1. Определить границы программы. Установить, что именно заявляется в российский реестр и какие компоненты входят в продукт.
2. Проверить правообладателя. Подтвердить соответствие требованиям статьи 12.1 закона № 149-ФЗ.
3. Проверить собственный код. Собрать документы по сотрудникам, подрядчикам и ранее приобретённым разработкам.
4. Составить список Open Source-зависимостей. Зафиксировать библиотеки, версии, лицензии и источники.
5. Проверить условия лицензий. Определить совместимость компонентов с выбранной моделью распространения.
6. Устранить юридические риски. При необходимости заменить компонент, изменить способ его использования либо получить отдельное разрешение правообладателя.
7. Подготовить техническое описание. Разграничить собственную функциональность и роль сторонних библиотек.
8. Проверить остальные требования. Оценить инфраструктуру, техническую поддержку, распространение ПО и применимые специальные критерии.
9. Сформировать заявление. Подготовить документы для подачи в установленном порядке.

Отдельно следует проверить требования к российской инфраструктуре хранения и сборки программного обеспечения, а также новые требования к совместимости с доверенными операционными системами, введённые постановлением Правительства РФ от 28.11.2025 № 1937 с поэтапными сроками применения.

Наличие корректно оформленных Open Source-лицензий не заменяет выполнение этих условий.

Подробнее — в статье «Реестр российского ПО в 2026 году: требования к совместимости с двумя российскими ОС».

Пример: российская программа использует стороннюю СУБД и библиотеки

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

Для работы используются PostgreSQL, библиотека с лицензией MIT и отдельный компонент LGPL.

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

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

При этом правообладателю не требуется утверждать, что ему принадлежат исключительные права на PostgreSQL или стороннюю библиотеку.

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

Ошибки, которые необходимо устранить до подачи

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

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

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

Частые вопросы об Open Source и помощь МинпромХелп

Можно ли включить в реестр российского ПО программу с библиотеками MIT?

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

Нужно ли получать исключительные права на все Open Source-библиотеки?

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

Можно ли использовать GPL в коммерческом программном обеспечении?

Коммерческое использование GPL-программ допускается. Однако при распространении объединённого произведения могут возникать обязательства по предоставлению исходного кода и лицензированию всего произведения на условиях GPL. Их необходимо оценивать применительно к конкретной архитектуре.

Обязателен ли SBOM для включения ПО в реестр?

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

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

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

Помощь МинпромХелп при включении Open Source-продукта в реестр российского ПО

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

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

Компания «МинпромХелп» оказывает содействие разработчикам при подготовке программного обеспечения к включению в реестр российского ПО.

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

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

Разрабатываете российское ПО с использованием Open Source и планируете включить его в реестр Минцифры? Обратитесь в «МинпромХелп» через официальный сайт компании или ознакомьтесь с услугой «Включение ПО в реестр российского программного обеспечения».

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

Нормативные и официальные источники

• Статья 12.1 Федерального закона № 149-ФЗ — требования к российскому программному обеспечению и правообладателям.
• Постановление Правительства РФ от 16.11.2015 № 1236 — правила включения программ в реестр в действующей редакции.
• Статья 1286.1 ГК РФ — открытая лицензия на использование произведения.
• Статья 1295 ГК РФ — права на служебные произведения.
• Статья 1296 ГК РФ — права на произведения, созданные по заказу.
• Единый реестр российского программного обеспечения — официальный реестр.
• Open Source Initiative: лицензия MIT — официальный текст условий лицензии.
• Apache License 2.0 — условия использования и распространения программ.
• GNU Project: вопросы об условиях GPL и LGPL — официальные разъяснения разработчиков лицензий.
• SPDX License List — идентификаторы и сведения об открытых лицензиях.