21 марта Redis Ltd. объявила, что, начиная с Redis 7.4, её in-memory data store будет выпускаться под несвободными лицензиями с доступным (source-available) исходным кодом. Новость малоприятная, но вполне ожидаемая. Необычно в этой ситуации обилие альтернатив для тех, кто хочет остаться со свободным ПО: есть как минимум четыре варианта замены, включая уже существующий форк под названием KeyDB и недавно анонсированный проект Valkey от Linux Foundation. Вопрос теперь в том, что предпочтут пользователи, провайдеры и создатели дистрибутивов Linux.

Краткая история Redis

У Redis непростая предыстория. Проект начинался с приложения-анализатора логов в реальном времени и назывался LLOOGG. Сальваторе Санфилиппо (также известный как antirez) запустил его, поскольку MySQL не удовлетворял его потребностям. Изначально Redis позиционировался как «база данных иного типа». Вместо реляционной базы данных Сальваторе сделал простую базу данных типа «словарь», которая хранит в памяти пару «ключ — значение». Её название как раз и произошло от REmote DIctionary Server (удаленный словарный сервер). С годами, конечно, она пополнилась кучей дополнительных функций. Redis быстро заняла видное место в рамках движения NoSQL. В 2010 году VMware наняла Сальваторе, чтобы тот занимался развитием Redis в полную силу. В 2013 году он перешёл в дочернюю компанию VMware — Pivotal — и продолжил работу над проектом.

Примерно в то же время популярность Redis начала стремительно расти. Проектом заинтересовались Twitter и Pinterest, и постепенно он начал появляться в дистрибутивах Linux. Redis появился в Ubuntu 12.04 (апрель 2012 года), в Fedora 18 (январь 2013 года) и других дистрибутивах. В сентябре 2013 года поддержкой Redis обзавёлся сервис ElastiCache от AWS. Пользователи сервиса получили доступ ко всем плюсам Redis, что только способствовало росту популярности этой БД.

В начале 2013 года стартап под названием Garantia Data начал предлагать услуги по работе с Redis, позиционируя себя как лучшую альтернативу для «Redis с открытым исходным кодом». В ноябре 2013 года Garantia провела первый раунд финансирования и сменила название на RedisDB. После некоторого противодействия со стороны Санфилиппо компания в начале 2014 года сменила название на Redis Labs. Санфилиппо присоединился к Redis Labs в качестве руководителя разработки в 2015 году. Он оставался в Redis Labs до 2020 года.

В 2018 году дополнительные модули, которые предоставляют функции поверх основной базы данных, перешли на новую лицензию. Компания решила воспользоваться модифицированной версией лицензии Apache 2.0 с дополнением в виде Commons Clause. Этот самый clause ограничивал право на продажу программного обеспечения или взимание платы за услуги. Причиной перехода стало то, что поставщики облачных услуг «используют Open Source-сообщество в своих интересах», продавая услуги, основанные на открытом коде, в разработке которого они не участвовали. Тогда компания заявляла, что Redis — «это BSD и всегда будет оставаться BSD».

Впрочем, Redis Labs была не единственной компанией, которая экспериментировала с лицензиями, ограничивающими использование. В частности, другие компании с венчурным участием, специализирующиеся на базах данных, тоже начали присматриваться к новым лицензиям, рассчитывая на эксклюзивную продажу своих услуг. MariaDB придумала Business Source License (BSL) для MaxScale в 2016 году, а MongoDB запустила Server Side Public License (SSPL) в конце 2018 года. В итоге Redis Labs остановилась на схеме двойной лицензии SSPL и собственной лицензии Redis Source Available License (RSAL) для своих модулей.

В середине 2021 года было решено отказаться от «Labs» в названии. Объявляя о переименовании, Redis вновь заявила о приверженности принципам Open Source и сообщила, что переименование компании «не повлияет на лицензирование Redis, которая всегда покрывалась и будет покрываться BSD». Также была внедрена модель управления, в соответствии с которой самые важные решения по «архитектуре, дизайну и философии» Redis будут приниматься «основной командой» сообщества. Казалось бы, в полномочия этой команды должны входить и вопросы лицензирования Redis. Страницы с описанием модели управления на сайте Redis больше нет, однако она доступна в интернет-архиве. Основная команда состояла из пяти человек, трое из которых представляли компанию Redis (Йосси Готлиб, Оран Агра и Итамар Хабер). Также в ее состав входили Чжао Чжао из Alibaba и Мэделин Олсон из AWS.

20 марта 2024 года компания Redis объявила, что «все будущие версии Redis будут выпускаться с source-доступными лицензиями», а именно SSPL и RSAL. Роуэн Троллоп, генеральный директор Redis, написал, что сохранение лицензии BSD теперь «противоречит нашей способности успешно развивать Redis в будущем». Под будущими версиями в данном случае подразумеваются Redis 7.4 и более поздние версии. В FAQ говорится, что, следуя политике безопасности компании, патчи безопасности будут бэкпортированы в предыдущие версии под оригинальной лицензией BSD из трёх пунктов.

Облако против Open Source

Сторонники лицензий с ограничением использования, вроде SSPL и RSAL в случае Redis, пытались представить всё как битву между облачными провайдерами вроде AWS и Open Source-сообществом. Ограничение использования, убеждали они, — единственная логичная альтернатива, а облачные провайдеры — единственные проигравшие. В 2019 году тогдашний гендиректор Redis Labs Офер Бенгал заявил, что после того, как Redis ввела лицензию с доступностью исходного кода для модулей Redis, было высказано «множество разных мнений», но это было необходимо, чтобы конкурировать с облачными провайдерами.

«Кое-кто осудил это [изменение лицензии]. Но после того, как шумиха улеглась, — и особенно после того, как другие компании выступили с аналогичной концепцией, — сообщество осознало, что оригинальная концепция открытого кода должна быть исправлена, поскольку она больше не подходит для современной эпохи, когда облачные компании пользуются своей монополией и заимствуют успешные Open Source-проекты, не внося в них никакого вклада».

В мартовском анонсе Троллоп написал, что «поставщики облачных услуг смогут предлагать Redis 7.4 только после согласования условий лицензирования с Redis», при этом «ничего не изменится для сообщества разработчиков Redis, которые продолжат пользоваться разрешительным лицензированием в рамках двойной лицензии».

Фраза «разрешительное лицензирование» вводит в заблуждение. Redis смогла перейти на несвободную лицензию в 7.4 и более поздних версиях только потому, что сторонние разработчики контрибьютили под разрешительной BSD-лицензией. Условия SSPL и RSAL несовместимы с общепринятой трактовкой термина «разрешительный» в Open Source-сообществе.

Также затруднительно согласовать утверждения о том, что облачные провайдеры не вносят вклад, с фактическими коммитами в репозитории Redis. Быстрый анализ коммитов с момента выхода 7.0.0 с помощью gitdm показывает 967 коммитов за этот период.

Доля коммитов:

Бинбин Чжу из Tencent принёс в проект почти 25% коммитов. Некоторые из контрибьюторов, которые попали в категорию «Неизвестно», несомненно, являются сотрудниками Redis, но очевидно, что компания работала не в одиночку. (Обратите внимание, что часть контрибьюторов с небольшими долями была опущена.)

Изменение модели распространения

В общем, ясно, что внесение вклада в код проекта не является истинной причиной смены лицензии. Redis — компания с венчурной поддержкой. В ходе многочисленных раундов финансирования с 2011 года она привлекла более 350 млн долларов. Компания и её инвесторы, похоже, решили отказаться от принципов Open Source в попытках заработать.

Впрочем, у них были основания для этого, если принимать во внимание результаты работы MongoDB. Компания вышла на биржу в 2017 году и чуть более года спустя перешла на SSPL. Вскоре после этого основные дистрибутивы Linux перестали включать её в состав, поскольку MongoDB больше не соответствовала их лицензионным стандартам. Но к тому времени компания переориентировалась на платформенную модель, которая побуждала бы разработчиков (и их работодателей) использовать и оплачивать MongoDB и дополнительные предложения по модели as-a-service. Распространение версии MongoDB с доступным исходным кодом можно рассматривать как стратегию, направленную на привлечение разработчиков, которым, по мнению компании, нет дела до Open Source.

Как в 2017 году писал основатель Redmonk Стивен О'Грейди:

«Поскольку разработчики стали всё чаще брать на себя контроль над техническим выбором и направлением — даже в ситуациях, когда проприетарная альтернатива технически лучше, доступность программного обеспечения с открытым исходным кодом обеспечила последнему огромное преимущество на рынке. Выбор между хорошим вариантом А, который можно сразу скачать, и теоретически отличным вариантом Б, который нужно было купить, на самом деле не был выбором».

Но Open Source, отмечает Грейди, «обычно менее удобен, чем альтернативы на основе сервисов». Если удобство — ключевой фактор, тогда у Open Source проблема. Особенно когда вендоры вроде MongoDB научились у проприетарных вендоров тому, что «привязка клиентов — это хорошо для бизнеса» (речь о vendor-lock in).

Хорошо ли это для бизнеса? MongoDB продолжала расти, обрастая клиентами, и за последний финансовый год заработала 1,68 миллиарда долларов. Рост превысил 30%. Доходы от сервиса баз данных Atlas также выросли более чем на 30%, что свидетельствует о том, что многие компании предпочитают платить за использование сервиса, а не пытаться делать всё самостоятельно. Несмотря на всё это, компания по-прежнему несёт убытки — более 345 миллионов долларов в прошлом году.

Впрочем, инвесторов больше интересует цена акций, нежели реальная прибыль. При выходе на биржу акции компании стоили около 33 долларов за штуку, а сейчас их цена превышает 350 долларов. Инвесторы Redis, скорее всего, будут рады похожим результатам.

Форки и альтернативы

Вендоры с венчурной поддержкой, как писал О'Грейди в прошлом году, похоже, пришли к консенсусу о том, что можно отказаться от открытого исходного кода. Особенно если им не «противостоят активно другие коммерческие интересы, фонды и прочие заинтересованные участники отрасли». Возможно, Redis неправильно оценила настроения в отрасли.

Когда в прошлом году HashiCorp перевела свои проекты на BSL, форк Terraform под названием OpenTofu появился в течение нескольких дней и сразу получил поддержку Linux Foundation. 28 марта фонд объявил о поддержке Valkey — прямого форка Redis 7.2.4. Проект поддержали Amazon Web Services (AWS), Google Cloud, Oracle, Ericsson и Snap.

Valkey появился всего через несколько дней после изменения лицензии Redis. Олсон написала, что она и «другие бывшие контрибьюторы Redis» начали работу над форком с рабочим названием placeholderkv, который покрывается оригинальной лицензией BSD с тремя пунктами. Хранителями выступили Олсон, Чжао, Виктор Сёдерквист и Пинг Кси. По словам Олсон, AWS не имеет никакого отношения к этому форку Redis. Это была её «попытка сохранить преемственность с сообществом». Рассматривался вариант KeyDB, но этот проект настолько разошёлся с оригинальным Redis, что в нём «отсутствует многое из того, к чему привыкло сообщество».

Мы выпускали на Хабре несколько статей о замене Redis на KeyDB:

• KeyDB как [потенциальная] замена Redis

• Наша новая удачная попытка бесшовной замены Redis на KeyDB

• KeyDB и Redis: в поисках серебряной пули — in-memory replicated DB (Replicated IMDB)

Стоит напомнить, что KeyDB появился в 2019 году в первую очередь по техническим, а не лицензионным причинам. Проект, который позиционирует себя как «более быстрая альтернатива Redis», был основан Джоном Салли, Эриком Бленкарном и Беном Шермелем, которые хотели реализовать многопоточность, но не смогли убедить хранителей (maintainers) Redis пойти в этом направлении. Салли и Шермель основали компанию, которая тоже называлась KeyDB и предлагала закрытую корпоративную версию продукта. Кодовая база была полностью открыта (под BSD-лицензией) в 2022 году, после того как KeyDB была приобретена компанией Snap.

Проблема с KeyDB в том, что она не успевает за Redis с момента форка. В ней до сих пор нет многих функций, появившихся в Redis 7. По словам Салли, у него мало времени для работы над вопросами, «не затрагивающими Snap напрямую», хотя проект «конечно, приветствовал бы помощь со стороны, и мы, конечно, можем выбрать дополнительных хранителей, если будет интерес со стороны сообщества». 22 марта Салли сообщил, что ведёт переговоры о «возможном» добавлении хранителей, чтобы приблизить KeyDB к Redis 7. Пока неясно, вытеснит ли Valkey KeyDB, но участие Snap делает это вероятным в долгосрочной перспективе.

Дрю ДеВолт, основатель и генеральный директор SourceHut, создал свой форк — Redict — на базе Redis 7.2.4, но решил использовать LGPLv3. В анонсе он отметил, что выбор лицензии был «обдуманным и сбалансированным по ряду причин». ДеВолт хотел copyleft-лицензию, при этом «максимально простую для соблюдения пользователями» и облегчающую интеграцию с модулями, совместимыми с Redis, или плагинами Lua, которые можно использовать для выполнения операций в Redis. Он также отметил, что в Redict не будет лицензионного соглашения с разработчиками (CLA), однако их попросят подтверждать контрибьюции с помощью сертификата происхождения. Несмотря на связь с SourceHut, ДеВолт разместил Redict на Codeberg, чтобы «обеспечить удобный и привычный пользовательский опыт для всех, кто знаком с сообществом Redis на GitHub».

Ещё один своеобразный претендент — Garnet от Microsoft, анонсированный 18 марта. Согласно анонсу, он разрабатывается Microsoft Research с 2021 года. Это удалённое кэш-хранилище, которое может кэшировать те же типы данных, что и Redis, и управлять ими. Проект разработан для совместимости с протоколом сериализации Redis. Garnet защищён лицензией MIT, написан на .NET C# и не претендует на прямую замену. Однако на странице совместимости API утверждается, что его можно «рассматривать как достаточно близкую отправную точку», которая работает «со многими клиентами Redis». С многими, но не со всеми. Например, один пользователь попытался перевести NodeJS-приложение на Garnet, но обнаружил, что команда FLUSHALL в Redis в настоящее время не поддерживается. Впрочем, поддержка отсутствующих API включена в дорожную карту проекта.

Поиск альтернатив

В очередной раз создателям дистрибутивов Linux приходится разгребать последствия. Нил Гомпа открыл обсуждение в списке разработчиков Fedora, отметив изменение лицензии и необходимость удаления Redis из Fedora. Джонатан Райт ответил, что заменой может стать KeyDB; он «немного поработал над её упаковкой» до смены лицензии. Позднее он отметил, что KeyDB станет «шагом назад и вызовет головную боль» у тех, кто захочет переехать с более поздних версий Redis. Тем не менее 23 марта Райт написал, что выложил готовые к тестированию сборки для Fedora и EPEL 8 и 9.

Вскоре после анонса Valkey Райт написал, что займётся его упаковкой, как только выйдет тегированный релиз. Также он заявил, что «ожидает, что Valkey станет [фактической] заменой Redis в большинстве случаев».

Гомпа также поднял этот вопрос в списке обсуждения openSUSE Factory. Доминик Леуенбергер ответил списком из 18 пакетов, зависящих от пакета redis в Tumbleweed. В первоначальном обсуждении в качестве возможных замен упоминались Redict и KeyDB (Valkey на тот момент ещё не был анонсирован).

Необходимость найти замену Redis — не единственная проблема для коллективных дистрибутивов. Джейкоб Михальски упомянул несколько сервисов, которыми пользуется openSUSE и которым потребуется замена Redis, включая программное обеспечение для хостинга кода Pagure (созданное и используемое Fedora), используемое для code.opensuse.org, и ПО для форумов Discourse.

Разработчик Debian Гильем Джовер разместил запрос на пакет (Request for Package, RFP), в котором указал KeyDB в качестве потенциальной замены Redis. Джовер отметил, что не знает, сможет ли стать полноценным хранителем, но с радостью готов помочь. В ходе переписки авторов оригинальной статьи с Джовером последний поведал, что его компания перешла с Redis 6 на KeyDB и миграция прошла «как по маслу». По его словам, «пожалуй, KeyDB не хватает некоторых функций Redis 7, но мы не заметили ни одного недостатка и не почувствовали, что что-то упускаем».

Джовер сказал, что пока рано говорить о том, будет ли продолжаться поддержка новых форков, и что LGPLv3-лицензия Redict «также может стать проблемой для экосистемы». В письме после анонса Valkey он отметил: «Думаю, мы продолжим паковать KeyDB, по крайней мере, в Debian. Если всё заглохнет, его всегда можно будет удалить или убрать оттуда».

Путь вперёд

Конечно, ещё слишком рано прогнозировать, какой из форков станет популярным (и станет ли). Valkey пока выглядит вполне достойной альтернативой. Возможность того, что один из форков быстро наберёт популярность при широкой поддержке сообщества и отрасли, должна заставить задуматься тех вендоров, которые рассчитывают на лёгкую жизнь после отказа от идеалов Open Source.

P. S.

В оригинальной статье стоит ссылка на подписку — приложим ее и сюда: https://lwn.net/Promo/slink-trial2-3/claim. 

Читайте также в нашем блоге:

• Открытый форк Terraform OpenTofu официально стал проектом Linux Foundation 

• HashiCorp отказалась от Open Source-лицензии для своих продуктов 

• Почему у CockroachDB меняют Open Source-лицензию

• KeyDB как [потенциальная] замена Redis

• Наша новая удачная попытка бесшовной замены Redis на KeyDB

• KeyDB и Redis: в поисках серебряной пули — in-memory replicated DB (Replicated IMDB)