Всё о получении статуса доверенного ПО: этапы, требования, сроки и наши услуги.
Материал давал точный и содержательный юридический разбор доверенного статуса для open source продуктов — с чёткой логикой по типам сценариев, лицензиям и CLA. Портили его только вымышленный многолетний опыт и статистика вместе с контактным блоком. Оставляем практически весь юридический анализ, убираем недоказуемые цифры.
Главное: постановление №1937 не содержит запрета на открытый код — доверенный статус получает не тип лицензии, а конкретный продукт с конкретным правообладателем. Открытая лицензия вроде MIT или Apache 2.0 не означает отказа от исключительных прав. Она лишь предоставляет пользователям широкое разрешение на использование и модификацию кода, а правообладатель эти права сохраняет. Ключевой вопрос для любого open source продукта — кому фактически принадлежат исключительные права на код и находится ли этот правообладатель под российским контролем.
| Утверждение из старой версии статьи | Реальное положение дел |
|---|---|
| «10 лет опыт работы с реестровыми процедурами Минцифры»; статистика «95% наших клиентов проходят экспертизу с первого раза» | Доверенный статус существует с марта 2026 года, многолетнего опыта и статистики по нему быть не может |
Почему вопрос непростой
Open source — не одна ситуация, а спектр разных сценариев с принципиально разными шансами на доверенный статус. Продукт может быть полностью оригинальной разработкой российской компании под открытой лицензией — в этом случае открытость лицензии не меняет факта принадлежности исключительных прав. Продукт теоретически может получить статус при выполнении остальных требований. Форк иностранного проекта с существенными доработками — ситуация сложнее. Права на оригинальный код принадлежат иностранному сообществу или организации, права на доработки принадлежат российской компании, получить статус можно только при чётком разграничении, что именно является оригинальной российской разработкой. Дистрибуция иностранного open source продукта без существенных изменений, лишь с русификацией или незначительной настройкой под видом «российского решения», статуса не даёт, поскольку исключительные права на ядро продукта российской компании не принадлежат. Вклад в международный open source проект, где права распределены между глобальным сообществом или иностранной некоммерческой организацией, тоже практически не оставляет шанса выделить «российскую часть» и получить на неё статус.
Ключевое требование: исключительные права
Центральный вопрос для open source продукта — кому принадлежат исключительные права, и это юридическая конструкция, не зависящая от типа лицензии. Первый вопрос для проверки — кто автор кода. Весь значимый код должен быть создан сотрудниками российской компании по трудовым договорам со служебными заданиями или подрядчиками с договорами об отчуждении прав, а если часть кода написана иностранными контрибьюторами, их права на свой вклад компании не принадлежат. Второй вопрос — есть ли Contributor License Agreement с контрибьюторами. Соглашение, по которому внешние авторы передают или лицензируют права на свой вклад правообладателю-мейнтейнеру, существенно улучшает юридическую позицию, а без CLA права на вклады внешних контрибьюторов остаются у них самих.
Третий вопрос — есть ли иностранный код в зависимостях. Использование иностранных open source библиотек как внешних зависимостей — стандартная практика и само по себе не препятствие, поскольку права на них иметь не нужно, они используются по своим открытым лицензиям. Проблема возникает именно тогда, когда иностранный код включён непосредственно в состав продукта как vendored-код, а не подключается как внешняя зависимость. Граница между «использованием чужой библиотеки» и «включением чужого кода в свой продукт» в этом случае становится юридически значимой. Четвёртый вопрос — соответствует ли лицензия требованиям реестра. Для включения в реестр российского ПО, обязательного предварительного шага, продукт должен соответствовать требованиям Минцифры о составе сведений, открытые лицензии в целом с реестром совместимы, но конкретная лицензия влияет на то, какие сведения нужно предоставить.
Лицензионные модели и их влияние на статус
| Лицензия | Совместимость с реестром | Влияние на доверенный статус | Ключевой риск |
|---|---|---|---|
| MIT, BSD, Apache 2.0 | Совместима | Не препятствует при наличии российского правообладателя | Права контрибьюторов без CLA |
| GPL v2, GPL v3 | Совместима | Не препятствует, но требует анализа производных работ | Копилефт-эффект GPL на форки и доработки |
| LGPL | Совместима | Зависит от характера использования | Требует анализа конкретной схемы использования |
| AGPL | Совместима | Не препятствует при наличии российского правообладателя | Копилефт-эффект, особенно значимый для SaaS-компонентов |
| Двойное лицензирование (open source + коммерческая) | Совместима | Наиболее благоприятная конструкция — права чёткие | Минимальный при правильном оформлении |
| Иностранная открытая лицензия на чужой продукт | Не применима — это чужой продукт | Невозможен — нет российского правообладателя | Базовое требование не выполняется |
Форк иностранного продукта: когда возможно, когда нет
Форки иностранных open source продуктов — распространённый сценарий на российском рынке, и граница между «существенной доработкой с собственными правами» и «переупаковкой чужого продукта» размыта, но принципиальна для оценки перспектив статуса. Форк может претендовать на статус, если российская компания взяла продукт под разрешительной лицензией вроде MIT или Apache, написала значительный объём оригинального кода поверх и создала принципиально новую функциональность, не существовавшую в оригинале. Оригинальный код при этом присутствует, но собственная разработка составляет существенную и самостоятельную часть, что требует тщательного правового анализа. Форк не может претендовать на статус, если продукт по сути остаётся тем же иностранным решением с минимальными изменениями (русификацией, незначительными настройками, ребрендингом). Ключевая функциональность в этом случае остаётся иностранной разработкой, независимо от открытости лицензии оригинала статус невозможен.
Практические шаги для open source разработчика
Если продукт имеет российское происхождение и рассматривается вопрос о доверенном статусе, первый шаг не «подать заявление», а провести правовой аудит: без него невозможно ни оценить перспективы, ни составить план подготовки. Аудит состава кода и прав включает инвентаризацию всего кода продукта: что написано сотрудниками компании, что получено от внешних контрибьюторов, что заимствовано из иностранных проектов, с анализом принадлежности прав по каждому элементу: какая доля кода собственная разработка, есть ли CLA с контрибьюторами, какие иностранные компоненты включены непосредственно в продукт. Оценка лицензионной чистоты проверяет совместимость всех используемых лицензий между собой и с требованиями реестра. GPL-продукты требуют особого внимания, поскольку производные работы должны распространяться под той же лицензией. При выявлении пробелов следует их оформление: введение CLA для новых контрибьюторов, урегулирование прав с историческими контрибьюторами, при необходимости замена проблемных заимствованных компонентов собственными реализациями.
Вопросы и ответы
Короткие ответы на вопросы, которые чаще всего возникают при подготовке документов и подаче заявки.
Продукт на GitHub под MIT-лицензией, теоретически кто угодно может его форкнуть — как это совместимо с требованием исключительных прав?
MIT-лицензия предоставляет пользователям широкие права на использование, копирование, модификацию и распространение, но не передаёт им исключительные права — правообладатель остаётся правообладателем. Возможность создать форк означает лишь, что у форкнувшего появятся права на свой форк, а не на оригинальный продукт. Если исключительные права на продукт принадлежат российской компании, MIT-лицензия не препятствует получению доверенного статуса.
Проект активно принимает pull request от контрибьюторов со всего мира — это проблема?
Да, потенциальная проблема, если нет CLA, по которому контрибьюторы передают или лицензируют права на свой вклад компании-мейнтейнеру. Без CLA права на каждый pull request формально остаются у его автора, а для иностранных контрибьюторов это означает, что часть кода продукта может не принадлежать российской компании. Решение — введение CLA для всех будущих контрибьюторов и отдельная проработка ситуации с уже принятыми историческими вкладами; чем раньше введён CLA, тем меньше объём последующего урегулирования прав.
Форкнули PostgreSQL и написали поверх российскую СУБД — можно ли претендовать на доверенный статус?
PostgreSQL распространяется под разрешительной лицензией PostgreSQL License, позволяющей создавать производные работы без обязанности открывать их код. Права на оригинальный PostgreSQL-код принадлежат PostgreSQL Global Development Group, права на доработки — компании-разработчику форка. Для оценки перспектив критичны два вопроса: насколько существенна и самостоятельна собственная разработка поверх PostgreSQL, и как продукт определён в реестровой записи. Ответить однозначно без детального правового анализа конкретного случая невозможно.
Источники
- КонсультантПлюс, порядок формирования перечня доверенного ПО: требование исключительных прав правообладателя по постановлению №1937.
- Реестр российского программного обеспечения, Минцифры России: требования к сведениям о продукте для включения в реестр.
