LGPL允许我这样做吗？

我打算使用LGPL软件开发商业软件。

在我使用的LGPL软件中，某个类中的某些功能没有完全实现。我想修改LGPL代码，以便通过添加类的dllexport infront以及通过添加函数的虚拟关键字infront来使类和未实现的函数在dll外部可见。

然后，我计划在我的专有软件中实现这些功能。我准备分发修改后的LGPL代码，但不分发按我想要的方式实现功能的专有软件。

这是否违反LGPL条款和条件？

这是一个复杂的问题，但我认为您的建议是不允许的。

您建议将钩子添加到库中，以使子类库（至少是子类）更容易分类。绕过LGPL 的精神。

问题是，如果您在自己的代码中将受LGPL许可约束的类子类化，则您的工作将成为基于库的工作，而不是使用库的工作，这意味着您的代码是派生的第2节（LGPL v2.1）涵盖的工作，而不是第6节（LGPL v2.1）涵盖的工作。即它成为LGPL的约束！

我认为Stephen Colebourne提供了有关Javalobby 的很好的总结。

我不是很讨厌与您的律师建议进行直言不讳的对话，但是在这种情况下，如果您打算进行此操作，我认为这样做是非常值得的，否则您可能会从Free Software收到一封讨厌的信基金会法律团队。

或者，您可以直接询问FSF。从他们的联系页面：

有关自由软件许可和版权的问题

请检查我们的许可常见问题解答，许可列表，常规copyleft信息以及相关页面。如果仍有问题，请发送电子邮件至<licensing@gnu.org>。

顺便说一句，在反射和LGPL相关问题中，gbjbaanb 从LGPL 3.0角度进行了回答。

标准我不是律师免责声明。

LGPL要求对库源代码进行修改，以将其分发给使用您的代码的任何人。它不要求你的代码，它使用的图书馆，是开源的，在相同的许可下发布。

Wikipedia提供了关于LGPL的更详细但非律师的描述，包括有关类继承的部分。

“我想修改LGPL代码...”这足以说明您必须释放任何修改后的代码。然后，是否扩展该修改后的代码是否是派生作品，尚有争议，如果是，则应遵循LGPL。

您似乎想做的是规避LGPL，在这种情况下，使用这些技术您将无法做到。

如果是衍生作品，则程序的条款必须允许“供客户自己使用的修改，以及用于调试此类修改的逆向工程”。使用LGPL程序的作品是否为衍生作品是一个法律问题。

但是，如果您要绕过LGPL，我会按照Mark Booth的建议与FSF联系。

我的猜测：（但IANAL）您应该将经过修改的库作为LGPL代码作为开源发布，然后将其放入商业程序中。那行得通。实际上，您最终将拥有一个开源的库分支，然后您将为其出售前端。

但是，正如许多其他人正确说的那样，请问FSF：这是一个有趣的病态场景；他们是否会和您一样想知道它是否适用。（或至少对此足够打扰，以便发布有关该主题的FAQ条目）

https://www.gnu.org/licenses/lgpl-java.html

如果您分发导入LGPL库的Java应用程序，则很容易遵守LGPL。您的应用程序许可证需要允许用户修改库，并对代码进行反向工程以调试这些修改。这并不意味着您需要提供源代码或有关应用程序内部的任何详细信息。当然，用户可能对库进行的某些更改可能会破坏界面，从而使库无法与您的应用程序一起使用。您无需担心，修改库的人有责任使其正常工作。

简而言之，只要您不更改库代码本身，继承就不会有问题，但是即使您更改了库代码，也只需要释放库修改的代码，而不发布应用程序代码。