从LGPL许可下的库继承一个类。这可以吗 ？ [英] Inherit a class from library which is under LGPL license . is that OK ?
问题描述
大家好。
我有一个LGPL许可的图书馆。
并希望我的申请成为封闭源和商业项目。
所以我不会修改原来的LGPL库的代码，
但我会链接LGPL lib（通过DLL文件），然后继承它的主类到来自我的闭源项目的一个新的，只修改我的项目的新继承类。
我从LGPL许可证中了解到我需要发布来自LGPL库的修改代码。这就是为什么我想继承它的代码然后才改变它，所以我想问你这是否公平和好，因为它可能违反了这个许可证的主要思想。给所有想要使用它的人免费提供它的源代码。
另外，如果我使用LGPL，我想问你到底需要做什么图书馆。
我明白我需要留下LGPL库的源代码（带我的应用程序）
并给出一个链接和信用等。
对不起我的英文错误，我将感谢您的任何更正。
并感谢大家阅读我的问题。
你好。
你问一个非常棘手的问题，很难给出一个回答，但似乎你想要做的就是确定。
根据维基百科关于LGPL的文章：
http://en.wikipedia.org/wiki/GNU_Lesser_General_Public_License [ ^ ]
非（L）GPLed程序可以如果不是衍生作品，则以任何条款分发。如果它是衍生作品，那么程序的条款必须允许修改客户自己的使用和逆向工程以调试这些修改。使用LGPL程序的作品是否属于衍生作品是一个法律问题。通过.so，.dll或类似介质动态链接到库的独立可执行文件通常被认为不是衍生作品（由LGPL定义）。它属于使用图书馆的作品的定义。以下是LGPL版本2.1第5段的摘录：
一个程序，它不包含库的任何部分的衍生物，但旨在通过编译或链接它与库一起工作，被称为使用图书馆的工作。这样的工作是孤立的，不是图书馆的衍生作品，因此不属于本许可证的范围。
但是老实说，如果你想要一个确定的答案，我想你应该向律师寻求建议。
Valery。
请参阅 http://en.wikipedia.org/wiki/GNU_Lesser_General_Public_License [ ^ ]。
挑战：必须启用客户以自己的库替换您交付的基于LGLP的库。例如，对于从LGPL库执行内联代码的语言（例如，C ++中的模板或内联函数调用），这在技术上并不完全给出。
外行人的观点：
安全方式=尽量避免依赖LGPL库。
如果不可能，请向图书馆提供商咨询放宽的许可证模型，例如：麻省理工学院。
如果不可能，请向您的高级管理层签字，因为潜在的诉讼是应该管理的项目风险。我建议：任何第三方库的使用都应该对所使用的库的任何许可模型进行签名：LGPL，MIT，MSPL，Apache等。每个许可模型通常都包含权利和义务（例如，打开您的代码，可能性更换图书馆，给予信用，交付形式等），在开发中使用之前需要检查和/或作为最终验收检查，所有义务都得到满足。
一个偏执的观点：还有一些技术概念将LGPL依赖代码与您的封闭源隔离（例如客户端/服务器架构：您的主应用程序调用某些服务器中实现的服务接口。您提供的服务器实现基于某些（L）GPL库代码。如果需要，该服务器是开源的。整个服务器可以被未来版本中不依赖于（L）GPL的任何东西替换。特别注意不要将依赖项注入客户端/服务器接口：您的主应用程序提供了所需的int表面定义（例如C / C ++头文件，没有模板，没有内联函数），而不是服务器！即然后服务器依赖于（L）GPL代码以及主应用程序接口定义，反之亦然。
在很大程度上取决于您/您的公司找到防水法律地位与合理努力满足许可证义务之间的平衡。依赖（L）GPL打破许可意图的闭源产品总是存在一定的风险。
干杯
Andi
Hello everyone .
I have a library which is under LGPL license .
And want my application to be a closed-source and commercial project .
So i will not modify the original LGPL library's code ,
But i will link the LGPL lib (via DLL file) and then inherit it's main class to a new one from my closed-source project and only than modify the new inherited class for my project .
And i understood from the LGPL license that i need to publish the modified code from the LGPL library . That is why i want to inherit its code and only then change it , so i want to ask you if this is fair and OK , because maybe its against the main idea of this license . to leave it's source code free to everyone who want to use it .
Also , I wanted to ask you what exactly i need to do in addition if i use a LGPL library .
I understood that i need to leave there a source code of the LGPL library (with my application)
and also give a links and credits etc .
Sorry for my English mistakes , I will thank for any corrections .
and thanks everyone for reading my questions .
Hello.
You are asking a very tricky question and it is quite hard to give an answer, but it seems that what you want to do is ok.
According to the wikipedia article on LGPL:
http://en.wikipedia.org/wiki/GNU_Lesser_General_Public_License[^]
The non-(L)GPLed program can then be distributed under any terms if it is not a derivative work. If it is a derivative work, then the program's terms must allow for "modification for the customer's own use and reverse engineering for debugging such modifications." Whether a work that uses an LGPL program is a derivative work or not is a legal issue. A standalone executable that dynamically links to a library, through a .so, .dll, or similar medium, is generally accepted as not being a derivative work (as defined by the LGPL). It would fall under the definition of a "work that uses the Library". The following is an excerpt of paragraph 5 of the LGPL version 2.1: A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a "work that uses the Library". Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License.
But to be honest, if you want a definitive answer, I think you should seek advice from a lawyer.
Valery.
See http://en.wikipedia.org/wiki/GNU_Lesser_General_Public_License[^].
The challenge: a customer must be enabled to replace your delivered LGLP based library by his own one. This is for example technically not fully given for languages that do inline code from the LGPL library (e.g. templates or inline function calls in C++).
A laymen's view:
The safe way = try to avoid depending from the LGPL library.
If not possible, ask the library provider for a relaxed license model, e.g. MIT.
If not possible, get sign-off from your senior management, since a potential lawsuit is a project risk that should be managed. My advise: any use of a third party library should get sign-off for any license model of the used library: LGPL, MIT, MSPL, Apache, etc. Each license model usually contains rights and obligations (e.g. open your code, possibility to replace the library, give credits, form of delivery, etc.) which need to be checked before used in development and/or as final acceptance check that all obligations are met.
A paranoid view: There are also some technical concepts to segregate the LGPL dependent code from your closed source (e.g. a client/server architecture: your main application calls some service interface that is implemented in some server. You deliver a server implementation that bases on some (L)GPL library code. That server was open source if needed. The whole server could be replaced by anything not depending on (L)GPL in future versions. Take special care to not inject dependencies into the client/server interface: your main application provides the needed interface definition (e.g. C/C++ header file, no templates, no inline functions), not the server! I.e. the server then depends on the (L)GPL code as well as on the main application interface definitions, not vice versa).
Depends very much on you/your company to find the balance between "water proof" legal status and reasonable effort to satisfy the license obligations. There is always a certain risk for closed-source products that depend on (L)GPL to break the intent of the licenses.
Cheers
Andi
这篇关于从LGPL许可下的库继承一个类。这可以吗 ？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
