与专有库链接的 GPL 代码是否取决于先创建哪个？[关闭]

Question

Microsoft 创建了他们的 Windows 和 MFC DLL 库等。开源开发人员编写了一个新的 MFC 应用程序，并将源代码以 GPL 形式发布。该应用程序必须与 MS DLL/库链接才能在 Windows 中运行，但我认为没有人可以争辩说我们现在有权强制 Microsoft 的 GPL 使用其 DLL。

这是否意味着 GPL 许可证实际上取决于哪个许可证首先“创建”？ 如果先创建专有库（例如 Windows DLL），并且在没有链接和任何 GPL 代码的情况下发布，然后将 GPL 程序与其链接，则 GPL 程序无法将专有库转换为 GPL，尽管专有代码是“与 GPL 代码链接”。

如果是这种情况，NVidia 或 RealNetworks 等公司可以采取以下措施吗？假设他们希望将专有的 HDDecoding 媒体解码引擎库保密，但他们也希望“利用”开源 GPL 代码来展示他们的硬件。

1. 他们创建了一个专有库来进行媒体解码并发布了一些示例代码。
2. 有人（开源开发）创建了“插件”，链接到这个专有库，用于 GPL 代码，例如 XBMC、Mplayer 或 VLC。
3. 他们是否可以争辩说，由于他们首先创建了专有库（就像 MS 首先创建所有 DLL 一样），与其专有代码链接的 GPL 程序不会将它们转换为 GPL 代码。

理论上，可以认为创建与 NVidia 专有媒体解码器库链接的 GPL vlc.exe 文件的开源开发人员违反了 GPL 许可证。

这是否意味着在 Windows 中运行的所有 GPL 程序（例如 VLC、git、cygwin 等）都违反了 GPL 许可证，因为它们肯定需要链接到专有的 Microsoft Windows 库才能运行。

案例2：这是怎么回事：

NVidia 可以创建一个新的硬件抽象库，隐藏最新的图形功能。他们还用这个库创建了一个 FreeBSD 驱动程序，并发布了 BSD 驱动程序的源代码，但不发布库源代码。

有人（Linux 开发人员）可以实现与该库链接的 Linux 驱动程序，以创建适用于 Linux 的 NVidia 图形驱动程序。但由于 NVidia 没有这样做，他们可以在启用“Linux 支持”的同时“隐藏”库源。

这确实违背了GPL的精神。

这是否意味着在 Windows/Mac/Iphone/PSP3 中运行使用 GPL 源创建的任何 exe 也违反了 GPL 精神？

Answer 1

来自 GNU GPL 常见问题解答：

在为非免费程序编写插件时，我可以应用GPL吗？

如果程序使用fork和exec调用插件，则插件是单独的程序，因此主程序的许可证对它们没有任何要求。因此，您可以将GPL用于插件，并且没有特殊要求。

如果程序动态链接插件，并且它们互相呼叫并共享数据结构，我们认为它们形成一个单个程序，必须将其视为主程序和插件的扩展。这意味着，被GPL覆盖的插件与非免费主程序的组合将违反GPL。但是，您可以通过向插件许可证添加例外来解决该法律问题，从而允许将其与非免费主计划链接。

另请参阅问题 我正在编写使用非免费库的免费软件.

和：

如果我使用GPL软件使用GPL兼容的库，会出现哪些法律问题？

GPL的两个版本都有其复印件的例外，通常称为系统库异常。如果您想使用的是符合系统库的标准，则不必做任何特别的事情即可使用它们；为整个程序分发源代码的要求也不包括这些库，即使您分发包含它们的链接可执行文件。

算作“系统库”的标准在不同版本的GPL之间有所不同。GPLV3明确定义了第1节中的“系统库”，以将其从“相应源”的定义中排除。 GPLV2在第3节结束时说，以下内容：

但是，作为一个特殊例外，源代码分布式分布式不需要包含任何正态分布（以源或二进制形式）的内容，其中包括可执行操作系统的主要组件（编译器，内核等），可执行操作系统运行的操作系统，除非该组件本身伴随可执行文件。

...

Answer 2

您对 GPL 限制生效的方式存在根本性误解。您的第一个示例包含在“系统库豁免”中 - 但即使不是，它也不会产生您所假设的效果。

GPL 规定，如果您分发 GPL 程序或其衍生品，您还必须根据 GPL 等效条款（向您分发程序/衍生品的人）提供该程序或衍生品的源代码。

这意味着，如果我分发与某些 Microsoft 代码链接的 GPL 程序，我必须提供整个蜡球的源代码，否则可能会因侵犯版权而被您起诉。请注意，只要 Microsoft 是第三方，就不会对其施加任何限制 他们 （当然！）。如果我无法访问 Microsoft 的代码（这很可能），那么我就无法在不违反您的许可的情况下分发该衍生作品。

Answer 3

IANAL，但创建顺序并不重要。如果链接两个二进制文件违反了 GPL，则 GPL 不允许这样做，无论哪个先创建。

正如 Michael Burr 所引用的，情况 1 由系统库异常解决。请注意，它与时间无关 - 如果不是系统库异常，在 Windows 98 上运行 2003 年编写的 GPL 代码（在 GPL 代码之前编写）与在 Windows 98 上运行 2003 年编写的 GPL 代码一样，都属于 GPL 违规。就是在 Vista 上运行它（这是在 GPL 代码之后编写的）。

我同意情况 2 违反了 GPL 的精神，但是，正如 GPL 使用的术语一样，NVidia 驱动程序并未与 Linux 内核“链接”，因为它是作为模块加载的。您将无法分发静态链接到其中的非 Free NVidia 二进制文件的 Linux 内核，但是现在谁分发静态链接的内核呢？

Answer 4

您永远不能通过链接到其他程序来更改它们的许可证。如果您的许可证不允许链接到非开源程序，您必须更改许可证或停止链接到这些程序。如果其他程序链接到您的程序，情况就会有所不同。在这种情况下，他们必须更改其许可证或停止链接到您的程序。

Answer 5

简而言之，这意味着您不能将 GPL 应用于不属于 GPL 的代码或库之上。 与 GPL 兼容 并分发已编译的组合作品，除非您应用 链接异常.

链接异常为您提供了一种分发包含非自由位的已编译可执行文件的方法，而无需特殊权限即可以源格式分发程序。

当然，此例外取决于非自由库，该库允许您分发与其链接的程序（尤其是静态链接）。

所以，回答你的第一个问题，不..这不是“先有鸡还是先有蛋”的情况。我的建议是，当面临必须编写异常的可能性时，最好选择限制较少的许可证，例如 Apache 或 3 条款 BSD 许可证。

其次，不，您不能只是将 GPL 应用于您的代码，以便更改您碰巧链接的内容的许可证。我们再次回到链接异常，这是您有责任提供的。

这 spririt GPL 生活在一个不存在专有软件的世界。RMS多次将此作为最终目标。剩下的就是 实用性 对于想要在非自由平台上分发自由软件的人来说，必须解决这个问题。

这是 Linux（在内核中）仅保留 GPL v2 的最大原因之一。