Проприетарные плагины для программ GPL: как насчет интерпретируемых языков?
Я разрабатываю приложение под лицензией GPL на Python, и мне нужно знать, позволяет ли GPL моей программе использовать проприетарные плагины. Это что FSF должен сказать по проблеме:
If a program released under the GPL uses plug-ins, what are the requirements for the licenses of a plug-in?
It depends on how the program invokes its plug-ins. If the program uses fork and exec to invoke plug-ins, then the plug-ins are separate programs, so the license for the main program makes no requirements for them.
If the program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single program, which must be treated as an extension of both the main program and the plug-ins. This means the plug-ins must be released under the GPL or a GPL-compatible free software license, and that the terms of the GPL must be followed when those plug-ins are distributed.
If the program dynamically links plug-ins, but the communication between them is limited to invoking the ‘main’ function of the plug-in with some options and waiting for it to return, that is a borderline case.
Различие между fork / exec и динамической компоновкой, помимо того, что является своего рода искусственным, не распространяется на интерпретируемые языки: как насчет плагина Python / Perl / Ruby, который загружается через import или execfile?
(править: я понимаю, почему различие между fork / exec и динамической компоновкой, но похоже, что кто-то, кто хотел соответствовать GPL, но идти против «духа» - я не могу - мог просто использовать fork / exec и межпроцессное взаимодействие, чтобы делать что угодно).
Лучшим решением было бы добавить исключение к моей лицензии, чтобы явно разрешить использование проприетарных плагинов, но я не могу этого сделать, поскольку я использую Qt / PyQt, который является GPL.
Ответы 3
@ Дэниел
The distinction between fork/exec and dynamic linking, besides being kind of artificial, doesn't carry over to interpreted languages: what about a Python/Perl/Ruby plugin, which gets loaded via import or execfile?
Не уверен, что различие является искусственное. После динамической загрузки код плагина разделяет контекст выполнения с кодом под лицензией GPL. После fork / exec этого не происходит.
В любом случае я бы предположил, что importing заставляет новый код запускаться в том же контексте выполнения, что и бит GPL, и вы должны относиться к нему как к случаю динамической ссылки. Нет?
he distinction between fork/exec and dynamic linking, besides being kind of artificial,
Я вовсе не считаю это искусственным. В основном они просто делают разделение по уровню интеграции. Если в программе есть «плагины», которые, по сути, запускают и забывают без интеграции уровня API, то полученная работа вряд ли будет считаться производной. Вообще говоря, плагин, который просто разветвляется / выполняется, будет соответствовать этим критериям, хотя могут быть случаи, когда это не так. Этот случай особенно актуален, если код «плагина» также будет работать независимо от вашего кода.
Если, с другой стороны, код сильно зависит от работы под GPL, такой как обширный вызов API или тесная интеграция структур данных, то это с большей вероятностью будет считаться производной работой. То есть, «плагин» не может существовать сам по себе без продукта GPL, а продукт с установленным плагином, по сути, является производным от продукта GPL.
Итак, чтобы было немного понятнее, те же принципы могут применяться к вашему интерпретируемому коду. Если интерпретируемый код сильно зависит от ваших API (или наоборот), то он будет считаться производной работой. Если это просто сценарий, который выполняется сам по себе с очень небольшой интеграцией, то это может и не быть.
В этом больше смысла?
Какой информацией вы делитесь между плагинами и основной программой? Если вы делаете что-то большее, чем просто выполняете их и ожидаете результатов (не делитесь данными между программой и плагином в процессе), то вам, скорее всего, сойдет с рук, если они будут проприетарными, иначе они, вероятно, должны быть под лицензией GPL ' d.
Я голосую за то, чтобы закрыть этот вопрос как не по теме, потому что он касается лицензирования и юридических вопросов, а не программирования или разработки программного обеспечения. Глянь сюда для подробностей и центр помощи для подробностей.