Reply by Second Amendment Loves You February 1, 20052005-02-01
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. > >
[...]
Reply by David February 1, 20052005-02-01
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
Reply by David February 1, 20052005-02-01
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.)


On Mon, 31 Jan 2005 17:36:29 +0000, Bryan Hackney wrote:
> David wrote: >> On Sat, 29 Jan 2005 02:07:10 +0000, Bryan Hackney wrote: >> >> >>>David wrote: >>> >>>>On Fri, 28 Jan 2005 11:27:50 +0100, Roland Zitzke wrote: >>>> >>>> >>>> >>>>>Hi, >>>>>I am looking for a library written in GNU C for the AVR which supports >>>>>HD44780 LCDs in 8-bit port mode, 1wire (Dallas) and UART. The library will >>>>>be used in a commercial project and should therefore be LGPLed or simmilar >>>>>license. >>>> >>>> >>>>If it's for a commercial (or otherwise closed-source) project, you can't >>>>use LGPL'ed software without a lot of hassle (involving providing unlinked >>>>object files instead of source files). Suitable licenses are >>>>typically either BSD-style, or modified GPL/LGPL/MPL (with a specific >>>>allowance for linking to closed source embedded software). >>>> >>> >>>Suppose you found something appropriate for the One-Wire protocol and the target >>>micro, which is highly unlikely, and suppose it was LGPL, and suppose you understood > > Oops, looks like it was not so unlikely. > >>>the LGPL and did not have any nervous legal types on staff. Would it really be a >>>hassle to comply with the LGPL? >>> >>>I see this opinion around here, and I don't understand it. Also the likelihood >>>of being asked for code and objects is very small for black box products, but I >>>would suggest being preemptive and posting it in a dark corner of your web site. >> >> >> How much of an issue it would be depends very much on the circumstances. >> If you include GPL'ed code directly in your application, then you have to >> make the entire source code available to anyone to whom you have provided >> binaries. That doesn't mean you have to make it freely downloadable from >> your website to anyone who wants it, but you have to include a written >> notice valid for three years along with the system you are selling or >> giving away, and charge no more than a reasonable distribution cost. >> >> For the GPL, that much is reasonably well known. The LGPL is subtely > > Not subtle at all. Very big difference. > >> 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 > > LGPL does not make a distinction between big and small systems, and it > explicitly says it does not make a distinction between static and dynamic > linking. >
Paragraph 6b of http://www.gnu.org/copyleft/lesser.html explicity describes using "a suitable shared library mechanism for linking with the Library". It doesn't distinguish "big" and "small" systems - that's just my way of drawing a line between embedded systems with staticly linked programs, and systems with dynamic library loading and linking.
>> 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. > > It's quite likely that the end user cannot make use of any libraries you > supply under the LGPL. That's not your problem. > > Where is the hassle? Why is supplying the libraries that you yourself > received as a 'gift' so much of a problem? Just post it on your website. >
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.
>> >> 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 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.
> If I publish under the LGPL and offer something of value for "free", > or even for sale, I can't help anyone who cannot be bothered to understand > the LGPL. > > Myself, I hate lawyers and legal speak, and believe all laws and contracts > should be transparent to everyone. If there is a gotcha somewhere, I would
Indeed - I much prefer licenses such as the avr-libc license at http://www.nongnu.org/avr-libc/LICENSE.txt which begins: The contents of avr-libc are licensed with a Modified BSD License. All of this is supposed to be Free Software, Open Source, DFSG-free, GPL-compatible, and OK to use in both free and proprietary applications. I am happier considering the intentions of the license than trying to understand the fine print. The intentions of the LGPL are quite clear - if you use an LGPL'ed library in your application, you must allow the end user to modify the library and use the modified library with that application.
> be pissed and renege on whatever I though I was offering under a simple > language license. I would recommend everyone else do the same. I would > claim deceit and make things right in another way. But this is not going > to happen, or it would have happened before now. > > I think the LGPL is a lot clearer and safer than many bought, non-free > library licenses, but you are welcome to you opinions, of course.
The LGPL may be clearer and safer than some non-free licenses, but that doesn't make it clear or safe. There are other open licenses that are better for use in embedded systems.
Reply by Bryan Hackney January 31, 20052005-01-31
Bryan Hackney wrote:
[...]
> > Myself, I hate lawyers and legal speak, and believe all laws and contracts > should be transparent to everyone. If there is a gotcha somewhere, I would > be pissed and renege on whatever I though I was offering under a simple > language license. I would recommend everyone else do the same. I would > claim deceit and make things right in another way. But this is not going > to happen, or it would have happened before now. >
I realize I mixed a couple of things here. One, as a publisher under the LGPL, it is your responsibility to understand what you are doing. The LGPL is a document you can use - it owes you nothing. Another, as a user of a library, if you feel you have been tricked into something, such as unintentionally obligating yourself to publishing source code that you did not want to, call bullsh*t and start over from there. But that's just not going to happen. [...]
Reply by Bryan Hackney January 31, 20052005-01-31
David wrote:
> On Sat, 29 Jan 2005 02:07:10 +0000, Bryan Hackney wrote: > > >>David wrote: >> >>>On Fri, 28 Jan 2005 11:27:50 +0100, Roland Zitzke wrote: >>> >>> >>> >>>>Hi, >>>>I am looking for a library written in GNU C for the AVR which supports >>>>HD44780 LCDs in 8-bit port mode, 1wire (Dallas) and UART. The library will >>>>be used in a commercial project and should therefore be LGPLed or simmilar >>>>license. >>> >>> >>>If it's for a commercial (or otherwise closed-source) project, you can't >>>use LGPL'ed software without a lot of hassle (involving providing unlinked >>>object files instead of source files). Suitable licenses are >>>typically either BSD-style, or modified GPL/LGPL/MPL (with a specific >>>allowance for linking to closed source embedded software). >>> >> >>Suppose you found something appropriate for the One-Wire protocol and the target >>micro, which is highly unlikely, and suppose it was LGPL, and suppose you understood
Oops, looks like it was not so unlikely.
>>the LGPL and did not have any nervous legal types on staff. Would it really be a >>hassle to comply with the LGPL? >> >>I see this opinion around here, and I don't understand it. Also the likelihood >>of being asked for code and objects is very small for black box products, but I >>would suggest being preemptive and posting it in a dark corner of your web site. > > > How much of an issue it would be depends very much on the circumstances. > If you include GPL'ed code directly in your application, then you have to > make the entire source code available to anyone to whom you have provided > binaries. That doesn't mean you have to make it freely downloadable from > your website to anyone who wants it, but you have to include a written > notice valid for three years along with the system you are selling or > giving away, and charge no more than a reasonable distribution cost. > > For the GPL, that much is reasonably well known. The LGPL is subtely
Not subtle at all. Very big difference.
> 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
LGPL does not make a distinction between big and small systems, and it explicitly says it does not make a distinction between static and dynamic linking.
> 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.
It's quite likely that the end user cannot make use of any libraries you supply under the LGPL. That's not your problem. Where is the hassle? Why is supplying the libraries that you yourself received as a 'gift' so much of a problem? Just post it on your website.
> > 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. 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 If I publish under the LGPL and offer something of value for "free", or even for sale, I can't help anyone who cannot be bothered to understand the LGPL. Myself, I hate lawyers and legal speak, and believe all laws and contracts should be transparent to everyone. If there is a gotcha somewhere, I would be pissed and renege on whatever I though I was offering under a simple language license. I would recommend everyone else do the same. I would claim deceit and make things right in another way. But this is not going to happen, or it would have happened before now. I think the LGPL is a lot clearer and safer than many bought, non-free library licenses, but you are welcome to you opinions, of course.
Reply by Anton Erasmus January 31, 20052005-01-31
On Mon, 31 Jan 2005 09:38:41 +0100, David
<david.nospam@westcontrol.removethis.com> wrote:

>On Sat, 29 Jan 2005 02:07:10 +0000, Bryan Hackney wrote: > >> David wrote: >>> On Fri, 28 Jan 2005 11:27:50 +0100, Roland Zitzke wrote: >>> >>> >>>>Hi, >>>>I am looking for a library written in GNU C for the AVR which supports >>>>HD44780 LCDs in 8-bit port mode, 1wire (Dallas) and UART. The library will >>>>be used in a commercial project and should therefore be LGPLed or simmilar >>>>license. >>> >>> >>> If it's for a commercial (or otherwise closed-source) project, you can't >>> use LGPL'ed software without a lot of hassle (involving providing unlinked >>> object files instead of source files). Suitable licenses are >>> typically either BSD-style, or modified GPL/LGPL/MPL (with a specific >>> allowance for linking to closed source embedded software). >>> >> >> Suppose you found something appropriate for the One-Wire protocol and the target >> micro, which is highly unlikely, and suppose it was LGPL, and suppose you understood >> the LGPL and did not have any nervous legal types on staff. Would it really be a >> hassle to comply with the LGPL? >> >> I see this opinion around here, and I don't understand it. Also the likelihood >> of being asked for code and objects is very small for black box products, but I >> would suggest being preemptive and posting it in a dark corner of your web site. > >How much of an issue it would be depends very much on the circumstances. >If you include GPL'ed code directly in your application, then you have to >make the entire source code available to anyone to whom you have provided >binaries. That doesn't mean you have to make it freely downloadable from >your website to anyone who wants it, but you have to include a written >notice valid for three years along with the system you are selling or >giving away, and charge no more than a reasonable distribution cost. > >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. > >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.
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 ? Regards Anton Erasmus
Reply by David January 31, 20052005-01-31
On Sat, 29 Jan 2005 02:07:10 +0000, Bryan Hackney wrote:

> David wrote: >> On Fri, 28 Jan 2005 11:27:50 +0100, Roland Zitzke wrote: >> >> >>>Hi, >>>I am looking for a library written in GNU C for the AVR which supports >>>HD44780 LCDs in 8-bit port mode, 1wire (Dallas) and UART. The library will >>>be used in a commercial project and should therefore be LGPLed or simmilar >>>license. >> >> >> If it's for a commercial (or otherwise closed-source) project, you can't >> use LGPL'ed software without a lot of hassle (involving providing unlinked >> object files instead of source files). Suitable licenses are >> typically either BSD-style, or modified GPL/LGPL/MPL (with a specific >> allowance for linking to closed source embedded software). >> > > Suppose you found something appropriate for the One-Wire protocol and the target > micro, which is highly unlikely, and suppose it was LGPL, and suppose you understood > the LGPL and did not have any nervous legal types on staff. Would it really be a > hassle to comply with the LGPL? > > I see this opinion around here, and I don't understand it. Also the likelihood > of being asked for code and objects is very small for black box products, but I > would suggest being preemptive and posting it in a dark corner of your web site.
How much of an issue it would be depends very much on the circumstances. If you include GPL'ed code directly in your application, then you have to make the entire source code available to anyone to whom you have provided binaries. That doesn't mean you have to make it freely downloadable from your website to anyone who wants it, but you have to include a written notice valid for three years along with the system you are selling or giving away, and charge no more than a reasonable distribution cost. 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. 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.
Reply by bithead January 30, 20052005-01-30
"Roland Zitzke" <FODVRUTMSTJC@spammotel.com> wrote in message 
news:35uid7F4llo9cU1@individual.net...
> Hi, > I am looking for a library written in GNU C for the AVR which supports > HD44780 LCDs in 8-bit port mode, 1wire (Dallas) and UART. The library will > be used in a commercial project and should therefore be LGPLed or simmilar > license. > I am sure I remember there were several good implementations available > from > www.avrfreaks.net > but this site appears to be down.
Try this. Has a great bootloader too. http://www.microsyl.com/
Reply by Bryan Hackney January 28, 20052005-01-28
David wrote:
> On Fri, 28 Jan 2005 11:27:50 +0100, Roland Zitzke wrote: > > >>Hi, >>I am looking for a library written in GNU C for the AVR which supports >>HD44780 LCDs in 8-bit port mode, 1wire (Dallas) and UART. The library will >>be used in a commercial project and should therefore be LGPLed or simmilar >>license. > > > If it's for a commercial (or otherwise closed-source) project, you can't > use LGPL'ed software without a lot of hassle (involving providing unlinked > object files instead of source files). Suitable licenses are > typically either BSD-style, or modified GPL/LGPL/MPL (with a specific > allowance for linking to closed source embedded software). >
Suppose you found something appropriate for the One-Wire protocol and the target micro, which is highly unlikely, and suppose it was LGPL, and suppose you understood the LGPL and did not have any nervous legal types on staff. Would it really be a hassle to comply with the LGPL? I see this opinion around here, and I don't understand it. Also the likelihood of being asked for code and objects is very small for black box products, but I would suggest being preemptive and posting it in a dark corner of your web site.
Reply by CBarn24050 January 28, 20052005-01-28
>Subject: Re: AVR library for LCD and 1wire? >From: David
>I am looking for a library written in GNU C for the AVR which supports >> HD44780 LCDs in 8-bit port mode,
There must be millions of them around but its so easy to write your own its hardly woth looking for them.
>and UART
even simpler, the standard library can be used.
>1wire (Dallas)
Ok that might take some thinking about, try looking on the dallas site.