Weddington, Eric wrote:
-----Original Message-----
From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
org] On Behalf Of David Brown
Sent: Thursday, January 03, 2008 1:30 AM
To: [email protected]
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
_______________________________________________
AVR-libc-dev mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
