使用 GPL 代码和 GPL 以外许可证的许可软件 [关闭]答案

【问题标题】：Licensing software that uses GPL code with licenses other than GPL [closed]使用 GPL 代码和 GPL 以外许可证的许可软件 [关闭]
【发布时间】：2010-05-27 20:48:51
【问题描述】：

假设我编写了一些代码，我们称之为 X。它使用一些 GPL 代码，我们称之为库 Y。显然我必须使用 GPL 许可证发布 X。没关系。我的问题是，我是否可以在 MIT 等许可下额外发布 X，这样如果有人只想要 X 而不是 Y，他们就不需要将它与 GPL 一起使用？

【问题讨论】：

标签： licensing gpl

【解决方案1】：

是的，您可以在任何您希望的许可下发布您的源代码。根据美国版权法，您拥有该权利。

但是，如果您在源代码中包含任何 GPL 源代码（或与任何 GPL 代码一起分发），则您必须为整个工作使用 GPL 许可。那是因为你必须同意他们的许可才能使用他们的代码。

顺便说一句。我不是律师。

【讨论】：

这个问题非常有针对性，而不是一般性问题。因此，在这种情况下，第一段不是正确答案。但是你的第二段是正确的。
@mP：我认为第一段是正确的：第三方，只要他不使用任何 GPL 部分，有权使用其他部分他们各自的许可证。
@mP：答案是直接、准确和正确的。您认为这有什么不正确的地方？

【解决方案2】：

MIT 许可证也与 GPL 兼容，这意味着 GPL 允许与使用 MIT 许可证的软件组合和重新分发。这个link应该为你提供全面的分析。您应该熟悉很多关于库、插件、模块等的 ifs and buts 和定义。

【讨论】：

这不是我要问的。在这种情况下，组合的软件都将是 GPL 的。 MIT 许可证只是一个示例，可以想象它可以使用与 GPL 不兼容的许可证。
查看此链接blog.milkingthegnu.org/2008/04/gpl-for-dummies.html 进行全面分析。
@swampsjohn：如果您的许可证与 GPL 不兼容，则不应将其与 GPL 作品结合使用。

【解决方案3】：

这里的关键问题是：如果您仅根据 MIT 许可证（或其他一些相当宽松的开源许可证）许可 X，您的软件 X 是否可以分发？

这个问题的答案是：

如果 X 对 GPL 许可库 Y 的依赖是强制性的并且无法避免构建/使用 X，则否。
是的，如果 X 对 GPL 许可库的依赖是可选的 Y，并且默认情况下它是禁用的。

如果无法避免对 Y 的依赖，那么在 MIT 下发布 X 将基本上阻止任何人（例如 Linux 发行版、商业供应商或提供预构建软件的网站）使用 GPL 许可库分发您的软件在构建中启用。

因此，虽然您可以决定根据 MIT 许可授权您自己的软件，但根据此许可发布它会给您的所有用户带来麻烦。

我猜这不是你要找的。p>

我的建议是您下定决心并在以下两者之间做出选择：

如果此 GPL 许可库 Y 对您的软件至关重要，请在 GPL 下发布 X。（最简单、做正确的事情）
如果 GPL 许可库 Y 是可选的，并且如果您确实需要在 MIT 许可下提供可用的软件版本，但希望允许（由您或其他人）分发启用了 Y 支持的 X。（仅在确实需要时）
如果 GPL 许可库 Y 是可选的，请在 MIT 下发布 X，但请注意，在启用 Y 支持的情况下，没有人能够以任何方式分发您的软件。（给用户带来潜在的麻烦，但好处并不明确）

我希望这会有所帮助。

【讨论】：

MIT+GPL=GPL，所以你的第三个要点实际上是聚合的 GPL。

【解决方案4】：

尽管我不是律师，但我的理解是，您可以根据您想要的任何许可集许可您的代码，只要您还许可它与您使用的组件兼容。

如果您的代码不依赖 GPL 代码，那么只要您不使用 GPL 代码分发它，您就不需要获得 GPL 许可。例如，IPython 最初使用的是 readline，但他们从显式/必需的依赖项中删除了它，并且只在它存在时才使用它，这样他们就可以遵守 GPL，但他们选择的任何许可都许可他们的软件。（抱歉，我找不到参考资料。）

【讨论】：

我假设它确实依赖于 GPL 代码，尽管理论上可以用不同的许可证编写 GPL 代码的替代品，也许有些人已经这样做（或将来会这样做） .
对 - 在 IPython 的情况下，他们“软化”了要求，因为如果 GNU 库不可用（并且他们不随它一起分发），软件仍然执行其“主要功能” ，但如果它在那里，它将使用它。

【解决方案5】：

是的，您可以使用 GPL 库；只要你dynamically link 就不要使用 GPL 许可证。否则Linux内核不会有很多驱动程序。

这意味着您必须有一个单独的可执行文件（和/或有关您使用该软件的事实的文档）；在运行时而不是编译时加载。这也意味着你离Dependency HELL!!!更近了一步

Dependency HELL 有几个领域，在这里它们没有特定的顺序：

DLL 地狱
DSO 地狱
罐子地狱
RPM 地狱
扩展冲突
定义 1 0

每个都有多种形式，最终形成最坏的形式：

多个循环和相互冲突的依赖关系的长链，它们在你的大脑中蠕动，吸走你的灵魂！！！

【讨论】：

哇，人们继续投反对票，根本没有 cmets，甚至不要考虑写任何 cmets。

定义 1 0