[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: Thu, 03 Jan 2008 09:29:32 +0100
User-agent: Thunderbird (Windows/20071031)

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. Sometimes you can put together a half-way solution involving distribution of linkable object files as a way of obeying the letter of the LGPL law while avoiding its spirit, but that's no help to anyone.

I would say that often the best license for open source embedded systems libraries is either an explicitly modified GPL or an existing license in the same spirit (such as the MPL or the CDDL - although these have a few extra clauses). What you want is a license that says basically:

This code is under the GPL with the modification that you may statically link the modified GPL code with any other code under any other license. This code may also be relicensed under the standard GPL.

Thus developers can use the library freely along with their own code, but any changes they make to the library code itself must be made available - effectively, it should be passed back to the community. This is the route taken for the www.freertos.org project, for example. The MPL (and the derived CDDL) cover much the same things, but have a few extra clauses (software patent junk, for those unfortunate enough to live in the USA and have to deal with that sort of problem), and they are technically incompatible with the GPL. Firefox and friends solve the problem by being triple-licensed under the MPL/GPL/LGPL.

Alternatively, if you are happy for users to modify the library code without contributing their changes (except voluntarily, of course), then a simple BSD license is probably the way to go.



reply via email to

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