Re: Static linking in LGPL, Upgrading LGPL libs

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

formatting link
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

Reply to
Karthik Balaguru
Loading thread data ...

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

Reply to
Michael Schnell

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

-Michael

Reply to
Michael Schnell

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

-Michael

Reply to
Michael Schnell

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.

d

Thx in advans, Karthik Balaguru

Reply to
Karthik Balaguru

n
d
d

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

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

Reply to
David Brown

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

Reply to
Jon Kirwan

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:

Reply to
David Brown

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.

Reply to
David Brown

But can you run ucLinux on those architectures?

For example, you can't generate position independent code with gcc for the AVR, but that's because there is no natural way to run PIC on that architecture, and very few practical uses of it if there were (and you certainly can't run ucLinux on it, being an 8-bit cpu).

Have you any examples of ucLinux on architectures where gcc cannot generate PIC?

Reply to
David Brown

Linkable object files are sufficient. The LGPL (v2.1) specifically lists one of the options as:

a) Accompany the work with the complete corresponding machine-readable source code for the Library including whatever changes were used in the work (which must be distributed under Sections 1 and 2 above); and, if the work is an executable linked with the Library, with the complete machine-readable "work that uses the Library", as object code and/or source code, so that the user can modify the Library and then relink to produce a modified executable containing the modified Library. (It is understood that the user who changes the contents of definitions files in the Library will not necessarily be able to recompile the application to use the modified definitions.)

Version 3 goes further for a "User Product", including a more general requirement that you provide sufficient information to enable the user to replace the combined work (e.g. if the device requires firmware updates to be digitally signed, you have to provide a suitable signing key).

You only have to provide source code for the library, not for your own code which is not derived from the library.

Obfuscated source code is not considered source code by the LGPL or GPL:

"Source code" for a work means the preferred form of the work for making modifications to it.

IOW, source code would be the form that you actually use; an intermediate form isn't sufficient, even if it compiles to the same object code.

What's strange about it? One of the fundamental principles of the GPL and LGPL is that the user is entitled to modify the code. If you provide a statically-linked binary, the user is unable to modify any of it, even the LGPL parts.

Reply to
Nobody

They certainly did. The LGPL specifically addresses both dynamic and static linking, saying (roughly) that if you don't use dynamic linking, you need to provide "linkable" object code.

The point is that the user has a right to use a modified copy of an LGPL'd library in place of the original.

Reply to
Nobody

In the context of licensing, there is typically only a single instance of a single program.

The PIC is useful, if there are several libraries from various vendors, but when the libraries are from a single vendor, it should be easy to link each library to a fixed and publicly known start address. Typically a function start address table is loaded at that address, followed by the actual library routine codes.

When linking the main program, reserve the space required by the library and provide small stub routines to perform an indirect indexed jump through the jump table (which is in a publicly known address).

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.

For architectures that do not easily support stacks, the library code may require some program instance ID parameter, so that the library can use different data sets for each program.

Reply to
Paul Keinanen

u
"

ed

Thats great :-)

e

Interesting ! Good snapshot of the relevant section of the license .

o

Okay .

for

a
e

Karthik Balaguru

Reply to
karthikbalaguru

Of course. Same mostly use "Flat" binaries. (AFAIK, you can do linked libraries with flat binaries, but I don't have an example).

NIOS2

-Michael

Reply to
Michael Schnell

on

e
.

nd

u
"

ed

Great !

Okay.

e
o

It appears to be a lot of work !

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 ?

But, as others pointed out, i think this is not allowed by LGPL.

This is interesting ! I wonder why it was not revised after the evolution of embedded systems . Strange ?

Any embedded specific clauses in LGPL to help embedded systems ?

Thx in advans, Karthik Balaguru

Reply to
karthikbalaguru

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

Reply to
Michael Schnell

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.

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.

Reply to
David Brown

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.

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

See below for your answer.

Reply to
David Brown

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.