Hamstersoft Ebook Converter нарушает GPL

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

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

При динамической линковке это произойдёт в рантайме, так что распространять можно

Другое дело, кто в винде будет качать вручную тонну зависимостей?

> При динамической линковке это произойдёт в рантайме, так что распространять можно

Да, конечно. Только одно: откуда ты возьмешь заголовочник и описание библиотеки?

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

ну да. правда при разработке ты тоже не должен пользоваться ничем gpl (можешь пользоваться только результатами работы продукта). А include и описание библиотеки - часть gpl продукта.

Если сможешь обойтись без онного - то можешь. Правда если не будет *.so и *.h - хер ты соберешь

> дистрибутив операционной системы — это не программа :-)

Рекомендуется читать дальше. Не хочу повторяться.

Теоретически можно воспользоваться clean-room reverse engineering: кто-то составляет описание интерфейса библиотеки, а ты пишешь хедер по этому описанию, авторство получается твоё, соответственно и лицензия.

я не уверен, что достаточно для этого только заголовочника.

да, с другой стороны, это не clean-room reverse engineering: в данном случае идет передача не о принципах и описание того, что есть, а прямой дословный пересказ. Это все равно, что один читает в слух исходник, а другой пишет

Да нет.Сходи по ссылке и прочитай все ответы. Там четко расписано, что даже взаимодействие через пайп не является железным аргументом в пользу отдельности пррограммы.

> Hamstersoft

Поступок, достойный уважения — не у всякой компании хватит смелости НАСТОЛЬКО открыто заявить, что она делает софт для хомячков.

Согласен.

> предположим я делаю ПРОПРИЕТАРНУЮ программу, которая работает только с определённой (shared-object) GNU_GPL-библиотекой, но это библиотеку НЕ включаю внутрь своей программы

А как ты сделаешь это? Насколько я понимаю, для того что бы скомпилировать программу, работающую с библиотекой, необходимо в исходные коды этой программы включить include-файлы этой библиотеки. А эти инклуды под GPL.

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

А если эта программа написана не на С? Тогда придётся (на основе .h) изобретать свои include, причём они будут внешне совсем не похожи на исходные, так что ещё вопрос, надо ли их публиковать под GPL.

> А если эта программа написана не на С? Тогда придётся (на основе .h) изобретать свои include, причём они будут внешне совсем не похожи на исходные, так что ещё вопрос, надо ли их публиковать под GPL.
Они будут произвольной работой?
GPL — это лицензия, действующая на основе копирайта, авторского права, разрешая пользователю делать с лицензированным объектом то, что авторское право по умолчанию запрещает. Так что если окажется, что по авторское право, не регулирует какие-то действ ия с библиотекой, то и GPL их никак не может регулировать.

использование авторское право по умолчанию запрещает

>> предположим я делаю ПРОПРИЕТАРНУЮ программу, которая работает только с определённой (shared-object) GNU_GPL-библиотекой, но это библиотеку НЕ включаю внутрь своей программы

А как ты сделаешь это? Насколько я понимаю, для того что бы скомпилировать программу, работающую с библиотекой, необходимо в исходные коды этой программы включить include-файлы этой библиотеки. А эти инклуды под GPL.

Можно написать заново на основании документации по библиотеке. Или любой POSIX *.h нарушает права? (кстати кого? SCO?)

> Можно написать заново на основании документации по библиотеке. Или любой POSIX *.h нарушает права?

Найди хоть одну GNU библиотеку под GPL, которая бы соодержала посиксовые функции.

Вообще, если можно взять аналогичную библиотеку от BSD и без изменений использовать бинарник, то он действительно не содержит GPL-кода и на него GPL не распространяется.

>> предположим я делаю ПРОПРИЕТАРНУЮ программу, которая работает только с определённой (shared-object) GNU_GPL-библиотекой, но это библиотеку НЕ включаю внутрь своей программы

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

ну вобщемто я не обговаривал язык программирования...

но да — если мы берём C/C++ — то зачастую при использовании какойто библиотеки — используется чужой #include <...>

..это удобно....

...и тут конешноже БУДЕТ нарушение GNU-GPL (ВЕДЬ я не могу сделать #include <...> БЕЗ согласия с лицензией :))

но вобщемто существует также и довольно распространённый способ когда мы прописываем библиотечные символы в своём коде НАПРЯМУЮ (или используем вызовы «dlopen()/dlsym()»)), без использования чужих заголовочных файлов.

всё зависит от количества символов которые нам необходимо использовать!

хотя да — всё это геморой конешно :-)

[[[но геморой можно уменьшить если написать свою shared-object-GNU-GPL-прослойку, которая работает комфортным способом с требуемой shared-object-GNU-GPL-библиотекой (но менее комфортным способом с проприетарной программой — а именно через вызовы «dlopen()/dlsym()»). а затем распространять ОТДЕЛЬНО проприетарную программу, и ОТДЕЛЬНО прослойку+библиотеку. возлагая всю ответственность об GNU-GPL — строго на пользователя]]]

а вот ещё интересный пример: некоторые модули для Python — написаны на чистом использовании «ctypes» (подгрузка и обращение к библиотекам напрямую). и разработчики этих модулей гордятся своим трудом :-)

кстате говоря — видил не так давно проприетарный продукт, отчасти написанный на Python (содержит только *.pyo файлы (без *.py) внутри *.zip-архива). а вот куча слухов о том что декомпиляция *.pyo-бинарника производится не сложно — оказываются слухами весьма устаревшими :-)

> но вобщемто существует также и довольно распространённый способ когда мы прописываем библиотечные символы в своём коде НАПРЯМУЮ
А где вы возьмёте эти символы, не имея доступа к самой библиотеке? Я так понимаю, что эти символы — будут частями кода библиотеки, которые ты включишь в свою программу.

если написать свою shared-object-GNU-GPL-прослойку

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

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

прослойка — *будет* производным кодом от библиотеки (всё верно! потомучто там используется #include <библиотека>)

а вот дальше транзитивность на проприетарную-программу — *не* распространится :-) , потомучто проприетарная-программа НЕ будет содержать ни #include <прослойка> ни #include <библиотека>

dlopen()/dlsyn() не нуждаются в #include <...> . а прослойка будет как раз ОПТИМИЗИРОВАННА для использования именно dlopen()/dlsyn() . так как это и есть основная цель прослойки :), а иначе зачем прослойка(?)!

главное только помнить что распространять прослойку вместе с проприетарной-программой — *не* лзя

И в общем-то правильно — проприетарщина не нужна.

ну это-то понятно.. тут никто не спорит :-)

> dlopen()/dlsyn() не нуждаются в #include <...>

А как они тогда узнают, что из той библиотеки можно вообще сделать?
Инклуд вроде как раз нужен компилятору что бы вкомпилить информацию о библиотеке в получаемый файл

>но это библиотеку НЕ включаю внутрь своей программы
В таком случае ты не нарушаешь ничего, вроде бы (по точно той же причине, что и nvidia-блоб). Другое дело — пользователи сабжевого софта не осилят инсталляцию библиотеки.

Вообще, от компании, всерьёз считающей, что google translate — повод написать supports 40 languages, не стоит ждать ничего хорошего. Как минимум японский перевод — машинный, причём явно с русского.

Разглядел Сколково. Претензии к качеству снимаются, в распиле оно не нужно.

Например, читаю http://cnswww.cns.cwru.edu/php/chet/readline/readline.html#SEC23

Пишу в коде

extern char *readline (const char *prompt);

int main () {
   ...
   char *line = readline ("Enter command: ");
   ...
}

Рядом кладу readline.so.6 скомпилированный из

char *readline (const char *prompt)
{
     char *s;
     scanf("%as", &s);
     return s;
}

В инструкции по установке пишу, что если пользователь не имеет readline.so.6, то может воспользоваться идущим в комплекте.

Я нарушаю GPL?

> dlopen()/dlsyn() не нуждаются в #include <...> . а прослойка будет как раз ОПТИМИЗИРОВАННА для использования именно dlopen()/dlsyn() . так как это и есть основная цель прослойки :), а иначе зачем прослойка(?)!

главное только помнить что распространять прослойку вместе с проприетарной-программой — *не* лзя

А как это повлияет на нарушение/ненарушение GPL, если ты даже будешь распространять прослойку вместе?

> В инструкции по установке пишу, что если пользователь не имеет readline.so.6, то может воспользоваться идущим в комплекте.

Я нарушаю GPL?

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

> В инструкции по установке пишу, что если пользователь не имеет readline.so.6, то может воспользоваться идущим в комплекте.

Я нарушаю GPL?

Вообще, ты не первый такой умный, так уже делал автор clisp:

http://clisp.cvs.sourceforge.net/viewvc/clisp/clisp/doc/Why-CLISP-is-under-GPL

В итоге он согласился с доводами Столлмана и решил, что лучше сделать clisp гплным, чем отказываться от readline

> а вот дальше транзитивность на проприетарную-программу — *не* распространится :-) , потомучто проприетарная-программа НЕ будет содержать ни #include <прослойка> ни #include <библиотека>

dlopen()/dlsyn() не нуждаются в #include <...> . а прослойка будет как раз ОПТИМИЗИРОВАННА для использования именно dlopen()/dlsyn() . так как это и есть основная цель прослойки :), а иначе зачем прослойка(?)!

главное только помнить что распространять прослойку вместе с проприетарной-программой — *не* лзя

Позиция FSF в этом вопросе — всё равно проприетарная программа и GPL-библотека будут являться вместе одной программой, только замаскированной под две, поскольку в одной из частей ясно видно намерение включить другую часть.

Вот отсюда:
http://clisp.cvs.sourceforge.net/viewvc/clisp/clisp/doc/Why-CLISP-is-under-GPL

> http://clisp.cvs.sourceforge.net/viewvc/clisp/clisp/doc/Why-CLISP-is-under-GPL

В итоге он согласился с доводами Столлмана и решил, что лучше сделать clisp гплным, чем отказываться от readline

Судя по этой переписке он согласился из-за libgmp, а не из-за readline. :)

К тому же там был другой вопрос, и никакого «клея» там не было.