Структурный риск Open Source

Инфраструктура, включающая ПО Open Source, таит в себе часто игнорируемый риск — программный компонент может быть технически зрелым, быстрым, популярным и с лицензией Apache 2.0, но структурно нестабильным. Через год компания, в которой собраны все авторские права на проект, может поменять лицензию, перенести ключевые функции в платный облачный продукт или вообще полностью перевести развитие в платный продукт, оставив открытую ветку кода в архивном статусе (например, CockroachDB в 2024 году). Только за период с 2018-го по 2026 год из 105 популярных проектов с открытым кодом в области данных и ИИ-инструментов 24% прошли через смену лицензии, сворачивание функций или поглощение. Для команды разработчиков это выглядит как неприятная миграция, а для ИТ-директора — управленческий провал: риск был виден заранее, но в момент выбора не был зафиксирован. Тем не менее на технологическом комитете признак Open Source часто воспринимается как достаточное основание для архитектурного одобрения программного компонента.

Релиз Mem0 v3 от 16 апреля 2026 года — один из заметных открытых инструментов для построения слоя памяти LLM-агентов. В этом релизе венчурно-финансируемая компания Mem0 убрала поддержку графовых хранилищ из SDK и перенесла графовые дашборды в платный продукт Mem0 Platform. У всех команд, использующих этот стек в своих боевых системах, после этого осталось три варианта: заморозить старую версию, мигрировать на новую без графа или переехать на хостинг. Все они не требуют изменения кода — это решение управленческого уровня, которое в больших организациях ложится на CIO.

Подобный эпизод не единичный — за прошедшие восемь лет таких было десятки, и почти все они задевают современный стек памяти LLM-агентов: векторные хранилища, графовые базы данных, оркестраторы, эмбеддинговые сервисы перевода сложных объектов в длинные массивы чисел (векторы). Вместе с тем корпоративный спрос на ИИ-инфраструктуру в 2024–2026 годах растет быстрее, чем команды успевают выстраивать процедуру выбора компонентов. Архитектурные решения принимаются под давлением сроков и часто без проверки структуры риска.

Параллельно появился отдельный класс событий — корпоративные поглощения проектов Open Source: проект формально остается открытым, но переходит под контроль одного владельца со своей стратегией. Закрытие сделки IBM по HashiCorp в феврале 2025 года — недавний тому пример. Код Terraform от этой компании формально остается в открытом форке OpenTofu, но дальнейшая судьба проекта уже зависит от бизнес-логики корпорации IBM, а не от сообщества. Для таких компонентов тип лицензии не является единственным сильным сигналом риска. Главный сигнал — структура управления проектом и тип его финансирования.

Масштаб проблемы

Если собрать публично известные события по 105 проектам Open Source в области данных и ИИ-инструментов за период с января 2018-го по май 2026 года [1], то получается достаточно тревожная картина (см. таблицу 1).

Смена лицензии — наиболее частая категория, но не доминирующая, поэтому концентрация внимания при выборе компонента лишь на его лицензии чревата рисками. К этим 29 событиям добавляются еще девять связанных эпизодов.

Четыре форка: OpenSearch в ответ на Elasticsearch (2021), OpenTofu в ответ на Terraform (2023), Valkey в ответ на Redis (2024), Trino в ответ на Presto (2019 год).

Три обратных разворота лицензии. Это случаи, когда вендор после ужесточения частично возвращается к лицензии, одобренной OSI под давлением форков: Elastic вернула AGPLv3 в 2024 году после трех лет под SSPL; Redis вернулся к AGPLv3 в мае 2025 года; InfluxDB — к MIT (MIT License — лицензия свободного программного обеспечения, разработанная Массачусетским технологическим институтом) и Apache 2.0 в январе 2025 года.

Одна остановленная попытка. В апреле 2025 года компания Synadia пыталась вывести NATS из фонда CNCF (Cloud Native Computing Foundation) и переоформить лицензию на BSL, но устав CNCF и контроль над товарным знаком, удерживаемый Linux Foundation, не позволили это сделать.

Один случай ужесточения лицензии в пределах OSI-периметра.

Для ИТ-директора главный показатель — 24% проектов выборки за восемь лет прошли хотя бы через одно неблагоприятное событие, определяющее базовый фон работы с открытыми продуктами. Речь идет не об аномалии и не о случайных громких исключениях — любая компания, держащая в своем стеке открытое ПО, рискует столкнуться с неблагоприятными событиями. Каждое из них требует архитектурного решения в сроки, которые диктует вендор.

Рискованные и стабильные проекты

Типичная ситуация на архитектурном комитете компании обычно выглядит следующим образом — команда разработчиков приносит открытый компонент, расхваливая его технические свойства (латентность, зрелость API, наличие поддержки корпоративного уровня, активность сообщества на GitHub), лишь вскользь упоминая лицензию: «Apache 2.0», «MIT», что воспринимается как доказательство открытости и доступности ПО. Комитет дает одобрение. Однако вскоре вендор объявляет о смене лицензии и вопрос возвращается уже не как архитектурный, а как инцидентный — с командой юристов, дедлайнами и внушительным счетом за миграцию.

Естественная реакция — больше внимания надо уделять лицензии. Однако не все так просто.

Картина по типу руководства проектами Open Source выглядит следующим образом: single-vendor — одна компания контролирует все права и может единолично менять лицензию (таких около 38%); foundation-governed — нейтральный держатель прав (Apache Software Foundation, CNCF, Linux Foundation или эквивалентный), таких 2 события на 43 проекта (~5%). Волонтерское управление в выборке представлено одним проектом без событий.

По структуре финансирования ситуация следующая: венчурно-финансируемые — 45%; Foundation-funded — 0%; коммерческие компании Open Source без венчурного капитала — 0%; корпоративно-спонсируемые без венчурного капитала — 11%; волонтерские — 0%. Эти показатели вытекают из выборки открытых проектов, наиболее часто используемых в области данных и ИИ-инструментов: топ-50 баз данных по рейтингу DB-Engines; проекты CNCF в статусах graduated и incubating; отраслевой каталог практиков по векторным хранилищам, оркестраторам и инструментам наблюдаемости. Это не случайная, а целевая выборка по всему сегменту Open Source, из которого ИТ-команды выбирают компоненты для своего ИИ-стека. Внутри сегмента картина показательная, но ее экстраполяция на весь Open Source ландшафт (включая академические или хобби-проекты), конечно, была бы некорректной.

Самое интересное находится на пересечении. Венчурно-финансируемый single-vendor проект с лицензией Apache 2.0 имеет ту же вероятность ее смены, что и венчурно-финансируемый single-vendor проект с лицензией BSL (Business Source License — лицензия, позволяющая бесплатно использовать исходный код для некоммерческих целей). Лицензия в этой выборке оказывается слабым показателем после того, как зафиксирован тип управления и финансирования. Разрыв между крайними сочетаниями single-vendor с венчурным финансированием против foundation-governance с невенчурным финансированием почти девятнадцатикратный: 46% (23 из 50) против 2,5% (1 из 40).

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

В проектах single-vendor все права в руках одной компании, и юридически такие компании обладают возможностью сменить лицензию без согласия сообщества, чем они и пользуются. Венчурный фонд работает на горизонте пяти-семи лет, а промышленная data-инфраструктура живет десятилетиями. Это рассогласование снимается двумя способами — либо вендор достаточно зарабатывает на поддержке, либо ужесточает лицензию для защиты выручки от облачных провайдеров. Обычно выбирается второе.

Проекты Foundation-governance работают иначе, что создает юридическую подстраховку — эпизод с NATS классический тому пример. Компания Synadia, единственный корпоративный стюард, попыталась вывести проект из CNCF и переоформить лицензию на BSL. Фонд CNCF передал права на товарный знак Linux Foundation, который сохранил контроль над названием. Через несколько недель стороны договорились — ядро NATS осталось под Apache 2.0 в CNCF, а Synadia сохранила право на отдельный продукт под лицензией BSL. От истории с MongoDB и Redis этот случай отличается лишь одной деталью — членством в фонде и передачей товарного знака.

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

• распределенный копирайт без единственного правообладателя;
• управление через фонд (Apache Software Foundation, CNCF, Linux Foundation и т. д.) с невенчурным владельцем;
• отсутствие монетизационного давления.

СУБД PostgreSQL в промышленном варианте существует примерно с 2000 года, и ее лицензия не менялась с 1990-х годов. Руководство single-vendor здесь структурно невозможно: права распределены по тысячам контрибьюторов без CLA-агрегации (Contributor License Agreement, соглашения, по которому контрибьютор передает авторские права на свой код одной компании). У PostgreSQL единого правообладателя нет. Компании EnterpriseDB, Crunchy Data, Supabase, Neon и Tembo строят свой бизнес вокруг проекта, и ни у одной из них нет возможности сменить лицензию.

Apache Kafka — донация от LinkedIn в Apache Software Foundation. Платформа Confluent, созданная разработчиками Kafka, не может сменить свою лицензию. Изменения лицензии Confluent коснулись только собственных периферийных инструментов этой платформы (Schema Registry, ksqlDB, REST Proxy), которые принадлежат компании напрямую, а не Apache Software Foundation.

Имеется более редкий, третий тип защиты неизменности лицензии. Популярное расширение pgvector для PostgreSQL используется для решений векторного поиска во многих ИИ-стеках — имеет лицензию MIT, а единственный разработчик расширения является единственным контрибьютором кода. Коммерческой структуры вокруг этого расширения нет, как и венчурного спонсора, поэтому менять лицензию некому. Но есть риск другого рода — bus-factor (число ключевых сотрудников компании или проекта, которые могут внезапно перестать поддерживать проект).

Чек-лист для архитектурного согласования

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

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

Технические характеристики компонента: латентность, модель консистентности, query-семантика (семантика поисковых запросов) фиксируются при его выборе и проверяются при согласовании архитектуры. Структурные характеристики также наблюдаемы, но почти никогда не документируются: в большинстве архитектурных комитетов обсуждают latency, SLA и зрелость API, а тип владения копирайтом упоминается случайно или вовсе остается за рамками.

Структурный паспорт не предписывает архитектурный выбор, а подсвечивает переменные, по которым фактически и выполняется выбор открытого компонента. Архитектор, предложивший компонент, венчурно-финансируемый single-vendor без надежного пути к замене, фактически рекомендует рискованное структурное условие. Архитектор, выбирающий компонент foundation-governed с невенчурным финансированием, предлагает более взвешенное решение. Выбор за ИТ-директором, но риск-профиль каждого решения принципиально разный. Эта разница должна быть зафиксирована в момент принятия решения.

Импортозамещение

Замещение иностранных компонентов ПО отечественными альтернативами несет структурные риски — выбор компонента Open Source под промышленную нагрузку с многолетним горизонтом эксплуатации. В российском контексте структурный риск меняет форму. Отечественный компонент single-vendor с собственной или ограничительной лицензией может быть необходимым выбором по соображениям регуляторики или политики закупок. Но его нельзя считать структурно безопасным только потому, что он локален. Юрисдикция не отменяет базовую логику: чем меньше контроля над кодом, товарным знаком и коммерческой моделью, тем выше зависимость от одного центра принятия решений. Чем шире распределено владение — между несколькими независимыми вендорами, через консорциум или формальную foundation-структуру — тем устойчивее проект к изменению стратегии любого отдельного игрока.

Структурный паспорт без изменений применим к отечественным альтернативам. Например, PostgreSQL под распределенной поддержкой нескольких отечественных вендоров (Postgres Pro и т. п.) дает структурно иной риск-профиль, чем single-vendor российская СУБД с лицензией одного правообладателя. Apache Kafka, продолжающая работать в инфраструктуре российских банков как foundation-проект под лицензией ASF, дает иной профиль, чем закрытый отечественный message broker от одного вендора.

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

***

Структурные переменные — это архитектурные переменные. Тип владения правами и тип финансирования программного компонента необходимо документировать так же, как latency-профиль и модель консистентности. Выбор должен быть обоснован уже в момент проектирования архитектуры, когда стоимость изменения еще мала. После того как событие по смене лицензии наступило, выбор будет делаться под давлением, что дороже и хуже. Архитектурное согласование на стороне ИТ-директора — естественное место, где этой видимости проще всего добиться.

Литература

1. Полный набор данных опубликован как открытый датасет под лицензией CC BY 4.0: DOI 10.5281/zenodo.20562988. В него включены 105 проектов и 38 событий с первоисточниками.

Дмитрий Дмитренко (dmitdm@gmail.com) — независимый эксперт (Москва).