Re: The bigger issue is badly licensed blobs (was Re: Firmware poll

[Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de>]

Nathanael Nerode <neroden@fastmail.fm> writes:

> Joe Smith wrote:
>
>> "Sven Luther" <sven.luther@wanadoo.fr> wrote in message
>> news:20060830073254.GA30412@powerlinux.fr...
>> 1. Module and firmware in free. (The firmware can be compiled into the
>> module, or can be loaded from a file.)
>> 
>> 2. Module in free, firmware in nonfree, loaded from file by driver. [One
>> could argue that the modules belong ion contrib, unless the firmware is
>> optional (perhaps allowing access to non-essential features)].
>> 
>> 3. Module in non-free. [Firmware compiled into module, has not yet be
>> seperated into seperate file. This is acceptable, but many of these could
>> be converted to type 2 if somebody puts in the work].
>> 
>> 
>> I know we have some modules of type 1. I'm pretty sure we have some
>> modules of type 3. It has not been clear to me if we currently have any
>> modules of type 2.
>
> Yes, we do. bluez-firmware and atmel-firmware.
>
>> Obviously if the infrastucture is not there, that should be fixed.
>
> It's there except for d-i.

Actualy D-I has the support it needs for this, at least net-retriever
I checked myself. But if the cd-retriever lacks it then it is trivial
to add the same code there. What isn't there is the md5sum / sha1 sum
in the release file for non-free/debian-installer/* on the debian
archive. A minor config problem.

The only real problem left arises when you need firmware to access the
udebs containing the firmware. That means if you use netboot and need
firmware for the network card or netinst and a cdrom that needs
firmware to be accessible. That can only be solved by building
non-free D-I images that already include non-free firmware. I don't
think that needs anything but config file changes for the build
process.

Besides D-I there is also the problem of debian-cd. Someone has to
build non-free CD images that include the firmware udebs. That is
mainly a infrastructure matter and not a software problem though.

>> Then we have DI. AIUI D-I curretly lacks support for Type 2 and Type 3
>> modules. This can definately be fixed, but doing it for etch could delay
>> release.
>
> Right.

Wrong, see above. Surprisingly enough the support for this was addes
_5_ years ago to support having udebs in main and local sections. A
non-free section is just a variation of that.

>> So the question I have is how long would etch need to be delayed to add
>> support for non-free firmware to D-I?
>
> Joey Hess estimated 6 months work, but that was to implement a whole bunch
> of uncommon special cases.  I think it is totally unnecessary to implement
> all, or even any, of those.
>
> http://lists.debian.org/debian-vote/2006/08/msg00122.html

(1) was nearly done. The Release file are missing the checksums. Minor
problem.

> For (2) from that post, which is the key sticking point for d-i, it needs to
> be done anyway, and honestly should not take more than a month if someone
> bothers.
>
> So -- point me to the correct parts of the installer.  I don't know where to
> find this "anna". libdebian-installer I'm looking at -- it would be a great
> help if someone could direct me to the part of the code which loads udebs
> from disk/network, because I can't find it.  Is that all in 'anna', which I
> can't find?  :-/  If I can't find the source code for 'anna', I can't fix
> it.

(2) was done 5 years ago (for the non-free case) by having the
retriver concatenate the downloaded Packages files into one before
passing it off to anna/libd-i. That way the problem is circumvented.

I also have a patch for libd-i to parse multiple packages files but
Bastian told me that the internal data structures of the parser will
break if packages with the same name appear and dependency resolving
might be off. Something I haven't yet seen happening since all my
tests had disjunct Packages files. This feature would only be needed
to support 3rd party repositories inside the installer though. Not for
Debians non-free.

One could also extend the trick of concatenating the packages file
even for 3rd party repositories. The retriever just need an extra
option to no delete the old file.

> (3) is trivial and simply requires the will to fix RC bugs.

(3) is wrong since there is a frimware-nonfree package with 2 firmware
udebs in experimental for example.

>
> (4) is frankly not nearly as important as Joey makes it out to be.  It is
> very unlikely that someone will have a machine where *both* the CD *and*
> the NIC *and* the floppy drive if present *and* the USB driver (USB key)
> need non-free firmware.  
>
> As long as there is one piece of hardware with fully free drivers which can
> be used to load the additional non-free material on the machine, it is
> perfectly tolerable that an alternate piece of hardware is not so
> supported.  (I've seen systems where the NIC needed non-free firmware
> downloaded and ones where the CD did, but never ones where both did.)  I
> know it's theoretically possible that someone will buy a "hell machine"
> where every single peripheral requires a non-free firmware download -- but
> it's unlikely.  And if that happens, they can still use the hard drive
> method or master their own CD.

(4) is the actual problem. But more a problem of organizing and
deciding.

Maybe we could compromise by making only a non-free (but comercially
distributable) image and have a question "Use non-free? y/n" for those
that insist on using 100% free software. If that is too much then I
fear having a free and non-free image is the only solution.

I would rather have non-free in the actual installer images and have
it labled as such on the CD (it would be in pool/non-free) than have
the non-free firmware remain in the kernel itself and on every
installed system but still claim 100% free.

MfG
        Goswin