company_banner

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

Автор оригинала: Peter Mattis, Ben Darnell, Spencer Kimball
  • Перевод
Прим. перев.: Гибкость и свободы, предлагаемые 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. от переводчика


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

Флант
DevOps-as-a-Service, Kubernetes, обслуживание 24×7

Комментарии 17

    +4
    Вполне может быть, что это разумный баланс, логично платить за то, что есть основа твоего бизнеса.
      +2

      Бывает свободное программное обеспечение — которое даёт пользователям свободу использовать ПО так, как они хотят, и бывает проприетарное ПО — которое запрещает пользователям.


      Была свободная база данных — стала не свободная. Дальше можно сколько угодно рассказывать что "BSL — это почти опенсорс", но нет. Это проприетарная лицензия. Finita la Cocroach.

        0
        ну тут можно долго спорить под понятием свободы. GPL тоже нельзя использовать так, как хочется. По-настоящему свободна только WTFPL
          +1

          Увы, в WTFPL отсутствует отказ от ответственности, из-за чего перестаёт быть свободным сам автор ПО, и использовать её — сомнительная затея

            0

            А есть такая же лицензия, но с отказом от ответственности и всё такое?

              0
              Есть. Apache 2.0, MIT, The Unlicense.
              Мне больше всего нравится MIT — короткая, понятная, без ограничения на использование, но с сохранением копирайта и отказом от ответственности.

              Apache 2.0 сложнее и накладывает некоторые ограничения на внесение изменений.
              The Unlicensed — тот же MIT но дополнительно разрешает выпилить копирайт.

              choosealicense.com/licenses
                +1

                Некоторые (не я), интерпретируя фразу «all copies or substantial portions of the Software» утверждают, что текст лицензии MIT нужно обязательно копипастить в абсолютно каждый файл, содержащий код по этой самой лицензии, и что лежащий в репозитории файлик LICENSE/NOTICE этому условию не удовлетворяет. Судя по тому, что многие проекты так не делают и что разные интерпретации этой фразы вообще существуют — не такая уж она и понятная ¯\(°_o)/¯

            +3

            Свободное программное обеспечение обеспечивает свободу программному обеспечению. Code as a core virtue. Когда вы ограничиваете свободу кода, то вы делаете не свободное программное обеспечение.


            Если же вы настаиваете, что "тут есть интерпретации", то это просто узурпация названия и попытка мимикрии.

              0

              Можно сколько угодно жонглировать словами и понятиями, но игнорировать то что Амазон сотоварищи убивают бизнесы, основанные на консалтинге/saas своего опенсурс продукта — это факт.


              И описанное в статье — неплохой баланс, для конечного пользователя, если он не хочет продавать SaaS, тут ничего не меняется.

                +1

                Как бизнес-отношения — да, пожалуйста. Компания Cocroach, разрабатывающая проприетарную базу данных решила разругаться с Amazon Web Services и поменяла условия лицензии. Ужас, ужас.


                Недавно так unity с каким-то геймостриминговым сервисом так ругалась. Вполне интересная тема.


                Но не надо это "обмазывать" словами про свободу ПО. Это ПО несвободное (хоть и бесплатное) и попытка в спор хозяйствующих субъектов притащить СПО становится похоже на попытку притащить L+ права в аналогичный спор.

                  0
                  На всякий случай обозначу, что они (Cockroach Labs) словом «free» не оперируют. Говорят конкретно про «open source». Что по сути, в контексте OSD, не особую разницу играет — ведь от этого definition они, конечно, всё равно ушли (даже несмотря на попытку затмить эту суть красивым оборотом «endorsed by OSI founder Bruce Perens» :-D)… Но в смысле тех акцентов, что изначально заложены в разнице между терминами (идеологией) OS и FS… — это прямо весьма показательно.
          +1

          А будет форк от 19.x и будет свободная LaCucarachaDB.

            +4
            Благодаря вашему комментарию узнал, что «кукарача» — это таракан. Спасибо.
            0

            Либо провайдеры платят за лицензию, либо продукт исчезнет (будет что угодно но не продукт). Форк это не выход, т. к. кто в нормальном режиме будет его развивать? Провайдер? Так может ему проще заплатить за лицензию, чем развивать все форки продуктов, которые ему запрещено продавать без лицензии.

              +1
              Стопицот провайдеров предлагают сотни бесплатных дистрибутивов на выбор для установки на VPS. И считается вполне нормальным, что хостинг провайдеры бесплатно эксплуатируют то, что создали сообщества и компания. Хотя чем тут не OSaaS?
                0

                Это разное, потому что в описанном случае — просто установленный дистрибутив, а не полноценный сервис его поддержки и управления им, как в случае с DBaaS.

                  +1
                  Принимается, но 1/10 от этой бесконечности хостингов предлагает managed VPS.

            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

            Самое читаемое