Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
Sven Luther <sven.luther@wanadoo.fr> writes:
> On Sat, Aug 12, 2006 at 11:03:29PM +0200, Goswin von Brederlow wrote:
>> 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.
>
> Well, the FSF argues that it is not important where the file is, as long as
> there is a logical link, in order to have the GPL cross the dynamic linking
> barrier. In the same way, the only relationship of the non-free firmware or
> your image or sound, is that it is transported in the same binary, and used as
> data offloaded to the peripheral device.
>
>> Assume the image/sound was rendered/generated from some source format
>> not included in the source. E.g. povray input.
>
> So ? What has this to do with it ?
So you can't claim the hexdump (or binary file) is the prefered form
of modification (source).
>> Is it an aggregation with the image linked into the binary?
>
> It depends if your binary is an image compressor, and only transports the
> image, or if said image is used in the binary for icons of its GUI for example
> or as splash screen.
If I just dump my hexcode of the image/sound to my black box (qiv or
xmms for example) for (dis)playing then I only transport the file. If
I (dis)play it myself then it isn't an aggregation. Intresting.
Or does the black box have to be hardware?
>> >> "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
>> together.
>
> Well, sure there is part to separate them. You could imagine a (non-free) tool
> called before lilo or grub, and which would upload those firmwares for the
> peripheral device to be ready when the free driver comes into play.
I can imagine a tool that rewrites non-free parts of a binary as free
software from scratch without breaking any laws about reverse
engeneering too. Does that mean they exist or are even possible? no.
> Or you could use the new initramfs/firmware loading kernel infrastructure to
> separate the firmware from the kernel.
That requires changes in the source. Exactly those changes is what I
say must happen. The firmware loading kernel infrastructure marks a
clear lines where an external blob of firmware gets loaded that isn't
part of the kernel binary itself.
> Err, is not this latest one what you are suggesting we do ? So, if i
> understood you well, your own argumentation is hitting you back there, and
> this is usually proof that there is something terribly wrong in your
> argumentation to start with.
No. You just argumented my point. The source changes to seperate the
firmware and to use the firmware loading kernel infrastructure makes a
difference imho.
Also notice that with the firmware loading kernel infrastructure you
can just delete the firmware file and the loader will give a simple
error. Good luck trying to remove the char *firmware from a kernel
image and not have it crash. Best you can do there is fill it with
dummy data.
> Friendly,
>
> Sven Luther
MfG
Goswin
Reply to: