Byron A Jeff wrote: > Correct. The arugment is that the relink requirement allows the library > to remain "free" and updatable by the end user. > > Personally I find it cumbersome to follow for embedded systems work. Right. I think here we see one of the reasons why people came up with the distinction between software and firmware. This distinction has become less "firm" over the years :) but it still exists -- and it shows when trying to apply the GPL license (created for software) to firmware. There are many terms in the (L)GPL licenses that seem to be very specific to software development (and specifically in C or languages that build similarly, with object files and object file libraries and compile/link stages). The whole license doesn't seem to make a lot of sense in situations where this is not given. > One missing point is that it's the devlopers responsibility to provide the > end user whatever tools required to make the relink, including propietary > compilers and linkers. In the case of software (let's say this includes that it runs on a sufficiently standardized hardware platform and on a sufficiently standardized operating system), this is assumed to be provided, somehow. This got me thinking... Does it make any sense at all to publish, say, a C# (or, to stay closer to home, a HiTech PICC or Microchip C) library under LGPL? This seems to require that any application that uses it (even when only linking in the library) provides the tools required to rebuild it, which contradicts the licensing terms of the tools: 'For an executable, the required form of the "work that uses the Library" must include any data and utility programs needed for reproducing the executable from it.' Sounds as if such a library could not be used by anybody, because nobody would be able to publish all "utility programs needed for reproducing the executable"... ? Gerhard -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist