Open source GPL/LGPL和静态链接

我在网上看到，存在以下组合：

专有源代码+GPL源代码->GPL源代码（所有代码必须在GPL下发布）

专有源代码+LGPL源代码->专有源代码（所有代码仍为专有）

---

现在，静态/动态链接GPL和LGPL代码如何与上述组合一起工作？

如果您想要分发组合的作品，您必须使用以下许可证

专有源代码+GPL源代码

• 静态或动态链接：

专有源代码+LGPL源代码

• 静态链接：
  • 要么
  • 或者。在这种情况下，其他需求与动态链接的需求相同
• 动态链接：

另见

---

更新（2014年11月）：包含对（L）GPL及其使用（包括分发）的清晰详细描述。我推荐它来了解更多细节

Proprity Source code+LGPL Source code->Proprity Source code，这是错误的，LGPL源代码仍然是LGPL。我投票结束这个问题，因为它是关于许可或法律问题，而不是编程或软件开发。许可是软件开发的关键部分。考虑到GPL和非GPL代码部分的静态和动态链接如何在更大程度上影响软件开发和编程，我不认为这是一个离题的话题，因此我会要求重新考虑它以保持开放。我想知道这是否应该迁移到。但这对开发人员来说也很重要，因此不确定。关于“您必须以LGPL的形式发布这两个部分”部分：我认为不一定是LGPL。在任何许可证下发布的应用程序源代码都应该可以，即使是禁止修改的许可证，只要它允许将未修改的应用程序源与LGPL库一起重新分发（因此可以重新编译）……不过，我认为“提供允许用户重新链接应用程序的所有内容”本部分还介绍了在LGPL之外的其他目录下提供源代码，所以可以重新编译，然后重新链接。我确信这条评论是绝对正确的。如果静态链接LGPL库，则应用程序本身必须是LGPL。在过去，我们的律师对这一点进行了反复检查。动态链接到LGPL库是避免成为LGPL的唯一方法。在apk（Android应用程序）中使用二进制（静态）或共享库有什么区别吗？在这两种情况下，用户都无法轻松替换apk中的库anyway@Stevan你的评论直接与LGPL自己的官方FAQ相矛盾。答案现在链接到了，并且答案也被更新为该信息：如果静态链接，则不需要在LGPL下授权代码，只需为用户提供一些方法来更新库代码并根据库代码重新链接可执行文件即可。这包括提供合适的未链接的二进制文件，或者根据专有许可证提供源代码。（我不确定你所说的“这条评论”是什么意思——我想你可能指的是当时的答案。）