GPL、LGPL 许可 [关闭]答案

【问题标题】：GPL, LGPL licencing [closed]GPL、LGPL 许可 [关闭]
【发布时间】：2011-01-04 12:34:44
【问题描述】：

我的应用程序使用 2 个库（未修改）。第一个在 GPL 下，第二个在 LGPL 下。这意味着我的应用程序需要在 GPL 和 LGPL 下发布，因为这两个库都将与我的应用程序一起提供。没关系。现在，应用程序公开了插件基础设施，因此任何人都可以为其编写插件。插件将无法直接与文本开头提到的这两个库进行通信，因为它们不知道应用程序背后的内容。插件不会随应用程序一起提供。用户将能够通过应用程序从开放/公共插件列表中选择他们想要安装的插件。

问题：

插件是否也需要在 GPL 下发布？
有没有办法在封闭源代码许可下发布一些插件？哪一个？
如果没有商业许可，防止公司编写在客户端（应用程序）端免费而在服务器端不免费的插件，最好的许可方法是什么？（插件调用对服务使用收费的 Web 服务）。在这种情况下，我希望公司支付一些费用，因为一方面这用于商业用途。例如，某人有一个可以在各种格式之间转换图像的 Web 服务。有人编写需要用户帐户信息（登录）的插件。插件连接到他的网络服务，验证，转换图像并收取一定金额的用户帐户。在此示例中，插件可免费安装和使用。他是否完全使用它是用户的选择。

这样的事情可能吗？

谢谢。

【问题讨论】：

我的想法是创建类似：biopdf.com/download.php，但带有插件。如果你仔细看看，他们说你必须下载 GPL 下的 ghostscript 库，这就是为什么它没有随他们的商业产品（不是 GPL）一起提供。他们还说他们调用 ghostscript 库并从他们的应用程序中使用它。我的问题是：这是否合法？因此，他们所做的是在他们的许可协议中写道，他们的虚拟打印机使用必须单独下载的 ghostscript 或 ghostscript 之类的库。因此，他们将 GPL 和商业应用程序分开。
这个问题似乎是题外话，因为它是关于许可的。
我投票结束这个问题，因为它是关于许可或法律问题，而不是编程或软件开发。 See here 了解详情，help center 了解更多信息。

标签： gpl lgpl

【解决方案1】：

你做了一些毫无根据的假设。

例如，您假设您的应用必须获得 LPGL 许可，因为其中一个库是。这是不真实的。如果你的应用是 GPL 许可的，你可以使用 LPGL 库。这是合乎逻辑的，因为 GPL 许可证实际上是 LGPL 的超集。

所以，Q1：否。 Q2：是的，保持这些插件是可选的并且界面定义良好。 Q3。你不能，真的。许多国家/地区在版权法中都有例外情况，这些例外情况会限制版权法用于限制互操作性的范围。由于所描述的插件的存在正是为了使您的程序和他的网络服务之间能够互操作，所以版权法对您来说是有限的。其次，这适用于全球，GPL 许可证禁止您对您的程序施加限制。因此它不能拒绝这样的商业插件。

【讨论】：

【解决方案2】：

是一场激烈的辩论。具体来说，如果程序提供的 API 用于转发调用，插件在逻辑上基本上依赖于所述库，因此被一些人认为受 GPL 约束。至少必须合理地确定所述插件可以“自己”/“独立”运行并且不依赖于代码 - 从法律角度，而不是技术角度。难以制定，IANAL 等等，最佳实践是不要停留在灰色地带；更好的发布代码：这比律师便宜，也让用户满意。
如果所述插件合理地独立于所使用的库（参见第 1 点），您可以选择任何您喜欢的许可证。
您无法真正阻止某人为您的程序编写与非免费啤酒服务接口的插件。您可以通过使用数字签名等技术措施阻止用户使用此类插件，但这也会影响 freebeer 服务的作者和 freefreedom 代码作者。
李>

【讨论】：

关于第 3 点，您不得在 GPL 程序中使用此类措施（这里就是这种情况）。即使可以，源的可用性也意味着这些措施无论如何都不会持续。
取决于 GPL 的版本。
你能指出发生这种争论的一些地方吗？
所有与 GPL 许可库链接的源代码都必须在 GPL 下发布。