Re: [avr-libc-dev] avr-lib-c-extentions library

[David Brown]

Weddington, Eric wrote:
>  
>
> > -----Original Message-----
> > From: 
> > address@hidden 
> > [mailto:address@hidden
> > org] On Behalf Of David Brown
> > Sent: Thursday, January 03, 2008 1:30 AM
> > To: address@hidden
> > Subject: Re: [avr-libc-dev] avr-lib-c-extentions library
> >
> > Weddington, Eric wrote:
> >
> > > > . same license as avr-libc to improve re-usability in closed source
> > > >   projects (that's the major distinction from Procyon AVRlib)
> > > I'm open to having the LGPL license on such a library project.
> > > (Definitely not the GPL, though.) I can be persuaded to 
> > either the BSD
> > > or LGPL license.
> > >
> > > Eric
> > I'm not a lawyer, but I have seen a couple of open source embedded 
> > projects get themselves into trouble by misunderstanding 
> > licenses (the 
> > LGPL in particular).
> >
> > The LGPL is no good for embedded development - it only really differs 
> > from the GPL in that you can dynamically link to a LGPL'ed library 
> > without any restrictions on the license for the rest of your 
> > code.  If 
> > you are linking statically, you must GPL (or LGPL) all your code.
>
> You're going to have to back up your claims on this one. I have never
> seen, nor heard of such a limitation.
>
> FYI, the libgcc library that ships with GCC, and many times gets linked
> into your AVR application, is licensed as LGPL.
>  
> Thanks,
> Eric Weddington

I could not find any reference to the licence for avr-libc, other than 
on the Savannah webpage that says "modified BSD license".  As for 
libgcc, it is *not* LGPL - it is "GPL with the libgcc exception clause" 
which specifically states that code from libgcc can be directly linked 
with your own code regardless of the license.  gcc itself is also under 
the GPL with a similar clause to avoid any questions about code 
generated by gcc.  yacc/lexx/bison and such tools are similar.

As for the LGPL, look at section 4d and 4e at 
http://www.gnu.org/licenses/lgpl.html.  The point of the LGPL is that 
end users should be able to get LGPL source code, modify it, and rebuild 
the executable binary of the application.  On desktops, this is normally 
achieved by having the LGPL'ed library dynamically linked as the program 
is loaded - if you are using static linking, you must provide linkable 
object files (at least) so that the end user can make such modifications 
to the library.  Clearly, this is not an ideal license for embedded AVR 
systems.

I believe there is some disagreement about whether the act of compiling 
and statically linking your code code with LGPL'ed code creates a 
"derived" work, or merely an "aggregate" (i.e., code from two sources 
placed side by side).  The FSF think it is a derived work, while some 
others think it is an aggregate (everyone agrees that it is an aggregate 
when linked dynamically).  But even if it is an aggregate, you must 
still provide some way for the user to be able to modify the LGPL'ed code.

Some links of interest:

http://teem.sourceforge.net/lgpl.html
http://www.ogre3d.org/wiki/index.php/StaticLinking
http://www.fox-toolkit.org/license.html

It can be very difficult to change the license of code at a later date, 
especially if there are many contributors who own the copyrights to the 
code, so it is important to be sure of your licenses at the start.  I 
know it's a pain to have to deal with such non-technical issues, but it 
would be a shame if people were unable to use the library because their 
employer's legal people were not happy with the licensing.

mvh.,

David