假设我有两个应用程序:一个是“服务器”应用程序,在 GPLv3 下获得许可,另一个是“客户端”应用程序,在非 GPL 兼容许可下获得许可。服务器作为 Windows 服务运行,客户端是普通的 Windows 应用程序,它们仅通过 TCP/IP 和 XML 进行通信(根本没有链接)。
我知道我可以在同一个媒体上分发这两者,或者在一个 zip 文件中一起分发,就 GPL 而言,作为“聚合”。
但是,我可以编写一个在一个进程中安装服务器和客户端的安装程序,只是为了用户友好吗?
假设我有两个应用程序:一个是“服务器”应用程序,在 GPLv3 下获得许可,另一个是“客户端”应用程序,在非 GPL 兼容许可下获得许可。服务器作为 Windows 服务运行,客户端是普通的 Windows 应用程序,它们仅通过 TCP/IP 和 XML 进行通信(根本没有链接)。
我知道我可以在同一个媒体上分发这两者,或者在一个 zip 文件中一起分发,就 GPL 而言,作为“聚合”。
但是,我可以编写一个在一个进程中安装服务器和客户端的安装程序,只是为了用户友好吗?
我相信您可以编写一个安装程序,为每个软件启动两个单独的安装程序。确保您提醒用户他将要发生的事情,并且为了使其更加明显,您可以为他们提供一个自定义选项,允许他们只安装一个或另一个(即使没有另一个就无法工作) .
但是,如果您这样做主要是为了避免 GPL 许可封闭源代码软件,您仍然会受到抨击。他们可能无法合法地对此做任何事情,但如果你激怒了足够多的人,你可能会很快发现一些开源竞争。
-亚当
只要
“唯一的条件是,你不能在禁止用户行使每个程序的个人许可授予他们的权利的许可下发布聚合。”
http://www.gnu.org/licenses/gpl-faq.html#MereAggregation
那么您应该可以使用安装程序。没有必要像其他海报提到的那样提供点击等:
http://www.gnu.org/licenses/gpl-faq.html#ClickThrough
然而,主要问题不是安装,而是您所做的是否是派生作品(它不像链接或不链接那么简单):
[..]管道、套接字和命令行参数是通常在两个独立程序之间使用的通信机制。[...] 但是,如果通信的语义足够紧密,可以交换复杂的内部数据结构,那么这也可以作为将这两个部分组合成一个更大程序的基础。
您必须确保有两个单独的许可证点击,一个用于 GPL v3 代码,一个用于非专有代码。您还需要非常认真地确保用户了解他们对 GPL v3 代码的权利,并证明您已经履行了提供该代码的义务。
伊纳尔。我没有仔细检查 GPL v3 的措辞以确保没有其他问题。
如有疑问,请考虑咨询SFLC(软件自由法律中心)。
下面有一组广泛的评论 - 阅读它。本说明部分是对评论的回应。
GPL 不是直接的 EULA(最终用户许可协议)。它更像是对软件开发人员的许可。但是,它确实授予软件接收者某些权利,并且 GPL 对作为软件开发人员的您施加了义务。特别是,它要求您作为开发人员明确授予您哪些权利,以及授予您向其提供 GPL 软件的人哪些权利。
您不必显示 GPL 的文本。您可能只是说“包 X 是根据 GNU 通用公共许可证版本 3 的条款分发的。您可以在http://www.fsf.org/licensing/licenses/gpl.html找到此许可证的条款。您有由于此许可而享有某些权利。您可以通过从 [ ...合适的 URL... ]下载包 X 的源代码从我们这里获得。当包 X 与包 Y 一起使用时,我们对包 X 提供有限的支持。 ..废话……废话……废话…… ”。
显示 GPL 本身的一个优点是您不必提供任何解释 - 解释法律文件很困难,尤其是对于非律师(比如我!)。您可能想明确说明用户拥有权利并且不必同意任何事情;这是明智的(我相信是准确的)。
请注意,对 Package X(假设的 GPL v3 软件)的支持收费是合法的 - 只要您实际提供支持。这是允许的。您也没有义务为从其他地方获得 Package X 的人提供支持;您可以将这种支持限制在您自己的客户身上。但是您不能阻止您的客户获取源代码,或者阻止您将 Package X 的源代码转发给他们自己的朋友、同事或客户。
我仍然不是律师 - 如果您需要法律建议,请准备好付费与在软件许可和 GPL 方面经验丰富的律师交谈。
我认为安装程序没有链接到它正在安装的内容,所以在我看来它就像是三个独立的程序在一个集合中,其中一个是 GPLv3。无论如何,我认为启动不同的安装程序进程不会做任何事情:要么这是一个聚合,要么它是一个单一的派生工作。
当然,这取决于衍生作品的定义,据我所知,这是一个未定的法律问题。但是,我会继续使用单个安装程序,并确保一些重要的文档提到了不同的许可证。