[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: David Brown
Subject: Re: [avr-libc-dev] avr-lib-c-extentions library
Date: Fri, 04 Jan 2008 10:22:23 +0100
User-agent: Thunderbird (Windows/20071031)

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.


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


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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]