В декабре 2025 года создатель Ruby on Rails Дэвид Хейнемейер Ханссон, также известный как DHH, представил Fizzy — новый open source-визуализатор, описанный им как «занимательный и современный взгляд на канбан». Это мог быть очередной пост с анонсом, если бы не одно «но»: лицензия Fizzy запрещает использовать проект для конкурирующих разработок.

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

Мы в Beeline Cloud решили разобраться в ситуации.

Доступный код — открытый код

Считается, что лицензии формата source available в первую очередь служат механизмом защиты. Так разработчики пытаются оградить свои проекты от крупных корпораций, которые «перегибают с добросовестным определением «открытости» исходного кода». Взять хотя бы историю с MongoDB: провайдеры перепродавали продукт компании как управляемый сервис, а разработчиков не устраивал тот факт, что с ростом облачного рынка значительная часть прибыли уходит мимо них. В ответ в MongoDB решили отказаться от GNU AGPLv3 и перейти на собственную лицензию SSPL — чтобы обязать провайдеров либо распространять всю сопутствующую инфраструктуру на условиях SSPL, либо приобретать коммерческую лицензию.

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

Иными словами, существует точка зрения, что разрыв между source available и open source не так велик, а само определение «открытого кода» нуждается в пересмотре с учетом новых реалий — притом что все больше проектов переходят на альтернативные лицензии. Например, в прошлом году библиотека Fluent Assertions для автоматизированного тестирования сменила Apache 2.0 на лицензию, ограничивающую коммерческое использование без подписки. Другой пример — СУБД ScyllaDB, авторы которой перевели коммерческую версию своего продукта в формат source available, но полностью прекратили поддержку открытой редакции.

Обратная сторона медали

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

Ограничения, заложенные в source available-лицензиях, часто характеризуют как «безобидные для рядовых пользователей», но на практике любые изменения, ведущие к ухудшению условий — будь то смена модели монетизации или ужесточение правил, — резко ограничивают пространство для маневра у участников комьюнити.

В случае с open source, при наличии активного сообщества и спроса на продукт, всегда можно сделать форк и развивать его независимо. Но антиконкурентные и SaaS-ограничения source-available лицензий, могут не позволить реализовать такой сценарий. «Появился бы форк OpenTofu, если бы оригинальная версия Terraform имела лицензию, запрещающую конкурентное использование? — пишет в своем блоге один британский разработчик. — Экосистема и бизнес, построенные вокруг Terraform благодаря открытому коду, обеспечили необходимый импульс и ресурсы для дальнейшего развития».

Также можно встретить мнение, что source available-проекты медленнее «обрастают» сообществом сами по себе, поскольку для контрибьюторов участие в них выглядит как бесплатная работа над проприетарным продуктом. И история помнит довольно радикальные примеры, когда «доступный» код буквально за одну ночь становился «недоступным». Один из них — движок The Machinery, который позиционировался как более легкая альтернатива Unreal Engine и Unity. Проект вышел в июле 2021 года под собственной лицензией: исходный код формально был доступен, но только после покупки корпоративной версии. Но уже в августе 2022 года компания закрылась, а пользователи получили письмо с требованием удалить движок и все бинарные файлы. В нем авторы ссылались на новый пункт лицензионного соглашения, добавленный за несколько дней до рассылки (поскольку разработчик имел право менять условия договора в одностороннем порядке и без уведомления пользователей).

Попытки найти компромисс?

Одним из способов уладить спор вокруг лицензирования стали компромиссные модели, при которых проект со временем переходит от source available к open source. Показательный пример — лицензия Business Source License (BUSL). По сути, главным ограничением лицензии является запрет на коммерческое использование конкурентами, однако по истечении заранее оговоренного срока он автоматически переходит под одну из открытых лицензий.

Можно встретить мнение, что такой подход полезен для экосистемы открытого кода. Во-первых, он защищает продукт разработчиков от недобросовестного коммерческого использования в период, когда проект еще не окреп. Во-вторых, к такой лицензии комьюнити относится более снисходительно — энтузиасты, которые вносят свой вклад и делают коммиты, уверены, что, в конце концов, проект будет передан в open source. И ряд компаний уже выбрал эту модель для запуска своих проектов. В 2016 году ее использовали для базы данных MaxScale, чуть позже — в платформе Sentry для поиска багов в фронтенд-приложениях. В компании отметили, что именно сочетание временной защиты и понятного механизма раскрытия кода стало определяющим фактором при выборе BUSL: «Мы хотели оптимизировать наш вклад в развитие open source-сообщества, поэтому защита, предоставляемая BUSL, и тот факт, что мы могли легко перелицензировать код, сделали решение очевидным».

Хотя стоит отметить, что подобные переменчивые лицензии нельзя считать серебряной пулей, так как они все же имеют определенные недостатки, а с их реализацией связан ряд сложностей. С одной стороны, лицензии вроде BUSL позволяют разработчикам устанавливать любые сроки перехода продукта в open source — хоть сотню лет (и такие проекты есть) — можно сказать, что в таком случае лицензия мало чем отличается от коммерческой.

С другой стороны, существуют более упрощенные и формализованные альтернативы вроде Functional Source License (FSL). В рамках FSL разрешено практически все, что не наносит ущерба интересам разработчика: исходный код можно изучать, изменять, распространять и отправлять улучшения автору проекта. Но по истечении срока «вызревания», который составляет всего два года, лицензия проекта меняется на Apache 2.0 или MIT. Сегодня FLS используют такие проекты, как клиент системы контроля версий GitButler и платформа Codecov для анализа покрытия кода тестами [что интересно, Sentry тоже перешла на эту лицензию].

Кроме того, в сообществе возникают сложности с оформлением подобной схемы в рамках крупных проектов. С такой ситуаций, например, столкнулись в Fedora при «упаковке» MaxScale после ее перехода с BUSL на GPL. В 2024 году разработчик и мейнтейнер Fedora Михал Шорм поднял вопрос о том, существуют ли особые требования к программному обеспечению, ранее распространявшемуся под BUSL. Другой контрибьютор обратил внимание на формат SPDX, который используют для обмена информацией о лицензиях, и задался вопросом, нужно ли добавить новый механизм: «Несвободные лицензии, которые превращаются в FOSS-лицензии, существуют не первый год. Теперь они начинают конвертироваться, и, наверное, нам нужно как-то отражать этот факт».

Представитель юридической команды Red Hat, консультирующий Fedora, отметил, что подобные ситуации ранее практически не рассматривались. По его словам, упаковка такого ПО «в теории допустима, но связана с определенными рисками» — прежде всего из-за возможного смешения лицензий. На тот момент обсуждение так и не привело к выработке сколько-нибудь конкретного плана действий о том, как в дальнейшем поддерживать бывший BUSL-код. Однако с учетом того, что в ближайшие годы подобных конверсий будет становиться все больше, вероятно, потребуется специализированный подход или даже отдельный фреймворк для работы с двойными лицензиями.

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

Что еще можно почитать в нашем блоге:

• Карьерный буст в новом году: читаем научно-техническую литературу эффективно

• Бастионы, SSH-шлюзы (и не только) для подключения к домашним лабораториям

• Шаг к селф-хостингу: серверные системы и платформы для управления приложениями

• Эта музыка будет вечной: микросервисы против монолита и другие споры в ИТ