从非GPL软件调用GPL软件


30

我可以(合法地)使用从我正在编写的另一个程序中以GPL发布的程序,而不必遵守GPL(对于我正在编写的程序)吗?

例如,我有一个使用程序的GUI(在GPL下),我可以将代码隐藏在GUI中甚至出售吗?

Answers:


30

您可以从自己的程序中使用 GPLed程序,而程序不会受到GPL的影响,但是如果您的程序不受GPL条款的约束,则无法将GPLed代码链接到自己的程序中。

在问题提供的示例中,您已围绕现有命令行程序编写了GUI包装程序,您的GUI不受GPL条款的约束,但前提是它是一个单独的程序,可以在GPLed程序中运行GPLed程序。单独的进程,并且仅通过现有界面(例如,通过命令行和/或通过stdin / stdout)与进程进行通信。

GPL FAQ中的一些相关内容:

两个单独的程序和一个包含两个部分的程序之间的界线在哪里?这是一个法律问题,最终由法官决定。我们认为,适当的标准既取决于通信机制(exec,管道,rpc,共享地址空间内的函数调用等),也取决于通信的语义(交换各种信息)。

如果模块包含在同一个可执行文件中,则它们肯定会组合在一个程序中。如果将模块设计为在共享地址空间中链接在一起运行,则几乎可以肯定意味着将它们组合到一个程序中。

相比之下,管道,套接字和命令行参数是通常在两个单独的程序之间使用的通信机制。因此,当它们用于通信时,模块通常是单独的程序。但是,如果通信的语义足够亲密,交换复杂的内部数据结构,那么这也可能是考虑将这两个部分组合成一个更大的程序的基础。


我可以发布旨在加载GPL覆盖的插件的非免费程序吗?

这取决于程序如何调用其插件。例如,如果程序仅使用简单的fork和exec来调用插件并与之通信,则这些插件是单独的程序,因此该插件的许可证对主程序没有任何要求。

如果程序动态链接插件,并且它们彼此进行函数调用并共享数据结构,则我们认为它们形成一个程序,必须将其视为主程序和插件的扩展。为了使用GPL覆盖的插件,必须在GPL或GPL兼容的自由软件许可下发布主程序,并且分发主程序以与这些程序一起使用时必须遵循GPL的条款。插件。

如果程序动态链接插件,但是它们之间的通信仅限于使用某些选项调用插件的“ main”功能并等待其返回,这是一个极端的情况。

请注意,在任何情况下,GPL都完全适用于基础命令行程序-如果分发它(而不是让用户从其他来源获得它),则您有责任向用户提供GPL的副本,以使之向他们清除命令行程序位于GPL下(即使GUI包装程序不在GPL之下),并应要求向他们提供命令行程序的源代码。再次从GPL常见问题解答:

如果人们要分发被GPL覆盖的软件,并将其称为“一部分”的系统(用户知道该系统是部分专有的),则用户可能不确定其对GPL覆盖的软件的权利。但是,如果他们知道自己收到的是免费程序加上其他程序,他们的权利将是明确的。

标准免责声明:我不是律师,即使我是律师,我也不是您的律师。如果您需要明确的答案,请咨询获得许可在您所在司法管辖区执业的适当法律专业人士。


1
应该注意的是,FSF在链接方面的立场是少数派立场。(而且,IMO,这毫无意义。自动化流程无法创建新作品。)
David Schwartz

1
但是,FSF确实编写了GPL。这使他们的意见更加重要。“当我们说X时,是指{...}”在法庭上通常被接受。“当您说X时,您的意思是{...}”,并非如此。
MSalters 2011年

“仅使用简单的fork和exec进行调用”是什么意思-有人可以澄清吗?
Krunal

那么,只需编写管道包装程序以在单独的进程中运行GPL代码即可轻松地绕过GPL吗?这似乎使GPL变得无关紧要,也无法执行。如果我编写自己的库并将其链接到GPLed库,该怎么办?我单独的独立库也将变成GPL吗?如果在使用GPL代码时链接到其他人的库怎么办?他们的图书馆是否已通过GPL认证?如果您对以上任何一个问题的回答均为“否”,那么它将带来巨大的漏洞,可以轻松绕过GPL。如果您回答“是”,那么您就违反了版权法。
Cerin 2015年

@Cerin-GPL仅真正适用于您分发的代码。因此,尽管你可以一个程序,它链接到GPL协议双方及非GPL兼容的许可,你不能再分发该程序给第三方,因为它会在同一个进程中运行GPL协议和非GPL兼容的代码。(“使用而无需重新分发”在许多人看来是GPL中的漏洞,因为这意味着Web服务等可以完全避开GPL,因为它们可以自己运行软件而不是将软件提供给用户来运行。GNUAGPL是尝试解决此问题。)
Dave Sherohman,2015年

0

取决于您使用它的意思?

  • 编译成你的代码
  • 使用共享库
  • 运行可执行文件

它还确切地取决于其他代码所使用的GPL版本/变体。

  • GPL
  • LGPL
  • 股份公司
  • 可能是其他

法律免责声明:我不是律师。


-2

这取决于您的程序“使用” GPL程序的精确程度。GPL FAQ有相当长的解释,但仍然有很多开放的解释:

您不能将GPL涵盖的软件合并到专有系统中。(...)但是,在许多情况下,您可以将专有GPL覆盖的软件与您的专有系统一起分发。为了有效地做到这一点,您必须确保自由程序和非自由程序保持正常通信,并且不要以使它们有效地成为一个程序的方式进行组合。(...) 如果将这两个程序组合在一起,以便它们实际上成为一个程序的两个部分,那么您就不能将它们视为两个单独的程序。因此,GPL必须涵盖整个过程。如果这两个程序保持良好的分离状态(例如编译器和内核,或者像编辑器和外壳程序),则可以将它们视为两个单独的程序-但必须正确执行。问题只是形式之一:您如何描述自己在做什么。我们为什么要关心这个?因为我们要确保用户清楚地了解馆藏中包含GPL的软件的免费状态。

我认为在您的GUI示例中,该GUI主要用于调用命令行GPL程序,两者显然形成了一个程序,因此您必须在GPL下发布代码。


不,他们没有“明确组成一个程序”。只要底层的命令行程序在没有GUI覆盖的情况下仍然能够运行,它们就可以通过“单纯的聚合”组合在一起,而不是“有效的单个程序”。请注意您引用的文本中的示例-编译器位于内核顶部,没有内核就无法运行,但是在没有编译器的情况下内核会很高兴地运行。
Dave Sherohman 2011年

1
@Dave:如果对命令行程序的许可证状态有疑问,则基本的命令行程序是否在没有GUI覆盖的情况下仍然能够运行可能会很重要-但问题是关于GUI,如果没有GUI,则完全没有用命令行程序,因此毫无疑问,它们构成一个程序。
Michael Borgwardt

让我们替换您引用的部分中的示例之一,看看它如何成立。“ ...但是问题是关于编译器的,没有内核它是完全没有用的,因此,毫无疑问,它们构成了一个程序,这是真的。” 当然,除了您引用的文字明确指出“您可以将它们视为两个单独的程序”。如果仅仅是依赖关系的问题,那么您永远无法在Linux上运行封闭的软件,因为如果没有(GPLed)内核,该软件将“完全无用”。
戴夫·谢罗曼

@Dave:当然,除了没有Linux内核,编译器和所有封闭软件都不是没有用的,因为它们可以并且可以在实现POSIX和/或C库标准的任何东西上运行,并提供自己的重要功能。 。与仅用于驱动一个特定命令行程序的GUI包装器完全不同。
Michael Borgwardt

3
但是,您在GUI部分上错了。相同的GUI包装器与其他CLI程序一起使用,尤其是原始CLI的更高版本。在这种情况下,这是相关的,因为这意味着基础程序的原始GPL权利仍然可以行使。如果我将其重新编译的速度提高了10%,那么CLI不会妨碍我。
MSalters 2011年

-3

没有。

GPL代码只能由其他GPL代码使用。

引用维基百科GPL文章的第一行:

GPL是第一个通用的Copyleft许可,这意味着派生作品只能在相同的许可条款下分发。

除此之外,GPL有几页长,并且存在多个版本。


警告,前面有个人咆哮!

我个人非常不喜欢GPL许可,因为它具有限制性和病毒性质。他们称其为“免费”,但实际上恰恰相反,除了其他GPL代码之外,其他任何人都不能使用GPL代码。因此,无论您当前的项目是否开放源代码,都迫使其他项目进入GPL或被迫重写整个库。有大量的开源项目,例如freeBSD,由于许可证不兼容而被迫重写成千上万行linux代码,从“做任何您想做的”的意义上来说它太“免费”了,这显然是与GPL不兼容。

如果您想要真正意义上的“免费”许可证,可以“做任何您想做的事”,那么我建议使用BSD或MIT许可证……实际上,其他大多数许可证都可以。仅有GPL确实存在问题,因为它的限制性如何以及如何迫使其他人加入其中。最后,它过于复杂。

嗯,也是单程票。GPL可以使用从大多数许可证获得许可的代码/库,但是这些库/代码不能依次使用GPL代码。


它说“衍生作品”。这包括动态链接到GPL代码的软件吗?
2011年

@WTP:绝对是的-LGPL的要点是拥有不同的许可证来允许这样做。
Michael Borgwardt

3
环绕命令行程序的GUI shell 不是为版权目的定义的“衍生作品”。
Dave Sherohman 2011年

1
@Dave Sherohman-似乎不清楚。 对此问题的公认答案是:“本质上,恕我直言,纯粹公开GPL程序功能的包装应该是GPL。” 这不仅是他们如何沟通的技术方面,而且是目的。例如,翻译一本书就是创建派生作品。将其转换为Kindle格式将是一项衍生工作。我可以看到一位法官裁定,添加GUI会创建派生作品。谨防。
Scott Whitlock
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.