Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
On Sun, Aug 13, 2006 at 04:01:12AM +0200, Goswin von Brederlow wrote:
> 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).
Well, i never argued that, i always said that the binary-only firmwares
without source, are non-DFSG-free, and should be handled accordyingly.
The point is that they are not considered a derivative work of the kernel
source, and thus that the presence of non-free firmware inside the kernel
binary is no breakage of the kernel GPL.
> >> 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.
If the image is integral part of your program, it being non-free breaks the
GPL of your program, independently of it being included in the same binary or
not.
displaying some random image doesn't count as 'being integral part of the
program'.
> Or does the black box have to be hardware?
nope, the same applies in all case, but i wish you would not mix the problems
and provide false argumentation for the case we agree with, in order to
disproof a totally different issue.
> >> >> "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.
Well, what is a bios apart from a tool which runs at system startup and
initialises the peripheral procesors in a state which will allow later
programs to use it ? I do bios/firmware writing for a living, and plan to
embedd exactly such non-free firmware into the flash firmware of my board, to
power onboard devices that need them.
So, again, what was your argumentation here ?
> > 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.
Indeed. and i *NEVER* said that they should not happen, i *NEVER said that
this was the point we are discussing, i actually *AGREE* with you there. This
is a fully orthogonal issue to the aggregate work status of the firmwares in
question with regard to the kernel.
So, now that we agreed that those modules need to go into non-free, but that
provided their licence is clear enough, like in the tg3 case, they are indeed
distriutable in non-free, let's go back to the initial point.
This is upstream work, and work which is slowly happening upstream, but will
never be ready in time for the etch release. The kernel team has not the
ressources to do all that work in a timely fashion for the stated etch
release, and delaying until it is ready may mean at least a year of delay for
the etch release, which is unacceptable for many.
So, if you are really concerned about this issue, start coding, we await your
patches impatiently, and will even help you bring them upstream, so they may
be integrated in the current debian kernels accordying to our current policy.
> 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.
Well, i would say that a single variable symbol is as much of a clean
boundary. The firmware loading infrastructure assuredly cannot contain less
information than this.
> > 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.
Bah.
> 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.
Maybe, which is why we move the *WHOLE MODULE* to non-free.
Friendly,
Sven Luther
Reply to: