В Redis Labs уже второй раз за последние полгода меняют модель лицензирования для ряда своих продуктов. Сейчас компания переходит с Apache 2.0 Commons Clause на Redis Source Available License (RSAL). Поговорим о причинах этого решения и особенностях RSAL.
/ Pixino / congerdesign / PD
Redis Labs уже не первый раз меняет лицензию на свои продукты. В августе прошлого года компания перевела несколько модулей — Redis Graph, ReJSON и др. — с лицензии GNU AGPL на Apache 2.0 Commons Clause. Тем самым компания запретила продажу оригинальных модулей сторонними организациями. Однако это привело к неприятным последствиям.
Во-первых, новая лицензия стала причиной путаницы и непонимания. Некоторые пользователи ошибочно решили, что работа с модулями теперь регулируется только Apache 2.0 (без Commons Clause). Во-вторых, запрет на продажу решений Redis «нанес удар» по открытому ПО. К примеру, часть сервисов были вынуждены удалить разработчики Debian и Fedora. Им пришлось создавать форки репозиториев модулей Redis и объединять их в проект GoodFORM.
Команда Redis Labs также столкнулась с непредвиденными трудностями. Ограничения лицензии замедлили рост сообщества вокруг продуктов, хотя ожидалось, что эффект будет прямо противоположным. Всё это привело к тому, что в Redis Labs создали свою лицензию, заточенную под нужды и особенности компании — RSAL.
Согласно условиям RSAL, разработчики могут использовать модули RediSearch, RedisGraph, RedisJSON, RedisBloom, RedisML и несколько других в своих сервисах, менять исходный код и внедрять его в приложения. Итоговые решения можно распространять и продавать.
RSAL ограничивает только тип конечных продуктов. Приложение на основе обозначенных модулей не может быть базой данных, инструментом для кэширования и индексирования, поисковым движком или софтом для работы с машинным обучением.
Цель этих ограничений — исключить коммерческую реализацию модулей конкурирующими компаниями без ущерба для сообщества Redis. Что касается самого ядра Redis, то как и в прошлый раз, оно остается открытым и распространяется под лицензией BSD. Для его поддержки в компании создали отдельную команду, которая будет управлять разработкой ядра независимо от того, что происходит с остальными компонентами.
/ Flickr / Mark Hougaard Jensen / CC BY-SA
Некоторые представители комьюнити полагают, что повторная смена лицензии может стать очередной ошибкой. Мэтт Эсей (Matt Asay) из Adobe не согласен с утверждением, что крупные корпорации, которые продают ПО на базе открытых продуктов, негативно влияют на развитие open source экосистемы. Он говорит, что такие организации, наоборот, помогают распространять открытые продукты на глобальном рынке.
Видение Redis также не разделяет Гордон Хафф (Gordon Haff), глава подразделения облачных технологий в Red Hat. Он считает, что за счет лицензирования в Redis пытаются «усидеть на двух стульях» — получать прибыль от продажи модулей и быть open source компанией.
Apache-гуру из Red Hat Рич Боуэн (Rich Bowen) назвал решение компании «бессмысленным». По его мнению, люди, которые приходят в open source, ожидают увидеть бесплатные решения и им едва ли захочется разбираться в каких-то ограничениях и условиях. С ним согласны члены организации Open Source Initiative (OSI). Они заявляют, что действия Redis противоречат определению и принципам открытого ПО.
Есть и те, кто видит смысл в переходе на новую лицензию. Например, руководитель BaenCapital отмечает, что корпорации, которые выстраивают свои продукты на основе открытого ПО, поступают неэтично. Поэтому действия Redis вполне понятны — с помощью новых лицензий компания защищает свои интересы и права разработчиков.
Один из создателей Ansible Майкл Дехаан (Michael DeHaan) тоже считает, что если весь софт распространять бесплатно, большинство проектов просто не выживет. Не всем компаниям удается привлечь инвесторов, поэтому продажа отдельных компонентов крупным организациям — один из способов удержаться на рынке.
Redis Labs — не единственные, кто пробует разные подходы к лицензированию. Так, в октябре 2018 MongoDB перешли с GNU AGPL на собственную версию GNU 3 — Server-Side Public License (SSPL). Цель смены лицензии та же, что и у Redis — не дать сторонним компаниям «упаковывать» и перепродавать открытую СУБД.
Авторы проекта Confluent тоже отказались от Apache 2.0 в пользу своего варианта — Confluent Community License. Условия новой лицензии запрещают продавать KSQL как проприетарное решение. Хотя реализовывать SaaS-сервисы на этом SQL-движке, все так же разрешено.
Есть и другие примеры компаний, где часть решений реализуют за деньги. Среди них — Elasticsearch, Hadoop, Berkeley DB и десятки других.
/ Pixino / congerdesign / PD
Немного истории
Redis Labs уже не первый раз меняет лицензию на свои продукты. В августе прошлого года компания перевела несколько модулей — Redis Graph, ReJSON и др. — с лицензии GNU AGPL на Apache 2.0 Commons Clause. Тем самым компания запретила продажу оригинальных модулей сторонними организациями. Однако это привело к неприятным последствиям.
Во-первых, новая лицензия стала причиной путаницы и непонимания. Некоторые пользователи ошибочно решили, что работа с модулями теперь регулируется только Apache 2.0 (без Commons Clause). Во-вторых, запрет на продажу решений Redis «нанес удар» по открытому ПО. К примеру, часть сервисов были вынуждены удалить разработчики Debian и Fedora. Им пришлось создавать форки репозиториев модулей Redis и объединять их в проект GoodFORM.
Команда Redis Labs также столкнулась с непредвиденными трудностями. Ограничения лицензии замедлили рост сообщества вокруг продуктов, хотя ожидалось, что эффект будет прямо противоположным. Всё это привело к тому, что в Redis Labs создали свою лицензию, заточенную под нужды и особенности компании — RSAL.
Что собой представляет новая лицензия
Согласно условиям RSAL, разработчики могут использовать модули RediSearch, RedisGraph, RedisJSON, RedisBloom, RedisML и несколько других в своих сервисах, менять исходный код и внедрять его в приложения. Итоговые решения можно распространять и продавать.
RSAL ограничивает только тип конечных продуктов. Приложение на основе обозначенных модулей не может быть базой данных, инструментом для кэширования и индексирования, поисковым движком или софтом для работы с машинным обучением.
Во всех остальных случаях разработанное ПО можно использовать и распространять с пометкой: This software is subject to the terms of the Redis Source Available License Agreement.
Цель этих ограничений — исключить коммерческую реализацию модулей конкурирующими компаниями без ущерба для сообщества Redis. Что касается самого ядра Redis, то как и в прошлый раз, оно остается открытым и распространяется под лицензией BSD. Для его поддержки в компании создали отдельную команду, которая будет управлять разработкой ядра независимо от того, что происходит с остальными компонентами.
/ Flickr / Mark Hougaard Jensen / CC BY-SA
Что думает сообщество
Некоторые представители комьюнити полагают, что повторная смена лицензии может стать очередной ошибкой. Мэтт Эсей (Matt Asay) из Adobe не согласен с утверждением, что крупные корпорации, которые продают ПО на базе открытых продуктов, негативно влияют на развитие open source экосистемы. Он говорит, что такие организации, наоборот, помогают распространять открытые продукты на глобальном рынке.
Видение Redis также не разделяет Гордон Хафф (Gordon Haff), глава подразделения облачных технологий в Red Hat. Он считает, что за счет лицензирования в Redis пытаются «усидеть на двух стульях» — получать прибыль от продажи модулей и быть open source компанией.
Apache-гуру из Red Hat Рич Боуэн (Rich Bowen) назвал решение компании «бессмысленным». По его мнению, люди, которые приходят в open source, ожидают увидеть бесплатные решения и им едва ли захочется разбираться в каких-то ограничениях и условиях. С ним согласны члены организации Open Source Initiative (OSI). Они заявляют, что действия Redis противоречат определению и принципам открытого ПО.
Есть и те, кто видит смысл в переходе на новую лицензию. Например, руководитель BaenCapital отмечает, что корпорации, которые выстраивают свои продукты на основе открытого ПО, поступают неэтично. Поэтому действия Redis вполне понятны — с помощью новых лицензий компания защищает свои интересы и права разработчиков.
Один из создателей Ansible Майкл Дехаан (Michael DeHaan) тоже считает, что если весь софт распространять бесплатно, большинство проектов просто не выживет. Не всем компаниям удается привлечь инвесторов, поэтому продажа отдельных компонентов крупным организациям — один из способов удержаться на рынке.
Кто еще недавно менял лицензию
Redis Labs — не единственные, кто пробует разные подходы к лицензированию. Так, в октябре 2018 MongoDB перешли с GNU AGPL на собственную версию GNU 3 — Server-Side Public License (SSPL). Цель смены лицензии та же, что и у Redis — не дать сторонним компаниям «упаковывать» и перепродавать открытую СУБД.
Авторы проекта Confluent тоже отказались от Apache 2.0 в пользу своего варианта — Confluent Community License. Условия новой лицензии запрещают продавать KSQL как проприетарное решение. Хотя реализовывать SaaS-сервисы на этом SQL-движке, все так же разрешено.
Есть и другие примеры компаний, где часть решений реализуют за деньги. Среди них — Elasticsearch, Hadoop, Berkeley DB и десятки других.
«Бесплатных проектов вроде Linux-ядра, WordPress или GIMP становится все меньше. Разработчики открытого ПО выстраивают бизнес-модели в попытке найти баланс между доходом и свободным распространением продуктов без ущерба для компании, — комментирует Сергей Белкин, начальник отдела развития провайдера виртуальной инфраструктура 1cloud.ru. — Но в ИТ-сообществе еще достаточно тех, кто выступает против изменений концепции open source. Поэтому в ближайшее время полностью свободное ПО не исчезнет с рынка, как бы ни менялись лицензии на отдельные продукты и их компоненты».
rsashka
Код как был открытым, так и остается.
Проблемы возникают в случае коммерциализации на базе подобных решений.
Но в этому случае владелец софта в своем праве, и никому ничего не обязан, захотел дал (выпустил под свободной лицензией), а захотел взял назад (поменял лицензию на не свободную).
Так же как и пользователи, если не согласны с подобной сменой, вольный форкнуться и начать играть в своей песочнице.
andreymal
https://ru.wikipedia.org/wiki/Определение_Open_Source пункт 1 например
rsashka
Цитата как раз оттуда:
вот только необходимость соответствия требуется только тем, кто хочет использовать логотип Open Source Initiative (OSI).Во всех остальных случаях под данным термином лучше понимать доступность исходников и не более того. Иначе можно очень сильно напороться на различные проблемы, как например в данном случае. Код Open Source, а лицензия не свободная.
andreymal
Windows 2000 и Opera 12 — опенсорс, окей
rsashka
Если код открыт владельцем, то так оно и есть.
andreymal
Ну вот уже начали выдумывать какие-то дополнительные условия, которых изначально в ваших утверждениях не было. А могли бы просто взять общепринятое определение от Open Source Initiative и не вводить в заблуждение ни других, ни самого себя
rsashka
Не передергивайте, и не пытайтесь сказать за меня того, что я не говорил.
Если украсть исходники и опубликовали их в интернете, то продукт от этого не будет ни открытым, ни свободным.
И я сказал, что только владелец имеет право принимать решение о публикации исходников и условиях их дальнейшего использования.
И только владелец принимает решение, как это называть. Может назвать Open Source, может Open Core или Shared Source, суть то от этого не изменится.
Причем это может делаться как раз с целью, что бы заполучить простодушных последователей, которые поведутся на знакомые слова не понимая их сути и юридических последствий.
andreymal
Не отмазывайтесь. Вы сказали: «доступность исходников и не более того». Про открытие владельцем в этом утверждении не было ни слова. Вы даже «законная доступность исходников» не стали писать. Windows 2000 и Opera 12 под ваше утверждение отлично подходят.
Поэтому и нужно не вестись какие попало утверждения и использовать определение от Open Source Initiative, согласно которому Redis (точнее, его аддоны) — больше не Open Source.
jreznot
Для читающих по диагонали. Сам Redis под лицензией BSD, а значит Open Source. Его аддоны — нет.
andreymal
Подзабыл об этом, спасибо
rsashka
А еще, я пропустил пару запятых и сделал три орфографические ошибки.
andreymal
А здесь забыли букву «ё» и поставили лишнюю запятую.)
Передёргивать тексты комментариев можно до бесконечности, и лучше с этим заканчивать, тем не менее толковать Open Source отлично от определения от OSI нет практического смысла именно по указанным вами причинам.
rsashka
andreymal
Да хотя бы с тем, что «Да используй как хочешь» приводит к тому самому бардаку, который вы устроили здесь в комментариях, пытаясь защищать выдуманное вами самими определение Open Source.
rsashka
Ой, что еще на этот раз, опять запятую пропустил?
Я не состою в OSI, поэтому мне, как и большинству, не нужно соблюдать рекомендации по использованию данного термина
Термин Open Source уже давно эксплуатируют кто во что горазд, и мне действительно печально, что грамотные люди-технари обычно слабо разбираются в юридических вопросах, чем часто пользуются ушлые юристы. А потом все поднимают хай по поводу вселенской несправедливости.
Поэтому я и написал первый комментарий про то, что нужно лицензию смотреть, а не опираться на «толкование» того или иного термина.
andreymal
Достаточно опираться на толкование OSI. Из этого автоматически вытекает необходимость смотреть лицензию.
У вас какая-то личная неприязнь к OSI или в чём проблема-то?
rsashka
Я раз за вас, и ваше автоматическое вытекание толкований.
rsashka
andreymal
И что? Это причина не использовать данное определение и выдумывать свой опенсорс, или в чём дело-то?
rsashka
Да используй как хочешь.
Я именно про это и говорю, что назваться Open Source может кто угодно.