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

Re: GPLed firmware flasher ...



On Fri, Mar 11, 2005 at 12:28:32PM +0100, Michael Below wrote:
> Sven Luther <sven.luther@wanadoo.fr> writes:
> > 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.
> 
> I think the opposite is right :) 
> 
> To the user, this doesn't appear as two separate works. He/she/it will
> see one program with pre-loaded data. If you are using already
> existing, copyrighted data (the firmware), this means you are building
> your work on top of the data. This is a derived work, I'd say (this
> doesn't imply anything to the weight of your work).

See my discussion about this in the kernel driver module firmware email.

> I think it is misleading if you think about the firmware as a program,
> which indeed doesn't communicate with the flasher. As far as I
> understand, the firmware that is being flashed doesn't run during
> operation of the flasher. I.e. it is being treated as data. And this
> data isn't treated "at arm's length", it is permanently incorporated
> into the executable.

Well, no, the at arm length is about executable code, since you recognize it
is data, the whole thing is moot and it is not a derived work.

Consider the case of a compression program which produce auto-uncompressing
files. Is the compressed file a derivative work of the compression program, or
just data. I think if in that case there is no doubt, and the flasher is
mostly the same case, since it basically uncompresses the firmware, and moves
it to the flash instead of the filesystem.

> So I'd say you should either build the flasher in a more general,
> "arm's length" way (one flasher executable, potentially different data
> files). Or you should consider using the LGPL. It doesn't fit exactly,
> but it should come closer to what you want.

Do you believe then also believe that a linux kernel with embedded initrd in a
.initrd section of the elf kernel file constitute a derived work of said
kernel ?

Friendly,

Sven Luther



Reply to: