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: Jon Kirwan on 7 Feb 2010 12:46 On Sun, 7 Feb 2010 08:44:57 -0800 (PST), Karthik Balaguru <karthikbalaguru79(a)gmail.com> wrote: ><snip> >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 ? ><snip> I'm also interested in reasoned answers to this question. I _write_ library routines, on occasion, which I'd like to make available fairly freely -- for no-cost commercial use as well as private/personal hobbyist use. In my case, I'm interested in licenses to consider and a description of trade-offs that I can gather and understand, more than a solution that solves the specific LGPL issue, since I can choose as I want what license to apply. An example is that I submitted a fast, LGPL licensed, floating point division routine for the 8051 core facet of SDCC. (I've no idea how to actually get it included in the distribution others may see, so that is yet another thing to learn about.) However, I hadn't bothered to go read the license in detail, reading instead a web page with its own discussion recommending it for situations that _sounded_ to me similar to what I wanted, and later uncovered the fact talked about here. I'd like to change it now, but don't know what fits my interest better. Rather than licensing it 6 ways to Sunday before finally figuring out which fits better someday, I wouldn't mind an education first so that I can make one more license update that is a reasoned one. I've looked at some of the BSD licenses, the wiki page on free licenses, Apple's APSL, the Apache licenses, and a bevy of other "suggestions" but still haven't decided how to weigh the choices well or what they emphasize. Many of these are targeted at very specific "desires" that aren't so much my own concerns. I'm not even entirely sure what concerns _should_ be my concerns, though I can think of a few. Hire an attorney just to give away source code? Not likely. So, I'd enjoy hearing some discussion. Jon
From: Michael Schnell on 7 Feb 2010 07:48 On 07.02.2010 18:16, David Brown wrote: > ucLinux has no problem with shared libraries: Not uClinux itself, but the gcc for some architectures just doesn't support it. -Michael
From: David Brown on 7 Feb 2010 15:49 Jon Kirwan wrote: > On Sun, 7 Feb 2010 08:44:57 -0800 (PST), Karthik Balaguru > <karthikbalaguru79(a)gmail.com> wrote: > >> <snip> >> 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 ? >> <snip> > > I'm also interested in reasoned answers to this question. I > _write_ library routines, on occasion, which I'd like to make > available fairly freely -- for no-cost commercial use as well > as private/personal hobbyist use. In my case, I'm interested > in licenses to consider and a description of trade-offs that > I can gather and understand, more than a solution that solves > the specific LGPL issue, since I can choose as I want what > license to apply. > > An example is that I submitted a fast, LGPL licensed, > floating point division routine for the 8051 core facet of > SDCC. (I've no idea how to actually get it included in the > distribution others may see, so that is yet another thing to > learn about.) However, I hadn't bothered to go read the > license in detail, reading instead a web page with its own > discussion recommending it for situations that _sounded_ to > me similar to what I wanted, and later uncovered the fact > talked about here. I'd like to change it now, but don't know > what fits my interest better. Rather than licensing it 6 > ways to Sunday before finally figuring out which fits better > someday, I wouldn't mind an education first so that I can > make one more license update that is a reasoned one. > > I've looked at some of the BSD licenses, the wiki page on > free licenses, Apple's APSL, the Apache licenses, and a bevy > of other "suggestions" but still haven't decided how to weigh > the choices well or what they emphasize. Many of these are > targeted at very specific "desires" that aren't so much my > own concerns. I'm not even entirely sure what concerns > _should_ be my concerns, though I can think of a few. > > Hire an attorney just to give away source code? Not likely. > So, I'd enjoy hearing some discussion. > > Jon It's a bad idea to pick a license because it's a common license, and some rough reading of web pages make it sound okay. There are endless numbers of libraries (and embedded development examples) that the author has given out under the GPL "so that others can use it however they want in their projects". When deciding on a license for your code, I would first make an absolutely clear statement of your intentions. This should be prominently displayed on the web page hosting your code, and should be included (or referred to) in each file. The great majority of potential users are honest and respectful - they will honour your wishes here, and it's a lot easier to do that when your wishes are in clear English rather than legalise. For those that will knowingly violate your wishes, there are three categories depending on their country and legal system. If the violator is in the USA, you will lose regardless of what license you have used. Unless your code is "big" enough to get the backing of the FSF, you simply don't have enough money to win regardless of who is wrong or right. If the violator is in Europe, a clear statement of your wishes will count heavily in your favour in any small claims court - these are designed to help "little people" against large companies. If the violator is in the far east, you'll never know about it, and have no way of pursuing the matter even if you do learn of it. As for the license itself, I'd recommend a "GPL with exception clause". Look at FreeRTOS for an example. With such a license, the code /you/ have written is under the GPL, as are any derivative files. But any files and modules the user has written are considered independently licensed. This really gives you the benefits of the GPL while leaving the user free to include the code in their closed source programs (statically linked, and without any requirements for the user to be able to update the software). Any modifications the developer makes to /your/ code have to be released according to the GPL requirements. The Mozilla Public License (MPL), used by Firefox etc., is basically the same, but with different details regarding things like copyright notices. But I'd recommend starting off looking at the FreeRTOS example: <http://www.freertos.org/index.html?http://www.freertos.org/a00114.html>
From: Michael Schnell on 7 Feb 2010 07:55 On 07.02.2010 17:44, Karthik Balaguru wrote: >> I wonder why LGPL has such a strange policy I suppose they just did not consider statical linking... -Michael
From: David Brown on 7 Feb 2010 16:12
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. 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. 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. 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. > 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. > Does any of the closed source vendor follow this approach ? > I don't know whether anyone does it when providing code to work with the LGPL - in real world situations, you typically use dynamic linking and thus there is no problem. I do know that obfusticated code has been used as a way of "getting around" the GPL - with the GPL, it is clearly against the spirit of the license and perhaps against the letter since it is not the real source code. >> 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 ? > Closed source vendors provide source code under all sorts of different licenses and conditions. I don't see this as any different, though I know of no examples. > 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. 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. >>> 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 |