Hello, On Thu, Nov 19, 2015 at 10:56:19AM +0100, Daniele Lacamera wrote: > This distinction seems to be the most difficult thing to define in a > LGPL context, if not in the obvious case of shared/dynamic linking > suggested at point 4.d.1, which is not applicable in embedded systems > core code.
Sorry for chiming in and IANAL but my understanding is that if one can (in reasonable sense, hence not counting RE, binary patching, writing big compatibility shims etc) substitute an LGPL library with another version of the same and all the changes to the said library are provided under LGPL, then the requirements are fullfilled. Linking mechanism specifics doesn't change anything here. So in the case of libopencm3 that would require proprietary software authors to at least provide object files for their proprietary parts plus source code (obfuscated if they wish so) that uses libopencm3's inline functions. Of course, free software authors do not need to do anything extra (but publish their patches to libopencm3). Does this understanding contradict some published opinions of FSF's or SFLC's lawyers? -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ------------------------------------------------------------------------------ _______________________________________________ libopencm3-devel mailing list libopencm3-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libopencm3-devel
