Comments 36
Коммерческие компании против того, чтобы некоммерческие становились коммерческими. Вот это новость!
Да не, тут скорее начало доходить, что определение от Open Source Initiative нужно только для использования их логотипа, но не делает код с названием «Open Source» сводным ПО (Free Software).

Кстати интересно, какое место в распределении доходов после смены лицензии выделяется для рядовых контрибьюторов. А то сначала разрабатывали сообща как open source, а потом оказывается, что какие-то чуваки этим владеют и могут менять лицензии как им вздумается.

Open Source != Free Source. Если бы линукс появился сейчас, его бы просто форкнул условный Амазон или Интел, навтыкал туда зондов и вообще неизвестно что было б на рынке серверных OS. Форкнуть линукс дорого, а форкнуть редис или монгу легко и бесплатно. IT гиганты просто паразитируют на open source.


Если такая тенденция сохранится, то качественный открытый и свободный софт просто постепенно исчезнет.

Форкнуть линукс дорого

Разработчики из реестра российского ПО готовы с вами поспорить)


Чем вам мешает форк монги? Куда делись принципы меритократии? Мне казалось, что опенсорс это про желание совместить альтруизм со своим хобби или работой, а получается, что вот мы сделали полусырой продукт, доработать его до качественного уровня мы не можем или не очень хотим, у вас тоже на это нет ресурсов, ну а другим это делать низзя. Вот и пользуйтесь и плюйтесь или не пользуйтесь.
На этом фоне отлично выглядит вирусные лицензии. Сделайте лицензию на подобии gnu gpl и заставьте эти чертовы корпорации давать пользу, если они хотят зарабатывать. От этого выиграют все, продукт будет расти семимильными шагами, а каждый сможет его использовать как минимум пропорционально вкладу.
Они просто хотят получить все плюсы опенсорсного по и зарабатывать как на закрытом по. Но держать планку, которую должно держать качественное закрытое по они таки не могут… и платить им как закрытому по никто не будет. Это просто тормозит развитие и все.

Сделайте лицензию на подобии gnu gpl и заставьте эти чертовы корпорации давать пользу, если они хотят зарабатывать

Мне тоже кажется, что это самый адекватный способ решения проблемы. *Надеваю шапочку из фольги* Но кое-кому, учитывая историю с RMS, кое-кому, видимо, так не кажется.

А почему программные продукты такие хитровывернутые, что нужны прослойки в виде "облачных" сервисов для их разворачивания? А?

Кто сказал что "нужны" и продуктами нельзя воспользоваться без прослойки облачных сервисов?

Не "нужны", а "упрощает жизнь" часто. А часто и усложняет. Но в целом очень многие сейчас отказываются от аренды голого железа, не говоря о покупке, в пользу разных *aaS.

Обычно SaaS берут чтобы не создавать или сократить количество сисадминов у себя в конторе (каждый из которых стоит ~100k usd в год в сша например)

Цель — запретить крупным ИТ-компаниям коммерциализировать их программное обеспечение в том или ином виде.

Ну, это же, мягко говоря, неправда.

Смотрите, есть условный Elastic, развивающий открытый продукт, а есть условный Amazon, который проворачивает с продуктом Elastic − ES − следующую нехитрую схему:

  1. Запускает ES в виде готового сервиса,
  2. Получает большую долю пользователей ES, которым лень в apt-get install,
  3. Вносит в API своего ES такие изменения, которые делают сервис несовместимым с оригинальным, открытым ES,
  4. Сообщество забивает на открытый ES, Elastic закрывается,
  5. Amazon выкручивает монетизацию своего ES на 11.

То есть условный Elastic в данном случае не «запрещает монетизировать», а старается элементарно выжить и защитить сообщество.
Получает большую долю пользователей ES, которым лень в apt-get install

Если бы там всё устанавливалось одной командой… В реальности там нужно курить мануалы вроде вот этого, а потом ещё разбираться, почему же установка по мануалу не сработала, курить форумы и т.п., так что, ничего удивительного, что люди готовы платить, чтоб только с этим не связываться. Сделайте, чтоб действительно всё устанавливалось одной командой и после этого работало как часы, будет другой разговор.

Вносит в API своего ES такие изменения, которые делают сервис несовместимым с оригинальным, открытым ES

Что мешает поддержать те же изменения в бесплатном продукте, чтоб совместимость восстановилась?
Сделайте, чтоб действительно всё устанавливалось одной командой и после этого работало как часы, будет другой разговор.

Чтобы три разных профессиональных продукта устанавливались и настраивались одной командой? Серьёзно?

Что мешает поддержать те же изменения в бесплатном продукте, чтоб совместимость восстановилась?

Прежде всего то, что условный Amazon не делится своим кодом с сообществом, в отличие от условного Elastic.
Прежде всего то, что условный Amazon не делится своим кодом с сообществом, в отличие от условного Elastic.

А разве AGPLv3 не помогла бы этого избежать?

Возможно, помогла бы, но вот MongoDB говорит, что может и не помочь. Или у условного Elastic есть другие причины сохранять пермиссивную лицензию. Я думаю, что это уже вопрос второстепенный. Пусть лучше будет пермиссивная и коммерческая лицензии, чем закрытый код.
Elasticsearch Service вообще говоря крутит опенсурсный ES на выбор вплоть до смены лицензии Elastic Co, из-за чего они форкнули проект под той же лицензией Apache 2.0 и следующие версии будут только их дистрибутива.
Чтобы три разных профессиональных продукта устанавливались и настраивались одной командой? Серьёзно?

Понятно же, что речь только про ES, ну зачем передёргивать. А там, глядишь, и остальные продукты научатся писать чтоб устанавливались одной командой.

Прежде всего то, что условный Amazon не делится своим кодом с сообществом, в отличие от условного Elastic.

Ах он злой, можно подумать что майкрософт делится кодом с разработчиками вайна. И да, как уже написали выше, надо было в качестве лицензии брать AGPLv3.
Понятно же, что речь только про ES

Если речь про сферический ES в вакууме, то он и устанавливается одной командой, наверное. ;)

На самом деле юзабилити продукта как таковое тут не при чём. У условного Amazon как у облачного провайдера есть очевидное преимущество перед условным Elastic или условным Canonical: он имеет возможность устанавливать что угодно на сдаваемый им в аренду компьютер, а Elastic или Canonical вынуждены полагаться на арендатора. Я думаю, это преимущество вполне может считаться неконкурентным.

Ах он злой, можно подумать что майкрософт делится кодом с разработчиками вайна.

Это не очень подходящая аналогия: wine не является первой реализацией win32, и MS не основывал Windows на общественно доступном коде (по крайней мере, целиком).
Если речь про сферический ES в вакууме, то он и устанавливается одной командой, наверное. ;)

На самом деле юзабилити продукта как таковое тут не при чём. У условного Amazon как у облачного провайдера есть очевидное преимущество перед условным Elastic или условным Canonical: он имеет возможность устанавливать что угодно на сдаваемый им в аренду компьютер, а Elastic или Canonical вынуждены полагаться на арендатора. Я думаю, это преимущество вполне может считаться неконкурентным.

Ну, значит, надо что-то где-то допилить, чтоб пользователи предпочитали всё что нужно бесплатно установить сами вместо того, чтобы платить условному Амазону. Раз платят, значит пока установка чего-то, что Амазон уже установил, вызывает боль.

Это не очень подходящая аналогия: wine не является первой реализацией win32, и MS не основывал Windows на общественно доступном коде (по крайней мере, целиком).

А вот не надо растягивать мою аналогию. Она только про то, что исходники не дают. А тут, кстати, исходники от первоначального продукта доступны, значит должно быть не сложнее, а проще поддержать «инновации» в API.
Ну, значит, надо что-то где-то допилить, чтоб пользователи предпочитали всё что нужно бесплатно установить сами вместо того, чтобы платить условному Амазону. Раз платят, значит пока установка чего-то, что Амазон уже установил, вызывает боль.

Да почему обязательно боль? Я сейчас бегло глянул на цены EC2 и Amazon ElasticSearch on-demand: получается, что готовый эластик стоит юзеру дешевле, чем если его ставить самостоятельно. Это нечестная игра, демпинг. Elastic Inc ничего не может этому противопоставить в техническом смысле.

исходники от первоначального продукта доступны, значит должно быть не сложнее, а проще поддержать «инновации» в API.

Вопрос опять же не в том, что проще, а зачем вообще. Зачем разработчику популярного продукта, наверняка имеющему планы по его развитию, отвлекать ресурсы от этих планов и тратить их на копирование фич своего же закрытого клона?

Условный Амазон предоставляет не услугу установки и настройки, а готовый сервис. Грубо говоря, условному Еластику надо ещё подкрутить железо, ОС и системные сервисы, чтобы у пользователя была коробка с двумя кабелями и кнопкой включения. И то это будет менее удобно чем облачный сервис. А без этого пользователю нужны как минимум люди, знающие, что такое apt, df, top и т. п.

Прежде всего то, что условный Amazon не делится своим кодом с сообществом, в отличие от условного Elastic.


А почему они это могут делать — правильно, лицензия (какая она там?) позволяет. А вот была бы условная GPL (которая запрещает закрывать исходники производных продуктов) и условные Amazon-ы были бы обязаны делиться своими наработками, и тем самым осуществляли бы вклад в OpenSource.

Т.е. мы сначала критикуем и хаем GPL за ее ограничения, пишем свою супер-пупер свободную лицензию, позволяющую все и не требующую ничего в замен, а потом плачем что другие после нескольких взмахов напильником продают за хорошие бабки их продукт, и не делятся ни бабками ни результатами тех маханий напильником.

Именно GPL не помешает Амазону. GPL требует открытия кода при распространении продукта. Амазон, как я понимаю, не распространяет его, а предоставляет сервис.


Для таких случаев есть AGPL.

Да вы абсолютно правы. Конкретно в этом кейсе нужна AGPL.

Но я то не про конкретную лицензию, я про подход «сначала выкопаем яму, залезем туда, а потом начинаем громко вопить о несправедливости»
курить мануалы вроде вот этого,..

Прошёл по ссылке, зашёл в часть «Elastic Search» выбрал раздел «Установка на Ubuntu» — увидел четыре шага — импорт ключа репозитария, подключение репозитария, установка командой apt, и добавление сервиса в автозагрузку. Всё. Раздел кончился, потому что и так работает.

Больше про Elastic Search ничего нет. Есть про Kibana и другие вещи и их взаимную интеграцию. Но это, вообще-то, уже не совсем про один OpenSource проект, а про комбинацию нескольких.

Значит всё-таки не одна команда, а четыре. Ну вот, кому-то и четыре шага — сложно, и, что более важно, он готов платить за избегание этих шагов деньги.
хех, вот было бы шоу, если бы Либроподобные офисы сменили лицензию…
Другой пользователь HN также заметил, что позицию организаций, сменивших условия лицензии, можно назвать лицемерной. Они сами предлагают платные корпоративные сервисы, параллельно используя Linux, GNU и другие приложения с открытым кодом. При этом они не делают никаких финансовых отчислений в их пользу.
Дело говорит пользователь. Будьте последовательными.
Например, в 2015 году FoundationDB купили Apple
Вот тут вздрогнул на секунду — неужели кто-то купил эппл. А, не, показалось.

Не очень понятно, они против продажи их продукта как сервиса, или против продажи сервисов, у которых под капотом их продукт, или ещё что?

ткнул на ссылку foundation db в вики, читаю:


С апреля 2018 FoundationDB переведена в разряд свободных СУБД и поставляется под лицензией Apache 2.0

вроде как наоборот выходит…

Месяц назад разработчик Ruby-библиотеки, упрощающей работу с Chef, в качестве протеста удалил собственный проект из репозитория на GitHub, когда узнал, что его используют инженеры Иммиграционной службы США.


Извините конено, но это больше похоже на политический протест против борьбы с нелегальной миграцией, чем на протест против комерческого использования.

Тут упор скорее на то, что если вы используете FOSS, то это ещё не гарантия, что вы всегда сможете его использовать, вернее не всегда сможете его переустановить. Удалят из открытого доступа, хостер типа гитхаба изменит условия "открытого доступа", изменят лицензию и т. п.

Only those users with full accounts are able to leave comments. Log in, please.