Недавно мы в Beeline Cloud рассказывали о полезных ресурсах для тех, кто желает влиться в open source и начать контрибьютить. Сегодня поговорим о крайне дискуссионном тренде в данной области — продолжающемся переходе западных open source-компаний на ограничительные лицензии. Кроме того, разберем примеры противоречивого опенсорсинга, когда открытый код на поверку оказывался не таким уж открытым. А в конце материала — поделимся литературой с рекомендациями о том, как эффективно работать с корпоративным open source в подобных условиях.

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

Несколько лет назад ряд ИТ-компаний начал активно модифицировать лицензии своих open source-проектов, чтобы защитить их от перепродажи в качестве части сервиса сторонними организациями. Этот тренд оказался устойчивым и до сих пор вызывает острые дискуссии в сообществе. Пожалуй, все слышали про ситуацию с HashiCorp, которая в августе 2023 года перевела Terraform (и других ключевых продуктов) с открытой лицензии MPL 2.0 на BUSL 1.1. Реакцию комьюнити на изменения лучше всего передает вышедший спустя две недели форк — OpenTofu, который поддержали сотни компаний и разработчиков (на Хабре есть материал, посвященный истории вопроса).

Еще один громкий пример смены лицензии — это кейс Elasticsearch и Kibana. С момента основания компании Elastic в 2012 году, оба этих продукта распространялись по лицензии Apache License 2.0. Но в 2021 году разработчики изменили свой подход и ввели сразу две лицензии: Elastic License и SSPL — обе так или иначе ограничили возможности облачных провайдеров в работе с продуктами компании без коммерческой лицензии. На тот момент сообщество восприняло изменения неоднозначно. Некоторые поддержали Elastic, аргументируя это необходимостью защитить труд разработчиков. Но звучала и критика — многие инженеры отмечали, что подобные изменения подрывают доверие к open source.

Неоднозначность стратегии перехода к формату source available подчеркивает и прошлогоднее решение Elastic вернутся к открытой модели распространения кода под AGPL. Компания добавила свободную лицензию в качестве одной из опций наряду с существующими ELv2 и SSPL. По словам руководства компании, изначально решение ограничить использование кода было принято для защиты от AWS, но теперь корпорация занимается развитием собственного форка OpenSearch, поэтому нужда в ограничительных лицензиях отпала — «на рынке установился иной ландшафт».

Однако в индустрии можно встретить мнение, что компания решила «вернуться к корням» не потому, что изменился рынок, а потому что она начала терять аудиторию и испытывать финансовые трудности. В конце августа 2024 года — за месяц до возвращения AGPL — капитализация Elastic упала сразу на 3 млрд долларов (и не восстановилась до сих пор). Глава компании CrafterCMS, которая развивает одноименную систему управления контентом с открытым исходным кодом, считает, что возвращение Elastic в open source — это попытка спасти положение: «Пусть это и шаг в правильном направлении, но этого недостаточно, ущерб уже нанесен. Трудности компании усугубляются тем, что ее некогда доминирующей позиции на рынке угрожают более открытые альтернативы».

И есть вероятность, что спасти положение не получится, потому что аудитория не хочет наступать на те же грабли снова: «На работе мы портировали все с ElasticSearch на OpenSearch, чтобы не думать о капризах руководства Elastic. Они могут передумать в любой момент, очевидно, не стоит рассчитывать них». И это далеко не единичный случай — подобные истории рассказывают многие сисадмины: «Последнее, что я сделал на прошлой работе, это остановил кластер Elasticsearch и запустил кластер OpenSearch — все из-за переполоха с лицензиями. И моя старая компания ни за что не вернется к ES».

Другой пример с несколько иной логикой — кейс системы управления базами данных ScyllaDB. Около года назад компания объявила, что прекращает разработку открытой версии проекта, а корпоративную редакцию переводит в формат source available. Команде становилось все сложнее поддерживать два независимых релизных потока, балансируя между открытой функциональностью и возможностями для бизнеса. «Разработка двух отдельных СУБД не оправдывает огромных издержек», — так написал глава ScyllaDB.

Реакция сообщества оказалась предсказуемо противоречивой: одни обвинили компанию в том, что она чрезмерно фокусируется коммерции, другие — отнеслись с пониманием, признавая, что такой шаг оправдан с точки зрения устойчивости бизнеса. Директор ScyllaDB утверждает, что перемены пойдут на пользу, и в перспективе пользователи выиграют. Однако это заявление вызывает вопросы, если вспомнить его позицию шестилетней давности — в 2018 году он резко критиковал аналогичный шаг MongoDB: «Стоит ли другим компаниям переходить на SSPL? Одним словом — нет. MongoDB переоценивают себя».

В целом участники открытого общества сходятся в одном: смена лицензий постепенно становится нормой в open source-индустрии. Лицензии меняют не только проекты на сотни тысяч пользователей, но и совсем нишевые решения. ��апример, в конце прошлого года разработчики инструмента для управления потоками данных Electric перевели его на BSL-лицензию — с ограничениями на коммерческое использование. Авторы пишут, что решили пойти на это шаг, потому что беспокоятся за жизнеспособность проекта и хотят укрепить связь с теми клиентами, которые «ценят их больше всего».

Еще один пример нишевого продукта, сменившего лицензию, — блог-платформа Bear. Разработчик перевел ее с открытой MIT на другую лицензию, основанную на Elastic License, обвинив многочисленные форки в том, что они паразитируют на его труде: «Больно видеть, как то, над чем ты так долго и упорно трудился, копируется и распространяется всего за несколько часов доработки».

Как правило, реакция сообщества на подобные шаги предсказуема — уход от open source воспринимается как предательство и отказ от принципов открытости. Однако в последние годы в отрасли наметился, пожалуй, еще более тревожный тренд — openwashing.

Мимикрия под открытый код

Бывает, что компании заявляют о приверженности «открытости» и даже передают свои продукты в open source, но на деле они не являются по-настоящему открытыми. В индустрии такой подход даже получил название openwashing [по аналогии с greenwashing, когда бизнес создает ложное впечатление об экологичности товаров и услуг].

Open source-сообщество, понятное дело, такой подход не ценит, однако все больше разработчиков выбирают идти по этому пути. Характерный пример — платформа для монетизации творческих проектов Gumroad, которая в апреле 2024 года объявила: «Теперь мы open source!». Компания объяснила, что хочет сблизиться с сообществом и развивать продукт совместно с разработчиками. Однако на практике оказалось, что компания использовала собственную лицензию, которая является не открытой, а ограниченно разрешительной. В частности, программное обеспечение могут использовать только небольшие фирмы с годовым доходом до 1 млн долларов, компании, с валовой выручкой всех продавцов площадки не более 10 млн долларов, а также государственные учреждения и некоммерческие организации.

Есть мнение, что распространение «опенвошинга» может навредить индустрии и подорвать доверие к открытому коду. Если подобное поведение станет нормой, разработчикам придется постоянно перепроверять условия новоиспеченных «открытых» (нет) лицензий. В то же время Дэн Лоренц, глава ИБ-компании Chaingurad, считает, что это проблема всей индустрии — даже независимых разработчиков: «Если вы думаете, что это проблема только больших компаний, то это не так. Это — общая проблема, которая затронет каждого, кто использует открытый исходный код. Из-за этого могут перестать работать целые проекты».

Особенно ярко openwashing проявляется в сфере разработки систем ИИ и машинного обучения. Здесь часто возникает ситуация, когда открыты веса, использованные при обучении модели. В результате многие проекты, заявленные как open source, на деле таковыми в полной мере не являются. Показательный пример — заявление Илона Маска в августе 2025 года о том, что Grok 2.5 — это открытая система. Однако на практике публике доступны лишь веса модели. При этом ИИ-инженер Тим Келлог охарактеризовал предложенную лицензию как «кастомную с антиконкурентными ограничениями». В частности, в документе указано, что производные продукты и сгенерированные данные нельзя использовать для обучения или улучшения сторонних ИИ-систем — что, по сути, является существенными ограничениями.

К слову, проблема открытости нейросетей настолько распространена, что на нее обращают внимание целые исследовательские группы. В прошлом году нидерландские специалисты из Центра языковых исследований Университета Неймегена изучили сорок различных LLM (включая Mistral, BLOOMZ, Stable Diffusion и ChatGPT) и оценили их по нескольким критериям: открытости исходного кода, доступности весов и документации, также проверили сами лицензии. Оказалось, что подавляющее большинство ИИ-моделей нельзя считать по-настоящему и полностью открытыми [PDF, стр.6].

О том, что собой представляет по-настоящему опенсорсная нейросеть, рассуждает автор дюжины книг о компьютерных технологиях Дэвид Линтикум: «Прозрачность в сфере ИИ подразумевает публичное документирование процесса разработки, обучения, настройки и внедрения моделей. Это означает полный доступ к наборам данных, весовым коэффициентам, архитектуре и процессам принятия решений при построении моделей. Большинство компаний, занимающихся разработкой систем ИИ, не достигают такого уровня прозрачности. Выборочно публикуя части своих моделей — часто без ключевых деталей — они создают иллюзию открытости».

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

Как работать с open source

Подобрали парочку полезных книг для тех, кто хотел бы лучше разобраться в том, какие существуют подходы к управлению open source-проектами и компаниями:

• «Business Success with Open Source». Книга рассчитана на управленцев в компаниях, работающих с открытым кодом. Автор — Вики Брассер — бывший вице-през��дент OSI. Она рассказывает, как работать с открытыми решениями: как составить дорожную карту продукта, разработать стратегию или проанализировать риски. Несколько глав посвящены интеграции открытых решений в инфраструктуру компании, и тому, как правильно контрибьютить в открытые проекты. Если вам понравится книга, то у автора есть еще одна — «Forge your future with open source». Она в целом дает контекст о культуре открытого исходного кода.

• «Producing Open Source Software». Автор — Карл Фогель, партнер компании Open Tech Strategies. Книга будет интересна менеджерам и разработчикам, планирующим запустить открытый проект или тем, кто уже это сделал. Текст, к слову, тоже в свободном доступе и распространяется по лицензии Creative Commons. Материал представляет собой подробнейшее руководство, которое охватывает полный цикл построения опенсорсного проекта: от запуска до поддержки после релиза. Автор пишет о нюансах, которые могут быть не очевидны, но требуют внимания: например, форкабельность проекта или работу с лицензиями. Также книга затрагивает человеческую сторону опенсорса: что происходит у успешных решений «под капотом», как выстраивать коммуникацию внутри команды и с аудиторией.

• «Program Management for Open Source Projects». Бен Коттон, бывший программный менеджер в Red Hat, написал книгу, которая поможет понять разницу, между руководителем продукта и руководителем программы. Отдельные главы посвящены коммуникации в команде и повышению эффективности планерок, выстраиванию четкой структуры рабочего процесса и не только. Например: Коттон учит поэтапному управлению программой проекта, более взвешенному принятию решений или объясняет, как работать с багами. Книгу оценила даже Вики Брассер, отметив ее эффективность: «Этой книгой Бен помог многим проектам. В ней блестяще опровергается мнение о том, что управлять open source-проектами легко, но в то же время в тексте есть рекомендации, как все сделать правильно».

Beeline Cloud — secure cloud provider. Разрабатываем облачные решения, чтобы вы предоставляли клиентам лучшие сервисы.

Дополнительное чтение в нашем блоге на Хабре:

• Первые шаги open source-контрибьютора: лучшие практики на основе тысячи проектов и руководства в стиле «с чего начать»

• Дерево против Wi-Fi, «проклятый» стол, погодные катаклизмы и другие причины и истории о неочевидных, порой нелепых багах

• Когда метод «просто погугли» не работает. Нишевые open source-инструменты для работы с научной и технической литературой

• С толикой «крипоты» — откуда пришло понятие feature creep и как «ползучее расширение функциональности» вредит проектам