Click here to Skip to main content
Rate this: bad
good
Please Sign up or sign in to vote.
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 9:25am
Rate this: bad
good
Please Sign up or sign in to vote.

Solution 1

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.
  Permalink  
v2
Rate this: bad
good
Please Sign up or sign in to vote.

Solution 2

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
  Permalink  
Comments
   
Nice analysis, my 5.
—SA
Andreas Gieriet at 4 days ago
   
Thanks for your 5!
Cheers
Andi

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

  Print Answers RSS
0 OriginalGriff 645
1 Maciej Los 225
2 Abhinav S 171
3 Richard Deeming 160
4 Suvendu Shekhar Giri 159
0 Sergey Alexandrovich Kryukov 9,623
1 OriginalGriff 9,095
2 Peter Leow 5,044
3 Kornfeld Eliyahu Peter 3,373
4 Maciej Los 2,581


Advertise | Privacy | Mobile
Web01 | 2.8.150327.1 | Last Updated 25 Mar 2015
Copyright © CodeProject, 1999-2015
All Rights Reserved. Terms of Service
Layout: fixed | fluid

CodeProject, 503-250 Ferrand Drive Toronto Ontario, M3C 3G8 Canada +1 416-849-8900 x 100