LINUX.ORG.RU

Arpi возвращается к G2.


0

0

Раньше собщалось о том, что один из основных разработчиков MPlayer и MPlayer G2 (Arpad Gereoffy) покинул оба проекта. Сегодня он анонсировал, что он продолжит работу над MPlayer G2. Прежде он покинул это проект из-за нежелания разработчиков выпускать код G2 под двойной лицензией (GPL и коммерческой). Теперь он принял решение выпустить код G2 (по крайней мере основной части этого плеера) под LGPL.

>>> Письмо Arpi в MPlayer-G2-dev

★★

Проверено: Die-Hard ()

Ответ на: комментарий от anonymous

> Хорошего то тут что ? :(

Хорошо то, что это открывает путь к использованию основы MPlayer G2 в коммерческих продуктах.

lumag ★★
() автор топика
Ответ на: комментарий от anonymous

А плохого что? Или ты сторонник "только себе и никому другому"? Типа мы андегряунд и все такое. Молодец Arpi.

anonymous
()
Ответ на: комментарий от lumag

> Хорошего то тут что ? :(

>>Хорошо то, что это открывает путь к использованию основы MPlayer G2 в коммерческих продуктах.

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

Lexa

anonymous
()
Ответ на: комментарий от anonymous

Да нет, Арпи пишет что перетер с большими пацанами, и те сказали мол мы заинтересованы в стабильном видеоплеере под Linux. Давай ты будешь делать, мы будем тебе помогать а потом пользовать. А то GPL нам как то не инетересен, а вот LGPL нормально, по-пацански. Где-то так. Короче повалял Арпи дурака, да и за ум взялся.

anonymous
()

Отличная новость.

Теперь можно будет создавать комерческие плееры на Mplayer lib API. Давно было пора завернуть его в библиотеку, а то fork()+exec() крайне неудобная вещь. Вот если б еще libxine отдали под LGPL.

Dead ★★★★
()
Ответ на: комментарий от lumag

>>это открывает путь к использованию основы MPlayer G2 в коммерческих >>продуктах.
Дык что тут хорошего-то ?!!
Это развитие не GPL сообщества а дяди билла :(

anonymous
()
Ответ на: комментарий от anonymous

>> то fork()+exec() крайне неудобная вещь

>Для виндокодеров

Не верно. Даже время на докозательство тратить не хочется. Помоему это очевидно.

Dead ★★★★
()
Ответ на: комментарий от Dead

> Не верно.

Для виндокодеров. У них своя правда.

> Даже время на докозательство тратить не хочется.

Заметно.

> Помоему это очевидно.

Только виндокодерам.

anonymous
()
Ответ на: комментарий от anonymous

Разозлил мля :)

Берем к примеру fork+exec Mplayer. Во-первых нужно обработать корректно все ошибки, во-вторых нужно распарсить из stdout многие параметры видео/аудио файла. Вместо того, чтобы получить всю нужную инфу парой вызовов API'шных функций.

P.S. Я уже три года как не винкодер. А ты кто? ;)

Dead ★★★★
()
Ответ на: комментарий от Dead

> Берем к примеру fork+exec Mplayer. Во-первых нужно обработать корректно все ошибки,

Какие и зачем? Ошибок ровно одна - "не играецца".

> во-вторых нужно распарсить из stdout многие параметры видео/аудио файла.

Да это очень сложно. Просто невозможно.

> Вместо того, чтобы получить всю нужную инфу парой вызовов API'шных функций.

В идеале. На практике это API будет или негибким или монструозным. И будет меняться каждую неделю.

> Я уже три года как не винкодер. А ты кто? ;)

А я он (винкодер) и есть. Обожаю красоту, продуманность и логичность юникса. Издалека.

anonymous
()
Ответ на: комментарий от anonymous

>Какие и зачем? Ошибок ровно одна - "не играецца".

ага и выдавать юзеру окошко с надписью "Хез. Какой-то error" :)

>Да это очень сложно. Просто невозможно.

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

>В идеале. На практике это API будет или негибким или монструозным. И будет меняться каждую неделю.

Мусье ортодоксальный писсимист?

Dead ★★★★
()
Ответ на: комментарий от Dead

> ага и выдавать юзеру окошко с надписью "Хез. Какой-то error" :)

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

> Мусье ортодоксальный писсимист?

Нет. Калашников не купил и китайский не учу.

anonymous
()
Ответ на: комментарий от anonymous

> да у луноходов всё через жопу под названием пайп

И в чем же недостатки данной конкретной жопы?

anonymous
()
Ответ на: комментарий от anonymous

> в отсутствии формата/структуры

Это можно назвать и возможностью использовать любой "формат/структуру".

anonymous
()
Ответ на: комментарий от anonymous

неа, использовать напрямую можно только неформатированый поток байтов или текста, как только поток начинает использоваться для передачи структурированых данных, нужны соглашения о формате и сериализация/десериализация. Плюсы конвейера только для широкоиспользуемых форматов - поток текста, аудио, видео.. и это ограниченый вид интеграции, на уровне api это совсем другое..

anonymous
()
Ответ на: комментарий от anonymous

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

Они нужны в любом случае. Как тут могут помешать пайпы - непонятно.

> и это ограниченый вид интеграции, на уровне api это совсем другое...

API можно понимать по разному. В конце концов вызов функции - это всего лишь заоптимизированная до неузнаваемости посылка сообщения. Запись порции данных в пайп - то же самое.

anonymous
()
Ответ на: комментарий от anonymous

ты думаешь о том что и я
или просто прикалываешься - от нех делать п"№;%шь?

yeolahim
()
Ответ на: комментарий от anonymous

>> Берем к примеру fork+exec Mplayer. Во-первых нужно обработать >>корректно все ошибки,

>Какие и зачем? Ошибок ровно одна - "не играецца". типа полное соответствие булевок логике - "играет"-"не играет"? ага, после таких вот виндокодеров, и проги у которых выдает "не могу загрузться"-"не могу работать"... мочить их надо пока они маленькие еще были >> Вместо того, чтобы получить всю нужную инфу парой вызовов API'шных >функций.

>В идеале. На практике это API будет или негибким или монструозным. И >будет меняться каждую неделю

ага, а в идеальном апи твоей обожаемой винды половина всех всех резервед фор фюче юз, это пример хорошего апи?

>А я он (винкодер) и есть. Обожаю красоту, продуманность и логичность >юникса. Издалека. удачи тебе а я после знакомства с виндой поближе(феееее) предпочитаю видеть красоту, продуманность и логичность юникса вблизи

anonymous
()
Ответ на: комментарий от ananymous

> а какая разница межнду ЛГПЛ и ГПЛ?

Самое главное - с ЛГПЛ(Library/lesser GPL) можно открытый продукт использовать как библиотеку(ничего там не изменяя, само собой) с коммерческим приложением. Т.е. если все-таки сделают что-то вроде libmplayer, к ней можно будет легально линковать(статически тоже) закрытое приложение. По-моему так. Правда, ведь в ГПЛ тоже еще оговариваются всякие там исключения, двойные лицензии, и т.п. так что я не врублюсь откуда весь сыр-бор. Но то что Арпи вернулся это хорошо однозначно :)

http://www.fsf.org/licenses/why-not-lgpl.ru.html

Sudonix
()
Ответ на: комментарий от Sudonix

> Самое главное - с ЛГПЛ(Library/lesser GPL) можно открытый продукт
> использовать как библиотеку(ничего там не изменяя, само собой) с
> коммерческим приложением. Т.е. если все-таки сделают что-то вроде
> libmplayer, к ней можно будет легально линковать(статически тоже)
> закрытое приложение

Нельзя. Статически линковать закрытый софт с LGPL-библиотеками НЕЛЬЗЯ, динамически - можно.

no-dashi ★★★★★
()

А я вот Ксин скачал и поставил. В общем пока нравицца ;)

anonymous
()

Что-то я не пойму - а разве можно ослаблять лицензию с GPL на LGPL? В чём тогда смысл GPL, если можно взять любой защищённый GPL продукт, внести изменения, назвать это следующей версией и объявить эту следующую версию LGPL?

А ещё следующую - чего доброго, и BSD можно объявить?

anonymous
()
Ответ на: комментарий от anonymous

> Что-то я не пойму - а разве можно ослаблять лицензию с GPL на LGPL?

Если ты Copyright holder --- то можно.

> А ещё следующую - чего доброго, и BSD можно объявить?

Да. Если ты --- владелец копирайта.

lumag ★★
() автор топика
Ответ на: комментарий от no-dashi

> Нельзя. Статически линковать закрытый софт с LGPL-библиотеками НЕЛЬЗЯ, динамически - можно.

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

lumag ★★
() автор топика
Ответ на: комментарий от no-dashi

>> Т.е. если все-таки сделают что-то вроде libmplayer, к ней можно будет легально линковать(статически тоже) закрытое приложение

> Нельзя. Статически линковать закрытый софт с LGPL-библиотеками НЕЛЬЗЯ, динамически - можно.

Статически можно, но тогда надо предоставлять пользователю хотябы свои объектники, чтобы он мог перелинковать приложение.

Посему такой вариант и не используется в основном -- очень трудно реализовать качественно.

awn
()
Ответ на: комментарий от Sudonix

Да не интересует Arpi использование Mplayer'а в коммерческих продуктах!

Больше его интересует, чтоб коммерческие кодеки портировали на Линукса, и не надо было хакать виндовые dll!

anonymous
()
Ответ на: комментарий от anonymous

> Это развитие не GPL сообщества а дяди билла :(

С чего ты взял ?? Наоборот, если дядя билл вдруг надумает использовать libmplayer (чего, конечно же, никогда не будет), то ему придется закоммитить свой код для работы с asf и прочим отстоем в общую бибилиотеку, которую потом сможет использовать и ГПЛ соопчество. А дядя билл оставит закрытым только код, отвечающий за скины ;-)))) ЛГПЛ для таких вещей практически идеальна.

LamerOk ★★★★★
()
Ответ на: комментарий от Sudonix

> По-моему так. Правда, ведь в ГПЛ тоже еще оговариваются всякие там исключения, двойные лицензии, и т.п. так что я не врублюсь откуда весь сыр-бор.

Сыр-бор от того, что Арпи собирался использовать мплэер (как проект) очень свободно (в смысле лицензионных ограничений), но весь остальной народ, который его создавал, хором сказал - ГПЛ и точка. Арпи обиделся, вскочил, выбежал, хлопнул дверью. Поплакал, подумал и вернулся просветленным ЛГПЛ ;-)))))))

Вот и еще одно применение ЛГПЛ - компромисс между ГПЛ сообществом и разработчиком ;-))))))))))))

LamerOk ★★★★★
()
Ответ на: комментарий от svyatogor

Да ладно вам. LGPL - хорошая вешь. К примеру, возьмеме HelixPlayer. Там нет MJPEG/MPEG1/MPEG2 - берем и пишем на ffmpeg плагин, т.к. он бегает по LGPL - если бы по GPL, то были бы проблемы (я знаю, что Helix по GPL, но Helix в качестве примера). Так что в любом случае хорошо, что по LGPL будет доступен.

Spectr ★★★
()
Ответ на: комментарий от anonymous

> Да не интересует Arpi использование Mplayer'а в коммерческих продуктах!

> Больше его интересует, чтоб коммерческие кодеки портировали на Линукса, и не надо было хакать виндовые dll!

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

LamerOk ★★★★★
()
Ответ на: комментарий от awn

> Статически можно,

Нельзя. C GPL можно линковать как угодно, с совтом за бабки - тока динамически. Ричард Столлман и так бочку на LGPL катил, и в его разъяснениях про плагины etc очень резко про это сказано.

Spectr ★★★
()
Ответ на: комментарий от LamerOk

>> Если ты Copyright holder --- то можно.

> Это еще кто такой ? Автор, что ли ?

Вообщем случае не обязательно. Если автор работает в какой-либо компании и что-то создал в рамках работы то Copyright holder - компания где он работает.

Toster
()
Ответ на: комментарий от LamerOk

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

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

anonymous
()
Ответ на: комментарий от LamerOk

>>ему придется закоммитить свой код для работы с asf и прочим отстоем в >>общую бибилиотеку, которую потом сможет использовать и ГПЛ соопчество.
А вот и шиш. Ничего мы импользовать не сможем. А он нашу LGPL библиотеку сможет. Это развитие дяди билла и иже с ним :(

anonymous
()
Ответ на: комментарий от LamerOk

>>Арпи собирался использовать мплэер (как проект) очень свободно (в >>смысле лицензионных ограничений), но весь остальной народ, который его >>создавал, хором сказал - ГПЛ и точка. Арпи обиделся, вскочил, выбежал, >>хлопнул дверью. Поплакал, подумал и вернулся просветленным ЛГПЛ
Надеюсь ему и сейчас скажут GPL и точка.

anonymous
()
Ответ на: комментарий от Toster

> Если автор работает в какой-либо компании и что-то создал в рамках работы то Copyright holder - компания где он работает.

В этом случае (в соответствии с договором о работе и зак-ством страны) автором (в юридическом смысле) является компания. Так что этот "копихолдер" по-русски автор ? ;-)))

LamerOk ★★★★★
()
Ответ на: комментарий от lumag

> > Что-то я не пойму - а разве можно ослаблять лицензию с GPL на LGPL?

> Если ты Copyright holder --- то можно.

Так ведь кроме Arpi там же есть и другие авторы? Что если они захотят только GPL?

anonymous
()
Ответ на: комментарий от anonymous

> Что если они захотят только GPL?

Там же ясно сказано: если это основополагающая часть - перепишут :)

lumag ★★
() автор топика
Ответ на: комментарий от LamerOk

> В этом случае (в соответствии с договором о работе и зак-ством страны) автором (в юридическом смысле) является компания. Так что этот "копихолдер" по-русски автор ? ;-)))

Нет. Если ты что-то написал, а потом отдал FSF, то автор --- ты, а Copyright holder --- FSF.

(Это как с UNIX --- написали одни, а авторские права и торговую марку столько раз передавали...)

lumag ★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.