Проприетарные плагины для программ GPL: как насчет интерпретируемых языков? [закрытый]
Я разрабатываю лицензионное приложение GPL в Python и должен знать, позволяет ли GPL моей программе использовать проприетарные Плагины. Это что ФСФ должен сказать на вопрос:
если программа, выпущенная под GPL, использует плагины, каковы требования к лицензиям плагина?
Это зависит от того, как программа задействует свои плагины. Если программа использует fork и exec для вызова подключаемых модулей, то подключаемые модули есть отдельные программы, поэтому лицензия на основную программу не предъявляет к ним никаких требований.
Если программа динамически компонуется с модулями, и они вызывают функции друг из друга и разделяют общие структуры данных, мы убеждены, что они формируют единую программу, которая должна рассматриваться как расширение и главной программы, и модулей. Это означает, что плагины должны быть выпущены под лицензией GPL или GPL-совместимого свободного программного обеспечения, и что условия GPL должны соблюдаться, когда эти плагины распространяются.
если программа динамически связывает плагины, но связь между ними ограничена вызовом "основной" функции плагина с некоторыми параметрами и ожиданием ее возврата, то это пограничный случай.
различие между fork / exec и динамической связью, помимо того, что оно является искусственным, не переносится на интерпретируемые языки: как насчет плагина Python/Perl/Ruby, который загружается через import или execfile?
(edit: я понимаю, почему различие между fork/exec и динамической связью, но похоже, что кто-то, кто хотел соответствовать GPL, но идти против "духа" - я не-мог просто использовать fork/exec и межпроцессную связь, чтобы сделать почти все).
лучшим решением было бы добавить исключение к моей лицензии, чтобы явно разрешить использование проприетарных плагинов, но я не могу этого сделать, так как я использую Qt/PyQt который является GPL.
3 ответов
он различие между fork / exec и динамической связью, помимо того, что он является искусственным,
Я не думаю, что это искусственный вообще. В основном они просто делают разделение, основанное на уровне интеграции. Если в программе есть "плагины", которые по сути огонь и забыть без интеграции уровня API, то результирующая работа вряд ли будет считаться производной работой. Вообще говоря, плагин, который просто раздвоен / exec'Ed будет соответствовать этому критериями, хотя могут быть случаи, когда это не так. Этот случай особенно применим, если код "плагина" будет работать независимо от вашего кода.
Если, с другой стороны, код глубоко зависит от работы GPL'Ed, такой как обширный вызов API или тесная интеграция структуры данных, то вещи, скорее всего, будут считаться производной работой. Т. е. "плагин" не может существовать сам по себе без продукта GPL, а продукт с установленным этим плагином по существу производная работа продукта GPLed.
поэтому, чтобы сделать его немного более ясным, те же принципы могут применяться к вашему интерпретируемому коду. Если интерпретируемый код сильно зависит от ваших API (или наоборот), то он будет считаться производной работой. Если это просто скрипт, который выполняется сам по себе с очень малой интеграцией, то это может быть не так.
это имеет больше смысла?
@Daniel
различие между fork / exec и динамической связью, помимо того, что оно является искусственным, не переносится на интерпретируемые языки: как насчет плагина Python/Perl/Ruby, который загружается через импорт или execfile?
Я не уверен, что различие is искусственные. После динамической загрузки код плагина разделяет контекст выполнения с кодом GPLed. После fork / exec это не так.
в anycase я бы предположил, что importing заставляет новый код работать в том же контексте выполнения, что и бит GPLed, и вы должны рассматривать его как случай динамической ссылки. Нет?
сколько информации Вы делитесь между плагинами и основной программой? Если вы делаете что-то большее, чем просто выполняете их и ждете результатов (не обмениваясь данными между программой и плагином в процессе), то вам, скорее всего, сойдет с рук, что они являются собственностью, иначе они, вероятно, должны быть GPL'D.