Inherit a class from library which is under LGPL license . is that OK ?

Question

0.00/5 (No votes)

See more:

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 .

Posted 4-Nov-12 8:25am

Member 8061245

Add a Solution

2 solutions

Add a Solution

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Valery Possoz · Accepted Answer · 2012-11-04T12:45:00

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.

Andreas Gieriet · Accepted Answer · 2012-11-04T13:50:00

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

Inherit a class from library which is under LGPL license . is that OK ?

2 solutions

Solution 1

Solution 2

Add your solution here

Preview 0

Inherit a class from library which is under LGPL license . is that OK ?

2 solutions

Solution 1

Solution 2

Add your solution here

Preview 0

Existing Members

...or Join us