4

我正在阅读一些较旧的 Joel 关于软件的文章，并偶然发现了Project Aardvark 规范，其中一个特定的部分引起了我的注意：

许可证

VNC 是 GPL。我们基于 VNC 构建的两个组件，帮助者和受害者，将需要在 GPL 下重新发布。

这没什么大不了的。该代码将针对我们自己的使用进行高度优化，并且需要反射器才能工作，这不会在 GPL 下发布。

这让我感到惊讶，因为我确定我在某处读到 GPL 不允许这种事情发生？

4

4 回答 4

3

这取决于反射器与其他一切的关系，由于我对这个项目一无所知，我无法对此发表评论。

GPL 依赖于版权法：如果您正在做版权法允许的事情，则无需关注 GPL。因此，GPL 适用于 GPL 软件的衍生作品，但不适用于分离软件。关于什么是衍生品和什么是独立的存在一些争论，但我不是律师，也没有职位。

有一点很清楚，如果一个程序没有链接到 GPL 程序，而是与它并排并通过标准的进程间通信进行通信，那么它就是它自己的独立工作，不受 GPL 约束。

因此，如果连接了反射器，则受 GPL 约束。如果它作为自己的单独进程运行，则不是。

于 2010-01-21T17:03:13.377 回答
1
于 2010-01-21T17:07:18.587 回答
1

首先，不要根据您从互联网上的人（包括我的）那里获得的法律建议做出任何商业决策。

我认为这在关于 GNU 许可证的常见问题中得到了解决：我可以编写使用非自由库的自由软件吗？

他们似乎对将 GPL 代码与使用不兼容许可证的库结合起来没有任何限制，但他们尽力描述了您使用完全免费软件的动机。

于 2010-01-21T17:11:45.860 回答
1

嗯，有很多 GPL 软件的依赖项是闭源的：例如，考虑在 Windows 上运行的每个 GPL 软件（即链接 Windows API DLL）。

所以，是的，您可以使用封闭源代码的依赖项。尽管如此，正如大卫指出的那样（感谢您的评论），系统库和其他依赖项之间存在差异。GPL 说（我强调）：

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

所以，我想这归结为这个“反射器”是否算作“通用工具”。如果它只是为了将其包含在 GPL 软件中而编写的，我想这不是；如果它在没有 VNC 派生软件产品的情况下服务于有用的目的，它可能是。

于 2010-01-21T16:52:04.917 回答