问GPL如何应用于必需的但非分布式的代码？

EN

首先，我不是律师，没有资格提供法律建议。联系你自己的律师寻求法律咨询。

也就是说，当程序可能依赖于库时，我在过去使用的指导方针涉及到GPL中“系统库”和“对应源代码”定义之间的交互：

可执行作品的“系统库”包括(a)包含在打包主要组件的标准形式中，但不是该主要组件的一部分，以及(b)仅用于允许使用该主要组件的作品，或实现一个标准接口的任何东西，而不是作为一个整体的作品，该标准接口的实现以源代码形式向公众开放。在此上下文中，“主要组件”是指可执行工作在其上运行的特定操作系统(如果有的话)的主要基本组件(内核、窗口系统等)，或用于产生工作的编译器，或用于运行工作的目标代码解释器。

目标代码形式的作品的“对应源代码”是指生成、安装和(对于可执行的作品)运行目标代码和修改作品所需的所有源代码，包括控制这些活动的脚本。然而，它不包括作品的系统库，或通用工具或普遍可用的免费程序，它们在执行这些活动时未经修改地使用，但不是作品的一部分。例如，对应的源包括与作品的源文件相关联的接口定义文件，以及作品被特别设计为需要的共享库和动态链接子程序的源代码，诸如通过那些子程序与作品的其他部分之间的亲密数据通信或控制流。

现在是指导方针:如果你可以合理地期望这个库在几乎每个系统上都是默认可用的，并且这个库是系统正确操作所必需的，那么将你的非GPL程序链接到GPL库是合法的。

这是一个非常严格的限制。在实践中，为他们的库选择GPL许可证的库作者对使用他们的库的非GPL程序不感兴趣。这样的库通常不会以使“对应源代码”的“系统库”子句如此有用的方式集成到系统中。(我不能随便说出任何我认为是重要系统库的GPL授权库)。

至于“联系”--我相信“联系”从来没有在法庭上争论过。为了安全起见，您不应该在同一进程中分发与GPL代码一起运行的专有代码。虽然C、C++等语言将这一点说得很清楚，但我希望大多数法官都能相信，任何语言的常规“要求”或“包含”机制都代表着“链接”的道德等价物--完全的源代码包含肯定会达到“在同一进程中运行”的相同意图。