Комментарии 11
Радикальным, но хорошим шагом кажется позиция монги - чем лицензия вирусней, тем лучше
Термин «открытое программное обеспечение» подразумевает, что исходный код можно модифицировать и даже коммерциализировать.
"Смешались в кучу кони, люди ..."
OpenSource != свободное ПО и открытый исходный код не всегда подразумевает возможность модификации и коммерциализации. Ну учите сперва матчасть, а уж только потом пишите.
Вы всё ещё отказываетесь признавать определение Open Source от OSI?
Мы с вами уже обсуждали тот факт, что определение организации Open Source Initiative требуется только для тех, кто хочет использовать логотип Open Source Initiative (OSI). Но никак не влияет на открытость исходников или на использование термина Open Source по отношению к программам с несвободными лицензиями но с доступным исходным кодом.
в статье действительно смешались "кони и люди"
насколько я понимаю - то идет процесс уточнения открытых лицензий: изначально никто не хочет чтобы лицензии были сложными или сильно ограничивающими.
Пока свободное и открытое ПО было небольшими утилитками - всем было норм. Но когда в опенсорс вышли базы данных - это породило эффект, когда команда разрабатывающая основное ПО фиксит баги и делает фичи А, Б, В, в то время как условный рептилоид делает форк в личный репозиторий, добавляет фичи Е, Ж, З и предоставляет услуги "БД как сервис" на своих личных серверах (ака "облако").
Таким образом - рептилоид 1) не делится своими фичами с оригинальной командой, 2) как только команда разработчиков делает новую фичу Г, он тут же может добавить ее себе.
В общем - сплошное переманивание клиентов и собака на сене.
Собственно лицензии Монги и т.д. - это чтобы отвадить таких нехороших рептилоидов с их облачными сервисами от высасывания их кода (или принудить их делиться фичами в основной проект).
Однако такие ограничения все еще делаются "по месту" (и со своими перегибами), и не всеми воспринимаются как "полезные ограничения" (изза перегибов).
Да, этот базар выглядит как броуновское движение (включая, хотящих "половить рыбку" в этой мутной воде - т.н. апологетов т.н. "этических лицензий"), но это жизнь :)
Всё правильно, но стоит ещё добавить, что рептилоид сначала делает цены на свой сервис ниже, чем может стоить запуск открытой БД on-premises. И фичи Е, Ж, З он плодит не просто так, а чтобы разработчик открытой БД не мог зарабатывать на поддержке бывшего своего продукта. А уж потом, когда пользователи перейдут к нему и оригинальный разраб загнётся с голоду, тогда можно задрать цены и отыграться.
AWS переименовали ElasticSearch в OpenSearch, но не сдались.
Многие поддерживают идею введения ограничивающих лицензий, но есть и те, кто с этим не согласен. Существует мнение, что новые соглашения противоречат концепции open source ...
Лично для меня, свободные лицензии — это что-то вроде BSD-2 и MIT, где лицензия запрещает удалять саму лицензию (не автору, то есть обходить лицензию) и в ней есть отказ от ответственности (защита автора от законодательств некоторых стран).
Более ограничивающие лицензии уменьшают базу пользователей кода, а значит уменьшают количество прецедентов использования, количество тестовых случаев и объём потенциальной обратной связи, помогающей развитию проекта.
Так, требование предоставлять изменённые исходные коды в GPL требует механизма для выполнения этого требования. Это не только сама пересылка по требованию или публикация, но и обеспечение синхронности между версией продукта и версией исходных кодов: нельзя просто так дать клиенту версию 1.2.3 + какие-то тестовые изменения и не зафиксировать эту комбинацию — клиент по запросу должен получить именно ту комбинацию исходников, из которых собран продукт, ни больше, ни меньше.
Для развития проекта важнее не требование предоставлять изменённые исходные коды, а обратная связь: прямое предоставление таких изменений в основной проект для ревью автором и/или командой разработчиков, сообщения об ошибках и т. п. Мало кому нужен открытый доступ к форку проекта с какими-то исправлениями (или «исправлениями»), отставший от базового проекта со всеми ошибками, которые уже исправлены в базовом проекте, с несовместимой конфигурацией и т. п.
Обратная связь методом пересылки патчей в теле письма в 20-х годах 21-го века, да ещё и когда сама система пересылки почты не гарантирует битовой целостности? Сообщение об ошибке особым образом сформированным письмом для регистрации факта ошибки и весь обмен комментариями такими же письмами с Web-страницей только для просмотра и поиска других сообщений (угадайте проект с такой bug tracking system)?
Вот, по-моему, гораздо важнее удобный механизм для обратной связи, чем требование предоставления измененных исходных кодов.
P.S. Я ни в коем случае не призываю использовать какую-либо конкретную лицензию или, наоборот, не использовать какую-либо иную: выбор лицензии — это прерогатива исключительно автора.
его объем составляет порядка $32 млрд
Вам известны хотя бы общие принципы подсчета? Откуда взялась эта оценка?
Что происходит с лицензиями в open source