Static linking in LGPL, Upgrading LGPL libs
in [Embedded]
|
Prev: Call for Papers: The 2010 International Conference on Computer Design (CDES'10), USA, July 2010
Next: Lab-Standard 49-Port USB Hub
From: Karthik Balaguru on 7 Feb 2010 05:40 On Feb 7, 2:35 pm, Michael Schnell <mschnell_at_bschnell_dot...(a)aol.com> wrote: > On 07.02.2010 10:25, David Schwartz wrote: > > > > > But you can also make the program available both statically-linked and > > dynamically-linked. > > You can't if the build system does not allow for dynamically linked > libraries. This is the case with many (embedded) uCLinux Architectures. > Interesting !! But, Why does it not support for dynamically linked libraries ? Just eager to know the reason for not supporting dynamic linking. Okay, But, I am really interested to know if the application linking the LGPL library statically should release the application source code also. So,continued to explore the licenses, and i got the below statements for LGPL from the link :- http://en.wikipedia.org/wiki/GNU_Lesser_General_Public_License#Differences_from_the_GPL ------------- "Essentially, if it is a "work that uses the library", then it must be possible for the software to be linked with a newer version of the LGPL-covered program. The most commonly used method for doing so is to use "a suitable shared library mechanism for linking". Alternatively, a statically linked library is allowed if either source code or linkable object files are provided." -------------- In the above extract, does the term 'source code' in the last line refer to the obfuscated source code ? Thx in advans, Karthik Balaguru
From: Michael Schnell on 7 Feb 2010 06:10 On 07.02.2010 11:40, Karthik Balaguru wrote: > But, Why does it not support for dynamically > linked libraries ? Just eager to know the reason > for not supporting dynamic linking. The compiler needs to support this. The dynamically linked (shared) libraries need to be loaded into a free spot in memory and at compile time you can't know where to find this and without an MMU you can't create a predefined address space for the library. One way of doing shared libraries is "PIC" (Position Independent Code). Not all compilers for all architectures support this. or shared libraries not only the code needs to be position independent, but also static data needs to be unique for each program linking the library dynamically. -Michael
From: Karthik Balaguru on 7 Feb 2010 08:44 On Feb 7, 3:29 pm, David Brown <david.br...(a)hesbynett.removethisbit.no> wrote: > Michael Schnell wrote: > > On 07.02.2010 06:12, karthikbalaguru wrote: > > >> I searched the internet and got few links. > >>http://answers.google.com/answers/threadview/id/439136.html > >> Though it discusses about static linking > >> in LGPL, it does not arrive at a definite > >> answer ! > > > Same here and seemingly everywhere ;) > > > The wording of LGPL seems to require that LGPL coded needs to be > > upgradeable by the end user. Thus to allow for this with statically > > Correct... > > > linked projects, the source code of the complete project needs to be > > available to the end user. > > Wrong... > > The key freedoms of the GPL are that the person who receives the > software can read the source code, modify it, use the original or > modified version, and pass on to others the original or modified version > under the same license. > > The LGPL aims to provide the same benefits to end users of libraries > while still being usable with software under other licenses. > Agreed . It makes it feasible for using the LGPL'ed libraries with closed source applications/proprietary softwares. > If you keep that in mind, it is a lot easier to understand what you are > and are not allowed to do with the LGPL (and the GPL, for that matter). > > Very roughly, if your code makes use of an LGPL'ed library, then the end > user has the right to the source code of the library (including any > modifications you may have made), and they must be able to modify and > recompile that library and use your application with the modified > version of the library. True incase of any modifications in the LGPL'ed library while using with the particular closed source application ! > With dynamic linking, this is easy to achieve - > they can re-compile the library and then just re-load the application. > This is True in the case of dynamic linking ! > With static linking, things are a little more complicated. However, you > do not have to make your own code available to the end user in a "nice" > form - it is enough that they can re-link with their modified library. > Thus you can provide it as linkable object code, or perhaps obfusticated > source code. I have many queries here - I think only linkable object code is enough. Won't linkable object files alone serve the purpose ? Why should the source code be provided to the end-user ? If source code is mandatory, can you pls elaborate how can obfusticated code appear ? Is the method of providing obfusticated approved by LGPL ? Does any of the closed source vendor follow this approach ? > And if you provide real source code, you don't have to use > the (L)GPL - you can deny any rights other than that the user can > re-compile and re-link, without allowing them the right to modify or > distribute your code. > I think, many closed source vendors will not opt for this method as the code is exposed to end-user even though the right to modify is absent. Do any of the closed software vendor follow this policy of providing closed source code without the right to modify ? I wonder why LGPL has such a strange policy as LGPL was to help the closed source softwares by providing them LGPL'ed libraries so that they need not reveal the source code, even though the free software community was also indirectly enjoying the benefits from LGPL. It seemed to be a gain for both the communities. > > Are the .h files that come with e.g the dynamically linked libc not > > released as LGPL ? How to upgrade those ? I don't think anybody ever > > intended them to only be used with open source software. > > Header files in LGPL libraries typically have explicit exceptions to > allow you to use them as you want. Otherwise, any code that #include'ed > the header file would technically be a derivative of that file (since > the C pre-processor just joins the files together), and then the (L)GPL > would cover the whole program. > > > > > OTOH, I never found a single notice that LGPL holders requested > > programmers to open their code for that upgradeablility reason. > > > -Michael- Hide quoted text - > > - Show quoted text - Thx in advans, Karthik Balaguru
From: Karthik Balaguru on 7 Feb 2010 11:44 On Feb 7, 6:44 pm, Karthik Balaguru <karthikbalagur...(a)gmail.com> wrote: > On Feb 7, 3:29 pm, David Brown > > > > > > <david.br...(a)hesbynett.removethisbit.no> wrote: > > Michael Schnell wrote: > > > On 07.02.2010 06:12, karthikbalaguru wrote: > > > >> I searched the internet and got few links. > > >>http://answers.google.com/answers/threadview/id/439136.html > > >> Though it discusses about static linking > > >> in LGPL, it does not arrive at a definite > > >> answer ! > > > > Same here and seemingly everywhere ;) > > > > The wording of LGPL seems to require that LGPL coded needs to be > > > upgradeable by the end user. Thus to allow for this with statically > > > Correct... > > > > linked projects, the source code of the complete project needs to be > > > available to the end user. > > > Wrong... > > > The key freedoms of the GPL are that the person who receives the > > software can read the source code, modify it, use the original or > > modified version, and pass on to others the original or modified version > > under the same license. > > > The LGPL aims to provide the same benefits to end users of libraries > > while still being usable with software under other licenses. > > Agreed . It makes it feasible for using the LGPL'ed libraries > with closed source applications/proprietary softwares. > > > If you keep that in mind, it is a lot easier to understand what you are > > and are not allowed to do with the LGPL (and the GPL, for that matter). > > > Very roughly, if your code makes use of an LGPL'ed library, then the end > > user has the right to the source code of the library (including any > > modifications you may have made), and they must be able to modify and > > recompile that library and use your application with the modified > > version of the library. > > True incase of any modifications in the LGPL'ed library > while using with the particular closed source application ! > > > With dynamic linking, this is easy to achieve - > > they can re-compile the library and then just re-load the application. > > This is True in the case of dynamic linking ! > > > With static linking, things are a little more complicated. However, you > > do not have to make your own code available to the end user in a "nice" > > form - it is enough that they can re-link with their modified library. > > Thus you can provide it as linkable object code, or perhaps obfusticated > > source code. > > I have many queries here - > > I think only linkable object code is enough. Won't linkable > object files alone serve the purpose ? Why should the > source code be provided to the end-user ? > Thinking over the same line, the other thought that popped up is, But, If only object files of the application given, how will the LGPL library upgradation get handled ? So, i think to support upgradation, the vendor should provide the source code which is a vendor might not do. So, i think, only dynamic linking is the best solution. But, i am not sure how LGPL is helpful in scenarios in which static linking is only possible. Any ideas to do static linking without providing source code and in the same time support for LGPL library upgradation ? > If source code is mandatory, can you pls elaborate how > can obfusticated code appear ? Is the method of > providing obfusticated approved by LGPL ? > Does any of the closed source vendor follow this approach ? > > > And if you provide real source code, you don't have to use > > the (L)GPL - you can deny any rights other than that the user can > > re-compile and re-link, without allowing them the right to modify or > > distribute your code. > > I think, many closed source vendors will not opt > for this method as the code is exposed to end-user > even though the right to modify is absent. Do any > of the closed software vendor follow this policy > of providing closed source code without the right > to modify ? > > I wonder why LGPL has such a strange policy > as LGPL was to help the closed source softwares > by providing them LGPL'ed libraries so that they > need not reveal the source code, even though > the free software community was also indirectly > enjoying the benefits from LGPL. It seemed to > be a gain for both the communities. > > > > > > > > Are the .h files that come with e.g the dynamically linked libc not > > > released as LGPL ? How to upgrade those ? I don't think anybody ever > > > intended them to only be used with open source software. > > > Header files in LGPL libraries typically have explicit exceptions to > > allow you to use them as you want. Otherwise, any code that #include'ed > > the header file would technically be a derivative of that file (since > > the C pre-processor just joins the files together), and then the (L)GPL > > would cover the whole program. > > > > OTOH, I never found a single notice that LGPL holders requested > > > programmers to open their code for that upgradeablility reason. > > > > -Michael- Hide quoted text - > > > - Show quoted text - > > Thx in advans, > Karthik Balaguru- Hide quoted text - > > - Show quoted text -- Hide quoted text - > > - Show quoted text - Thx in advans, Karthik Balaguru
From: David Brown on 7 Feb 2010 12:16
Michael Schnell wrote: > On 07.02.2010 11:40, Karthik Balaguru wrote: >> But, Why does it not support for dynamically >> linked libraries ? Just eager to know the reason >> for not supporting dynamic linking. > > The compiler needs to support this. The dynamically linked (shared) > libraries need to be loaded into a free spot in memory and at compile > time you can't know where to find this and without an MMU you can't > create a predefined address space for the library. > > One way of doing shared libraries is "PIC" (Position Independent Code). > Not all compilers for all architectures support this. > > or shared libraries not only the code needs to be position independent, > but also static data needs to be unique for each program linking the > library dynamically. > > -Michael ucLinux has no problem with shared libraries: <http://www.ucdot.org/article.pl?sid=03/11/25/1126257> Life is often /easier/ with statically linked libraries on ucLinux systems, and static linking is often more efficient - shared libraries have an overhead in disk/flash space, ram, and run-time. So unless you really are sharing them a lot, or need to update them independently, static linking is smaller and faster. On small embedded Linux systems, you have only a few programs running - sharing libraries brings you few benefits at noticeably costs. But you can happily use shared libraries if you want. I would be very surprised to hear of a cpu architecture that works with ucLinux, yet does not support PIC - and even more surprised to hear of a compiler where the cpu supports PIC but the compiler does not. Certainly gcc will fully support PIC on any ucLinux system, and other compilers are rarely used on such systems. |