Обертка GUI вокруг приложения GPL CLI, это производная?
Если я разрабатываю оболочку графического интерфейса это только выполняет как приложение GPL cli (в качестве аргумента, скажем, деготь), должен ли я выпустить оболочку графического интерфейса пользователя как GPL? Это производная работа?
Что я должен выпустить, если это производная работа?
И приложение GPL, и оболочка будут распространяться вместе.
Просто возбуждает бинарник, добавлю к описанию;)
Если это производная работа, вам следует лицензировать свою программу под GPL и выпускать («делать доступным») ее исходный код всякий раз, когда вы ее распространяете.
Я голосую за то, чтобы закрыть этот вопрос как не по теме, потому что речь идет о лицензировании или юридических вопросах, а не программирование или разработка программного обеспечения. Глянь сюда для подробностей и центр помощи для подробностей.
Ответы 2
IANAL, но я почти уверен, что если вы не свяжете код GPL со своим кодом и просто используете интерфейс командной строки, GPL не повлияет на ваш код. Единственная ваша обязанность - распространять исходный код GPL.
Если вы решите распространять приложение GPL, я предлагаю вам просто включить сжатый исходный tar tar на носитель, а не просто «сделать доступным» через загрузку, поскольку вам придется поддерживать сайт загрузки на неопределенный срок для всех версий GPL приложение, которое вы распространяете.
IANAL. Цитата из раздела простая агрегация FAQ GPL (выделено мной):
An “aggregate” consists of a number of separate programs, distributed together on the same CD-ROM or other media. The GPL permits you to create and distribute an aggregate, even when the licenses of the other software are non-free or GPL-incompatible. The only condition is that you cannot release the aggregate under a license that prohibits users from exercising rights that each program's individual license would grant them.
Where's the line between two separate programs, and one program with two parts? This is a legal question, which ultimately judges will decide. We believe that a proper criterion depends both on the mechanism of communication (exec, pipes, rpc, function calls within a shared address space, etc.) and the semantics of the communication (what kinds of information are interchanged).
If the modules are included in the same executable file, they are definitely combined in one program. If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program.
By contrast, pipes, sockets and command-line arguments are communication mechanisms normally used between two separate programs. So when they are used for communication, the modules normally are separate programs. But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program.
Другой вопрос из FAQ, который относится к этому: «Если программа, выпущенная под GPL, использует плагины, каковы требования к лицензиям плагина»:
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.
..
ИМХО, по духу, чистая оболочка, которая просто раскрывает функциональность программы GPL, должна быть GPL.
Я согласен. IMHO, оболочка, написанная специально для одного приложения, является производной по крайней мере по духу, если только это не было чем-то достаточно общим, чтобы действовать как оболочка для большого класса программ.
+1 за цитирование обсуждения производных работ и «интимных» сообщений.
Можете ли вы более точно определить «оболочку» - связано ли приложение с графическим интерфейсом пользователя с кодом GPL или оно просто выполняет двоичный файл?