Эрик Реймонд: «GPL больше не нужна»

>Насколько я помню, вопрос был "какие", а не "какие нужные лично мне". Не передергивай :)

Пусть назовёт другие. Я кроме этих и cdrecord'а никаких не знаю.Хотя... он ведь уже "покинул" нас :)

> И у этой попытки есть своя отрицательная сторона: люди, особенно юристы и руководители корпораций, смотрят на GPL и чувствуют страх.

Тут много высказались *неправильно* на тему этого страха, и вроде бы только unihorn вскользь упонянул интересный аспект.

Речь идет о том, что для компании (пишущей с закрытыми исходниками) гораздо надежнее может смотреться двойная лицензия (как была у трольтеч и осталась у мускула). Почему? Предоположим, компания юзает какой-то GPL код в виде сторонней утилиты, линковка с ним не требуется. Но в будущем может случится, что заказчики компании попросили *минорное* измение софта компании, для чего уже потребовалась линковка.

И вот тут встает вопрос. Сейчас компании линковка не нужна. И что, слать письма разработчикам "а вот нам пока не-GPL лицензия не нужна, но все равно вы пожалуста определитесь с ее ценой, вдруг мы в будущем ее купим" ?

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

С моей точки зрения LGPL достаточно хорошо решает эти проблемы, не создавая при этом прямой дыры для воровства. BSD в общем очень приятно использовать, но я сомневаюсь, что свои наработки будут комминить в BSD прогу.

s/комминить/коммитить/

Тебе уже на звали, ты невежда.

> И вот тут встает вопрос.
Это называется планирование. Компания должна аккуратно смотреть на лицензии всего, что она использует. Не только с учетом сегодняшних задач, но и глядя в светлое завтра.

>Тебе уже на звали, ты невежда.

>на_звали

>невежда

Ну ты поняло)

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

> Это называется планирование. Компания должна аккуратно смотреть на лицензии всего, что она использует. Не только с учетом сегодняшних задач, но и глядя в светлое завтра.

Так и хочется добавить "Ваш К.О.".

Я писал о том, что компании боятся GPL не потому, что бояться воровать (как тут многократно писали), а потому, что оно вносит странную (и страшную) непредсказуемость в будущее.

> а потому, что оно вносит странную (и страшную) непредсказуемость в будущее.
Будущее вообще непредсказуемо. С любой лицензией. Всегда есть шанс, что условия изменятся, и ты окажешься у разбитого корыта (и со счетом за ремонт корыта в размере большем, чем капитализация твоей компании).

Данная проблема - второго порядка. По сравнению с действительно ужасной для коммерсантов проблемой "код не украсть и не слинковать"

> Данная проблема - второго порядка. По сравнению с действительно ужасной для коммерсантов проблемой "код не украсть и не слинковать"

Обычно проблема "код не украсть и не слинковать" вообще не стоит.

Привнесем немного конкретики. *Предположим*, libcurl была бы лицензирована под GPL. Тогда компания пишет гуй к ней с закрытым исходником, из него запускает патченный curl (который допустим пропатчили на предмет вырезания справки и обфускации опций ком. строки до 1-2 букв) с правильными параметрами. Юзеру, отвалившему бабло за гуй, самому запускать curl в голову не приходит.

Гуй типа teleport pro/offline explorer/web snake/...

В гуй конечно добавлены кусочки закрытого кода, который парсит хтмл, ответы сервера, ходит по дереву, ...

> из него запускает
Это и называется: GPL поставил компанию в коленно-локтевую. Интерфейс командной строки - отнюдь не самый удобный, в качестве API.

> Это и называется: GPL поставил компанию в коленно-локтевую. Интерфейс командной строки - отнюдь не самый удобный, в качестве API.

Гы-гы-гы. Мне как раз интерфейс командной строки *удобнее* чем API. Особенно неприятно возится чисто сишной фишкой, когда от меня для чтения входного потока требуют отдать коллбяк на функцию, выделяющую память.

> Интерфейс командной строки - отнюдь не самый удобный, в качестве API.

Пробегись по диагонали по опциям curl-а и по мануалу libcurl -- мне кажется, ты передумаешь.

Кстати, к этой либе 2 плюсовых интерфейса, и оба мне не понравились совсем, притом что я больше плюсист, чем сишник.

>Интерфейс командной строки - отнюдь не самый удобный, в качестве API.

Разве? Хотя да, сложно вызвать fopen из glibc используя коммандную строку :)

> Мне как раз интерфейс командной строки *удобнее* чем API
Вы человек, у Вас другие требования к интерфейсам.

> Особенно неприятно возится чисто сишной фишкой, когда от меня для чтения входного потока требуют отдать коллбяк на функцию, выделяющую память
А сложные структуры данных как передавать? Все будем в XML запихивать, в духе XML RPC?

> А сложные структуры данных как передавать? Все будем в XML запихивать, в духе XML RPC?

Если есть командно-строчная версия, то там эта проблема как-то решается. И думаю решается не так уж плохо даже XML-ем (хотя тут можно еще лучше).

Несколько бОльшая проблема возникает, если состояние надо удерживать между вызовами. Для этого можно например демонизировать утилитку.

З.Ы. Я даже думал демонизировать курл, заставляя его читать комстроки из stdin -- но это только чтобы не тратить проц на запуск его каждый раз. Профит был сомнителен однако.

> Вы человек, у Вас другие требования к интерфейсам.

Бывают и другие требования, чем у меня. Но мне кажется типовое требование к либе -- *побыстрее* сваять че-нить рабочее, и тут ком. строка явно опережает C API.

> Если есть командно-строчная версия, то там эта проблема как-то решается.
У вас куча усилий будет уходить на сериализацию и десериализацию данных.

> Для этого можно например демонизировать утилитку.
Вот это я и называю: "коленно-локтевая". Вы старательно и последовательно изобретаете клиент-сервер на том месте, где мог бы быть нормальный API.

> и тут ком. строка явно отстает от C API.
(fixed) ибо ком. строка в прототипировании обгоняет только для случая, когда действие простейшее, выходные данные отсутствуют (или укладываются в отдельную строку или число). В остальных случаях Вам придется парсить. Чего в случае C API не нужно.

>оно вносит странную (и страшную) непредсказуемость в будущее.

Как раз оно избавляет от непредсказуемости -- код придётся открывать, и "выжать" клиентов не удастся. Какая уж тут непредсказуемость? Полная определённость!

> Вы старательно и последовательно изобретаете клиент-сервер на том месте, где мог бы быть нормальный API.

(на всякий случай напомню, что курл на самом деле под МИТ-Х лицензией, и обсуждение гипотетическое)

Я по-прежнему утверждаю, что во многих реальных случаях комстрока удобнее "нормального АПИ".

Другое дело, что язык программирования должен быть таким, чтобы внутри него можно было иметь удобство комстроки в "нормальном АПИ". Ни один из изветных мне языков это не дает.

> В остальных случаях Вам придется парсить.

Да, придется... Я прям дрожжу от страха...

> как раз оно избавляет от непредсказуемости -- код придётся открывать, и "выжать" клиентов не удастся. Какая уж тут непредсказуемость? Полная определённость!

Прочти пожалуста *внимательно* -- там есть как минимум купить под дуальной лицензией либо юзать в ком. строке.

> В остальных случаях Вам придется парсить.

И часто кстати НЕ ПРИДЕТСЯ. Например (хотя пример устаревший, сейчас она под LGPL) -- Qt.

1. Вывод она все равно делает на экран.

2. Если надо дергать свой код из кути-шных слотов или ковырять кутишные объекты -- встроенный скриптовой язык вам в руки (да, он уже есть в кути).

> Я по-прежнему утверждаю, что во многих реальных случаях комстрока удобнее "нормального АПИ".

Для полного счастья не хватает zsh backend for SWIG: была бы и комстрока, и API почти нормальное.

> что во многих реальных случаях комстрока удобнее "нормального АПИ".
Ну вот мы сейчас начнем статистику собирать... Я утверждаю, что комстрока удобна только в простейших случаях. И я указал, в каких именно. В остальных - не избежать доп. работы по поддержке интерфейса с вызываемым процессом. Что очевидно сложнее, чем использование продуманного С интерфейса.

> что язык программирования должен быть таким, чтобы внутри него можно было иметь удобство комстроки
> Ни один из изветных мне языков это не дает.
Именно потому что это никому нафиг не сдалось. Нужен API - используй API. Командная строка для другого. А если хочется общаться между процессами - тогда извольте применять sockets, tcp(и выше), shmem, ... Командная строка - простейший и самый убогий из межпрограммных интерфейсов. Существует только потому, что удобен для человека.

> Да, придется... Я прям дрожжу от страха...
Можете дрожать, можете кидать в воздух чепчики. Но это уже убивает постановку задачи "быстро накидать что-то рабочее" - во всяком случае, дает резкое преимущество сишному API, где этой фигней заниматься не нужно.

> встроенный скриптовой язык вам в руки
Это как бы за пределами обсуждаемого. Мы говорим о (сферической) библиотеке с чисто сишным интерфейсом. Если библиотека изначально предоставляет продуманный скриптовый интерфейс, это уже другая ситуация.

> Но это уже убивает постановку задачи "быстро накидать что-то рабочее" - во всяком случае, дает резкое преимущество сишному API, где этой фигней заниматься не нужно.

Ну хорошо, отвечу серьезно. Чисто сишный апи конвертировать в XML неудобно, но объектный -- можно вполне автоматически с 0 трудозатрат.

> Мы говорим о (сферической) библиотеке с чисто сишным интерфейсом.

Кстати, не могу вспомнить сишных библиотек под GPL (вспоминаю только LGPL). Вот кути была недавно...

> Чисто сишный апи конвертировать в XML неудобно, но объектный -- можно вполне автоматически с 0 трудозатрат.
Насчет 0 - это 4.2. Как минимум придется использовать какую-то тулзовину типа компилятора сишного апи в xml-евский.
Далее, производительность такого интерфейса при приличных объемах данных будет унылой, как и положено XML.
Далее, как Вы правильно сказали, действительно придется научиться демонизировать "серверный процесс", чтобы хранить состояние.

В общем, траблов - дохрена, если не стоит задачка в духе "запустить sendmail c параметрами и забыть". Да, все решаемо - но не надо грубо обманывать почтеннейшую публику утверждениями, что командная строка эффективнее нормального API.

> В остальных - не избежать доп. работы по поддержке интерфейса с вызываемым процессом. Что очевидно сложнее, чем использование продуманного С интерфейса.

+1

Общаться с линкером на отвлечённые темы касательно результатов компоновки весьма проблематично.

Да и сама командная строка на данном уровне развития почти как ассемблер. Ну выше, чем C уровень, но всё равно ассемблер. Вот, например, в Ассемблере, если надо скопировать/соединить строку, надо всё расписывать: как узнать последний байт строки, что и куда переслать. Если нужна память, память вручную выделять. Или вручную дёргать менеджер памяти.

В bash, конечно, есть for и прочее, но они не сильно отличаются от LOOP префикса. Если нужно скомпилировать пропатченную версию пакета из SVN, нужно придумывать, куда бы разместить SVN версию, вытягивать SVN версию, накладывать патч, компилировать, в общем, описывать низкоуровневые последовательности действий вместо высокоуровневого вычисления функций.

Нет возможности работать с директориями как с RAII объектами, не хватает IPC между экземплярами шелла.

Эрик Реймонд

да ты капиталист вонючий!!!

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

> Кстати, не могу вспомнить сишных библиотек под GPL
Их очень мало. Потому что все-таки лицензировать библиотеку (не приложение) под GPL - это для очень суровых столлманоидов. Большинству адекватных хватает LGPL.

Кстати, самба нынче гпл3, небось и все библиотечки в ней тоже?

>там есть как минимум купить под дуальной лицензией либо юзать в ком. строке

Так это не GPL непредсказуемости добавляет. Покупая GPL-ный код ты точно знаешь, что он у тебя будет столько, сколько ты захочешь и с возможностями, определяемыми твоим кошельком по цене, соответствующей себестоимости * некий разумный коеффициент. И ты точно знаешь, что то так же определяются твои доходы от продажи твоих наработок. Это _предсказуемость_.

И наоборот, если я начну часто прыгать со скал, непредсказуемость моей жизни вырастет. Зато можно ожидать непредсказуемого же роста доз адреналина. То же с закрытым софтом.

> Мы говорим о (сферической) библиотеке с чисто сишным интерфейсом.

Вот допустим будет у меня задача -- "сделай видео/аудио плеер". Естественно, я сразу же побегу скриптовать mplayer. Хотя он под GPL v.2, все что мне надо практически я получу без запихивания своего кода внутрь его исходника. Я могу держать свой закрытый код отдельно.

И вообще, именно так должна себя вести хорошая программа.

> производительность такого интерфейса при приличных объемах данных будет унылой, как и положено XML ... но не надо грубо обманывать почтеннейшую публику утверждениями, что командная строка эффективнее нормального API.

Эффективнее в смыле удобнее и быстрее разрабатывать в большинстве практических случаев. Если же вдруг пишется сервер, которому нужна производительность -- тут хмл конечно бесполезен.

Но в общем-то, все такие серверы уже написаны, а 90% людей вполне мирятся даже с тормозами ПХП -- которые, я думаю, не меньше тормозов интерпретации ХМЛ.

> Естественно, я сразу же побегу скриптовать mplayer
А если я потребую накладывать фильтры на видео, показываемое mplayer-ом? Например, в уголок хочу поместить лого моей домашней видео-коллекции. Ваши действия?

> все такие серверы уже написаны
rotfl. Тепловая смерть софтовой индустрии, не меньше.

> мирятся даже с тормозами ПХП -- которые, я думаю, не меньше тормозов интерпретации ХМЛ.
Что-то вы путаете мух с котлетами...

> Нет возможности работать с директориями как с RAII объектами, не хватает IPC между экземплярами шелла.

Я веду флейм грубо говоря на тему "popen удобнее чем С function call, так что не нужна ваша GPL". А язык программирования bash здесь вторичен -- да, у него есть недостатки (и их обсуждение тоже может быть интересно)

> А если я потребую накладывать фильтры на видео, показываемое mplayer-ом? Например, в уголок хочу поместить лого моей домашней видео-коллекции. Ваши действия?

Я вообще-то не специалист по м-плееру, но вроде годится это (man mplayer):

bmovl=hidden:opaque:fifo

The bitmap overlay filter reads bitmaps from a FIFO and displays them on top of the
movie, allowing some transformations on the image. Also see TOOLS/bmovl-test.c for
a small bmovl test program.

И если все программы писать как mplayer (а именно так надо стараться это делать), то GPL почти ничем не отличается от LGPL.

И может даже от BSD почти не отличается.

> То же с закрытым софтом.

Мне кажется, ты совсем не понял то, что я хотел сказать.

отличный тред! до слез (неразборчиво) меня.
узнаю старый (неразборчиво) добрый ЛОР :))

Я конечно понимаю, что на фоне таких жирных троллей я смотрюсь незаметно, но...

Кто же вам сказал, что GPL преследует цель защиты от воровства открытого кода разработчиками закрытого?

Или не дай бог она создана для того, чтобы привлекать в Linux проприетарных разработчиков? На**й нужны индусы вместе с unihorn и Эриком Реймондом (мое мнение)!!!

Она создана исключительно для тех, кто пишет ПО для сообщества! Публикуя свою разработку под GPL, я не хочу оградить свой код от того, что им воспользуется MS, а хочу, чтобы они не имели возможности заявить права на мою разработку. Иными словами, до тех пор, пока MS продает свои бинарники на основе моего кода, я к ним претензий не имею, исключительно до того момента, пока они не выйдут и не скажут: "Это наша идея, наш патент! Мы это разработали, платите нам бапки!!!". Вот тут моя GPL и должна сработать. Она для этого создавалась!

> Публикуя свою разработку под GPL, я не хочу оградить свой код от того, что им воспользуется MS, а хочу, чтобы они не имели возможности заявить права на мою разработку.

А я-то, наивный, думал, что GPL — это такая прагматичная лицензия, обязывающая других патчи выкладывать :)

>Мне кажется, ты совсем не понял то, что я хотел сказать.

У меня тоже такое чувство. А что ты хотел сказать, утверждая, что "это порождает непредсказуемость" в ветке про GPL?