GPL可以暗示为衍生作品吗？

共有三个软件项目：A，B和C。

A发布给任何人，并根据GPL许可。

B扩展了A，也已发布，但没有许可证信息或被LGPL错误地许可。基本上，它不是GPL违反了A的许可。B的源代码仍然可用。

C扩展B。C可以在GPL下发布吗？动机是“ A是GPL，任何衍生产品也必须是GPL，所以B也是GPL，C也可以是GPL”。

首先，B违反了A上的GPL。但这并不是您真正关心的问题，并且与这里的问题无关（谁知道，也许B在A的代码上从A获得了LGPL许可证，以便可以在LGPL下发布它？ ）。

问题是“您可以基于LGPL代码构建GPL软件吗？” 答案就是“是”。

LGPL的限制不如GPL（因此，除非另有规定，否则B违反A的许可），而且还可以很容易地将其重新纳入GPL项目。

来自LGPL许可证：

3. 包含库头文件中的材料的目标代码。应用程序的目标代码形式可以包含来自作为库一部分的头文件的资料。您可以根据自己的选择传达此类目标代码，但前提是，如果所包含的材料不限于数字参数，数据结构布局和访问器，或小宏，内联函数和模板（长度为十行或更少行），请执行以下两个操作：

   a）在目标代码的每个副本中都应特别注明使用了库，并且本许可证涵盖了库及其使用。
   b）在目标代码中随附GNU GPL和此许可文档的副本。

它是许可证的一部分。您可以轻松地基于LGPL代码构建GPL软件。

您必须注意一些版本差异，以确保代码在GPL的正确版本下以正确的方式获得许可。

如果没有提供许可证信息，则您无权对其进行扩展。B不应被分发，但其贡献未获得开源许可证的许可。这可能是发布的内部项目或其他事件。

它没有根据与GPL扩展兼容的许可证提供。考虑这样一种情况，一家公司在内部使用GPL软件（可以接受-并非违规）错误地将其回购公开。

在这种情况下，项目C很有可能本身就侵犯了版权（B添加的，未经GPL许可的材料，因为它不应该首先分发）。

一个不能强迫别人的源许可证。它要么符合许可证，要么违反许可证。如果违反，则按照许可证中的规定：

除非本许可明确规定，否则您不得传播或修改涵盖的作品。以其他方式传播或修改它的任何尝试都是无效的，并且将自动终止您在本许可下的权利（包括根据第11条第3款授予的任何专利许可）。

违反GPL并不意味着该材料属于GPL，而是不能分发。

有版权持有人：A创作的作品具有版权，B的增补作品具有版权，C所做的任何更改均具有版权。C必须检查他是否有权使用A和B拥有版权的软件。

A根据GPL获得许可。我非常确定，即使您从错误地许可了B的B收到了GPL，GPL仍允许您使用G条款下的A的作品。可能存在实际问题：例如，您必须能够提供源代码。如果您收到的软件没有源代码，那么您将无法按照GPL条款进行发布。

B被其他许可所许可。B 应该已经根据GPL获得许可，但没有。如果B的许可证给您的权利高于GPL，则您实际上没有A的代码的任何权利-B不能给您A的代码的其他权利。您可以在GPL条款下使用A的代码，因为A允许使用它，而B的附加代码则在B的许可下使用。

如果B在比GPL更严格的许可下发布了他们的代码，则B很可能会侵犯版权。根据GPL许可，您不能使用B的代码。这常常令人困惑：GPL无法强迫 B做任何事情。它仅给B选择：以这种方式发布，在法律上是可以的，或者以另一种方式发布，并且是非法的。B有权采取非法措施并承担后果（因侵犯版权而被起诉）。您没有B赋予您的B的代码的任何权利。

从技术上讲，可以使用GPL许可证本身未涵盖的代码扩展GPL库。缺点是，当您分发创建的派生作品时，必须遵守GPL对您的所有要求。

在您的情况下，这意味着可以在GPL下使用库A，而在LGPL下使用库B中的新代码。组合的作品（库B）在GPL许可下有效地分发，并且可以这样分发，因为LGPL许可与GPL许可兼容（您可以在GPL许可的项目中使用LGPL许可代码）。
在这种情况下，最好在GPL下将新代码存储在库C中，并且在GPL下也进行最终的工作。