Как собрать гибридное облако с помощью Kubernetes, которое может заменить DBaaS

Ну не бинарники а исходники. Ну не Yam a Yum все верно — есть мелкие недочеты в расшифровке. Суть главное в том что мир стремится к упрощению :)

Чем для вас опасна MongoDB SSPL лицензия?

Что вы имеете ввиду?

Чем для вас опасна MongoDB SSPL лицензия?

Позиции компаний конечно разные но здесь вопрос больше в подходу к Бизнесу. Тактики MongoDB куда более близки к Oracle чем к другим Open Source компаниям.

Например (из личного опыта) большинство MongoDB user groups/meetups по всему миру контролируются прямо или коственно MongoDB и конкуренты туда ни в коем случае не допускаются.

Чем для вас опасна MongoDB SSPL лицензия?

Есть задачи которые в MongoDB решаются удобнее есть которые удобнее решаются в PostgreSQL — например когда к этому JSON хочется применить все возможности SQL.

Многие задачи где используется MongoDB весьма просты.

Чем для вас опасна MongoDB SSPL лицензия?

Давайте представим что есть софт для которого раздавать исходники можно а вот собранные RPM/DEB пакеты уже нельзя. Конечно для тех кто предпочитает собирать все для себя из исходников для них это не проблема… но таких людей становится все меньше люди используют стандартные сборки и репозитории так как так проще и эффективней

Так вот DBaaS это то же самое что пакеты для Cloud — решение которое для большинства пользователей (возможно не для вас) более удобное и эффективое.

Соответственно монополия для этого режима использования софта создает все те риски которые Open Source позволяет избежать

Чем для вас опасна MongoDB SSPL лицензия?

Можно конечно. Это если вы разработчик и сами принимаете решения — во многих случаях разработчики умеют использовать MongoDB и хотят именно ее (ну или на худой конец что-то полностью совместимое)

Есть и технические проблемы — в MongoDB «sharding» встроенный и стандартный тогда как в PostgreSQL, MySQL (DocStore) это приходится делать отдельно и ручками.

Чем для вас опасна MongoDB SSPL лицензия?

Решил перевести одну из достаточно новых статей и эта казалось была бы интересна для аудитории Habr.

Пишу об этой проблеме сейчас так как хочется предотватить «инфляцию» Open Source — многие компании сейчас рекламирует Open Core, Shared Source (SSPL, BSL), Open Source Compatible (Amazon Aurora) как в общем то эквивалентную Open Source и многие молодые инжинеры тоже не совсем понимают в чем разница и почему лучше по возможности предпочитать Open Source.

Percona Server for MongoDB тоже SSPL (к сожалению) так как другого выбора без полного форка нет. Но другой софт для MongoDB — Percona Backup for MongoDB, Kubernetes Operator распространяются под открытыми лицензиями.

Чем для вас опасна MongoDB SSPL лицензия?

Тут на самом деле интересно. MongoDB изначала использовала лицензию AGPL а не GPL для того чтобы Amazon и другие не смогли сделать Cloud версию. Но когда на самом деле стали появлятся Cloud версии которые предоставляют MongoDB (compose.io, mlab.com objectrocket.com и многие другие) оказалось что AGPL не достаточно чтобы надежно предотврвтить такие бизнесы и MongoDB перешла на SSPL

Чем для вас опасна MongoDB SSPL лицензия?

DocumentDB не базируется на MongoDB. По неподтвержденным слушам это MongoDB протокол поверх Aurora PostgreSQL.

Есть еще CosmosDB (Azure) тоже независимая имплемениация базового протокола MongoDB

Чем для вас опасна MongoDB SSPL лицензия?

SSPL Не CopyLeft лиценция такие как SSPL и AGPL так как ограничения накладываются на использование а не распространение.

Если интересно посмотрите дискуссию по этому поводу

lists.opensource.org/pipermail/license-review_lists.opensource.org/2018-November/thread.html#3800

SSPL относится к классу «Source Available» лицензий — не открытому/свободному програмному обеспечения.