Прим. перев.: Гибкость и свободы, предлагаемые Open Source-лицензиями, позволили современным поставщикам крупных SaaS-решений поставить под большой вопрос успешность бизнеса у небольших компаний, стоящих за разработкой востребованных Open Source-проектов. В этой заметке от авторов CockroachDB — распределённой и отказоустойчивой РСУБД — в полной мере раскрывается суть проблемы и возможный путь её решения.



CockroachDB задумывалась как программное обеспечение с открытым кодом. В те годы, что прошли с момента появления проекта на GitHub (впервые код был опубликован в феврале 2014 года — прим. перев.), мы придерживались относительно типичного пути развития, балансируя между философией открытого исходного кода и созданием жизнеспособного бизнеса. Основной код выходил под лицензией Apache License 2 (APL), был запущен управляемый сервис, часть дополнений для компаний выпускалась под enterprise-лицензией.

Но наши прошлые представления о верной бизнес-модели основывались на ключевой норме OSS-мира: можно строить бизнес вокруг мощного Open Source-продукта, не предполагая, что придет более крупная технологическая компания, предлагающая тот же продукт как услугу. Эта норма больше не действует.

В принципе, юридически ничто никогда не мешало конкурентам предлагать в качестве услуги (as-a-service) OSS-продукт, созданный другой компанией. А теперь мы видим, что это действительно происходит. Сегодня мы наблюдаем рост числа высокоинтегрированных провайдеров, которые пользуются своим уникальным положением и предлагают as-a-service-версии OSS-продуктов. Понятно, что их высокая интеграция сильно повышает удобство работы пользователей. Совсем недавно подобное случилось с форком ElasticSearch, «позаимствованным» Amazon (Salil Deshpande в статье TechCrunch искусно охарактеризовал случившееся как «корыстное и рациональное»).

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

Начиная с сегодняшнего дня, мы вводим исключительно разрешительную версию Business Source License (BSL). Пользователи CockroachDB могут масштабировать нашу СУБД на любое количество узлов. Они могут свободно использовать CockroachDB и встраивать ее в свои приложения (независимо от того, поставляют ли они их потребителям или предлагают в качестве услуги). Также можно запускать CockroachDB как услугу для внутренних целей компании. Единственное, чего нельзя делать, — предлагать коммерческую версию CockroachDB в виде as-a-service без покупки соответствующей лицензии.

Чтобы обеспечить дальнейшее развитие проекта, наше ограничение имеет скользящее временное ограничение: через три года после релиза лицензия превращается в стандартную лицензию Apache 2.0. Меняя условия лицензии и вводя временной лимит, мы преследуем две цели:

• создать конкурентоспособную базу-данных-как-услугу (DbaaS);
• попутно гарантировать, что основной продукт останется полностью открытым.

Сравнение различных подходов к лицензированию Open Source

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

Модель copyleft

Основоположником традиции copyleft стала GNU GPL. Ее цель — предотвратить появление проприетарных форков, в некоторых случаях требуя обнародования исходного кода. В этот лагерь попадают Affero General Public License (AGPL) и родственная Server-Side Public License (SSPL). Именно в SSPL особое внимание уделяется проблеме конкурирующих сервисов.

Однако мы считаем, что все эти лицензии одновременно избыточны и недостаточны. Избыточны они в том смысле, что детали сложны, а copyleft-требования не всегда ясны. Многих потенциальных пользователей отпугивают требования о раскрытии кода, которые потенциально слишком широки. Недостаточны они в том смысле, что конкуренты готовы и могут раскрыть достаточно своего кода, чтобы к ним не возникало никаких вопросов, при этом не принеся никакой пользы разработчикам основной технологии. Amazon поступила так с Open Distro для Elasticsearch, хотя лицензия copyleft от нее этого и не требовала.

Нам было нужно что-то более простое и жесткое.

Многоуровневая модель

Также мы рассматривали возможность использования трехуровневой модели: Open Source-ядро, enterprise-компоненты и некий средний уровень с функциями, исходный код которых закрыт, однако их можно использовать совершенно бесплатно. Эта модель довольно популярна в мире ПО; и с некоторыми вариациями мы использовали ее до сегодняшнего дня.

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

Решение найдено: BSL

Мы начали изучать лицензии с временными ограничениями и обнаружили, что нет нужды создавать новую лицензию с нуля. Лицензия Business Source License (BSL) версии 1.1 для MariaDB содержала все необходимое, и уже была одобрена основателем OSI Брюсом Перенсом (Bruce Perens). BSL — параметризованная лицензия, поэтому мы используем ее не так, как MariaDB.

Ключевое отличие состоит в нормах дополнительного права использования (Additional Use Grant) — например, MariaDB допускает использование MaxScale максимум на трех серверах. Additional Use Grant у CockroachDB разрешает использовать наш продукт на любом количестве узлов при условии, что вы не предлагаете его как коммерческую DbaaS. В течение трех лет наша версия BSL защищает существующий код CockroachDB от применения в качестве DBaaS без приобретения соответствующей корпоративной лицензии. Через 3 года это ограничение снимается и код становится открытым (в смысле, который заложен в лицензию Apache) и может свободно использоваться для любых целей.

Мы применяем эту лицензию к базовой версии CockroachDB (то есть к коду, который до этого подпадал под Apache 2.0). Это означает, что ядро CockroachDB больше не является открытым (в соответствии с Open Source Definition от OSI), хотя полный код по-прежнему доступен и разрешено любое коммерческое использование за исключением DBaaS. Мы считаем это лучшим способом сбалансировать потребности бизнеса с нашей приверженностью Open Source. Новая лицензия позволяет подавляющему большинству пользователей свободно использовать, распространять и изменять код CockroachDB (а через три года он становится открытым безусловно).

Что к чему: как устроена BSL

Мы вводим новую лицензию CockroachDB, начиная с версии 19.2. Теперь код нельзя использовать для организации коммерческого database-as-a-service (DBaaS) без заключения соответствующего соглашения с Cockroach Labs. Трехлетнее ограничение применяется к каждому релизу.

Корпоративные дополнения CockroachDB продолжат выходить под Cockroach Community License (CCL). Работа с ними требует соответствующего лицензионного соглашения с Cockroach Labs; эта лицензия не конвертируется в Open Source через три года.

Поясним на конкретном примере. CockroachDB 19.2 (выход запланирован на октябрь 2019-го) будет первым релизом, придерживающемся новой схемы лицензирования. Он будет включать код как под BSL, так и под CCL. В октябре 2022-го (спустя три года после выходы) часть CockroachDB 19.2, подпадающая под BSL, будет конвертирована в APL. Патчи не меняют дату конверсии: конверсия всех релизов 19.2.х произойдет в октябре 2022, хотя на тот момент три года исполнится только базовому релизу 19.2.0. CockroachDB 20.1 (выпуск запланирован на апрель 2020) станет открытой в апреле 2023, и так далее.



Старых версий перемены не коснутся: CockroachDB 19.1 и дальше будет работать под лицензией Apache, и все будущие патчи 19.1.х также будут выходить под APL.

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

P.S. от переводчика

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

• «Что общего у крупных успешных Open Source-проектов?»;
• «Чудной трюк, чтобы сделать день мейнтейнеру Open Source-проекта»;
• «Знакомство с СУБД CockroachDB и создание отказоустойчивого кластера с ней на Ubuntu 16.04».