Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
md@Linux.IT (Marco d'Itri) writes:
> On Aug 07, Goswin von Brederlow <firstname.lastname@example.org> wrote:
>> > No, because those are not linked together with the GPLed code, but are a mere
>> > aggregation of works inside the same media, i.e. the binary file. Those
>> > non-free firmware will never run inside the same memory space as the kernel,
>> > and are offloaded to a peripheral processor, and the communication media
>> > between the kernel and this peripheral processor running said firmware is
>> > clearly defined, there is no doubt that those non-free firmware do not break
>> > the kernel GPL.
>> They are linked in, they have symbols, the code directly references
>> their address. Can you name one tool that will easily remove such
> No. They are a char array, it's data copied where the hardware wants it.
> It's not code called by other functions.
That still leaves the symbol for the variable holding the char array
and its size. The code copying the data references that variable and
size. I didn't say the code is called.
Compare it to including a hexdump of an image or sound in a header
file and including that in the binary. And compare it with having that
same image or sound as external file shipped in the same deb.
Assume the image/sound was rendered/generated from some source format
not included in the source. E.g. povray input.
Is it an aggregation with the image linked into the binary?
>> "aggregated" code from the kernel image?
> Not relevant.
If it is an aggregation then there must be a way to break it up and
only keep the GPLed parts. I think that is very much relevant. I don't
think you can call something an aggregation if it is inseperably bound