Форки, облачные технологии и новая экономика лицензирования открытого исходного кода

Когда компания HashiCorp сменила лицензии Terraform и многих других своих продуктов с открытой лицензии MPL 2.0 на Business Source License (BSL), это вызвало бурную негативную реакцию. Настолько сильной, что сообщество создало форк Terraform под названием OpenTofu под полностью открытой лицензией. OpenTofu продолжает набирать обороты, а HashiCorp (входящая в состав IBM с февраля 2024 года) демонстрирует признаки стабилизации, но отголоски сопротивления до сих пор раздаются в технологической индустрии.

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

Давайте рассмотрим, какое влияние коммерческое форкирование оказывает на разработчиков открытого исходного кода, и изучим, как работает BSL. Мы рассмотрим, что это означает на практике как для стартапов с открытым исходным кодом, так и для корпоративных пользователей. Мы расскажем, что команды могут (и не могут) делать с BSL, когда стоит обратить внимание на коммерческую подписку и почему эта гибридная модель отражает то, как открытый исходный код действительно работает внутри современных предприятий.

Стоимость коммерциализации облачных технологий

Согласно отчету Perforce OpenLogic «State of Open Source 2025», в 2025 году 96% организаций сохранили или увеличили использование программного обеспечения с открытым исходным кодом (OSS). Именно это широкое внедрение технологий с открытым исходным кодом и инновации, происходящие вокруг них, вдохновили крупных поставщиков облачных услуг на извлечение прибыли. И они это сделали. Рынки переполнены высокодоходными коммерческими версиями проектов с открытым исходным кодом. Создание форков открытого исходного кода не является незаконным, но когда это явно происходит за счет создателей и сопровождающих сообщества, такая практика вызывает постоянные этические и экономические опасения в сообществе открытого исходного кода.

Отток прибыли

Самая очевидная цена для разработчиков — это потеря дохода. Облачные сервисы на базе OSS, даже «облегченные» версии, входят в число самых высокодоходных продуктов для облачных провайдеров. Это прибыль, которую разработчики никогда не увидят. Amazon Relational Database Service (RDS) (PostgreSQL, MySQL) широко считается одним из самых прибыльных предложений AWS. Azure Cache for Redis и Google Memorystore — это управляемые решения Redis с чрезвычайно высокой маржой, которые приносят доход, намного превышающий доход компаний, создавших эти базы данных. И не стоит забывать об OpenSearch — форке Elasticsearch от AWS, который оказался настолько успешным, что его широко считают одним из факторов, повлиявших на решение Elastic вновь перейти на лицензирование с открытым исходным кодом для Elasticsearch и Kibana по лицензии AGPLv3 2024 года.

Увеличение нагрузки на обслуживание

Помимо упущенной прибыли, исследования показывают, что коммерческие форки приводят к долгосрочному расхождению и дополнительной работе по координации. Рефакторинг и реорганизация затрудняют распространение патчей от одного форка к другому и обратно в исходный проект. Кроме того, эмпирические исследования фрагментации проектов показывают, что когда облачный провайдер создает форк проекта, другие участники, как правило, присоединяются к наиболее влиятельному дистрибутиву. Участники мигрируют в сторону форка, потому что именно там их работа имеет реальное влияние. Даже нейтральные участники часто следуют за форком, не имея идеологической привязки.

Фрагментация и путаница среди пользователей

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

Динамика сообщества растет

Несмотря на все это, нельзя отрицать популярность Valkey (форка Redis, поддерживаемого Linux Foundation), OpenTofu, Opensearch и других. Тогда можно задаться вопросом, перевешивают ли потенциальные потери ту защиту, которую, как считается, обеспечивает BSL. Будет ли принятие структуры BSL автоматически означать отторжение разработчиков? Позволит ли это командам получить надлежащий доступ к открытому исходному коду, одновременно защищая интеллектуальную собственность?

Все признаки указывают на положительный результат. По нашему опыту, сообщество SurrealDB не отреагировало негативно; оно продолжает расти вместе с нашей клиентской базой.

Что такое Business Source License (BSL)?

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

• Использование программного обеспечения бесплатно для разработчиков и инженерных команд в большинстве случаев. Это касается внутренних проектов, прототипов, тестирования и большинства некоммерческих видов использования. Команды могут модифицировать, расширять и распространять его внутри своей организации.
• BSL включает ограничение, которое ограничивает коммерческую конкуренцию. Это критически важное условие для многих поставщиков и владельцев проектов. Оно включено для ограничения коммерческого использования, которое напрямую конкурирует с поставщиком. Распространенным примером является размещение программного обеспечения в качестве платного продукта «Программное обеспечение как услуга» без коммерческой лицензии.
• По истечении установленного периода он становится полностью открытым исходным кодом. Каждый проект определяет «дату изменения». После этого версия BSL преобразуется в лицензию с открытым исходным кодом, одобренную Open Source Initiative (OSI), такую как Apache 2.0 или MIT, становясь полностью открытой для всех. В случае SurrealDB дата изменения наступает через четыре года после запуска каждой версии. Например, текущая версия 3.0 переходит на Apache 2 1 января 2030 года.

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

Что BSL дает предприятиям

Для руководителей компаний модель лицензирования BSL предлагает прагматичный компромисс. Во-первых, она предоставляет разработчикам и инженерам бесплатный доступ без предварительных лицензионных сборов или переговоров. Команды могут использовать ее для любых целей — тестирования, обучения, внутренней сборки и развертывания — при условии, что она не используется в коммерческих целях.

Условия лицензии ясны: внутреннее использование разрешено, коммерческий рехостинг — нет. Такая прозрачность снижает неопределенность в вопросах соответствия требованиям. Это обеспечивает ясность для юридических и закупочных команд.

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

Это модель, созданная для современного предприятия: динамичная, ориентированная на разработчиков, но в то же время ответственная. В большинстве случаев использование в предприятиях начинается с мотивированных команд, решающих реальные проблемы. В SurrealDB наша цель — упростить правила: вот что вы можете делать с SurrealDB в рамках BSL, а вот когда вам следует обратиться к нам по поводу поддержки или коммерческой лицензии.

Когда команды переходят с бесплатной версии на платную

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

1. Зависимость от производства. Когда внутренняя система становится критически важной для операционной деятельности, компания обычно обращается за коммерческой поддержкой, чтобы получить гарантии, обеспечить бесперебойную работу и получить помощь экспертов.
2. Масштабируемость и производительность. Предприятия, масштабирующие базу данных между отделами или регионами, получают преимущества от расширенных функций модели подписки, таких как кластеризация, наблюдаемость или расширенная поддержка интеграции.
3. Управление и соответствие нормативным требованиям. Для организаций, имеющих отдел по программам с открытым исходным кодом (OSPO) или группы по обеспечению соответствия, подписка упрощает процессы аудита и обеспечивает юридическую ясность.

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

Переход от сообщества к коммерческому сектору — это не смена менталитета, а формализация успеха. Это признание того, что открытый исходный код был правильным инструментом для старта, а гарантии корпоративного уровня — правильным инструментом для дальнейшего развития.

BSL в контексте: отраслевая тенденция

MariaDB стала пионером BSL, чтобы защитить свою базу данных от коммерческого переноса, сохранив при этом ее открытость для пользователей. CockroachDB и Sentry пошли по аналогичному пути, обеспечив доступность инноваций для сообщества и одновременно защитив возможность поставщиков создавать жизнеспособные бизнесы. Это не отход от открытого исходного кода; это эволюция. Модель открытой разработки остается неизменной; BSL просто вводит границы добросовестного использования, соответствующие реалиям предприятий. А поскольку программное обеспечение, лицензированное по BSL, по-прежнему общедоступно, прозрачно и поддается аудиту, разработчики продолжают учиться, экспериментировать и вносить свой вклад.

Остается ли хард-форк риском?

Что произойдет, когда программное обеспечение станет полностью открытым? Действительно ли BSL защищает нас от риска коммерциализации третьими сторонами? С практической точки зрения, реальная защита BSL заключается в ограниченном по времени контроле, а не в постоянной эксклюзивности. В течение четырехлетнего срока действия лицензии компании не могут на законных основаниях предлагать программное обеспечение в качестве конкурирующего управляемого сервиса. Это дает компаниям защищенный период для монетизации внедрения, построения бренда, создания экосистемы API и ускорения инноваций, чтобы опередить альтернативы.

Конечно, BSL не исключает полностью возможность форка после конверсии, но, учитывая, насколько устаревшим к тому времени будет исходный набор инструментов, это маловероятно. Таким образом, BSL защищает поставщиков от немедленных коммерческих форков и устраняет стимул к форку в будущем.

Модель партнерства для современного предприятия

BSL отражает более общую истину о современных корпоративных ИТ. Внедрение программного обеспечения больше не является решением, принимаемым сверху вниз. Разработчики открывают для себя новые возможности, команды создают прототипы, организации масштабируются, а поставщики вмешиваются, чтобы помочь предприятиям превратить инновации на низовом уровне в надежность производства. Вот почему внедрение открытого исходного кода — это не просто история сообщества, а история бизнеса.

Многие крупные организации находят новые решения благодаря инженерам, экспериментирующим с версиями с открытым исходным кодом. Когда ранние пилотные проекты доказывают свою ценность, руководители напрямую участвуют в обеспечении поддержки предприятия, оптимизации производительности и совместной разработке дорожной карты. Эта модель внедрения «снизу вверх» в настоящее время является стандартом во всей отрасли, а BSL обеспечивает правовую и операционную основу для ее устойчивого развития.

Рекомендации для руководителей

• Поощряйте ответственное изучение. Предоставьте своим командам возможность тестировать инструменты с открытым исходным кодом, но убедитесь, что они понимают политику вашей компании в отношении лицензирования и использования.
• Официально закрепите то, что работает. Когда решения с открытым исходным кодом показывают свою ценность, рассмотрите возможность их официального закрепления посредством корпоративных соглашений, обеспечивающих безопасность, управление и непрерывность.
• Рассматривайте BSL как средство, а не как ограничение. Оно защищает обе стороны: вашу свободу для инноваций и способность поставщика поддерживать разработку.
• Помните об общей цели. Открытый исходный код и корпоративные подписки — это не противоположности, а партнеры в инновациях.

Открытые инновации и устойчивое развитие

Лицензия Business Source License отражает развитие открытого исходного кода. Она оставляет дверь открытой для инноваций, одновременно определяя четкие границы коммерческого использования. Для предприятий это означает, что разработчики могут продолжать создавать продукты с помощью любимых инструментов безопасно, ответственно и с четким планом поддержки, когда это наиболее важно. А для таких компаний, как SurrealDB, это гарантирует, что открытые инновации и устойчивый бизнес могут процветать вместе.