Re: Auditing free and non-free packages
Andrew M.A. Cater wrote:
> Andrew J. Barr wrote:
Now if they could only
figure out some way to do something similar for the Intel Centrino radios...
Andrew
It's been done - but you have to go to the SourceForge site to get the
firmware - which requires you to sign an Intel licence agreement - and then
put this in /lib/firmware or some such: firmware version may be
dependent on kernel/tools version. Then the equivalent Intel drivers
also work - I've a Thinkpad next door using ipw2200 drivers very nicely
thanks. The latest ipw3945 drivers are even more free, as I understand
it, and firmware may be more freely distributable IIRC.
What I want to see is automated retrieval and installation of the
PRO/Wireless radio firmware. Clickwrap license agreements aren't a
(technical) problem for Debian packages, see sun-java6 for an example.
As it stands now, you have to go to sourceforge.net (or more
specifically, bughost.org) and download the firmware .tgz and extract it
into /lib/firmware. The original reason for not packaging the 2x00
firmware was that the license terms did not clearly allow this. I
believe Intel has clarified their license, and even if they haven't,
there's no reason that the acceptance of the clickthrough agreement and
the subsequent retrieval and installation of the firmware image cannot
be integrated into APT and dpkg. The license terms for the bcm43xx
firmware blob are probably even more ambiguous (as it's not distributed
outside of being embedded in the Windows driver) but those intrepid
Debian packagers have figured out a way to deliver it to users with
minimal fuss.
I was just struck by the difference in experience between my Thinkpad's
wireless and the PowerBook's wireless, and while I realize there are
legal hurdles to delivering the firmware to Debian users, that doesn't
mean there aren't technical solutions to those hurdles.
Andy
PS: The driver installed on the user's laptop knows what firmware image
it needs, so as long as it's there it doesn't much care what else is in
/lib/firmware. So a safe bet is including all firmware images in the
'process' (whatever that ends up being), or at least all firmware images
that have been used by the driver since it went into Linus' tree.
Reply to: