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: Michael Schnell on 8 Feb 2010 08:57 On 07.02.2010 22:15, David Brown wrote: > > But can you run ucLinux on those architectures? Of course. Same mostly use "Flat" binaries. (AFAIK, you can do linked libraries with flat binaries, but I don't have an example). > > Have you any examples of ucLinux on architectures where gcc cannot > generate PIC? > NIOS2 -Michael
From: karthikbalaguru on 8 Feb 2010 09:01 On Feb 8, 2:12 am, David Brown <david.br...(a)hesbynett.removethisbit.no> wrote: > Karthik Balaguru 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 ? > > Yes, linkable object code is enough - source code in some form is an > alternative. Great ! > You could also use something like an intermediate assembly > file if you wanted. As long as the end user can re-link your code with > their compilation of the library, and produce a working application in > the end, you are fine. > Okay. > Actually, this is not quite enough on its own. You also have to provide > any relevant makefiles or other build details so that the user can > repeat the process. If special tools are required, you may also have to > provide them ("standard" tools are fine - but what counts as "standard" > in the embedded development world? As long as we are talking about > embedded Linux, the answer is easy - gcc. But a general answer is way > beyond what I can give here). > > You may also have to provide things like signing keys or firmware update > procedures - the (L)GPL v. 3 is more explicit about that sort of thing. > It appears to be a lot of work ! > Getting all the details legally and morally right here is not easy - it > is with good reason that the LGPL is considered a bad license for > embedded systems. > Strange that LGPL is bad for embedded systems. I think, embedded systems is one of the domains that might be ever-green ! Any clause/licenses to help embedded systems ? > > If source code is mandatory, can you pls elaborate how > > can obfusticated code appear ? Is the method of > > providing obfusticated approved by LGPL ? > > "Obfusticating" means rendering the code illegible, even though it can > be compiled properly. One method would be to replace all identifiers > with a random sequence of letters. But even something as simple as > using the preprocessor output can make code hard to understand. > But, as others pointed out, i think this is not allowed by LGPL. > > > 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. > > The LGPL was conceived for dynamically linked shared libraries, even > though it is not exclusively limited to them. Embedded systems were > simply not considered at the time. This is interesting ! I wonder why it was not revised after the evolution of embedded systems . Strange ? > And RMS, the author of the GPL and > LGPL, has said he simply does not care about the problems the GPL and > LGPL cause for embedded developers - in his opinion, /all/ source code > should be released and modifiable by the end user, and if someone is so > selfish as to want to keep their source code secret, they deserve all > the problems they get. > > Any embedded specific clauses in LGPL to help embedded systems ? Thx in advans, Karthik Balaguru
From: Michael Schnell on 8 Feb 2010 09:03 On 08.02.2010 06:41, Paul Keinanen wrote: > If the library needs to be used from more than one program, then it > needs to be reentrant, i.e. all modified variables must be in the > stack of the calling program. It does not make much sense to do dynamic linking if the library can't be shared. / Shared (thus reentrant) libraries (theoretically) can use static variables if any dynamic linkage creates a new address space for same. This can be done by means of the MMU or by means of a pointer. I seem to remember that normal PC so's do this. -Michael
From: David Brown on 8 Feb 2010 15:12 Michael Schnell wrote: > On 07.02.2010 22:15, David Brown wrote: > >> >> But can you run ucLinux on those architectures? > > Of course. Same mostly use "Flat" binaries. (AFAIK, you can do linked > libraries with flat binaries, but I don't have an example). > The final linking is done by the link-loader when you start a program or load a shared library into memory, so with ucLinux's flat binaries you don't need PIC to run software or to use shared libraries. You will need PID if the shared library has to keep track of application-specific data, however. Where PIC is important is for XIP binaries - execute in place - which run from flash. These are not loaded into ram, and thus the link-loader can't patch in addresses. >> >> Have you any examples of ucLinux on architectures where gcc cannot >> generate PIC? >> > > NIOS2 > Fair enough. The Nios2 gcc port is out-of-tree, and won't support features that Altera don't see as important, making it a little more limited than mainline targets. But I accept your point here.
From: David Brown on 8 Feb 2010 15:17
karthikbalaguru wrote: > On Feb 8, 2:12 am, David Brown > <david.br...(a)hesbynett.removethisbit.no> wrote: >> Karthik Balaguru 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 ? >> Yes, linkable object code is enough - source code in some form is an >> alternative. > > Great ! > >> You could also use something like an intermediate assembly >> file if you wanted. As long as the end user can re-link your code with >> their compilation of the library, and produce a working application in >> the end, you are fine. >> > > Okay. > >> Actually, this is not quite enough on its own. You also have to provide >> any relevant makefiles or other build details so that the user can >> repeat the process. If special tools are required, you may also have to >> provide them ("standard" tools are fine - but what counts as "standard" >> in the embedded development world? As long as we are talking about >> embedded Linux, the answer is easy - gcc. But a general answer is way >> beyond what I can give here). >> >> You may also have to provide things like signing keys or firmware update >> procedures - the (L)GPL v. 3 is more explicit about that sort of thing. >> > > It appears to be a lot of work ! It is also a lot of work to develop the code yourself, or to earn enough money to be able to buy commercially licensed code for the same purpose. Just because something costs zero dollars, does not mean it is zero cost :-( When you choose your software components, you have to take these things into account and find a balance that suits your needs and your project. > >> Getting all the details legally and morally right here is not easy - it >> is with good reason that the LGPL is considered a bad license for >> embedded systems. >> > > Strange that LGPL is bad for embedded systems. > I think, embedded systems is one of the domains > that might be ever-green ! > > Any clause/licenses to help embedded systems ? > >>> If source code is mandatory, can you pls elaborate how >>> can obfusticated code appear ? Is the method of >>> providing obfusticated approved by LGPL ? >> "Obfusticating" means rendering the code illegible, even though it can >> be compiled properly. One method would be to replace all identifiers >> with a random sequence of letters. But even something as simple as >> using the preprocessor output can make code hard to understand. >> > > But, as others pointed out, i think this is not allowed > by LGPL. > "Obfusticated" code is not considered "source code", nor is any intermediary code (for example, if you are using something that generates C code from a higher level language, the C code does not count as "source code"). Thus it does not satisfy the requirements of the GPL. But it is, as far as I can tell, good enough as the equivalent of linkable object code. >>> 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. >> The LGPL was conceived for dynamically linked shared libraries, even >> though it is not exclusively limited to them. Embedded systems were >> simply not considered at the time. > > This is interesting ! > I wonder why it was not revised after the > evolution of embedded systems . Strange ? > See below for your answer. >> And RMS, the author of the GPL and >> LGPL, has said he simply does not care about the problems the GPL and >> LGPL cause for embedded developers - in his opinion, /all/ source code >> should be released and modifiable by the end user, and if someone is so >> selfish as to want to keep their source code secret, they deserve all >> the problems they get. >> >> > > Any embedded specific clauses in LGPL > to help embedded systems ? > > Thx in advans, > Karthik Balaguru |