All streams
Search
Write a publication
Pull to refresh
84
0
Тимур Тукаев @TimurTukaev

Head of Marketing @ Ænix, Open Source Enthusiast

Send message

Собственно, MariaDB как раз идет по пути Open Core, когда лицензия на ядро соответствует определению OSI, а ряд коммерчески привлекательных компонентов лицензируются по-другому. Что касается ухода команды, то тут такой момент: была core-команда, которая определяла развитие продукта и делала основную часть работы. А потом она уходит — и естественно, что просто в силу того., что она была и закрывала большой скоуп задач, другая такая, но уже свободная, состоящая из волонтеров, команда практически не имела возможности нормально сформироваться. Ну и BSL довольно хитрая лицензия:) Большинству пользователей она и дальше, думаю, будет вполне ок, так что остается совсем мизерный шанс на то, что кто-то начнет форкать и развивать старые версии их продуктов дальше:) Ну это просто жизнь такая:)

Ну и если бы все в жизни работало так прямолинейно, то было бы очень просто жить:)

Повторюсь, тут речь идет о том, что разрушается сама экосистема FOSS. А она, существуя, приносит гораздо большую ценность для всей индустрии, даже несмотря на то, что ее правилами пользуются недобросовестные участники. Плюс момент с обвинением тех, кто не контрибьютит именно в продукты HashiCorp, но использует их для извлечения выгоды — я вот не уверен, например, что сама HashiCorp контрибьютит прям во все FOSS-проекты, которыми пользуется в работе. Повторюсь — их мотивация вполне понятна, но мне лично все равно грустно от того, что каждое такой действие постепенно может разрушать экосистему FOSS. Ну и что касается прав на свои продукты — ребята сами говорят об этике, как о серьезном мотиваторе для изменения лицензий на свои продукты («такое поведение не соответствует духу Open Source»). Но фактически своими действиями создают неудобную ситуацию и для многих добросовестных участников системы. Опять же, дать обещание рынку, лицензировав свои продукты под одной лицензией, в какой-то момент передумать и сделать другую — тоже своего рода этический момент. Да, они имеют на это право, да, осуждать их, возможно, и не стоит, но момент в любом случае несколько скользкий и отрицать это, кажется, нет смысла.

К сожалению, в любой системе будут проявляться «читеры», которые стремятся использовать правила системы таким образом, чтобы извлекать выгоду максимально легко и недобросовестно, при этом как бы играя по формальным правилам системы. Проблема в том, что подобные действия «читеров» негативно сказываются на добропорядочных участниках этой системы. А когда в экосистеме Free Software и Open Source Software происходят такие перелицензирования в довольно крупных продуктах, это бьет далеко не только по «читерам», но и по куче добросовестных участников. Более того, раз за разом после подобных изменений в рынке сама экосистема FOSS ослабевает и по капле теряет свою ценность. И ту хотелось бы найти какой-то баланс между борьбой системы с «читерами», которую не получится вести исключительно на формальном. юридическом поле (просто потому, что все кейсы не описать), и негативным воздействием на добросовестных участников. А экосистема FOSS реально несет огромную ценность для всех ее участников. И без нее ИТ-мир будет совсем не тем.

Мотивация HashiCorp вполне понятна и объяснима. Но это не отменяет того, что новость важная и действия HashiCorp создают риски для многих компаний, которые использовали их решения в своих продуктах.

Да, действительно имеют право. Но факт и в том, что они отказались от Open Source-лицензии в определении Open Source Initiative. Тут момент такой: представьте, что вы строили бизнес на некоем Open Source-решении, а вендор говорил, что Open Source — это его жизнь и душа:) И в какой-то момент вендор в одностороннем порядке говорит, что так больше не работает. Да, он имеет право, да, его вполне можно понять. Но ведь вы вполне могли контрибьютить в другие Open Source-решения и быть вполне добросовестным пользователем OSS. Да и определение ограничений в лицензии довольно туманное, что тоже формирует некоторые риски: You may make production use of the Licensed Work, provided such use does not include offering the Licensed Work to third parties on a hosted or embedded basis which is competitive with HashiCorp's products.

Конечно, HashiCorp делает очень крутые продукты. Но такие моменты с лицензиями в любом случае заставляют задумываться о рисках, связанных с использованием их решений в коммерческих проектах — и это столь же объяснимо и понятно, как и право HashiCorp на изменение условий.

Там самый важный момент вот в этой части лицензии: You may make production use of the Licensed Work, provided such use does not include offering the Licensed Work to third parties on a hosted or embedded basis which is competitive with HashiCorp's products.

И если смотреть объективно, то кто будет решать, конкурирует компания с HashiCorp или нет? А если завтра HashiCorp разработает новый продукт и компании, которые использовали их решения в продуктах, которые им конкурентами не являлись, вдруг станут их конкурентами (потому что новый продукт будет с ними конкурировать). Достаточно скользский момент, на мой взгляд. И самое главное — они дали другим компаниям выстраивать бизнес, опираясь на их продукты. Как бы негласно давая обещание, что все так и будет продолжаться. А теперь в одностороннем порядке эту возможность отбирают. А ведь среди таких компаний вполне могут быть (хотя и не факт, что есть) контрибьюторы в их продукты. Или в другие Open Source-проекты. А таким заявлением все компании, которые строят свою бизнес-модель на решениях HashiCorp, но не контрибьютят именно в продукты HashiCorp, как бы приравниваются к негодяям:) А ведь они вполне могут вносить большой вклад в другие проекты. Free Software и Open Source Software в определении OSI на практике как раз ведь и подразумевают такую модель, при которой компании и отдельные разработчики могут участвовать не в тех проектах, которые они используют в своих проектах. Понимаю, что написал очень запутанно, но надеюсь, будет понятно:)

Это хороший пойнт, спасибо за разъяснение позиции! Так гораздо понятнее стало, о чем речь. Момент про размывание, о котором говорит Столлман, лично мне тоже близок, я с ним тут согласен. И на самом деле в какой-то степени прискорбно, что две очень близких философии настолько сильно расходятся в некоторых моментах, что местами доходят до «внутривидовой агрессии».

Не уверен, что Open Source существовал до них именно в качестве термина — словосочетанием он был, это факт. И сочетание это применялось в том числе к проприетарным программам, которые на каких-то условиях могли делиться с пользователями исходниками. А общеупотребительные слова и сочетания действительно отказываются регистрировать в качестве торговых марок. А вот Open Source-лицензия или Open Source Software — достаточно однозначные сочетания. Да, возможно, на них ни у кого нет юридических прав. Но это не делает их менее конкретными. Можно наполнять их любым смыслом, но де-факто в ИТ у них достаточно однозначная трактовка и ведет она к критериям, разработанным OSI. Посмотрите даже на текст упомянутого в новости заявления HashiCorp — они там сами нигде не говорят «мы остались Open Source». Напротив, подчеркивают, что модель Open Source принесла им проблемы. Более того, когда заканчивается вводная часть заявления HashiCorp и речь начинает идти о BSL, сочетание Open Source вообще пропадает из текста.

Из Википедии: «Термин open source (с англ. — «программное обеспечение с открытыми исходными кодами») был использован в качестве определения в 1998 году Эриком Реймондом и Брюсом Перенсом, которые утверждали, что термин free software (свободное программное обеспечение) в английском языке неоднозначен и смущает многих предпринимателей». А Эрик Реймонд и Брюс Перенс как раз являются основателями OSI. Соответственно, они придумали этот термин, они под него и создали OSI и OSD. Компании могут выкладывать исходники под своими условиями, но именно термин Open Source изначально появился под философию OSI. Так что все же это мешает продукту быть аутентичным Open Source:)

Небольшое уточнение: выйдет не в составе EE, а именно для enterprise-клиентов.

Планируем, что в Deckhouse EE Commander появится в четвертом квартале 2023 года. По выходу в Deckhouse CE пока планов нет, но в будущем всё может быть:)

Тут вряд ли идёт речь именно о совместимости. Насколько я понял, имеется в виду некий отдельный модуль для подключения сторонних модулей и плейбуков. И то эта фича особенно подчеркивается для этапа первых релизов, пока своих модулей практически нет. Вроде бы ставку делают в итоге именно на свою экосистему.

Релиза ещё не было, код на GitHub тоже пока не выложен. Так что в данный момент это скорее на уровне обещаний разработчика. Вероятно, в Discord-чате проекта могут такие детали прояснить (ссылка на него есть на сайте jet).

Судя по всему, с глобальной блокировкой ситуация уже не такая однозначная. В Python могут принять PEP 703 – Making the Global Interpreter Lock Optional in CPython: https://peps.python.org/pep-0703/

Самым первым в комментариях отписался как раз один из основателей Coroot. Можно ему в комментариях задать вопрос

Справедливости ради, после публикации она появилась в нескольких тематических каналах и чатах (по желанию владельцев этих каналов и участников чатов), и ее там приняли достаточно хорошо. Если отвечать на вопрос, релевантна ли она для топа российских ИТ-новостей, — да, на самом деле релевантна. Именно для DevOps-отрасли это действительно важное событие, которое может многое изменить и повлиять на рынок.

Information

Rating
Does not participate
Location
Россия
Works in
Registered
Activity

Specialization

Marketing Director, Редактор
Lead
People management
Project management
Content Marketing
Literary editing
Linux
DevRel