Static linking in LGPL, Upgrading LGPL libs

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 linked projects, the source code of the complete project needs to be available to the end user.

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.

OTOH, I never found a single notice that LGPL holders requested programmers to open their code for that upgradeablility reason.

-Michael

If the source code of the complete project needs to be given to the end user , then how is it different from GPL ?

Wasn't LGPL introduced so that the proprietary software can use the free library features instead of opting for other alternative libraries that provide similar feature ? Wasn't it indirectly saving the free softwares ?

From one of the link in internet, i understand that incase a library provides a unique capability and there is no competitor, then that library might be released under GPL so that it would bring in the GPL terms to the application using it and thus that application will be available freely just because it has to use that unique library.

I think, if it is dynamically linked, there is no problem either for upgradation.

Interesting ! Does this hold true even for closed source applications that statically liked the LGPL libraries ? Any ideas ?

Thx in advans, Karthik Balaguru

It doesn't. You just completely blew out the context. The context was the case where the binary is only available statically-linked to the library and provides no way to replace it. In that one specific case, then you have to give the source code the complete statically-linked object.

But you can also make the program available both statically-linked and dynamically-linked. Or you can make the program available only dynamically-linked to the library. Or you can make it available statically-linked, but with hooks so it can (at run time) use a dynamically-linked version instead. Or you can ship the object files so the user can link it to a different version to make a new statically-linked version. Or a million other things.

Yes.

DS

You can't if the build system does not allow for dynamically linked libraries. This is the case with many (embedded) uCLinux Architectures.

-Michael

So, in this specific case (LGPL based libaries), the person has to give only the complete statically-linked object files and not the closed source code of the project.

Thx in advans, Karthik Balaguru

Correct...

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.

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. With dynamic linking, this is easy to achieve - they can re-compile the library and then just re-load the application.

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. 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.

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.

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 :-

------------- "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

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

Sounds like a nasty hack. IMHO this can't be compatible with the spirit of any GNU developer.

Yep. But I don't think this was meant by the OP, he asked about "if the source code of the application has to be given".

Everybody just assumes this, but most don't exactly know about it. Thanks for the clarification !

Any comment on this ?

Thanks,

-Michael

Not uClinux itself, but the gcc for some architectures just doesn't support it.

-Michael

I suppose they just did not consider statical linking...

-Michael

Agreed . It makes it feasible for using the LGPL'ed libraries with closed source applications/proprietary softwares.

True incase of any modifications in the LGPL'ed library while using with the particular closed source application !

This is True in the case of dynamic linking !

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 ?

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.

Thx in advans, Karthik Balaguru

The spirit of the LGPL is quite specifically that you can obtain the source code to the library, modify the source code to the library, and make use of that modified source code the same way the original was used.

DS

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 ?

'ed

Thx in advans, Karthik Balaguru

ucLinux has no problem with shared libraries:

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.

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

In this particular situation, obfusticated source code is perfectly reasonable, and arguably better than just linkable object code (since the user can take advantage of better compilers as well as newer library versions). The author who used the LGPL asks people to keep the library itself free, and to allow end users to update or modify that library for use with application code. He doesn't ask you to reveal your own code, or give anyone else access to it - if he wanted that, he'd have used the GPL.

It is explicitly stated in the LGPL, as long as you are talking about standard C header stuff (constants, typedefs, macros, small inline functions, etc.).

It is perhaps worth noting that if you were talking about a typical C++ library header file with significant class definitions, it may not be covered here - without an explicit exception given by the library copyright owner, your own code that uses it may count as a "derivative work" and have to be released under the (L)GPL.

I've not heard of any such cases either, but that's no proof that there are no such cases. However, I would except that most LGPL library authors are willing to accept a somewhat looser interpretation of the license than many GPL authors - often their main aim is that people can use the library as they wish, but must release any changes they make to the library back to the public. Another point is that it is probably much harder to prove such cases than for GPL violations, and thus conflicts are more likely to be settled in private.

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:

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.

"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.

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.

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.

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.