Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 93
Почему бы просто не заплатить авторам за их работу?
Одно другому не мешает. Раскрутить клиента на покупку такого софта и поддержку авторов — святое дело.
Но я в принципе не люблю GPL — ибо это вирус. И свой софт стараюсь выпускать под Public Domain — если никто палки в колёса не ставит, как в описанном выше случае.
Но я в принципе не люблю GPL — ибо это вирус. И свой софт стараюсь выпускать под Public Domain — если никто палки в колёса не ставит, как в описанном выше случае.
Никто не мешает вам использовать двойное лицензирование.
GPL только требует доступность исходников производного продукта под GPL в случае распространения бинарников слинкованых с библиотекой. Так что если не распространяете бинарники — никто вообще не заставляет выкладывать исходники под GPL.
При этом никто не мешает вам выложить ваши исходники скажем под GPL и BSD одновременно. Тогда те кто не будут линковать GPL-библиотеку смогут спокойно использовать ваш продукт соответственно с лицензией BSD.
GPL только требует доступность исходников производного продукта под GPL в случае распространения бинарников слинкованых с библиотекой. Так что если не распространяете бинарники — никто вообще не заставляет выкладывать исходники под GPL.
При этом никто не мешает вам выложить ваши исходники скажем под GPL и BSD одновременно. Тогда те кто не будут линковать GPL-библиотеку смогут спокойно использовать ваш продукт соответственно с лицензией BSD.
Я не знаю, может из текста топика это не до конца ясно — «недостаток MatrixSSL» с моей точки зрения не в том, что авторы денег хотят — это как раз абсолютно нормально — а в том, что они из-за этого решили усложнить окружающим жизнь осознанно предпочтя GPL (у них в FAQ это говорится открытым текстом).
«Но у неё есть один недостаток: денег авторы хотят.» Чего то я не понял — за GPL денег просят?.. Это как? А люди правильно, молодцы. Теперь никто не захапает результат их труда. Если бы им было все пофиг, выпустили бы под BSD.
Я уже перефразировал это предложение в топике. Действительно, сначала я его сформулировал очень неудачно, так, что не понятно ни что авторы хотят, ни что мне в этом не нравится.
У них двойная лицензия. GPL подразумевает что софт, который использует MatrixSSL будет тоже под GPL. Если вы пишете свой продукт и хотите использовать эту либу — есть вторая лицензия, коммерческая. Она-то и стоит денег, которые автор не хочет платить.
Да не платить я не хочу, а релизить свой код под GPL я не хочу! Это разные вещи! См. коммент выше.
Да, собственно, те же яйца — только в профиль :)
Так купите библиотеку по второй, коммерческой лицензии, и выпускайте уже свой софт под абсолютно какой угодно лицензией.
Не думаю, что это возможно. Я пишу Perl-модуль, использующий MatrixSSL (а, точнее, Crypt::MatrixSSL, уже заражённый GPL). Если я куплю одну лицензию, и выложу свой модуль под Public Domain или standard Perl license на CPAN, то что, весь мир сможет использовать коммерческую версию MatrixSSL благодаря покупке мной одной лицензии? Так не бывает, у них наверняка в коммерческой лицении есть специальные ограничения на этот случай.
Библиотека распространяется по двойной лицензии и варианта всего два:
1. Использовать MatrixSSL бесплатно и открыть свою разработку под GPL.
2. Использовать MatrixSSL платно и не открывать свою работу вообще.
Варианта открыть свою разработку под третьей лицензией (BSD, Beer-ware, etc...) нет вообще!
GPL всё ещё называется свободной лицензией :)
1. Использовать MatrixSSL бесплатно и открыть свою разработку под GPL.
2. Использовать MatrixSSL платно и не открывать свою работу вообще.
Варианта открыть свою разработку под третьей лицензией (BSD, Beer-ware, etc...) нет вообще!
GPL всё ещё называется свободной лицензией :)
Угу. :) Вот я и пытаюсь изобрести третий вариант, чтобы сделать GPL истинно свободной.
Считаю, что ваш вариант единственно подходящий.
Будет 2 продукта: один под GPL, а второй под вашей лицензией.
Будет 2 продукта: один под GPL, а второй под вашей лицензией.
Все ваши разработки можете сразу отправлять Эбену — он их учёт и c GPLv4 они уже не будут совместимы.
А если по теме: вы можете выпускать своё приложение под какой угодно лицензией. И никто ваши исходники открывать не запретит. Чего вы не можете делать так это поставлять ваши не-GPL-совместимые исходники и MatrixSSL единым пакетом. Никакой RPC ничего не изменит.
А если по теме: вы можете выпускать своё приложение под какой угодно лицензией. И никто ваши исходники открывать не запретит. Чего вы не можете делать так это поставлять ваши не-GPL-совместимые исходники и MatrixSSL единым пакетом. Никакой RPC ничего не изменит.
У меня тоже есть вопрос. Допустим, я пишу заказчику приложение с использованием компонентов с GPL.
В конце предоставляю заказчику в т.ч. исходники, и свои и компонентов.
Есть ли в таком случае, какие-либо конфликты с GPL?
В конце предоставляю заказчику в т.ч. исходники, и свои и компонентов.
Есть ли в таком случае, какие-либо конфликты с GPL?
Если в итоге ваш заказчик будет распространять это приложение — не важно, продавать или бесплатно. То он должен распространять их вместе с исходниками.
jquery на GPL и MIT, и используют его повсеместно.
В таком случае исходники нужно показать не только заказчику, а всему миру: sourceforge, etc…
Правда в моей компании делают так: тихо выкладывают в общий доступ на фтп фирмы… с одной стороны софт доступен, с другой — об этом нигде не говорится :(
Правда в моей компании делают так: тихо выкладывают в общий доступ на фтп фирмы… с одной стороны софт доступен, с другой — об этом нигде не говорится :(
Получается, что если продукт даже для внутреннего пользования, то исходники (согласно GPL) все равно нужно опубликовывать?
По запросу. Выложите где нить на ftp. Если попросят, дадите доступ. И не надо считать GPL вирусом. Тут просто — «не нравится, плати». А то повторяете слова руководителей MS.
Нет.
Вы обязаны предоставлять исходник (сразу или по запросу) только тем, кому вы предоставили скомпилированный продукт (object code).
Вы обязаны предоставлять исходник (сразу или по запросу) только тем, кому вы предоставили скомпилированный продукт (object code).
Бред. GPL не обязывает предоставлять исходники кому попало, а только пользователям GPL-ного продукта.
Нет, это неверно. GPL не требует «показывать исходники всему миру». GPL требует в точности то, что она требует: если вы передаете производную работу с GPL-лицензированной своему заказчику, то вы обязаны передать её вместе с исходниками и тоже на условиях GPL (то есть заказчик, если захочет, сможет распространять её дальше на тех же условиях). Если вы даете возможность скачать свою программу всем желающим (в виде бинарника) — тогда да, нужно предоставлять и исходники всем желающим. Но если вы делаете работу под заказ, такого требования нет. Подробнее см. первоисточники.
Там есть тонкость: если вы сразу передаёте исходники — то всё как описано, но если вы передаёте только бинарники — то исходники у вас может уже требовать кто угодно.
Не могли бы Вы привести источник, подтверждающий это утверждение, либо какое-то его обоснование. Мне оно кажется в высшей степени странным.
Ась? Вы же сами привели источник!
Там написано что так сделано для того, чтобы люди получившие ваши бинарники через 10е руки всё равно могли получить исходники, но в самой лицензии никаких ограничений подобного рода нет: ваше предложение должно быть выписано сразу на any third party (это юридический термин — обозначает всех людей кроме тех двух «party», которые участвуют в передаче бинарников)…
If you choose to provide source through a written offer, then anybody who requests the source from you is entitled to receive it.Чётко и недвусмысленно.
Там написано что так сделано для того, чтобы люди получившие ваши бинарники через 10е руки всё равно могли получить исходники, но в самой лицензии никаких ограничений подобного рода нет: ваше предложение должно быть выписано сразу на any third party (это юридический термин — обозначает всех людей кроме тех двух «party», которые участвуют в передаче бинарников)…
Да, спасибо, Вы безусловно правы. Логика действительно такая: либо исходник «сразу на бочку», либо — для всех желающих. Эх, надо перечитать GPL FAQ :)
Это, вроде, только GPLv2. В GPLv3 сказано (пункт 6b):
Хотя, конечно, вряд ли кто-то будет проверять наличие бинарников.
Convey the object code [...] accompanied by a written offer [...] to give anyone who possesses the object code either (1) a copy of the Corresponding Source for all the software in the product that is covered by this License [...] or (2) access to copy the Corresponding Source from a network server at no charge
Хотя, конечно, вряд ли кто-то будет проверять наличие бинарников.
По-моему ваш вариант с клиент-серверной системой — то что надо.
Как бы не так. Если он не собирается распространять свои разработки вместе с MatrixSSL на одном носителе — то и RPC никакого не нужно: достаточно слинковать всё динамически и не включать MatrixSSL в комплект поставки. Если же комплект поставки включает MatrixSSL, то всё становится сложнее. Например если вы разработаете полноценный протокол для использования SSL библиотек, сделаете несколько реализаций (OpenSSL, GnuTLS, MatrixSSL, etc) и т.д. и т.п. — то да, можно будет говорить о том, что это «mere aggregation». А если выяснится что RPC там нифига не документированный и завязанный на MatrixSSL API, то вряд ли суд будет к вам сильно благосклонен…
Программу написанную под GPL можно продавать? С исходниками в комплекте
если вы не согласны с лицензией выбраной создателями программы — то и незачем пользоваться.
Поставленный вопрос довольно нетривиален. Заведомо известно, что в FSF полагает любую (стастическую или динамическую) линковку программы с библиотекой созданием derivative work с библиотеки. Что касается RPC, то здесь мне не все ясно. Вроде бы, никто не считает общение веб-браузера с веб-сервером с помощью HTTP созданием производной работы. Но RPC мне кажется более жесткой связкой клиентской программы с серверной, и может порождать derivative work при определенной трактовке.
Я думаю, что основной вопрос, который здесь следует задать, звучит так: можете ли вы написать сторонее приложение (которое вы не собираетесь лицензировать под GPL), не имея информации о внутреннем устройстве исходной GPL-ной библиотеки, и опираясь, скажем, только на спецификации публично-доступных протоколов? (Понятно, что я могу написать веб-браузер, не заглядывая во внутреннее устройство IIS, просто глядя на спецификации HTTP, поэтому мой браузер заведомо не будет производной работой с IIS; IIS в данном случае можно будет заменить на Apache или на что угодно еще.) Если ответ отрицательный, то я полагаю, что получившийся гибрид может считаться созданием производной работой с исходной библиотеки и не может распространяться под лицензией, отличной от GPL.
Более того: даже если написание такой «тройки» программ может быть и легальным, но совместное распространение может оказаться нелегальным. Этот вопрос необходимо изучить отдельно.
В любом случае, наверное, имеет смысл посоветоваться с каким-нибудь юристом, разбирающимся в вопросах свободных лицензий. Правда, боюсь, что в России таковых нет или почти нет.
Я думаю, что основной вопрос, который здесь следует задать, звучит так: можете ли вы написать сторонее приложение (которое вы не собираетесь лицензировать под GPL), не имея информации о внутреннем устройстве исходной GPL-ной библиотеки, и опираясь, скажем, только на спецификации публично-доступных протоколов? (Понятно, что я могу написать веб-браузер, не заглядывая во внутреннее устройство IIS, просто глядя на спецификации HTTP, поэтому мой браузер заведомо не будет производной работой с IIS; IIS в данном случае можно будет заменить на Apache или на что угодно еще.) Если ответ отрицательный, то я полагаю, что получившийся гибрид может считаться созданием производной работой с исходной библиотеки и не может распространяться под лицензией, отличной от GPL.
Более того: даже если написание такой «тройки» программ может быть и легальным, но совместное распространение может оказаться нелегальным. Этот вопрос необходимо изучить отдельно.
В любом случае, наверное, имеет смысл посоветоваться с каким-нибудь юристом, разбирающимся в вопросах свободных лицензий. Правда, боюсь, что в России таковых нет или почти нет.
Запаковываете библиотеку в DLL обёртку, собственно DLL — у Вас будет идти по лицензии GPL с открытыми кодами. В программе динамически вызываете эту DLL. Пользователю при установке вашей программы показываете как лицензию на свою программу, так и отдельно говорите что часть библиотек таких и таких — поставляются на основе лицензии GPL. Всё — при обращении к GPL коду на уровне системных вызовов (т.е. при динамическом обращении к DLL с кодом GPL), лицензировать вашу программу под GPL ненужно (но вот саму DLL придётся лицензировать под GPL).
Я не вполне уверен в столь однозначной трактовке. Есть ли у вас информация о прецедентах такого использования GPL-лицензированных библиотек крупными проектами (где можно было бы ожидать, что потенциальное нарушение условий лицензии заинтересует разработчиков исходной GPL-библиотеки)?
Замечу, что как я писал выше, динамическую линковку с какими-либо библиотеками FSF считает созданием «производной работы». См. также релевантные вопросы в GPL FAQ: О GPL-ных плагинах, О GPL-библиотеках.
Замечу, что как я писал выше, динамическую линковку с какими-либо библиотеками FSF считает созданием «производной работы». См. также релевантные вопросы в GPL FAQ: О GPL-ных плагинах, О GPL-библиотеках.
Я тоже не уверен. Точнее, я практически уверен в том, что это легально только с LGPL, но не с GPL.
Это абсолютно легально с точки зрения GPL до тех пор пока вы не распространяете комплект включающий в себя как саму DLLку, так и программу, её использующую.
Лакмусовая бумажка — видеодрайвера nVidia. Пока вы не распространяете их вместе с ядром — вы ничего не нарушаете (nVidia всё делает по закону). А вот как только вы кладёте на один CD и исходники ядра и бинарные драйвера — всё становится сложнее. До суда пока дело не доходило, но разборки подобные с дистрибутивами поставляющими драйвера nVidia в комплекте уже были…
Лакмусовая бумажка — видеодрайвера nVidia. Пока вы не распространяете их вместе с ядром — вы ничего не нарушаете (nVidia всё делает по закону). А вот как только вы кладёте на один CD и исходники ядра и бинарные драйвера — всё становится сложнее. До суда пока дело не доходило, но разборки подобные с дистрибутивами поставляющими драйвера nVidia в комплекте уже были…
С драйверами nVidia и ядром вообще ситуация интересная. Насколько я понимаю мнение Торвальдса (могу поискать релевантную переписку на LKML), он говорит, что мы не можем считать видеодрайвер «производной работой с ядра», если, скажем, существенная часть кода этого драйвера совпадает с версией того же драйвера под Windows, а из кода ядра для сборки этих драйверов нужны только заголовочные файлы (Торвальдс считает, что это fair use этих участков кода). Тем самым, если принять трактовку Торвальдса, то конечно само по себе существование таких драйверов действительно 100% легально.
Насчет совместной дистрибуции — вопрос более интересный. Я так понимаю, что единственные правообладатели, чьи права могут нарушаться при такой совместной дистрибуции — это права авторов linux kernel. Насколько я понимаю, они смотрят на это «сквозь пальцы» (в отличие от, например, распространения kernel в различных устройствах при несоблюдении устройств — см. gpl-violations.org). Что касается «наездов» на вендоров GNU/Linux-дистрибутивов — я помню какую-то мутную историю, связанную с этим, но, кажется, тот человек, который пытался призвать к ответственности кого-то из вендоров, на самом деле никаких прав это делать не имел.
В то же время, описанная автором исходного поста ситуация явно иная: здесь разработчики исходной библиотеки кровно заинтересованы в том, чтобы условия GPL выполнялись максимально строго, и скорее всего, если автор сделает то, что им задумано (основательно порушив бизнес-модель исходного разработчика), я думаю, что это явно не останется незамеченным со стороны исходных девелоперов.
Насчет совместной дистрибуции — вопрос более интересный. Я так понимаю, что единственные правообладатели, чьи права могут нарушаться при такой совместной дистрибуции — это права авторов linux kernel. Насколько я понимаю, они смотрят на это «сквозь пальцы» (в отличие от, например, распространения kernel в различных устройствах при несоблюдении устройств — см. gpl-violations.org). Что касается «наездов» на вендоров GNU/Linux-дистрибутивов — я помню какую-то мутную историю, связанную с этим, но, кажется, тот человек, который пытался призвать к ответственности кого-то из вендоров, на самом деле никаких прав это делать не имел.
В то же время, описанная автором исходного поста ситуация явно иная: здесь разработчики исходной библиотеки кровно заинтересованы в том, чтобы условия GPL выполнялись максимально строго, и скорее всего, если автор сделает то, что им задумано (основательно порушив бизнес-модель исходного разработчика), я думаю, что это явно не останется незамеченным со стороны исходных девелоперов.
Там были разные разговоры на тему легальности/нелегальности этой деятельности, но да — большой заинтересованности не было.
Тут же предлагается впрямую пойти «с шашкой против танка»: попытаться обойти GPL и поставить под сомнение основу бизнес-модели таких незначительных фирм как Nokia, Sun, etc. Посмотрим что из этого выйдет :-)
Тут же предлагается впрямую пойти «с шашкой против танка»: попытаться обойти GPL и поставить под сомнение основу бизнес-модели таких незначительных фирм как Nokia, Sun, etc. Посмотрим что из этого выйдет :-)
а разве SUN форсирует GPL? netbeans имеет двойное лицензириование, opensolaris — CDDL, openoffice — LGPL, OpenJDK -GPL+linking exception
SUN заплатил миллиард за MySQL AB, у которого бизнес-модель именно такая: бесплатно для свободного ПО, за денюжку для закрытого.
mysql за деньги покупается, как правило, не ради возможности слинковать с ним программу…
И ради этой возможности тоже. Embedded MySQL имеется в виду. Думаете зря они перевели клиентские библиотеки с LGPL на GPL?
об embedded mysql не задумывался. Только я что-то про GPL по ссылке ничего не вижу.
а какие ещё клиентские они на gpl перевели?
а какие ещё клиентские они на gpl перевели?
Об embedded mysql не задумывался.Однако же он продаётся — и довольно неплохо продаётся.
Только я что-то про GPL по ссылке ничего не вижу.А зачем там что-то про GPL? Embedded mysql продаётся тем, кто хочет встраивать MySQL в свои приложения, но не хочет публиковать исходники.
а какие ещё клиентские они на gpl перевели?Обычные — libmysql, собственно…
Давайте вернёмся к конкретной ситуации.
Есть Perl-модуль Crypt::MatrixSSL. Он действительно включает в себя библиотеку MatrixSSL — как исходники, так и линкуется с ней при установке. И у него лицензия GPL.
Я пишу свой Perl-модуль, который использует Crypt::MatrixSSL. Мой модуль не распространяется вместе с Crypt::MatrixSSL и не включает его. Оба модуля пользователь должен самостоятельно загрузить со CPAN. (Кстати, а сам CPAN не считается тем самым «распространителем» обоих модулей одновременно?)
И Вы считаете, что в этой ситуации я могу спокойно релизить свой модуль не под GPL?… И что, все программы, которые используют Crypt::MatrixSSL (как и мой модуль) но не включают его в комплект поставки (как и мой модуль — кстати, perl-модули вообще не принято включать в комплект поставки perl-скриптов, юзеры их практически всегда устанавливают со CPAN сами) — тоже могу быть не GPL?
А в чём же тогда, простите, был смысл для авторов MatrixSSL выбрать именно GPL, а не LGPL? И в чём же тогда разница между GPL и LGPL?
Есть Perl-модуль Crypt::MatrixSSL. Он действительно включает в себя библиотеку MatrixSSL — как исходники, так и линкуется с ней при установке. И у него лицензия GPL.
Я пишу свой Perl-модуль, который использует Crypt::MatrixSSL. Мой модуль не распространяется вместе с Crypt::MatrixSSL и не включает его. Оба модуля пользователь должен самостоятельно загрузить со CPAN. (Кстати, а сам CPAN не считается тем самым «распространителем» обоих модулей одновременно?)
И Вы считаете, что в этой ситуации я могу спокойно релизить свой модуль не под GPL?… И что, все программы, которые используют Crypt::MatrixSSL (как и мой модуль) но не включают его в комплект поставки (как и мой модуль — кстати, perl-модули вообще не принято включать в комплект поставки perl-скриптов, юзеры их практически всегда устанавливают со CPAN сами) — тоже могу быть не GPL?
А в чём же тогда, простите, был смысл для авторов MatrixSSL выбрать именно GPL, а не LGPL? И в чём же тогда разница между GPL и LGPL?
Нет, если модуль использует Crypt::MatrixSSL (т.е. содержит use Crypt::MatrixSSL), то я полагаю, что это очевидно является созданием производной работы с библиотеки, и требует выполнения условий GPL.
Я тоже так думаю. Но я спрашивал у khim.
А тут суд нужен чтобы разобраться. Тут нужно смотреть на сам модуль — как именно используется Crypt::MatrixSSL, для чего и в каких масштабах. Авторы GPL и FAQ тут не поможет: например если ваш модуль содержит строчку «use Crypt::MatrixSSL», но дальше ловит исключение и использует OpenSSL если у вас нет Crypt::MatrixSSL — то с какой стати он должен считаться производным от MatrixSSL?
Рассуждения о том что можно и чего нельзя делать скачивая модуль с сети касаются только случая, когда модуль не является производным от MatrixSSL. Но вы на это повлиять никак не можете создавая Crypt::MatrixSSL.
Рассуждения о том что можно и чего нельзя делать скачивая модуль с сети касаются только случая, когда модуль не является производным от MatrixSSL. Но вы на это повлиять никак не можете создавая Crypt::MatrixSSL.
А в чём же тогда, простите, был смысл для авторов MatrixSSL выбрать именно GPL, а не LGPL? И в чём же тогда разница между GPL и LGPL?Разница появляется когда кто-то собирается распространять готовый продукт. То есть если оба ваших модуля будут включены в состав ePages или другой подобной системы — то тут-то и потребуется лицензия от авторов MatrixSSL и от вас (если ваш модуль тоже будет под GPL).
Если пользователь сам скачивает два модуля и линкует их у себя на компьютере — никаких проблем. Но если он хочет их включить в какой-нибудь законченный продукт (роутер там или NAS какой-нибудь) — так он и огребает по полной. Достаточно вам передать кому-нибудь болванку с MatrixSSL и модулем, который использует не-GPL-совместимую лицензию… и вы лишаетесь права использовать MatrixSSL навсегда.
То, что «у себя под подушкой» вы можете использовать GPL-библиотеку с любым софтом есть серъёзное ограничение GPL, но оно было сделано сознательно: это следует из подхода Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running the Program is not restricted.
Конечно если кто-то выпустит что-то не-GPL-совместимое с использованием Crypt::MatrixSSL и самой MatrixSSL, то он может попасть под статью «пособничество» — но это уже далеко не такое страшное дело, как прямое нарушение авторских прав…
Когда распространяете всё на 1 CD у Вас должно быть 3 лицензии, 1 на вашу программу, 1 GPL на DLL, 1 GPL на чужой код включённый в DLL. При этой эта DLL должна беспрепятственно отделятся от вашего проекта и при необходимости заменятся на другую (типа ваша программа не просто за пускатель dll, а в ней есть хоть 1 форма с авторством) — требования GPL по таким DLL. Т.е. это похоже на то же самое как закрытые программы используют в Linux вызовы таких dll (*.so) как — ядра, GTK и т.д.
Вы опять путаете GPL и LGPL. LGPL — это то, что вы описали. GPL же требует большего. Например достаточно того, чтобы вместо GPL-ной версии можно было подставить что-нибудь другое (Linux реализует POSIX стандарт и потому на программы, использующие только системные вызовы, описанные в POSIX, GPL не распространяется).
Простой возможности заменить DLL недостаточно! Закрытые программы используют LGPL'ную glibc, которая, в свою очередь, использует GPL'ное ядро. Если бы не стандарт POSIX, то glibc пришлось бы делать GPL'ной и у авторов закрытых программ начались бы проблемы.
Простой возможности заменить DLL недостаточно! Закрытые программы используют LGPL'ную glibc, которая, в свою очередь, использует GPL'ное ядро. Если бы не стандарт POSIX, то glibc пришлось бы делать GPL'ной и у авторов закрытых программ начались бы проблемы.
Т.е. стандарт POSIX был до Linux. Общение с ядром закрытых программ производится на основании этого стандарта. Спасибо что рассказали. Тогда возможно можно будет работать по такому же варианту. Описать вариант обмена данными на основе XML. Ваша программа создаёт этот XML и складывает её в определённое место, а программа GPL читает информацию из этого XML и выполняет. Т.е. код GPL код зашивается не в просто DLL, а в программу читающую XML файл заранее описанного формата в определённый промежуток времени.
Ну об этом даже в FAQ написано: in many cases you can distribute the GPL-covered software alongside your proprietary system. To do this validly, you must make sure that the free and non-free programs communicate at arms length, that they are not combined in a way that would make them effectively a single program.
Тут нет чётких правил (DLL — низзя, RPC-можно), скорее речь идёт о том, что сам интерфейс общения между GPL и не-GPL частями чётко описан (HTTP, POSIX, etc).
Тут нет чётких правил (DLL — низзя, RPC-можно), скорее речь идёт о том, что сам интерфейс общения между GPL и не-GPL частями чётко описан (HTTP, POSIX, etc).
если обертка будет действительно независимой апликухой — такой вариант сработает (пару раз что то подобное делали в совсем безвыходных ситуациях)
Я считаю GPL — это будущее нации
Программы должны быть свободны, а программисты — получать все блага из госфонда как депутаты
Программы должны быть свободны, а программисты — получать все блага из госфонда как депутаты
Простите, я все равно не понял, чем Вам не нравится GPL, кроме того, что она вирусная.
А я и не описывал, чем не не нравится GPL, так что не удивительно, что Вы это не поняли. :)
Если Вам интересно, то мне не нравится GPL тем, что это по своей сути агрессия. Это целенаправленная, жёсткая агрессия против коммерческого ПО. Объявление войны коммерческому ПО, если угодно.
Многие сейчас используют GPL просто потому, что «так делают все», потому, что GPL ассоциируется с F/OSS, и потому, что сами они в лицензиях не разбираются. Многие потому, что GPL это вирус, и у них нет выбора. И я не думаю, что большинство разработчиков осознанно выбирает GPL, чтобы поучаствовать в войне с проприетарным ПО.
Я не чувствую желания участвовать в этой войне. Не чувствую опасности лично для себя, при мысли что мой код, выпущенный под Public Domain, возьмёт коммерческая фирма и будет делать на нём деньги, а со мной не делиться. Более того, я не испытываю потребности защищаться от того, что кто-то сотрёт моё имя из исходников и поставит своё — иначе я бы использовал, например, MIT, а не Public Domain.
В общем, кто хочет воевать — пусть воюет, а я предпочитаю просто программировать.
Если Вам интересно, то мне не нравится GPL тем, что это по своей сути агрессия. Это целенаправленная, жёсткая агрессия против коммерческого ПО. Объявление войны коммерческому ПО, если угодно.
Многие сейчас используют GPL просто потому, что «так делают все», потому, что GPL ассоциируется с F/OSS, и потому, что сами они в лицензиях не разбираются. Многие потому, что GPL это вирус, и у них нет выбора. И я не думаю, что большинство разработчиков осознанно выбирает GPL, чтобы поучаствовать в войне с проприетарным ПО.
Я не чувствую желания участвовать в этой войне. Не чувствую опасности лично для себя, при мысли что мой код, выпущенный под Public Domain, возьмёт коммерческая фирма и будет делать на нём деньги, а со мной не делиться. Более того, я не испытываю потребности защищаться от того, что кто-то сотрёт моё имя из исходников и поставит своё — иначе я бы использовал, например, MIT, а не Public Domain.
В общем, кто хочет воевать — пусть воюет, а я предпочитаю просто программировать.
Понятно, спасибо.
То есть, Ваши возражения носят идеологический характер, а технически Вас GPL устраивает?
То есть, Ваши возражения носят идеологический характер, а технически Вас GPL устраивает?
Именно так. Я могу свои модули и под GPL выпускать, лично для меня — технически — выпущу я их под Public Domain или GPL разницы никакой. Проблемы будут у тех, кто будет этими модулями пользоваться.
Собственно, обсуждаемый в топике модуль я уже выпустил под GPL, ибо воротить сетевой сервис с RPC ради отвязки от GPL мне лениво. Тем более, что до конца не понятно, легально это или нет — сколько людей, столько и мнений.
Собственно, обсуждаемый в топике модуль я уже выпустил под GPL, ибо воротить сетевой сервис с RPC ради отвязки от GPL мне лениво. Тем более, что до конца не понятно, легально это или нет — сколько людей, столько и мнений.
Очень интересно.
Вы там выше говорили, что «кто хочет воевать — пусть воюет, а я предпочитаю просто программировать». А выясняется, что и Вы решили повоевать с GPL, которая Вам в принципе нравится, Вы думаете о гипотетических других, «кто будет этими модулями пользоваться».
Решение выпустить модуль под GPL приветствую и одобряю.
Вы там выше говорили, что «кто хочет воевать — пусть воюет, а я предпочитаю просто программировать». А выясняется, что и Вы решили повоевать с GPL, которая Вам в принципе нравится, Вы думаете о гипотетических других, «кто будет этими модулями пользоваться».
Решение выпустить модуль под GPL приветствую и одобряю.
Я не воюю с GPL, я тихо мирно релизю в Public Domain и не морочусь. А вот когда GPL приходит в мой дом (в лице Crypt::MatrixSSL), и вынуждает меня заморачиваться, думать под какой лицензией я обязан выпускать свой код, etc. — вот тогда и я могу немного повоевать, из принципа. Знаете, кто к нам с мечом придёт…
И я никогда не говорил, что мне GPL «в принципе нравится» — Вы явно выдаёте желаемое за действительное. :) GPL мне активно не нравится, по описанным выше причинам.
Решение одобрять или не одобрять сложно, т.к. никакого «решения» по сути небыло — меня взяли за горло и вынудили использовать GPL. Не вижу повода для одобрения… :(
И я никогда не говорил, что мне GPL «в принципе нравится» — Вы явно выдаёте желаемое за действительное. :) GPL мне активно не нравится, по описанным выше причинам.
Решение одобрять или не одобрять сложно, т.к. никакого «решения» по сути небыло — меня взяли за горло и вынудили использовать GPL. Не вижу повода для одобрения… :(
Вот потому-то я и спросил про идеологическую составляющую Вашего протеста.
Налицо конфликт идеологий, философий, если хотите.
Вы же понимаете, почему GPL такая, какая она есть?
Налицо конфликт идеологий, философий, если хотите.
Вы же понимаете, почему GPL такая, какая она есть?
Никто вас за горло не брал и выбор у вас был, однако: MatrixSSL — далеко не единственная библиотека с поддержкой SSL. Есть OpenSSL, GnuTLS и другие.
Почему-то про коммерческие библиотеки (где каждый разработчик должен платить денежку авторам отдельно) никто не говорит что это, дескать, «объявление войны» (и MatrixSSL такую возможность вам даёт в явном виде), а GPL — это, дескать, агрессия, вирус, etc.
Почему-то про коммерческие библиотеки (где каждый разработчик должен платить денежку авторам отдельно) никто не говорит что это, дескать, «объявление войны» (и MatrixSSL такую возможность вам даёт в явном виде), а GPL — это, дескать, агрессия, вирус, etc.
выше уже было написано, что даже наличие коммерческой лицензии может и не помочь
Именно. Коммерческие лицензии, как правило, гораздо более агрессивны чем GPL (вы обычно вообще не можете их распространять со своей библиотекой — каждому разработчику приходится отдельно покупать QT или Turbo Vision, распространять эти библиотеки вместе со своей библиотекой вы вообще не имеете права). Даже многие бесплатные библиотеки Microsoft вы должны обязательно скачивать с сервера Microsoft, просто приложить их к вашей библиотеке вы не можете. Но к этой агрессии все уже привыкли и как-то на неё не реагируют. А GPL — прям как красная тряпка на быка…
>каждому разработчику приходится отдельно покупать QT или Turbo Vision, распространять эти библиотеки вместе со своей библиотекой вы вообще не имеете права)
постойте-постойте, что-то насчёт QT вы, кажется, заговариваетесь — каждому разработчику нужно покупать лицензию на QT, но как минимум конечный продукт можно распространять вместе с QT без дополнительных отчислений (насчёт библиотек — не знаю).
Т.е. если Skype использует GPL-версию QT, то ему нужно открывать исходники, если же коммерческую — то не нужно.
постойте-постойте, что-то насчёт QT вы, кажется, заговариваетесь — каждому разработчику нужно покупать лицензию на QT, но как минимум конечный продукт можно распространять вместе с QT без дополнительных отчислений (насчёт библиотек — не знаю).
Т.е. если Skype использует GPL-версию QT, то ему нужно открывать исходники, если же коммерческую — то не нужно.
Т.е. если Skype использует GPL-версию QT, то ему нужно открывать исходники, если же коммерческую — то не нужно.В точности та же альтернатива есть у пользователей MatrixSSL. Но если вдруг разработчики QT или MatrixSSL откажутся продавать ему коммерческую лицензию — значит и всё, можете быть свободны. То же самое — и с разработчиками GPL-программ/библиотек, только вы ещё бесплатно получаете «триал», да не простой «триал», а золотой: позволяющий вам выпускать программу под GPL вообще без отчислений! У вас подход «як мед, так ще й ложкою»…
выше обсуждалось, кто конечным пользователям либы, основанной даже на коммерческой версии MatrixSSL придётся либо платить за MatrixSSL, либо открывать сорцы:
«Конечным пользователям» либы, основанной на коммерческой версии QT или MatrixSSL придётся платить за QT/MatrixSSL, другой альтернативы у них просто нет. Почему-то это никого не напрягает. А GPL — напрягает, хотя её вполне можно рассматривать в качестве бесплатного триала…
Угу. «Если вы используете бесплатный триал нашего приложения вы обязаны выпустить своё тоже в форме бесплатного триала.» Вирус это, а не триал.
GPL не совместим ни с чем, кроме GPL. Это — плохо. Я не скажу, что это хуже, чем закрытые исходники коммерческих продуктов, но это и не лучше.
И если с коммерческими продуктами по крайней мере всё ясно — обычно нельзя ничего, кроме как ими просто пользоваться — то с GPL ситуация не столь однозначная: где проходит та грань, на которой более открытые продукты (BSD/MIT/PublicDomain) и более закрытые продукты (коммерческие) могут взаимодействовать с GPL — не ясно. Нет, я понимаю, что лично Вам это ясно. И мне тоже ясно. И многим другим людям тоже ясно. Проблема только в том, что «ясны» нам совершенно разные вещи, что продемонстрировал и этот топик.
Пока речь идёт о заимствовании кода — всё четко и понятно. И никаких проблем нет. Но когда связь менее явная — библиотеки, которые линкуются статически, динамически, которые опциональны и могут вообще не всегда использоваться; библиотеки, которые используют другие библиотеки, ...; описанные в топике сервисы взаимодействующие через pipe/unix socket/tcp socket, с недокументированными протоколами, с документированными протоколами, с универсальными протоколами или привязанными к интерфейсу конкретной библиотеки; распространяемые совместно, раздельно, или совместно но третьим лицом (CPAN); с исходниками доступными всем, только тем у кого есть приложение и он может это доказать, или всем но чисто теоретически т.к. никто не знает адреса того ftp, на котором они лежат…
Поэтому, IMHO, овчинка выделки не стоит: GPL для библиотек использовать нельзя! Это создаёт больше проблем для всех, чем приносит кому-то выгоды. Единственное исключение — если Вы заинтересованы в распространении GPL-вируса, то GPL-библиотеки этому способствуют значительно эффективнее, чем GPL-приложения.
GPL не совместим ни с чем, кроме GPL. Это — плохо. Я не скажу, что это хуже, чем закрытые исходники коммерческих продуктов, но это и не лучше.
И если с коммерческими продуктами по крайней мере всё ясно — обычно нельзя ничего, кроме как ими просто пользоваться — то с GPL ситуация не столь однозначная: где проходит та грань, на которой более открытые продукты (BSD/MIT/PublicDomain) и более закрытые продукты (коммерческие) могут взаимодействовать с GPL — не ясно. Нет, я понимаю, что лично Вам это ясно. И мне тоже ясно. И многим другим людям тоже ясно. Проблема только в том, что «ясны» нам совершенно разные вещи, что продемонстрировал и этот топик.
Пока речь идёт о заимствовании кода — всё четко и понятно. И никаких проблем нет. Но когда связь менее явная — библиотеки, которые линкуются статически, динамически, которые опциональны и могут вообще не всегда использоваться; библиотеки, которые используют другие библиотеки, ...; описанные в топике сервисы взаимодействующие через pipe/unix socket/tcp socket, с недокументированными протоколами, с документированными протоколами, с универсальными протоколами или привязанными к интерфейсу конкретной библиотеки; распространяемые совместно, раздельно, или совместно но третьим лицом (CPAN); с исходниками доступными всем, только тем у кого есть приложение и он может это доказать, или всем но чисто теоретически т.к. никто не знает адреса того ftp, на котором они лежат…
Поэтому, IMHO, овчинка выделки не стоит: GPL для библиотек использовать нельзя! Это создаёт больше проблем для всех, чем приносит кому-то выгоды. Единственное исключение — если Вы заинтересованы в распространении GPL-вируса, то GPL-библиотеки этому способствуют значительно эффективнее, чем GPL-приложения.
GPL не совместим ни с чем, кроме GPLОднако. Apache 2.0, Artistic 2.0, Boost, Modified BSD и другие лицензии вполне совместимы с GPL. Более того, GPL 3.0 была специально изменена так чтобы Apache 2.0 была с ней совместима.
И если с коммерческими продуктами по крайней мере всё ясно — обычно нельзя ничего, кроме как ими просто пользоваться — то с GPL ситуация не столь однозначная: где проходит та грань, на которой более открытые продукты (BSD/MIT/PublicDomain) и более закрытые продукты (коммерческие) могут взаимодействовать с GPL — не ясно.Это нормально — это со всеми лицензиями так. С коммерческими — особенно.
Поэтому, IMHO, овчинка выделки не стоит: GPL для библиотек использовать нельзя! Это создаёт больше проблем для всех, чем приносит кому-то выгоды. Единственное исключение — если Вы заинтересованы в распространении GPL-вируса, то GPL-библиотеки этому способствуют значительно эффективнее, чем GPL-приложения.Собственно поэтому RMS её и рекомендует использовать :-) Но есть ещё и второй варинт: использовать GPL для «бесплатного триала», а «настоящую» версию продавать за деньги. GPL много кто так использует. Sun (MySQL), Nokia (QT), вот и MatrixSSL для этого же её использует. Интересно — что ещё вы можете предложить для подобного использования: когда вы хотели бы опубликовать исходники, но при этом хотели бы собирать с производителей закрытого ПО лицензионные отчисления?
слава богу хоть JRE(Java Runtime) совсем бесплатен, втч и для распространения
MatrixSSL к вам не приходил, вы его самостоятельно к себе затащили. Не нравится лицензия? — Используйте продукт с другой лицензией или напишите свой.
Про GPL, яростно агрессирующую на коммерческое ПО, пойдите в Красную Шапку и расскажите. То-то они удивятся.
>релизить свой софт под GPL из-за неё я не хочу,
GPL обуславливает права на собственно продукт, который она представляет, и права на производные от этого продукта.
Если в Вашем коде нет ни одной строчки из продукта под GPL, то Вы вольны распространять свой продукт под любой лицензией.
GNU C Compiler (GCC) имеет лицензию GPL, но это не значит, что Apple не может компилировать им свою MacOS X и не выкладывать исходники операционки.
GCC также используется во FreeBSD, но она не перестала от этого быть менее свободной под лицензией BSDL.
>я предпочитаю Public Domain или, в крайнем случае другие открытые лицензии, но не GPL-вирус!
Все свободные лицензии: GPL, MIT, BSDL, APL, MPL, CDDL и LGPL относятся к Public Domain, но каждая несёт специфические ограничния на дальнейшую модификацию как самого продукта, так и его лицензии.
GPL обуславливает права на собственно продукт, который она представляет, и права на производные от этого продукта.
Если в Вашем коде нет ни одной строчки из продукта под GPL, то Вы вольны распространять свой продукт под любой лицензией.
GNU C Compiler (GCC) имеет лицензию GPL, но это не значит, что Apple не может компилировать им свою MacOS X и не выкладывать исходники операционки.
GCC также используется во FreeBSD, но она не перестала от этого быть менее свободной под лицензией BSDL.
>я предпочитаю Public Domain или, в крайнем случае другие открытые лицензии, но не GPL-вирус!
Все свободные лицензии: GPL, MIT, BSDL, APL, MPL, CDDL и LGPL относятся к Public Domain, но каждая несёт специфические ограничния на дальнейшую модификацию как самого продукта, так и его лицензии.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как отвязаться от GPL?