Журнал "Information Security/ Информационная безопасность" #4, 2026

Open Source часто выбирают не только ради экономии, но и ради свободы дей- ствий. У вас есть исходный код, продукт можно развернуть у себя, доработать под свои задачи, а поддержку при необходимости передать другому под- рядчику. Но вместе с кодом вы не полу- чаете контроль над всем проектом. У компании-разработчика может сме- ниться владелец или бизнес-модель, из команды могут уйти ключевые люди, а следующие версии – выйти под другой лицензией. Бывает и так, что открытая ветка просто перестает развиваться. Сразу после таких изменений ничего страшного обычно не происходит: уста- новленная версия работает, сервисы не падают, данные остаются на месте. Сложности появляются позже, особенно если вы пользуетесь продуктом несколь- ко лет и успели связать с ним другие системы, написать свои доработки и выстроить эксплуатацию. Тогда изме- нения вокруг проекта уже приходится учитывать в собственных планах. Примеров хватает. MySQL пережил несколько смен владельцев, у Elastic- search и Redis изменились лицензии, а публичная ветка Greenplum в итоге перестала развиваться. Правила вокруг проекта иногда меняются Один из самых известных примеров – MySQL. В 2008 г. Sun Microsystems купи- ла компанию MySQL AB, которая стояла за разработкой СУБД, а уже в 2009 г. Oracle объявила о покупке самой Sun. Сделка завершилась в 2010 г., и MySQL оказалась под контролем одного из крупнейших производителей коммерче- ских СУБД. Часть разработчиков решила не ждать последствий смены владельца. Майкл Видениус и другие участники команды начали развивать MariaDB – форк MySQL с собственной открытой веткой разработки. У Elasticsearch изменения коснулись лицензии. В 2021 г. Elastic отказалась от Apache 2.0 для новых версий Elastic- search и Kibana, перейдя на Elastic License и SSPL. В ответ AWS продолжила развитие последней доступной под Apache 2.0 версии Elasticsearch 7.10.2 в рамках отдельного проекта OpenSearch. Похожая история произошла с Redis: в 2024 г. новые версии Redis перевели с BSD на RSALv2 и SSPL, после чего на основе последней BSD-версии появился Valkey. Вокруг него быстро собрались крупные участники индустрии, а разви- тие проекта перешло под управление Linux Foundation. Greenplum пошла по другому сцена- рию. Эта аналитическая СУБД несколько раз переходила вместе с бизнесом от одного владельца к другому, а в мае 2024 г. публичный репозиторий Green- plum Database перевели в архивный режим, после чего разработка этой ветки прекратилась. Во всех четырех случаях пользовате- лям пришлось реагировать на разные события: где-то сменился владелец, где- то лицензия, а где-то прекратилась пуб- личная разработка. И почти каждый раз рядом с исходным проектом появлялся альтернативный путь, который стал воз- можен благодаря открытому коду. Форк – всегда запасной выход? Истории MariaDB, OpenSearch и Valkey показывают одно из главных преиму- ществ Open Source: если развитие исход- ного проекта перестает устраивать часть сообщества, код можно взять за основу и продолжить работу отдельно. Но от создания форка до появления жизне- способной альтернативы – довольно большая дистанция. Новому проекту нужны разработчики, которые знают код и готовы поддержи- вать его годами, а также ресурсы на выпуск релизов, исправление уязвимо- стей и развитие экосистемы. Поэтому развитию MariaDB помогло участие быв- ших разработчиков MySQL, OpenSearch – участие AWS, а Valkey довольно быстро получил поддержку крупных компаний и перешел под управ- ление Linux Foundation. Для пользователей важен и еще один момент: хороший форк должен позво- лять перейти на него без полной пере- стройки инфраструктуры. Чем дольше сохраняется совместимость с исходным проектом, тем доступнее такой вариант для тех, кто уже вложился в интеграции и эксплуатацию. Поэтому возможность сделать форк еще не гарантирует неза- висимость. Зато она оставляет запасной путь, если вокруг исходного проекта меняются правила. DuckDB: можно ли разделить судьбу компании и проекта? Свежий повод вернуться к этой теме появился в августе 2026 г., когда стало известно, что DuckLabs присоединяется к AWS. Именно в DuckLabs работает основная команда разработчиков Duck- DB – популярной аналитической СУБД с открытым исходным кодом. На первый взгляд история знакомая: компания, вокруг которой сосредоточена разработка успешного Open Source-про- екта, становится частью крупной техно- логической корпорации. Но DuckDB устроен немного иначе. Права на проект и торговые марки принадлежат незави- симой некоммерческой организации DuckDB Foundation, а устав фонда закрепляет MIT-лицензию. DuckLabs занимается разработкой и коммерче- скими продуктами вокруг DuckDB, но юридически компания и проект разде- лены. После объявления сделки разра- ботчики подтвердили, что лицензия и модель управления DuckDB не меняются. Это защищает проект от части сценари- ев, которые мы уже видели в других историях: новый владелец DuckLabs не получает вместе с компанией возмож- ность просто переписать правила для DuckDB. Однако корпоративные изменения все равно имеют значение, поскольку основ- ная команда разработчиков теперь будет работать в структуре AWS, у которой есть свои продукты и приоритеты. Фонд может защищать лицензию и правила управления, но не определяет, на что разработчики будут тратить большую часть своего времени через несколько лет. Поэтому история DuckDB интересна не как очередной повод ждать непри- ятностей после поглощения, а как попыт- ка заранее отделить проект Open Source от судьбы компании, которая финанси- рует его разработку. Насколько хорошо такая конструкция работает, станет понятно лишь со временем. В заключение Все эти истории не означают, что при выборе Open Source нужно заранее готовиться к смене лицензии или погло- щению разработчика. Но технических характеристик и условий лицензии для оценки проекта недостаточно – полезно понимать, кто принимает ключевые решения и насколько проект зависит от одной компании. Стоит посмотреть, кому принадлежат права на код и торговую марку, кто финансирует разработку и насколько широко распределена работа между независимыми участниками. От этого во многом зависит, сможет ли проект развиваться дальше, если основной спонсор изменит планы или уйдет. И заранее полезно оценить стоимость выхода. Если через несколько лет условия перестанут вас устраивать, насколько сложно будет перейти на форк или другой продукт и сколько собственной инфраструктуры придется переделать. l 50 • СПЕЦПРОЕКТ Свободный код, несвободные обстоятельства