Static linking in LGPL, Upgrading LGPL libs - Page 2

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Re: Static linking in LGPL, Upgrading LGPL libs
On Sun, 07 Feb 2010 12:10:21 +0100, Michael Schnell

Quoted text here. Click to load it

In the context of licensing, there is typically only a single instance
of a single program.
Quoted text here. Click to load it

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

Quoted text here. Click to load it

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.


Re: Static linking in LGPL, Upgrading LGPL libs

Quoted text here. Click to load it

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


Re: Static linking in LGPL, Upgrading LGPL libs
Quoted text here. Click to load it

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.

Quoted text here. Click to load it

Thx in advans,
Karthik Balaguru

Re: Static linking in LGPL, Upgrading LGPL libs
Quoted text here. Click to load it

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.


Quoted text here. Click to load it

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.

Quoted text here. Click to load it

Re: Static linking in LGPL, Upgrading LGPL libs
Quoted text here. Click to load it

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

Quoted text here. Click to load it

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


Quoted text here. Click to load it

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


Quoted text here. Click to load it

Any comment on this ?

Thanks,
-Michael

Re: Static linking in LGPL, Upgrading LGPL libs
On Feb 7, 3:20A0%am, Michael Schnell

Quoted text here. Click to load it

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

Re: Static linking in LGPL, Upgrading LGPL libs
Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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.

Re: Static linking in LGPL, Upgrading LGPL libs
On Feb 7, 3:29A0%pm, David Brown
Quoted text here. Click to load it

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

Quoted text here. Click to load it

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

Quoted text here. Click to load it

This is True in the case of dynamic linking !

Quoted text here. Click to load it

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 ?

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

Thx in advans,
Karthik Balaguru

Re: Static linking in LGPL, Upgrading LGPL libs
Quoted text here. Click to load it

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 ?

Quoted text here. Click to load it

Thx in advans,
Karthik Balaguru

Re: Static linking in LGPL, Upgrading LGPL libs

Quoted text here. Click to load it

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

-Michael

Re: Static linking in LGPL, Upgrading LGPL libs
On Sun, 7 Feb 2010 08:44:57 -0800 (PST), Karthik Balaguru

Quoted text here. Click to load it

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

Re: Static linking in LGPL, Upgrading LGPL libs
Quoted text here. Click to load it

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

Re: Static linking in LGPL, Upgrading LGPL libs
On Feb 8, 1:49A0%am, David Brown
Quoted text here. Click to load it

'GPL with exception clause' is interesting.
True that without applying the linking exception,
code linked with GPL code becomes automatically GPL.
Reer - http://en.wikipedia.org/wiki/GPL_linking_exception

LGPL's linking exception appears to be more
customer friendly.

Thx,
Karthik Balaguru

Re: Static linking in LGPL, Upgrading LGPL libs
Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

Re: Static linking in LGPL, Upgrading LGPL libs
On Feb 8, 2:12A0%am, David Brown
Quoted text here. Click to load it

Great !

Quoted text here. Click to load it

Okay.


It appears to be a lot of work !

Quoted text here. Click to load it

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 ?

Quoted text here. Click to load it

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

Quoted text here. Click to load it

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

Quoted text here. Click to load it

Any embedded specific clauses in LGPL
to help embedded systems ?

Thx in advans,
Karthik Balaguru

Re: Static linking in LGPL, Upgrading LGPL libs
Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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

Quoted text here. Click to load it

See below for your answer.

Quoted text here. Click to load it

Re: Static linking in LGPL, Upgrading LGPL libs
Quoted text here. Click to load it

Thats great :-)

Quoted text here. Click to load it

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

Quoted text here. Click to load it

Okay .


Karthik Balaguru

Re: Static linking in LGPL, Upgrading LGPL libs
Quoted text here. Click to load it

The GNU Compiler Collection is intended to be widely used.
A c-compiler without its library is worthless.
That is the reason for LGPL:
  that you can release commercial programs without revealing
  your source code.

It would be a rare c-program that nowhere uses e.g. a malloc or
strcpy. So the malloc going with gcc is not GPL-ed.

One more note:
   If you're using the resulting program internally, the
   GPL imposes no restrictions on you.

From my personal experience:
  I saved a company's cash cow by replacing the compiler
  by gcc. I even modified gcc! But the company didn't
  distribute that gcc, so that is neither here nor there.
  Then we used gcc including its libraries to make
  embedded software for industrial machines worth
  millions of Euro's.
  The competition would be interested to see the source
  code *of the machines* but of course we didn't distribute
  that, and we were in no obligation to do so.
  And no: this is 68000 code in EPROM. No dynamic libraries.

Quoted text here. Click to load it

You shouldn't rely on others. You should just read the LGPL.

A good legal system works this way:
  you as an expert interpret LGPL
  you give expert witness and a judge follows your opinion
  lawyers base action and advice on previous judges rulings

This is how it works now in the US:
  the party with the shallow pockets give in
  there comes a settlement
  this servers as jurisprudence to force judgements in the same
    way
  lawyers are now the only ones who can figure out what to do
    because judgements are no longer effectively based on law

This also undermines the democracy. A parliament makes
written laws that are objective and should apply to everybody.
But those laws are no longer followed.

<SNIP>

Quoted text here. Click to load it


--
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
We've slightly trimmed the long signature. Click to see the full one.

Site Timeline