Re: firmware blobs
Sven -
On Wed, Aug 16, 2006 at 09:01:15PM +0200, Sven Luther wrote:
> Ah, it has been argued, that since the driver depends on the firmware to work,
> it should then go to contrib, but not stay in main, so moving the whole stuff
> to non-free is lightyears easier to handle, and you don't need to do the
> source-code modification work to remove the firmware.
I don't buy that argument. There might be other means of
loading the firmware (warm boot from windows, additional
hardware, etc.). Once it's in, the driver will work fine.
The driver depends on the hardware to work, too, and we don't
require a way to stuff the hardware into the tarball.
The source-code modification work is easy (in most cases).
The hard part will be testing: you have to get the modified
kernel, the firmware blob, and initrd scripting infrastructure
in the hands of someone (relatively competent) who has the
affected hardware. They also have to be willing to reboot
a few times.
> [chop] people where saying that we were fools to ask [for a real
> firmware license] from
> broadcom, given their non-free-software attitude and all, and they were rather
> helpful and after some lengthy discussion and consulting of their legal
> department, they agreed to change the licencing, so it is no more defacto
> GPL2 (altough it remains non-free, but at least it is distributable).
>
> The main problems are those drivers where the copyright author is lost.
I think the job is worth doing, but it's far more than I can
accomplish in an afternoon. Just for fun, I might try to follow
up on the two blobs I started chasing down.
> > I already emailed Frederik Schueler, suggesting that the offending
> > code get ripped out of 2.6.17 before its upcoming migration to testing.
>
> Hehe, but this public list is probably the best place to handle such stuff,
> since we are a maintainer team.
OK. I now publicly suggest "that the offending code get ripped out
of 2.6.17 before its upcoming migration to testing."
- Larry
Reply to: