Итак, насчёт разных лицензий. Фактически, 3 варианта:
GPL — полная защита СПО, ничего комбинировать нельзя
LGPL — неполная защита СПО, можно комбинировать, но свободная часть остаётся свободной
3-clause BSD, MIT и аналоги — отсутствие защиты СПО, можно закрывать код
Надо сказать, что «комбинирование» — не совсем удачный термин. Строго говоря, GPL не запрещает комбинировать СПО и не-СПО. GPL запрещает распространять такую комбинацию без сырцов. То есть можно использовать GPL-библиотеки с проприетарным ПО. Но нельзя такое ПО распространять (вообще, можно попробовать распространять в виде сырцов, но тогда теряется основной смысл проприетарности).
Теперь, о бинарниках. Я в своё время направил подобный вопрос в FSF. Они мне сказали примерно следующее: степень интеграции двух программных объектов (СПО-объекта и не-СПО-объекта) определяется в суде. Если суд скажет, что имеет место комбинация, то разработчик нарушил GPL. Это касается таких экзотических способов как связывание GPL-библиотеки через сокет с проприетарной программой, так как с простой линковкой всё и так ясно — нельзя.
Сайт FSF отдельно говорит о плагинах (когда происходит динамическая линковка, но при этом отсутствует явная заточка головного ПО под плагин, то есть разработчики головного ПО не могут предвидеть, плагины под какими лицензиями будут комбинироваться с их ПО, поскольку интерфейс универсальный). Это — серая зона. В частности, известны проприетарные программы, под которые пишутся свободные плагины — и никто никого пока не судит.
В смысле «только»? Очередной релиз Миранды — событие отнюдь не дискретное, многие фичи, упомянутые в ченджлоге, были доступны в alpha-версиях в течение N месяцев. Стабильность упомянутых alpha-версий была вполне приличная (последний месяц — вообще в основном багфиксовые preview-версии были). Если хотел пользоваться Мирандой — мог продолжать пользоваться.
Действительно, зачем тебе установленная Java Runtime Environment, если ты ею не пользуешься? Особенно в Windows, где всё так запущено. И зачем, кстати, тебе устанавливать Qt просто так, если ты им не пользуешься?
Хороший подход — это реализация основы клиента на C/C++ и дописывание всего остального на скриптах. Или наоборот, реализация компонентов клиента в виде библиотек и использование скриптов в качестве основы клиента (склейки компонентов). Это открыло бы богатый набор возможностей, который не ограничивался бы слапами.
Смотря как понимать слово «модули». Если говорить о модулях для Python, то у него есть встроенная система управления модулями (у других языков тоже есть, я думаю). Если говорить о KVIrc… Чем система управления модулями концептуально отличается от системы управления скриптами?
Что касается размера, то см. комментарий насчёт QT и Java. Скриптовый интерпретатор ставится в систему один раз (а если мы говорим о Linux, то он там скорее всего уже стоит), что не увеличивает, а наоборот — уменьшает размер скачиваемых программ. KVIrc pre-4.0 win32 весит 42 мегабайт (распакованный), из них 15 — SSL и QT.
Не буду спорить. Поскольку никто переписывать KVIrc (или его скриптование) не собирается, то и доказывать что-то мне незачем.
Применение полноценных языков выгоднее в перспективе. Программисты, знакомые с таким языком, смогут быстро и легко модифицировать программу под свои нужды. Программисты, не знакомые с этим языком, смогут его изучить. И в любом случае это позволяет использовать модули/библиотеки, доступные для этого языка (что особо актуально для Python, потому что он поставляется «с батарейками»). Для не-программистов использование широко распространённого языка облегчит написание скриптов (больше справочного материала).
При использовании самопального языка преимуществ нет вообще никаких. Я сомневаюсь, что сделать интерпретатор для нового языка легче, чем сделать биндинги для уже существующего языка.
Как это всё делается под Виндой. Без скриптов, исключительно с помощью гуёвых программ:
1) файл (ape/flac) распаковывается обратно в wav
2) cue правится, чтобы указывал на wav-файл (иногда этого не требуется)
3) cue монтируется в виртуальный оптический привод
4) с привода аудиодороги рипаются тривиально (CDex)
GPL — полная защита СПО, ничего комбинировать нельзя
LGPL — неполная защита СПО, можно комбинировать, но свободная часть остаётся свободной
3-clause BSD, MIT и аналоги — отсутствие защиты СПО, можно закрывать код
Надо сказать, что «комбинирование» — не совсем удачный термин. Строго говоря, GPL не запрещает комбинировать СПО и не-СПО. GPL запрещает распространять такую комбинацию без сырцов. То есть можно использовать GPL-библиотеки с проприетарным ПО. Но нельзя такое ПО распространять (вообще, можно попробовать распространять в виде сырцов, но тогда теряется основной смысл проприетарности).
Теперь, о бинарниках. Я в своё время направил подобный вопрос в FSF. Они мне сказали примерно следующее: степень интеграции двух программных объектов (СПО-объекта и не-СПО-объекта) определяется в суде. Если суд скажет, что имеет место комбинация, то разработчик нарушил GPL. Это касается таких экзотических способов как связывание GPL-библиотеки через сокет с проприетарной программой, так как с простой линковкой всё и так ясно — нельзя.
Сайт FSF отдельно говорит о плагинах (когда происходит динамическая линковка, но при этом отсутствует явная заточка головного ПО под плагин, то есть разработчики головного ПО не могут предвидеть, плагины под какими лицензиями будут комбинироваться с их ПО, поскольку интерфейс универсальный). Это — серая зона. В частности, известны проприетарные программы, под которые пишутся свободные плагины — и никто никого пока не судит.
ублюдочнаядикая помесь аудио-проигрывателя, медиа-органайзера и браузера.Но вообще, правильно сказал.
P.S. Какие тэги Фубар выставляет при конверсии?
Действительно, зачем тебе установленная Java Runtime Environment, если ты ею не пользуешься? Особенно в Windows, где всё так запущено. И зачем, кстати, тебе устанавливать Qt просто так, если ты им не пользуешься?
Хороший подход — это реализация основы клиента на C/C++ и дописывание всего остального на скриптах. Или наоборот, реализация компонентов клиента в виде библиотек и использование скриптов в качестве основы клиента (склейки компонентов). Это открыло бы богатый набор возможностей, который не ограничивался бы слапами.
Смотря как понимать слово «модули». Если говорить о модулях для Python, то у него есть встроенная система управления модулями (у других языков тоже есть, я думаю). Если говорить о KVIrc… Чем система управления модулями концептуально отличается от системы управления скриптами?
Что касается размера, то см. комментарий насчёт QT и Java. Скриптовый интерпретатор ставится в систему один раз (а если мы говорим о Linux, то он там скорее всего уже стоит), что не увеличивает, а наоборот — уменьшает размер скачиваемых программ. KVIrc pre-4.0 win32 весит 42 мегабайт (распакованный), из них 15 — SSL и QT.
Не буду спорить. Поскольку никто переписывать KVIrc (или его скриптование) не собирается, то и доказывать что-то мне незачем.
При использовании самопального языка преимуществ нет вообще никаких. Я сомневаюсь, что сделать интерпретатор для нового языка легче, чем сделать биндинги для уже существующего языка.
Судя по сырцам, Python вызывается точно так же — python.begin и python.end
1) файл (ape/flac) распаковывается обратно в wav
2) cue правится, чтобы указывал на wav-файл (иногда этого не требуется)
3) cue монтируется в виртуальный оптический привод
4) с привода аудиодороги рипаются тривиально (CDex)
Вроде бы месяцев 7 назад кто-то начал разрабатывать Python'овый скриптовый движок для KVIrc… Вот это бы следовало бы осветить…