GPL代码与专有库的链接是否取决于首先创建的?

ton*_*ee 17 linux windows freebsd gpl nvidia

Microsoft创建了他们的Windows和MFC DLL库等.开源开发编写新的MFC应用程序并将源代码作为GPL发布.该应用程序必须链接MS DLL /库才能在Windows中运行,但我认为没有人可以争辩说我们现在有权强迫微软的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中运行使用GPLed源创建的任何exe也违反了GPL的精神?

Mic*_*urr 8

从GNU GPL FAQ:

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

如果程序使用fork和exec来调用插件,那么插件是单独的程序,因此主程序的许可证对它们没有要求.所以你可以使用GPL作为插件,没有特殊要求.

如果程序动态链接插件,并且它们相互进行函数调用并共享数据结构,我们认为它们构成了一个程序,必须将其视为主程序和插件的扩展.这意味着GPL覆盖的插件与非自由主程序的组合将违反GPL.但是,您可以通过向插件的许可添加例外来解决该法律问题,并允许将其与非免费主程序链接.

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

和:

如果我将GPL不兼容的库与GPL软件一起使用,会出现哪些法律问题?

两个版本的GPL都有他们的copyleft的例外,通常称为系统库例外.如果要使用的GPL不兼容的库满足系统库的标准,那么您不必执行任何特殊的使用它们; 即使您分发包含它们的链接可执行文件,分发整个程序的源代码的要求也不包括这些库.

什么算作"系统库"的标准在不同版本的GPL之间有所不同.GPLv3在第1节中明确定义了"系统库",以将其从"对应源"的定义中排除.GPLv2在第3节末尾附近说了以下内容:

但是,作为一个特殊的例外,分发的源代码不需要包含正常分布的任何内容(源代码或二进制形式),以及运行可执行文件的操作系统的主要组件(编译器,内核等),除非该组件本身伴随可执行文件.

...


caf*_*caf 5

您对GPL限制的生效方式存在根本性的误解.你的第一个例子被"系统库豁免"所涵盖 - 但即使它不是,它也不会产生你提出的效果.

GPL表示,如果您分发GPL程序或其衍生产品,您还必须根据GPL等效条款(向您分发程序/衍生产品的人员)提供程序或衍生产品的来源.

这意味着,如果我发布与Microsoft的一些代码相关的GPL程序,我必须提供整个蜡烛的来源,否则可能会因违反您的版权而被起诉.请注意,只要Microsoft是第三方,这对它们没有任何限制(当然!).如果我无法访问微软的代码,那么我就不能在不违反许可证的情况下分发该衍生作品.