微软创build了自己的windows和MFC的DLL库等等。一个开源的开发者编写一个新的MFC应用程序，并以GPL的forms发布源代码。 该应用程序必须链接到MS DLL /库运行在Windows中，但我不认为任何人都可以争辩说，我们现在有权强制微软的GPL DLL。
这是否意味着GPL许可实际上取决于哪一个是“创build”的？ 如果首先创build专有库（例如Windows DLL），而不是链接和任何GPL代码发布，然后GPL程序与其链接，则GPL程序不能将专有库转换为GPL，尽pipe专有代码是“链接“与GPL代码。
如果是这种情况，那么NVidia或RealNetworks公司可以执行以下操作吗？ 我们假设他们喜欢将专有的HDDecoding媒体解码引擎库保留为私有的，但他们也想“利用”开源的GPL代码来展示他们的硬件。
理论上可以说，创build与NVidia专有媒体解码器库链接的GPL vlc.exe文件的开源开发者违反了GPL许可证。
这是否意味着在Windows中运行的所有GPL程序（如VLC，git，cygwin等）都违反了GPL许可证，因为它们肯定需要与专有的Microsoft Windows Libraries链接才能运行。
案例2：这有什么问题：
NVidia可以创build一个隐藏最新graphicsfunction的新硬件抽象库。 他们还使用这个库创build一个FreeBSD驱动程序，并释放BSD驱动程序的源代码，但不是库源代码。
有人（Linux开发人员）可以实现与该库链接的Linux驱动程序，以便为Linux创build一个NVidiagraphics驱动程序。 但是由于NVidia没有这样做，他们可以在启用“Linux支持”的同时保持图书馆资源“隐藏”。
这当然违反了GPL的精神。
这是否意味着在Windows / Mac / Iphone / PSP3上运行任何使用GPLed源码创build的exe文件也违反了GPL的精神？
从GNU GPL FAQ：
在为非免费程序编写插件时，我可以申请GPL吗？
如果程序使用fork和exec来调用插件，那么插件是单独的程序，所以主程序的许可证对它们没有要求。 所以你可以使用GPL插件，没有特别的要求。
如果程序动态链接插件，并且互相调用函数并共享数据结构，我们认为它们构成了一个单一的程序，这个程序必须作为主程序和插件的扩展。 这意味着GPL覆盖的插件与非免费的主程序的组合将违反GPL。 但是，您可以通过向插件的许可添加例外来解决该法律问题，并允许将其与非免费主程序链接。
另请参阅我正在编写使用非免费库的免费软件的问题。
和：
如果我使用GPL软件与GPL不兼容的库，会出现哪些法律问题？
GPL的两个版本都有一个copyleft的例外，通常称为系统库例外。 如果您要使用的GPL不兼容的库符合系统库的标准，那么您不必做任何特殊的操作就可以使用它们; 即使分发包含它们的链接可执行文件，为整个程序分发源代码的要求也不包括这些库。
什么被视为“系统库”的标准在不同版本的GPL之间有所不同。 GPLv3在第1节中明确定义了“系统库”，将其排除在“对应源”的定义之外。 GPLv2在第3节结尾附近说了以下内容：
但是，作为一个特殊的例外情况，分发的源代码不需要包含正常分布的任何东西（以源代码或二进制的形式）与可执行程序运行的操作系统的主要组件（编译器，内核等）除非该组件本身附带可执行文件。
…
您对GPL限制的生效方式有一个基本的误解。 你的第一个例子是“系统图书馆豁免”所涵盖的，但即使没有，也不会有你所说的效果。
GPL表示，如果您分发GPL的程序或其衍生产品，则还必须根据GPL等效条款（向您分发程序/衍生产品的人员）提供程序或衍生产品的源代码。
这意味着，如果我分发与Microsoft的一些代码相关的GPL程序，则必须将源代码提供给整个论坛，否则有可能被您起诉以破坏您的版权。 请注意，只要Microsoft是第三方，这不会对他们施加任何限制（当然！）。 如果我无法访问微软的代码，那么我不能分发这些衍生工作，而不会违反您的许可证。
IANAL，但是创作的顺序并不重要。 如果链接两个二进制文件将违反GPL，那么GPL将不允许这样做，不管哪个是先创建的。
正如迈克尔·伯尔（Michael Burr）引用的那样，案例1由系统库异常来解决。 请注意，它不是时间依赖性的 – 如果不是系统库异常，那么运行GPLed代码（在GPL代码之前编写的Windows 98）上运行的GPLed代码就会与GPLed代码一样多将运行在Vista上（这是写在GPLed代码后）。
我同意，案例2违反了GPL的精神，但是，由于GPL使用的术语，NVidia驱动程序并不与Linux内核“链接”，因为它是作为模块加载的。 你将无法分配一个静态链接到非自由NVidia二进制文件的Linux内核，但是这些日子谁分配静态链接的内核呢？
你不能通过链接到其他程序许可证，从来没有。 如果您的许可证不允许链接到非开源程序，您必须更改许可证或停止链接到这些程序。 如果其他程序链接到你的情况将是不同的。 在这种情况下，他们必须扣留许可证或停止链接到您的程序。
它的意思，就是你不能将GPL应用于与GPL不兼容的代码或库之上，并且分发已编译的组合工作，除非你应用了一个链接异常 。
链接异常为您提供了一种分发包含非空闲位的编译可执行文件的方法，而不需要特殊的权限来以源格式分发程序。
这个例外当然取决于非免费的库，允许你分发与之链接的程序（尤其是静态的）。
所以，要回答你的第一个问题，不，这不是一个“鸡或蛋”的情况。 我所推荐的是在面临可能需要编写例外的情况下，最好选择一个更少限制的许可证，比如Apache或者3条款的BSD许可证。
其次，不，你不能把GPL应用到你的代码中，以便改变你碰巧连接的东西的许可证。 再一次，我们回到链接的例外，这是你的责任提供。
GPL的spririt在一个没有专有软件的世界里。 RMS已经多次声明这是最终的目标。 对于那些想要在非免费平台上发布免费软件的人来说，剩下的是实用性 。
这是Linux（如在内核中）仅保留GPL v2的最大原因之一。