围绕GPL CLI应用程序的GUI包装器,它是派生的吗? [英] A GUI wrapper around a GPL CLI application, is it a derivative?

查看:97
本文介绍了围绕GPL CLI应用程序的GUI包装器,它是派生的吗?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

如果我开发的GUI包装器仅执行 GPL cli应用程序(出于争论的原因,请说

If I develop a GUI wrapper that only executes a GPL cli application (for the sake of argument, say tar) must I release the GUI wrapper as GPL? Is it a derivitive work?

如果是衍生作品,我必须发布什么?

If it is a derivative work what must I release?

GPL应用程序和包装器都将一起分发

Both the GPL application and the wrapper will be distributed together

推荐答案

IANAL.引用GPL常见问题解答(重点是我的)的仅聚合部分:

IANAL. Quoting the mere aggregation section of the GPL FAQ (emphasis mine):

集合"由多个单独的程序组成,这些程序一起分布在同一CD-ROM或其他介质上.即使其他软件的许可证是非免费的或不兼容GPL的,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.

两个单独的程序和一个包含两部分的程序之间的界线是什么?这是一个法律问题,最终由法官决定.我们认为,适当的标准既取决于通信机制(exec,管道,rpc,共享地址空间内的函数调用等),也取决于通信的语义(交换各种信息).

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.

常见问题解答中与此问题相关的另一个问题根据GPL发布的程序使用插件,插件许可证的要求是什么?":

Another question from the FAQ that relates to this is "If a program released under the GPL uses plug-ins, what are the requirements for the licenses of a plug-in":

这取决于程序如何调用其插件.如果程序使用 fork exec 来调用插件,则这些插件是单独的程序,因此主程序的许可证对此没有要求.

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, in spirit, a pure wrapper that merely exposes the functionality of a GPL program should be GPL.

这篇关于围绕GPL CLI应用程序的GUI包装器,它是派生的吗?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆