On Thu, Dec 22, 2005 at 09:38:08PM -0600, Tad Anhalt wrote:
> Wouter van Ooijen wrote:
> > It allows any form of linking, but when you link statically it requires
> > you to publice the code (your code!) you link against it. I don't know
> > any commercial license that imposes any requirement on code you link
> > with the licensed code.
> 
>    _My understanding_ of the situation is that the act of linking itself 
> is what LGPL allows.  Static/dynamic isn't the issue except that there 
> must be a way provided to re-link with (a) different version(s) of the 
> LGPL library(s).

Correct. The arugment is that the relink requirement allows the library
to remain "free" and updatable by the end user.

Personally I find it cumbersome to follow for embedded systems work.

>    Dynamic linking allows the end-user to replace the shared object 
> (so/dll/whatever) directly and therefore meets this requirement by 
> default. 

Bingo.

> Static linking does not meet the requirement by default and in 
> this case, the developer has to provide this functionality.  That may be 
> as simple as providing the (proprietary) object file separately in 
> addition to the linked version or even just the object file itself with 
> the assumption that it will be linked by the party you are distributing 
> the (still proprietary) compiled code to.

All on point.

One missing point is that it's the devlopers responsibility to provide the
end user whatever tools required to make the relink, including propietary
compilers and linkers.

As I said it's too cumbersome.

>    Libraries that are under GPL don't allow any linkage at all (for 
> proprietary code) and, frankly, the license doesn't try to hide that 
> fact.  In fact, the verbiage is surprisingly blunt on that point.

Which makes GPL libraries rare indeed. Any applications code written to
use such a library would have to be GPL. While that's probably Stallman's
desire, most resonable folks would find it to be overboard.

>    The extra wrinkle with glibc is that it specifically removes the 
> requirement for re-linking support.  glibc++ has a different exception 
> entirely that is AFAICT supposed to provide the same results when the 
> situation is complicated with lots of inlined code (eg: templates).
> 
>    Don't take my word for it though.  I've probably missed something 
> critical and should be roasted over high heat. YMMV, etc, etc.

I think your points are on point.

[snip]

>    To more directly answer the indirect question posed, there doesn't 
> appear to be anything distributed with gcc that would require you to 
> distribute your source code just through the act of compiling it using 
> the included tools.  There is actually a FAQ entry that states the same 
> thing on the FSF page.

Right. Now there was a time when bison/flex output was GPL code. But
even that restriction has been relaxed.

>    Going one step further, I don't recall ever seeing a GPLed library 
> that didn't have huge warnings all over the place letting you know not 
> to link it into proprietary code so it's not clear to me where the 
> problem comes in ?

My question is why would someone make a library GPL if you really wanted
folks to use it? Stallman argues GPL domination here:

http://www.gnu.org/licenses/why-not-lgpl.html

"Using the ordinary GPL for a library gives free software developers an
advantage over proprietary developers: a library that they can use, while
proprietary developers cannot use it."

He posits that the LGPL is for common libraries. But for uncommon ones:

"However, when a library provides a significant unique capability, like GNU
Readline, that's a horse of a different color."

The zealotry definitely bleeds through. I don't buy it. I take the more
moderate stance that everyone should contribute to the community code but
they can do what they want with their own personal code and the combinations
of community and personal code (for Wouter: regardless of the method of
combination).

>    My comments on this thread are solely from the perspective of a 
> developer attempting to satisfy standard professional due-diligence into 
> licensing issues.  Please don't make assumptions based on what I've said 
> here about my position on what you should or shouldn't do with your 
> code, personal feelings on the FSF, etc.

Great job. I really appreciate it.

>    In other words, it looks like this thread is dying and I really don't 
> want to unnecessarily prolong it.  I would be very interested in 
> reasoned critiques of where I've gone wrong in my interpretation though.

Nothing wrong AFAICT.

BAJ
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist