Почему ElasticSearch, MongoDB и MariaDB перешли на строгие лицензии? В чем разница между ними? Как они влияют на сообщество? Читайте ниже, чтобы узнать ответы.
В предыдущей статье "Лицензия на открытый исходный код для основателей стартапов" мы рассказали о наиболее популярных вариантах лицензирования. Как правило, стартапы с открытым исходным кодом на ранних стадиях выбирают очень свободные лицензии, такие как MIT или Apache, а на более поздних стадиях переходят на более жесткие лицензии, такие как GPL.
Но времена меняются, и проекты с открытым исходным кодом становятся все более "расчетливыми". Основатели начинают проекты с открытым исходным кодом как бизнес с самого первого дня. В конечном итоге это влияет на их отношение к лицензированию. Я полагаю, что в ближайшем будущем мы увидим, как многие компании с открытым исходным кодом перейдут на тяжелые лицензии или даже примут их с самого начала.
Сегодня мы хотим рассказать о знаковых компаниях с открытым исходным кодом, которые положили начало этой тенденции тяжелого лицензирования: ElasticSearch, MongoDB и MariaDB. Почему они так решили? В чем разница между их лицензиями? Как это влияет на их сообщества? Читайте ниже, чтобы узнать ответы.
Лицензия MongoDB (SSPL)
MongoDB стала первым крупным игроком, который перешел с разрешительной лицензии на лицензию с авторским правом. В октябре 2018 года MongoDB объявила о переходе на новую лицензию под названием SSPL или server side public license. Оригинальную запись в блоге об этом можно найти здесь.
Лицензия SSPL - это очень сильная лицензия с авторским паром, и по сути это более тяжелая версия GPL. SSPL требует, чтобы любой, кто предлагает функциональность программного обеспечения или его модифицированной версии третьим сторонам в качестве услуги, должен выпустить весь исходный код, включая программное обеспечение, API и другое программное обеспечение, которое потребуется пользователю для самостоятельного запуска экземпляра услуги, под SSPL.
Другими словами, это означает, что если вы выпускаете SaaS-версию лицензированного по SSPL программного обеспечения, размещенного на AWS (или у любого другого провайдера), то вам придется выпустить весь исходный код вашего хостинг-провайдера. Таким образом, это означает, что вы не сможете создать конкурирующее SaaS-решение, используя лицензионный код SSPL. Если только у вас нет собственного хостинг-провайдера с открытым исходным кодом.
Вы видите, что основная цель лицензии SSPL - защита компании от конкурирующих SaaS-решений. Выдержка из официального FAQ подтверждает это:
Условие авторского права в разделе 13 SSPL применяется только тогда, когда вы предлагаете функциональность MongoDB или модифицированные версии MongoDB третьим лицам в качестве услуги. Для других приложений SaaS, использующих MongoDB в качестве базы данных, условие авторского права не действует.
Когда и как использовать SSPL?
SSPL используется такими компаниями, как MongoDB и Elastic (у компании есть две лицензии на выбор). SSPL довольно известен и предоставляет очень точный язык, который защищает ваше программное обеспечение от перепродажи. Главный недостаток - длинный текст, который может отпугнуть соавторов.
Чтобы использовать SSPL, нужно просто добавить его текст в репозиторий.
Лицензия Elastic (EL)
Немного истории...
В январе 2021 года ElasticSearch объявил о переходе с Apache License 2.0 на Elastic License. Это решение было обусловлено в основном тем, что AWS уже несколько лет предоставляет сервис Amazon Elasticsearch Service, который полностью основан на Elasticsearch.
Если вы знакомы с Apache License 2.0, то знаете, что AWS имела право продавать Elastic через управляемый сервис. Но, тем не менее, у них не было права использовать торговую марку Elastic, как это прямо указано в лицензии Apache License 2.0. AWS нарушила этот пункт и дополнительно создала путаницу, что Amazon Elasticsearch Service - это партнерство между AWS и Elastic.
Сочетание этих событий привело к тому, что Elastic решила изменить лицензию. Фактически, компания приняла как SSPL, так и Elastic License - пользователи могут самостоятельно выбирать, какую лицензию выбрать. Впрочем, AWS это не остановило. Они просто форкнули последнюю доступную версию Elastic под лицензией Apache и переименовали ее в "Amazon OpenSearch Service". Вот так все просто.
ELv1
Elastic License 1.0 (ELv1) - это начальная версия Elastic License. Первоначально она была введена в 2018 году для каталога X-pack исходного кода Elastic. В январе 2021 года эта лицензия была применена ко всей базе кода Elastic, но быстро была заменена на Elastic License 2.0. Если вам интересно, вы можете найти текст ELv1 здесь.
По сути, эти ELv1 и ELv2 почти идентичны - ELv2 просто короче и немного более свободна. Вероятно, вам не нужно много знать о ELv1.
ELv2
Elastic License 2.0 - это очень короткая и простая лицензия без авторского права, которая позволяет использовать, копировать и распространять программное обеспечение. Она имеет только три ограничения:
- Вы не можете предоставлять программное обеспечение другим лицам в качестве управляемой услуги.
- Вы не можете взламывать функциональность лицензионного ключа или удалять/отключать функции, защищенные лицензионными ключами
- Вы не можете удалять или скрывать любые лицензионные, авторские или другие уведомления.
Что ж, коротко и ясно. Ничего не нужно удалять, ничего не нужно добавлять.
Ограничения ELv2 и SSPL на самом деле очень похожи, за исключением одного пункта:
SSPL имеет оговорку о авторском правке, ELv2 - нет. Теоретически, с SSPL вы можете продавать программное обеспечение как управляемую услугу, если вы откроете исходный код всей инфраструктуры (концепция авторского права). В ELv2 нет пункта об авторском праве - он просто запрещает продавать программное обеспечение как управляемую услугу во всех случаях. Но на практике реальной разницы нет.
Когда и как использовать ELv2?
ELv2, очевидно, используется компанией Elastic и уже принят такими стартапами, как AriByte и OpenReplay. Это интересный показатель того, что ELv2 уже используется "молодыми" проектами.
ELv2 - это хороший выбор для "тяжелых" инфраструктурных продуктов, которые рискуют быть перепроданы хостинговыми компаниями. ELv2 защищает их от этой проблемы и в то же время не запрещает использовать программное обеспечение как часть другого продукта. Такая свобода очень важна для развития сообщества вокруг продукта.
Чтобы использовать ELv2, вам нужно просто добавить его текст в репозиторий.
Лицензия MariaDB Business Source License (BSL)
Корпорация MariaDB в 2017 году представила новую лицензию под названием BSL или Business Source License. Эта лицензия используется для MariaDB MaxScale, интеллектуального прокси-сервера баз данных. MariaDB Server - это форк сообщества сервера MySQL, который лицензируется по лицензии GPL. Как вы помните, GPL - это лицензия с авторским правом, и все производные работы от программ, лицензированных по GPL, должны быть лицензированы по GPL. Вот почему BSL применяется только к MariaDB MaxScale, а не к самому MariaDB Server.
Лицензия BSL является хитрой. По умолчанию она не разрешает коммерческое использование программного обеспечения, но гарантирует, что в будущем это программное обеспечение станет открытым исходным кодом (лицензия GPL или Apache). Да, звучит сложно, поэтому давайте разберем все пошагово.
Запрещено производственное использование
В принципе, BSL запрещает производственное использование программного обеспечения. Хотя ограниченное производственное использование может быть разрешено "Грантом на дополнительное использование". Мы поговорим об этом немного позже.
Производственное использование - довольно модный термин, как вы можете себе представить. Согласно официальному FAQ, производственное использование "обычно свидетельствует о среде, которая приносит значительную пользу бизнесу". Думаю, это можно перевести как "коммерческое использование запрещено". Конечно, лицензия BSL не признана OSI в качестве лицензии с открытым исходным кодом.
Неважно, хотите ли вы предоставлять BSL'ed программное обеспечение как услугу или просто использовать его как часть другой услуги. BSL по умолчанию запрещает оба этих случая использования, если только что-то не разрешено в "Дополнительном разрешении на использование".
Грант на дополнительное использование
"Грант на дополнительное использование" - это островок свободы в море BSL. Это очень гибкая конструкция, которая позволяет предоставлять пользователям дополнительные свободы.
Например, посмотрите на пункт "Additional Use Grant" из лицензии MariaDB MaxScale License:
| 1 2 3 4 5 6 | Licensor: MariaDB Corporation Ab Licensed Work: MariaDB MaxScale (TM) v.6.1. The Licensed Work is (c) 2021 MariaDB Corporation Ab Additional Use Grant: You may use the Licensed Work when your application uses the Licensed Work with a total of less than three server instances for any purpose. |
Таким образом, вы можете свободно использовать MariaDB MaxScale в коммерческих целях, если у вас менее трех экземпляров сервера.
Вы также можете взглянуть на это положение для Sentry и CockroachDB, которые также приняли BSL.
Дата изменения
Последняя важная часть BSL - это ее гарантия превращения в лицензию с открытым исходным кодом где-то в будущем. Давайте снова посмотрим на лицензию MariaDB MaxScale:
| 1 2 3 4 | Change Date: 2026-03-08 Change License: Version 2 or later of the GNU General Public License as published by the Free Software Foundation. |
Пункт Change Date фактически говорит, когда эта программа изменит лицензию. Если дата не указана, то она равна 4 годам со дня выпуска кода.
В пункте Change License указывается лицензия, которая станет активной в дату изменения. Change License может быть любой BSL-совместимой лицензией, такой как GPL или Apache 2.0.
Интересен тот факт, что дату изменения можно изменять сколько угодно раз. Это фактически позволяет устанавливать разные даты для разных версий программного обеспечения. Например, MariaDB MaxScale 2.0 уже является открытым исходным кодом и лицензией GPL, но MariaDB MaxScale 6.2 планируется сделать открытым исходным кодом только в 2026 году.
Когда и как использовать BSL?
BSL используется такими компаниями, как MariaDB, Sentry и CockroachDB. Вероятно, это самая гибкая лицензия из всех существующих. Она может быть хорошим выбором для компаний, где функциональность существенно меняется от версии к версии - новые версии будут защищены от коммерческого использования, а старые будут автоматически выпущены по разрешительной лицензии.
Чтобы использовать BSL, нужно просто включить текст лицензии в репозиторий.
Apache 2.0 с оговоркой об авторском праве
Последней, но не последней в списке сильных лицензий является Apache 2.0 с Commons Clause. Это хорошо известная лицензия Apache 2.0 с довольно коротким преамбулой под названием "Commons Clause". Давайте посмотрим на формулировку этого пункта из репозитория n8n:
| 1 2 3 4 5 6 7 8 9 10 11 12 | "Commons Clause" License Condition v1.0 The Software is provided to you by the Licensor under the License, as defined below, subject to the following condition. Without limiting other conditions in the License, the grant of rights under the License will not include, and the License does not grant to you, the right to Sell the Software. For purposes of the foregoing, "Sell" means practicing any or all of the rights granted to you under the License to provide to third parties, for a fee or other consideration (including without limitation fees for hosting or consulting/ support services related to the Software), a product or service whose value derives, entirely or substantially, from the functionality of the Software. Any license notice or attribution required by the License must also include this Commons Clause License Condition notice. |
По сути, этот пункт гласит, что вы можете делать с программным обеспечением все, что угодно, как сказано ниже в Apache License 2.o, но вы не можете "продавать" это программное обеспечение. Оно прямо запрещает предоставлять платные услуги хостинга, консалтинга или поддержки для этого программного обеспечения.
Положительным моментом в Commons Clause является то, что можно продавать производную версию программного обеспечения, которая "существенно" отличается. Я проясню этот вопрос немного позже.
Apache 2.0 с добавленной Commons Clause больше не считается лицензией OSI на открытый исходный код. В двух словах: это компромисс между разрешительной лицензией и лицензией с авторским правом, но у нее есть некоторые врожденные недостатки.
Положение об авторских правах
Положение об общине было первоначально разработано Хизер Микер, известным экспертом по лицензированию открытых исходных кодов. Теоретически, это положение может применяться к различным разрешительным лицензиям, таким как MIT, Apache и BSD. Но все же Apache является наиболее распространенным вариантом.
В статье Commons Clause используется модный термин "существенная производная". Вероятно, его следует понимать как ограничение на продажу производного продукта, который добавляет лишь несущественную ценность к программному обеспечению - например, изменяет имена, API или подписи функций. Как вы понимаете, это определение может трактоваться очень по-разному, поэтому на практике использование лицензированного по Commons Clause программного обеспечения внутри платного продукта довольно рискованно.
Еще одна проблема с Commons Clause - путаница. Когда разработчики видят Apache 2.0, они ждут Apache 2.0. Но Commons Clause переворачивает все с ног на голову, поэтому от Apache 2.0 практически ничего не остается, несмотря на то, что его текст идет сразу после Commons Clause.
Когда и как использовать Apache 2.0 с Commons Clause?
Ну, чтобы использовать этот вариант лицензирования, вы должны просто добавить лицензию рядом с вашим репозиторием. Вы просто берете текст Apache 2.o, текст Commons Clause и помещаете первый текст перед первым. Все просто.
Apache 2.0 с Commons Clause используется такими компаниями, как n8n и Redis Labs (для некоторых модулей). По-видимому, Commons Clause может быть "мягким" вариантом перехода от полностью разрешительной лицензии к более сильной версии. Но, на мой взгляд, путаница, создаваемая этой лицензией, перевешивает ее "мягкость".
Влияние на общество
Общим недостатком всех упомянутых здесь лицензий является влияние на сообщество. Они не признаны Open Source Initiative (OSI) в качестве лицензий с открытым исходным кодом, поскольку нарушают 6-й пункт из определения программного обеспечения с открытым исходным кодом. В этом пункте говорится, что лицензия с открытым исходным кодом не должна ограничивать кого-либо в использовании программного обеспечения в определенной области или деятельности.
Кроме того, есть некоторые признаки недовольства сообщества новой тенденцией лицензирования. Например, недавно появилась альтернатива MongoDB с "действительно открытым исходным кодом". Посмотрите, как FerretDB обвиняет MongoDB в "отказе от своих корней с открытым исходным кодом".
Такие гиганты, как MongoDB, вряд ли много потеряют от этого разочарования. Но следует помнить, что это может нанести существенный вред стартапу с открытым исходным кодом на ранней стадии, который только ищет соответствие продукта и сообщества.
На мой взгляд, есть три важных аспекта, минимизирующих влияние на сообщество:
- Лицензия должна быть короткой, простой и понятной
- Она должна запрещать только прямую перепродажу программного обеспечения. Использование программного обеспечения как части другого сервиса не должно быть запрещено.
- Она не должна запутывать разработчиков
Заключительные слова
Выбор лицензии - дело непростое, но мы надеемся, что эта статья прольет свет на эту сложную тему.