GPL是否声明GPL软件的依赖性也必须在GPL下发布?

时间:2010-01-21 16:49:26

标签: gpl

我正在阅读一些较老的Joel关于软件的文章并遇到了Project Aardvark spec,一个特别的部分引起了我的注意:

  

许可证

     

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

     

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

这令我感到惊讶,因为我确信我在某处读到了GPL不允许这种事情?

4 个答案:

答案 0 :(得分:3)

这取决于反射器与其他一切之间的关系,因为我对这个项目一无所知,所以我无法对此发表评论。

GPL依赖于版权法:如果您根据版权法做某些事情,则无需关注GPL。因此,GPL适用于GPLed软件的衍生作品,但不适用于分离软件。关于什么算作衍生品和什么是分开的,存在一些争论,但我不是律师而且没有立场。

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

因此,如果反射器被链接,则它受GPL的约束。如果它作为自己独立的进程运行,则不是。

答案 1 :(得分:1)

嗯,有很多GPL软件的依赖是封闭源:例如,考虑在Windows上运行的每个GPL软件(即链接Windows API DLL)。

所以,是的,您可以使用闭源的依赖项。然而,正如David指出的那样(感谢评论),系统库和其他依赖项之间存在差异。 GPL说(由我强调):

  

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

所以,我想这归结为这个“反射器”是否算作“通用工具”。如果它只是为了将它包含在GPL的软件中而编写,我猜这是 no ;如果它在没有VNC衍生软件产品的情况下有用,可能

答案 2 :(得分:1)

http://www.gnu.org/licenses/gpl-faq.html

标准IANAL免责声明。 GPL是根据版权法强制执行的,因此其病毒规定仅适用于您从事衍生作品的情况。将源代码修改为GPL程序计为衍生作品。静态链接也是如此。动态链接是值得商榷的。简单地调用GPL程序或以其他方式与一个程序进行通信肯定不会。最重要的是,它确实取决于“依赖”在这种情况下的含义。

答案 3 :(得分:1)

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

我认为这是在关于GNU许可证的常见问题解答中解决的:Can I write free software that uses non-free libraries?

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