Open source и реестр российского ПО

Открытый код требует проверки

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

Что собрать по зависимостям

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

Практический порядок проверки

1. 01Состав

   Инвентаризация компонентов и зависимостей.

2. 02Права

   Лицензии, собственные изменения и документы.

3. 03Инфраструктура

   Сборка, репозитории, пакеты и обновления.

4. 04Доказательства

   Описание продукта и проверяемая граница прав.

Типовые риски

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

Как помогаем

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