GPLv2程序可以依赖Apache许可的库吗？

许可了GPL（版本2）的软件程序是否可以依赖APLv2许可的库，而不会违反GPL？这里的语言向我暗示也许没有。

在我的特定情况下，我正在看一个使用某些APLv2许可的外部库的守护程序。

更新 （响应答案/评论。）

1. 出于这个问题的目的，我无法重新授权主程序（守护程序）
2. 主程序已经扩展了使用apr-util和其他APLv2组件的功能

我的问题是，我是否可以在GPLv2下发布扩展的守护进程，或者如果我承诺（a）发布此扩展，那么这是否需要我自己保留（不分发）和/或在没有APLv2的情况下重新实现，并且（b）使守护程序保持GPL？

首先让我们澄清一些术语。当FSF说许可证与GPL兼容时，它们并不意味着许多人将其解释为什么意思。许多人将“兼容”解释为意味着两个软件可以在同一应用程序中愉快地共存。

这与FSF的含义很接近，但是GPL的copyleft条款使事情变得更进一步。

从GPL常见问题解答中，重点是我的。

这意味着其他许可证和GNU GPL是兼容的；您可以在一个较大的程序中将根据其他许可发布的代码与根据GNU GPL发布的代码进行组合。
所有GNU GPL版本都允许私下进行此类组合。如果组合以相同的GNU GPL版本发布，它们还允许分发此类组合。

因此，如果可以在GPL之下吸收其条款，则许可证与GPL兼容。

因此，让我们看一下APLv2和GPLv3。

• APLv2_Lib + GPLv3_Lib =>将库合并为GPLv3是可以的。
• APLv2_Lib + GPLv3_Lib =>将lib合并为APLv2是不可行的。

Apache 在这里说了很多：

我们避免使用GPLv3软件，因为GPLv3作者仅考虑与其链接以创建衍生作品。我们想兑现他们的许可证。

但是，您正在使用由GPLv2（而非v3）许可的守护程序。

FSF很清楚，您想要做的事情对于公共发行是不可接受的。

请注意，该许可证与GPL版本2不兼容，因为它具有某些要求，而该要求不在该GPL版本中。其中包括某些专利终止和赔偿规定。

因此，回答您的问题：

不可以，您不能使用GPLv2和APLv2许可材料分发组合的守护程序。
FSF明确指出该组合是不允许公开发行的。

备择方案：

1. 您是允许私自使用它。

2. 您也可以重写APLv2功能，然后将新工作与GPLv2工作结合起来。

3. 您可以看到该守护程序是否可以更改为GPLv3。如果是这样，那么您就可以将APLv2工作合并到现在的GPLv3守护程序中。

我的观点与基于OP的ASF链接文本的OP一致。

基于您的案例的有限信息以及我对各种FOSS许可证的理解，ASF（Apache软件基金会）不喜欢将ASFv2代码作为使用GPLv2的系统的一部分的想法：无论总体项目是否具有GPLv2 ，或总括项目为GPLv2，尝试包含ASFv2。

此外，似乎不应发生具有GPLv3代码的ASFv2总体项目，但GPLv3总体项目可以具有ASFv2代码。

也许是警告（根据Gnu），这是它们如何相互作用的方式。如果链接在一起，则在执行期间共享相同的数据副本，它们是同一程序中的一个。但是，如果它们作为单独的进程（即派生的）在不同的不同进程之间传递数据，则可能会允许您执行操作，因为它们对他们来说是单独的程序。如果它在执行期间使用共享的数据空间，并且不对不同的进程进行操作，那么您可能无法执行您的操作，因为对于它们来说，它们是相同的或紧密耦合的，以致于它们是独立的或独立的。