Peter wrote: >>> _My understanding_ of the situation is that the act of linking itself >>> is what LGPL allows. Static/dynamic isn't the issue except that there >>> must be a way provided to re-link with (a) different version(s) of the >>> LGPL library(s). >>> >> Which of course wrecks havoc with any embedded sort of application. >> "Here's the .o module of our proprietary code that can be linked >> with this list of LGPL libraries. And there's your box with its >> OTP soldered in chip containing the old code. Have fun!" > > I do not see a problem with that. The LGPL does not imply non-OTP > devices. Specify flash to the client and provide the .o file and a copy > of the LGPL on the documentation cdrom and just forget about it imho. It seems you are right in that the LGPL doesn't require you to provide the user with a possibility to actually write the code into any chip. (Which kind of shows that the GPL was not intended to be applied to firmware. The actual requirement, see below, doesn't really make much sense in such a situation.) But it seems to require you to provide the user with all tools to create your application executable. Which seems to exclude applications written for any commercial compiler. Which seems to imply that you can't license a library that's written for a commercial compiler with LGPL. (Well, you of course can, but it seems that then nobody would be able to use it.) (This issue doesn't seem to have to do much with embedded or not.) Gerhard -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist