MIT等与GPL兼容的许可证如何在GPL程序中使用而不受copyleft条款的约束？

我目前正在研究在商业环境中针对应用程序与GPL库链接的可能性和含义。

根据我对GPL的了解，只要在内部使用该应用程序，就没有义务发布其代码（即使将副本移至受控子公司）。

我不明白的是FAQ中的以下几点：

如果库是根据GPL（而非LGPL）发布的，是否意味着使用该库的任何软件都必须符合GPL或GPL兼容许可？是的，因为实际运行的软件包括该库。

如果我看一下与GPL兼容的许可证，其中一些许可证（如增强许可证）似乎没有强加代码的发布。使用它会造成一种情况，您可以遵守GPL许可，而不必遵守其公开代码的义务（这似乎不太可信）。

（注：Adobe Photoshop中的某些组件在boost下获得许可，我认为该代码不是按需提供的）

最合理的解释是我遗漏了一些东西……您能告诉我我哪里做错了吗？

MIT等与GPL兼容的许可证如何在GPL程序中使用而不受copyleft条款的约束？

简短的回答：不是。它们将成为copyleft的对象。

长答案：

该许可证兼容性维基百科的文章有一个良好的部分GPL兼容：

许多最常见的自由软件许可证，例如原始的MIT / X许可证，都是“ GPL兼容的”。也就是说，他们的代码可以与GPL下的程序组合而不会发生冲突（新的组合会将GPL应用于整个程序）。

[加重]

从FSF常见问题解答中可以更明确地了解GPL兼容性：

这意味着其他许可证和GNU GPL是兼容的；您可以在一个较大的程序中将根据其他许可发布的代码与根据GNU GPL发布的代码进行组合。

仅出于教育目的，这是FSF对各种许可的评论

FSF对助推许可的评论

这是宽松的，允许的非copyleft自由软件许可证，与GNU GPL兼容。

这意味着，在Boost中获得许可的任何内容都可以轻易地归入GPL。

哪里变得棘手

假设我们有Foo在Boost Bar下获得许可的项目，并且在GPL下获得了许可并想要使用的项目Foo。

Bar+Foo因为许可证是兼容的，所以允许使用，并且Bar+FooGPL 的发布必须Bar是GPL。 Foo本身（不带Bar 或 Bar+Foo）的情况下，在Boost许可下仍然可用。换句话说，Bar+Foo对Foo自身没有许可证影响。

项目组合的最终许可仅是该组合的前瞻性事件。这不是追溯事件。

因此，如果其他人想采取行动Foo并做其他事情，那么他们仍然可以自由地这样做，而无需遵循GPL的版权保留条款。但是，如果采用Bar+Foo，删除Bar和仅使用+Foo它们，则自从采用GPL以来Bar+Foo，它们仍然受GPL条款的约束。

您的其他问题：

根据我对GPL的了解，只要在内部使用该应用程序，就没有义务发布其代码（即使将副本移至受控子公司）。

FSF GPL常见问题解答（关于源代码分发）直接回答了这一问题

GPL不需要您发布修改后的版本或其任何部分。您可以自由进行修改并私下使用它们，而无需发布它们。这也适用于组织（包括公司）；组织可以制作修改后的版本并在内部使用它，而无需在组织外部发布。

全资子公司被视为上级组织的一部分，因此从法律上讲您是无所不知的。FSF将指出您虽然违反了自由软件的精神。

“兼容GPL”是指与GPL不冲突的许可证。限制较少的许可证（例如Boost许可证）与GPL“兼容”，因为它不会限制代码用户执行GPL允许用户执行的任何操作。也就是说，Boost许可证允许人们自由复制，这就是GPL要求允许的人员。

不兼容的许可证的一个示例是需要向原始作者收取费用以供用户分发副本的许可证。由于GPL明确允许免费和付费分发，因此这种限制性更强的许可证将不兼容。

换句话说，GPL说“您必须允许$ A，$ B和$ C”。任何允许$ A，$ B，$ C以及$ D和$ E的许可证都是兼容的。允许$​​ A和$ B但不允许$ C的许可证将不会。

您没有记错：FAQ答案不完整。应该说，组合程序必须根据GPL许可，而不是GPL兼容许可。此后已得到纠正（请参见下文：我强调了重要的一点）：

是的，因为该程序实际上链接到库。因此，GPL的条款适用于整个组合。与库链接的软件模块可能已获得各种GPL兼容许可，但整个作品必须已获得GPL许可。另请参阅：说许可证“与GPL兼容”是什么意思？

我之前曾说过：“如果库是根据GPL发布的，则使用该库的任何软件都必须归于GPL本身，因为它具有所谓的“病毒”性质。不允许使用与Boost兼容的GPL兼容许可。” “使用它的软件”是指组合的模块和库。