GPL静态与动态链接规则如何应用于解释语言？

据我了解，GPL禁止从非GPL代码到GPL代码的静态链接，但允许从非GPL代码到GPL代码的动态链接。那么当所讨论的代码因为是用一种解释语言（例如Perl）编写而根本没有链接时，该怎么办？

如果认为该规则是动态链接，则利用该规则似乎太容易了，但是，另一方面，如果认为该规则是静态的，则从合法的非GPL代码中引用GPL代码也似乎是不可能的！编译语言至少在静态链接和动态链接之间有区别，但是当所有“链接”都在运行脚本时，没有明确的许可就无法说出意图！

还是我对这个问题的理解不正确，使问题无济于事？我也听说过涉及动态链接的“类路径异常”。那不是GPL的一部分，而是可以添加到GPL的一部分，因此仅当许可证包含此例外时才允许动态链接吗？

至于有关解释语言的特定问题，GPL FAQ非常清楚：

对解释器而言，解释后的程序只是数据；基于版权法的免费软件许可（例如GPL）不能限制您使用解释器的数据。您可以根据需要以任何方式在任何数据（解释程序）上运行它，并且不需要将该数据授权给任何人。

至于关于动态链接还是静态链接的一般性问题。首先，FSF和Stallman的观点是，链接是静态还是动态都没有关系，GPL会以两种方式感染。从FSF GPL常见问题解答：

如果程序动态链接插件，并且它们彼此进行函数调用并共享数据结构，那么我们认为它们形成一个程序，必须将其视为主程序和插件的扩展。这意味着将GPL覆盖的插件与非免费的主程序结合使用会违反GPL。

和

将 [程序名称] 静态或动态链接到其他模块，将基于[程序名称]进行组合工作。因此，GNU通用公共许可证的条款和条件涵盖了整个组合

但是，从法律的角度来看这是值得怀疑的。在唯一实际涉及动态链接的案件上-Galoob诉任天堂 -上诉法院裁定，衍生作品“必须以某种形式纳入受版权保护的作品的一部分”。动态链接不是这种情况。

无论如何，无论动态链接是否确实感染了，都可以解决。例如，Nvidia已使用它为Linux提供二进制驱动程序。您创建（L）GPL包装器，但是作为作者，您可以添加特殊例外来与特定的封闭源链接。Vide FSF GPL常见问题解答。

注意：这是一个法律问题。Programmers.SE不是法律论坛，而是编程论坛。尽管这里的人们对编程非常了解，但是他们对法律一无所知。如果您想提出法律问题，则应该在法律论坛上提出，那里有一些人实际上对该主题有所了解。

GPL没有提及静态或动态链接。它甚至没有说有关链接什么都。我与之交谈的每位律师或法官都说，静态和动态链接的问题是完全不相关的。

版权与创造力有关。静态链接与动态链接是技术实现细节。无论是静态链接还是动态链接，都不是创造性的行为，它不可能更改作品的版权状态。

在您的问题中，您谈论的是“解释语言”。但是这个术语没有意义：没有解释语言。语言是一组抽象的数学规则和限制。语言不会被解释或编译。一种语言就是。术语“解释语言”不仅是错误的，而且是荒谬的。如果英语是一种打字语言，那将是一种打字错误。

解释和编译是解释器或编译器（duh！）的特征，而不是语言的特征。每种语言都可以用解释器实现，每种语言都可以用编译器实现。大多数语言都有。大多数现代语言实现甚至将两者结合在一个执行引擎中。

例如，Rubinius Ruby实现包含一个静态的提前编译器，它将Ruby代码编译为Rubinius字节码；一个解释器，用于解释Rubinius字节代码；以及一个动态的实时编译器，其将Rubinius字节代码编译为LLVM。 IR，LLVM基础结构又将其编译为本机代码。MacRuby Ruby实现完全不包含解释器，它直接将Ruby代码编译为LLVM IR，然后进一步编译为本机代码。

另一方面，有C或C ++的解释器。

所有这些只是技术细节。它与版权完全无关。

有人是否侵犯了他人的版权只是没有道理，而取决于是否有人选择使用解释程序运行该程序或首先编译该程序。

问题是一个作品是否衍生自另一个作品。它可以动态链接并仍然可以派生，也可以静态链接而不是完全派生。

不知道其中有多少真相，还有IANAL等；但是在我的解释中，重要的是您链接到的库是否以某种形式包含在“二进制文件”中（对于动态编程语言，“二进制文件”只是分布式的源代码；这是在这种情况下，我对FSF对“二进制”的定义做了什么。

因此，如果您从代码中引用库而未将它们包含在您的发行版中，则我认为这等同于“动态链接”，而如果您将库与产品捆绑在一起，或将库的一部分复制粘贴到自己的代码中， “静态链接”方案将适用。至少，这是GPL的精神：您可以不受限制地自由使用（运行，检查，参考）GPL软件，但是只要从中获得（通过链接或复制其中的一部分到您的计算机中）自己的可分发产品），它具有病毒性，并且您的软件也必须经过GPL授权。