[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: GPLed firmware flasher ...



sven.luther@wanadoo.fr wrote:

>My understanding of this is that neither the firmware constitute a derived
>work from the flasher, nor the flasher constitute a derived work of the
>firmware. The fact that they are individually packaged in the same elf binary
>does not constitute a linking act, nor a derivation/modification act, but mere
>aggregation, and is thus not a problem for the GPL.
Correct. The firmware is not some other code which the loader is
interacting with, it's just some data which happens to be stored in an
ELF binary.
But anyway, the definition of "derived work" is something which can only
be settled by a court.

>which seems to me to be saying that to be a derivative work, one of them must
>contain code from the other (or use it in the library case), but the firmware
>is independent from the flasher and vice-versa.
Yes, this is a reasonably simple definition of what a derived work is,
functionally similar to the one in the GPL FAQ.

>That said, the flasher program is itself using the OF methods of the existing
>firmware but since it is using the installed version and not the one it is
>flashing, one can consider that the OF methods are indeed covered by the GPL
>clause 3) exception for stuff normally included in the system, altough one
This is not different from LILO using BIOS calls. What matters is the
interface.

>One wonders about the definition of modules, and one can consider that in this
>case there is no communication altogether between the the two parts, at least
>not when the code is run, and later once the firmware is installed, the
>communication method between the two being the IEEE 1275 standard, so there is
>no surprises.
Yes, I this is the important point.

-- 
ciao,
Marco



Reply to: