与专有库链接的GPL代码是否取决于首先创建的库? [英] Does GPL code linking with proprietary library depend which is created first?

问题描述

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

Microsoft creates their windows and MFC DLL library, etc. An open source develop write a new MFC application and release the source code as GPL. The app has to link with the MS DLL/libraries to run in Windows, but I don't think anyone can argue that we now have the right to force the Microsoft's GPL their DLL.

这是否意味着GPL许可证确实取决于首先创建"了哪个许可证?如果首先创建的专有库(例如Windows DLL)是在未链接的情况下发布的，则没有任何GPL代码，并且稍后将其与GPL程序链接在一起，则尽管专有代码与GPL代码链接"了，但GPL程序无法将专有库转换为GPL.

Does this mean the GPL license is really depends on which one is "created" first? If proprietary library is created first (such as Windows DLLs) that is published without linking and any GPL code and later a GPL program is linked with it, then the GPL program can't convert the proprietary library into GPL although the proprietary code is "linked" with the GPL code.

在这种情况下，诸如NVidia或RealNetworks这样的公司可以做以下事情吗?让我们假设他们喜欢将专有的HDDecoding媒体解码引擎库保密，但是他们还想利用"开源GPLed代码来展示其硬件.

If this is the case, can company such NVidia or RealNetworks do the following? Let's assume they like to keep the proprietary HDDecoding media decoding engine library private, but they also want to "leverage" the opensource GPLed code to showcase their hardware.

1. 他们创建了一个专有库来进行媒体解码并发布一些示例代码.
2. 有人(开源开发)创建了链接到此专有库的GPL代码(例如XBMC，Mplayer或VLC)的插件".
3. 他们是否可以辩称，由于他们首先创建了专有库(就像MS首先创建了所有DLL)，所以与其专有代码链接的GPL程序不会将它们掩盖为GPL代码.

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

One can in theory argue that the opensource developer who creates the GPL vlc.exe file that link with the NVidia proprietary media decoder library is violating the GPL license.

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

Does that mean all the GPL programs running in Windows such as VLC, git, cygwin, etc are all violating the GPL license because they definitely need to link with the proprietary Microsoft Windows Libraries to run.

情况2:这是怎么回事:

Case 2: What's wrong with this:

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

NVidia can create a new Hardware abstraction library that hides the latest graphics functions. They also create a FreeBSD driver with this library and release the source code of the BSD driver but not the library source code.

某人(Linux开发人员)可以实现与此库链接的linux驱动程序，从而为Linux创建NVidia图形驱动程序.但是由于NVidia并未这样做，因此他们可以在启用"Linux支持"的同时将库源保持为隐藏".

Someone (Linux developer) can implement the linux driver that links with this library to create a NVidia graphics driver for Linux. But since NVidia didn't do this, they can keep the library source "hidden" while enable the "Linux support".

这肯定违反了GPL的精神.

It certainly violates the spirit of GPL.

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

Does it mean that running any exe created with GPLed source in Windows/Mac/Iphone/PSP3 also violates the spirit of GPL?

推荐答案

来自GNU GPL常见问题解答:

From the GNU GPL FAQ:

在编写 非免费程序的插件?

Can I apply the GPL when writing a plug-in for a non-free program?

如果程序使用fork和exec来执行 调用插件，那么插件是 单独的程序，因此许可证 主程序没有要求 为他们.因此，您可以将GPL用于 插件，并且没有特殊 要求.

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. So you can use the GPL for a plug-in, and there are no special requirements.

如果程序动态链接 插件，然后进行函数调用 互相分享数据 结构，我们认为它们形成了 单一程序，必须加以处理 作为两者的延伸 程序和插件.这表示 GPL涵盖的组合 带有非免费主程序的插件 会违反GPL.但是你 可以通过以下方式解决该法律问题 向您的插件添加例外 许可，允许链接 使用非免费的主程序.

If the program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single program, which must be treated as an extension of both the main program and the plug-ins. This means that combination of the GPL-covered plug-in with the non-free main program would violate the GPL. However, you can resolve that legal problem by adding an exception to your plug-in's license, giving permission to link it with the non-free main program.

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

See also the question I am writing free software that uses a non-free library.

并且:

如果我使用以下法律问题 与GPL不兼容的GPL库 软件?

What legal issues come up if I use GPL-incompatible libraries with GPL software?

两个版本的GPL都有一个 他们的Copyleft例外，通常 称为系统库异常. 如果与GPL不兼容的库 想要使用符合条件的 系统库，那么您不必 做一些特殊的使用它们；这 分发源代码的要求 对于整个程序不包括 这些库，即使您 分发链接的可执行文件 包含它们.

Both versions of the GPL have an exception to their copyleft, commonly called the system library exception. If the GPL-incompatible libraries you want to use meet the criteria for a system library, then you don't have to do anything special to use them; the requirement to distribute source code for the whole program does not include those libraries, even if you distribute a linked executable containing them.

什么才算是 系统库"之间有所不同 GPL的不同版本. GPLv3 明确定义系统库" 在第1节中，将其从 相应来源"的定义. GPLv2在即将结束时说了以下内容 第3部分:

The criteria for what counts as a "system library" vary between different versions of the GPL. GPLv3 explicitly defines "System Libraries" in section 1, to exclude it from the definition of "Corresponding Source." GPLv2 says the following, near the end of section 3:

但是，作为特殊例外， 分发的源代码不需要 包括正常情况下的任何东西 分布式(以来源或 二进制形式)的主要组成部分 (编译器，内核等)的 作业系统 可执行文件运行，除非该组件 本身随可执行文件一起提供.

However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.

...

这篇关于与专有库链接的GPL代码是否取决于首先创建的库?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！