问题标签 [gpl]

在 GNU 通用公共许可证 (GPL) v3 开源许可证下发布 iOS 应用程序是否合法？显然，你不能使用其他人的 GPL 源，但我拥有整个源的版权可以吗？

如果 GPL 许可证不合适——我可以使用 MIT 许可证、BSD 许可证或其他许可证吗？

我有一个使用 LGPL 下的组件的商业网络应用程序。由于该组件具有插件架构，因此我现在为该组件创建了一个使用库 (LGPL) 的插件。该库使用 GPL 数据源。

这是否意味着我必须为我的网络应用程序释放源？还是只需要释放插件的源代码？

感谢您的任何意见和建议，并原谅我的英语不好。

我可以使用 upx packer 压缩商业程序吗？还是 GPL 限制我这样做？

我在 MySQL 上使用 Python/Django。我目前正在使用GNU GPL 许可下的MySQLdb 。有没有类似 GPL 许可的具有“类似”功能的库？

澄清：

• 我还不知道是否要分发我的源代码或为我的应用程序收费。我所知道的是，我不希望通过选择 MySQL 和 Python 来为我做出这些决定。
• 我目前正在使用 Django 构建一个 Web 应用程序，我认为这个问题无关紧要，因为我没有“分发”任何东西，但我正在编写的 Python 代码可能可以作为桌面应用程序分发，这就是GPL 开始困扰我。

谢谢

我们正在评估几个用于图形操作的 Python 库。我们尝试了“networkx”（http://networkx.lanl.gov/）和“igraph”（http://igraph.sourceforge.net/）。

虽然两者都是优秀的模块，但 igraph 因其性质而更快 - 它是 libigraph 的 Python 包装器 - 一个极快的图形 C 库（使用 LAPACK 等）。

现在，igraph 库是 GPL 许可的。我的问题是：我可以导入 igraph 并在我的商业 Python 脚本中使用它吗？

（这是一个普遍的问题，不仅限于 igraph。如果答案很明显，我们深表歉意——我是许可证新手！）

谢谢，拉吉

编辑：更具体地说，简单地导入 GPL Python 模块是否会使我的商业代码易于向公众发布？

假设我的网站基于 GPL 代码。

AFAIK 通过网站向用户提供服务——甚至是付费服务——并不违反 GPL。这是因为 GPL 是关于分发的，而我没有提供任何代码。我正在提供服务，可能会收费。

但是，假设我向我的网站提供了一个 API，并为使用该 API 收费。

有人可以争辩说，实际上我只是将我的网站变成了一个软件，通过将其作为外部软件应用程序的一部分进行分发，从而违反了 GPL？

这是一个假设的场景（即：我只是想出来，我不打算这样做！）

是什么阻止了公司通过执行以下操作来阻止 GPL 衍生作品的有效使用

1. 分叉 GPL 项目
2. 制作衍生作品
3. 出售衍生作品并以混淆形式发布源代码

所以从技术上讲，他们已经将源代码发布回社区。但它实际上是无用的。

我知道这将是一件相当低级的事情，而且这违反了 GPL 的精神，但 GPL 能防止这种类型的滥用吗？如果是这样如何

我正在开发一个支持插件的应用程序。我想知道我是否可以在应用程序上应用 LGPL，还是 LGPL 仅适用于图书馆？

要点是我希望应用程序大致是 GPL，但这不是在应用程序加载的插件或脚本上强制执行的。但是，GPL 认为插件是衍生作品，因此在这种情况下，纯 GPL 并不好。

目前我一直在考虑 MPL，但它明确指出该许可证将在加利福尼亚州的管辖范围内，这对于欧洲人来说是不可接受的。

如果我想留下一个弱副本，那么对于应用程序的许可证来说，更谨慎的选择是什么。我应该应用 GPL 而非 LGPL 的任何标准例外情况，以及 LGPL 如何适用于应用程序？许可证确实谈到了库，如果我想将它应用于应用程序，这对我来说是相当混乱的。

我目前正在评估在商业应用程序中使用 PyQt，我很惊讶地发现 PyQt 商业许可证不允许您在应用程序的脚本 API 中公开任何 PyQt 库。从PyQt 网站：

与您的应用程序一起分发所需的 PyQt 模块和 QScintilla 库的权利，只要这些应用程序的用户自己不能直接访问 PyQt。否则，这些用户自己就会成为开发人员，并且需要他们自己的 PyQt 和 Qt 商业版本的副本。

这是因为如果他们被允许访问 PyQt，您实际上会在 PyQt 商业许可证中存在“漏洞”吗？我想，这个条款填补了这个漏洞。我想知道 GPL 和相关许可证中是否必须有类似的条款？否则，当然，您将能够在开源许可证下发布应用程序，该许可证本质上只不过是一个“外壳”应用程序，它允许人们“编写”其行为 - 所说的行为是创建第二个，非使用 GPL PyQt 绑定的 GPL 应用程序。

我毫不怀疑这个“漏洞”在 GPL 中得到了解决，它一定有很多有才华的律师用细齿梳来检查它。- 真的，我正在尝试更多地了解法律如何影响程序员的生活。GPL 和其他开源许可证似乎是一个不错的起点。

此外，在 LGPL 下发布的同一系统会不会有类似的问题？或者该许可证更宽松的性质是否意味着允许用户通过应用程序访问库时不会发生太多冲突？

我想在 GPLv3 下发布一个小软件。它是用 C# 为 .NET 3.5 SP1 框架编写的。它还使用在 MS-PL 下发布的MEF库。MS-PL 不兼容 GPL。但是，MEF 库最终会被滚动到 .NET 4 版本中，到那时，它就变成了一个系统库，不再重要了。

我仍然希望尽快发布代码，只是为了获得一些反馈并为早期采用者提供代码（尽早发布，经常发布）。我知道我可以在 GPLv3 第 7 节下编写一个例外，允许接收者将此代码与此特定库链接。

这个异常会是什么样子？它是否位于项目目录中 LICENSE 文件旁边的单独文件中？我是否也必须在所有文件头中提及异常？我知道 ClassPath 异常，但有谁知道某个特定库发生异常的情况，例如？