Открытый код импортозамещения

Использование Open Source стало стандартом разработки IT-продуктов во всем мире: современные приложения состоят из десятков модулей, многие из которых базируются на программном обеспечении с открытым исходным кодом. Разработчикам не нужно каждый раз заново создавать базовые куски кода – благодаря этому и произошло бурное развитие технологий в последнее десятилетие.

Такой же «бум» нужен российскому рынку решений для госсектора и объектов критической информационной инфраструктуры в рамках импортозамещения. Использование программы с открытым исходным кодом, казалось бы, поможет решить эту задачу. Это признают и в Минцифры, разрабатывающем меры поддержки Open Source.

Но российская IT-отрасль разделилась на два лагеря – сторонников и противников применения в импортозамещении программного обеспечения, основанного на Open Source. Масла в огонь добавил декабрьский скандал с уязвимостью, обнаруженной в открытой библиотеке Apache Log4j 2.0 (CVE-2021-44228) – эта библиотека используется миллионами Java-приложений для регистрации сообщений об ошибках. Злоумышленники уже активно используют эту уязвимость в атаках. Так можно ли создать безопасные IT-системы для госсектора на основе открытого ПО?

Продукт – не проект

Корень всех противоречий – в разной трактовке понятий и сути обсуждаемого предмета. Нужно различать просто открытый код, свободное программное обеспечение (СПО) и продукт, созданный на базе ПО с открытым кодом.

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

Опенсорс-проекты разрабатываются на базе открытого кода сообществом специалистов. Использование таких наработок регламентируется лицензиями – например, самая распространенная GPL (General Public License). Первая и вторая версии этой модели лицензирования достаточно строгие: все изменения должны быть возвращены в комьюнити, и они очень ограниченно могут быть коммерциализированы. А вот GPL v3/LGPL v3, так же как и MIT/BSD, MPL, Apache License, дают право сделать полноценный коммерческий продукт на базе открытых проектов. И этот продукт может быть закрытым, а код – сильно переработанным. Более того, продукт может состоять из модулей на базе разных проектов с открытым исходным кодом.

Проект – это идея, выраженная в примере ее реализации и размещенная на портале для публикации проектов с открытым исходным кодом.

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

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

Например, компания Red Hat продает коммерческий продукт Red Hat Enterprise Linux на базе поддерживаемого ею открытого проекта Fedora (дистрибутив Linux). То есть технология «обкатывается» в рамках Fedora, проходит строгий аудит в комьюнити разработчиков, а затем «отбирается» в продукт. Это дорогой продукт, потому что он хорошо проработан, имеет гарантию и поддержку, он готов сразу «из коробки» выполнять свои функции без потерь из-за простоя на доработку.

И обратная история: на базе востребованного продукта Red Hat Enterprise Linux развивается открытый проект – CentOS (так же AlmaLinux, Rocky Linux и VzLinux). И это уже некоммерческая история. Проект поддерживается сообществом разработчиков, а для конечных пользователей является бесплатным.

Использовать Open Source в импортозамещении можно и нужно, но речь идет о российских продуктах, разработанных на базе проектов с открытым исходным кодом, а не самих проектах со сложной и подчас непонятной моделью управления. Если проводить аналогию с примером Red Hat, нам нужно создавать свой Red Hat Enterprise Linux, а не вносить в реестр отечественного ПО условный CentOS.

Открытый код и безопасность

Многие проекты СПО стали стандартом для разработки тех или иных решений во всем мире. Основные претензии к Open Source как таковому со стороны IT-экспертов, выступающих против его применения в импортозамещении, – к его безопасности.

Открытый код хорош именно тем, что он аудируемый: здесь легче обнаружить и исправить ошибки. В итоге качество кода существенно выше, чем у любого проприетарного ПО, которое зависит от конкретного человека или небольшой группы разработчиков. Например, обнаружение уязвимости в Apache Log4j 2.0 – это первый подобный случай с 2014 г., когда нашли уязвимость уровня CVSS 10. Каждый раз это громкие скандалы, открытые разбирательства и устранение ошибок. Все в курсе и могут принять меры для защиты своих систем. В то же время наличие закладок в проприетарном зарубежном ПО – это практически повсеместная практика, с которой все как будто бы смирились. Что под капотом такой программы – всегда тайна.

Если нужно усилить безопасность конечного продукта на основе открытого кода – это можно сделать внутри него. Например, операционная система специального назначения Astra Linux: часть модулей убрана, добавлена модель управления доступом SELinux и криптозащита, используются другие протоколы. Все это реализуемо.

Альтернативы использованию СПО в том числе для импортозамещения нет: чтобы с нуля создать свое решение для замены зарубежного ПО, нужны десятки лет и огромные инвестиции. Например, Linux разрабатывали специалисты со всего мира в течение 30 лет. Можно ли разработать что-то подобное быстро и в отдельно взятой стране? Вряд ли, да и не нужно. Это базовая платформа, благодаря которой поддерживается совместимость многих IT-продуктов. Это упрощает и ускоряет создание экосистемы решений.

В России и Китае

В России есть примеры создания успешных коммерческих продуктов на базе международных опенсорс-проектов. Например, компания Postgres Professional объединила российских разработчиков сообщества открытой СУБД PostgreSQL и создала свою базу данных Postgres Pro. Компания вносит вклад в международную версию и параллельно выпускает собственный продукт, включенный в реестр отечественного ПО и сертифицированный ФСТЭК.

Российская операционная система ALT создавалась изначально как российская адаптация Mandrake Linux. Но сейчас это давно уже полностью самостоятельный продукт с собственным большим репозиторием, находящимся под контролем отечественной компании BaseALT в России. При этом над коммерческим продуктом работает более сотни программистов и в нем уже большая доля собственного кода.

В Китае государственная операционная система UOS основана на исходном коде международного проекта Deepin – дистрибутива Linux. Сейчас это полноценный продукт, на котором работают все государственные органы и сервисы. Мы тоже идем по этому пути, не нужно с него сворачивать.

С процессорами сложнее

Использовать Open Source в импортозамещении целесообразно, когда речь идет о программном обеспечении. Это действительно отработанная модель во всем мире. В аппаратных средствах – совершенно другая история. Например, есть открытая система команд для процессорных архитектур RISC-V. На ее основе предлагается создать новый отечественный процессор для импортозамещения.

RISC-V – это проект создания процессорных ядер на основе открытой системы команд. Если сравнивать с открытым кодом в мире программного обеспечения, то ему пока очень далеко до таких устоявшихся проектов в СПО, как Linux или PostgreSQL. Отсюда вытекает несколько серьезных рисков. Во-первых, невозможно создать полноценный процессор общего назначения на основе RISC-V ни за пять, ни за 10 лет. Проект слишком сырой и недоработанный, а значительно сокращенная система команд изначально ориентируется на применение во встраиваемых системах и интернете вещей (IoT). Во-вторых, именно в аппаратных средствах большое количество участников приводит к значительно большей фрагментированности разработки, что неприемлемо в случае процессорных архитектур, так как объединять топологию разных разработчиков ядер – это не сливать ветки версий одной программы, написанных на одном и том же языке программирования. В-третьих, развитием технологии занимается некоммерческая организация RISC-V Foundation, которая может скорректировать вектор или волюнтаристским методом внести изменения в систему команд в любой момент. Это автоматически сделает все версии разных разработчиков несовместимыми друг с другом.

Но главное – у нас уже есть отечественные процессоры, в том числе на собственной архитектуре («Эльбрус»). Нужно помогать развиваться российским разработчикам, вложившим много сил и средств в свои решения. В России нет такой острой необходимости в открытых архитектурах в отличие от того же Китая, где нет собственных наработок в этой сфере.

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