AVR library for LCD and 1wire?

On Mon, 31 Jan 2005 19:20:24 +0200, Anton Erasmus wrote:

> On Mon, 31 Jan 2005 09:38:41 +0100, David
> <david.nospam@westcontrol.removethis.com> wrote:
> 
>>For the GPL, that much is reasonably well known.  The LGPL is subtely
>>different, and many people (including the O/P) don't fully understand the
>>difference.  The LGPL was made specificly for libraries on "big" systems
>>with shared libraries.  You can treat the LGPL'ed code much like GPL'ed
>>code, or you can *dynamicly* link it to code under any other license (the
>>headers of LGPL'ed libraries are excepted from the license).  The idea is
>>that if you sell me a closed-source binary using an LGPL'ed library, I can
>>update that library and re-link the program to use the new version of the
>>library.  For programs in "big" systems with dynamic library loading,
>>there is no problem.  For embedded systems (using static linking), it's a
>>great hassle if you want to keep your code hidden.
>>
> 
> This does not exclude the use of LGPL'd code in smaller systems. If
> one writes a small wrapper for the library, which basically allows the
> rest of one's firmware to be able to find out via the wrapper code
> where all the library routines are, then the library (+wrapper code)
> can be updated without having to re-load or link the main firmware
> code. AFAICS this satisfies the LGPL license. The wrapper code
> must of course be made available. I think such a open source wrapper
> with a suitable license would actually be quite usefull.
> 
> I have done a similar thing in the past where I kept my own library
> code in a seperate EPROm, from my main code which was still being
> written. This was done to speed up download time. I was downloading
> s-records over a 9600 serial link. Total program size was almost 500K,
> so it took forever. By keeping the debugged library code in a library
> I cut the average download size to about 30K of code.
> 
> Any errors in my reasoning regarding the LGPL license ?
> 

As far as I can see, you are effectively implementing a system of dynamic
linking, which (by my understanding) is LGPL-compatible.

> Regards
>    Anton Erasmus

David wrote:
> I'm not a lawyer, but I've done my best to read the LGPL and the GPL.  My
> comments to your reply are found below, and are my interpretations of what
> I've read.  It is quite possible that I'm wrong, and I'm happy to be
> corrected if I am, but I've had no luck finding any sort of "definitive"
> answers.  I'm confident I understand the rights and responsibilities that
> follow the use of GPL'ed code, and also the use of BSD-style, MPL-style,
> and the various explicitly modified licenses that are typically used for
> libraries such as the avr-libc.  I'm far from sure about the LGPL,
> however, and if I wanted to use LGPL'ed code in an embedded system, I'd
> ask the author regarding his/her intentions and wishes.  (Use on
> dynamically linked systems is another matter.)

[...]

> 
> There is no problem with supplying source copies of the libraries,
> including any changes made to the libraries (such changes are "derivitive
> works" of the library, and therefore also LGPL'ed).  The question is about
> code from the "work that uses the Library", as the LGPL calls it.  That
> code (i.e., your application code) is per se not affected by the LGPL. 
> However, to quote from paragraph 5:
> 
> 	 However, linking a "work that uses the Library" with the Library creates
> 	 an executable that is a derivative of the Library (because it contains
> 	 portions of the Library), rather than a "work that uses the library".
> 	 The executable is therefore covered by this License. Section 6 states
> 	 terms for distribution of such executables.
> 
> Section 6 gives two basic ways to fullfill the LGPL requirements when you
> distribute your executable linked with the library - you can a) provide
> your code "as object code and/or source code, so that the user can modify
> the Library and then relink to produce a modified executable containing
> the modified Library", or you can b) use a suitable shared library
> mechanism.  As with the GPL, you can also simply include a written offer
> to provide the object/source code on request.
> 
> Given that the compiler and linker for embedded systems are typically not
> included in the target's operating system, section 6 also requires that
> these be made available.  If you are not able to distribute them (for
> example, if they are proprietry applications), then you can't use 6a), and
> must use some sort of dynamic linking.
> 
>

You are correct. If a linking utility for the executable is not free, then
static linking may be a problem for you. If a linking utility is free, there
is no problem.

>>>The effects will depend on your market and your product.  If you are
>>>working with "big" systems (say, ucLinux or pc software), there is no
>>>problem.  If the cost is in the hardware, or you are (for other reasons)
>>>quite happy to release your software code, then there is no problem.  If
>>>you are sure your market is highly unlikely ever to read or take up your
>>>written offer of the source code, then you have no problem. But in many
>>>cases, it's an extra layer of complexity that you really don't want, and
>>>you should therefore think just as hard about using LGPL'ed code as GPL'ed
>>>code.
>>>
>>
>>I think you have projected your biases on this topic.
>>
> 
> 
> What biases do you think I have?  I am a heavy user of open source
> software, and a heavy user of closed source software.  I believe there is
> a place for a variety of licenses, just as there is a place for a variety
> of programming languages and processor architectures.  There is also a
> place for the LGPL, including in embedded systems, as long as users
> remember that with staticly linked systems it is effectively the same as
> the GPL.
> 
> 
>>Why would I publish under the LGPL?
>>
>>*) Want to receive credit
>>*) Want to get back any improvements that someone makes
>>*) Don't want to publish under GPL (scare people off)
>>*) Trust the LGPL to do this
>>
> 
> 
> Sure - there are plenty of good reasons for choosing the LGPL.  When you
> write your code, you are absolutely free to choose the license you want. 
> But if you write an AVR library for using one-wire devices and license it
> under the LGPL, then you will effectively require users to open-source
> (GPL, LGPL, or a number of other licenses) their application code as well
> as their modifications to your library.  If that's what you want, then

This is not the case for gcc-avr, in which a linking utility is free.

> that's fine - as long as both you and your users are aware of this.  If
> you want only to require publishing of changes to your library code rather
> than the complete application code, then choose a different license, such
> as the MPL, or write an exception clause.
> 
> 

[...]