[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Proposal: The DFSG do not require source code for data, including firmware

Anthony Towns wrote:
> If it makes sense, what are the major difficulties/inconveniences/whatever
> that were found in having this happen for etch, that will need to be
> addressed to achieve an etch+1 release that's both useful and convenient
> for both people who need/want non-free things, and those who want a
> completely free system?

From the d-i side, the major difficulties are:

1. The archive did not support a non-free section for udebs until today.
2. libd-i and anna do not support multiple udeb sources, but can only
   pull from one at a time; noone has yet fixed this
3. The Debian kernel does not currently have non-free firmware separated
   into different packages.
4. Numerous installation cases become much more complex assuming the
   above is all implemented. Examples:

   a. netboot install where the NIC needs non-free firmware.
      Possible solutions include:
      i. Ship a non-free installation image, either extra-debian (as is
         done for the nslu2), or in non-free. With the problems that:
	 * Such an image will automatically become the image most users use
	   to install, since it's more likely to work.
	   (Example: the nslu2 install image)
	 * So the free image won't be used or tested much.
	 * So we've doubled our work and QA for no actual benefit.
      ii. Ship only a single free image, with some procedure (ie,
         cat firmware.cpio >> initramfs) that users can run to make it
	 include the non-free firmware.
	 * This limits the users who can use it to users competant to
	   assemble it on their own.
      iii. Require that the user feed the machine some media with the
	 * Assumes that the drivers for the media don't need non-free
	 * Assumes that the machine supports removable media.
	 * Removes most of the benefit of netbooting in the first place.
   b. CD install where the CD, disk, NIC, etc need non-free firmware.
      Possible approaches include:
      i. Provide some way for the user to remaster the CD.
         * Too hard for most users.
	 * If the CD drive itself needs non-free firmware they will
	   need to modify the initrd too, which gets into the really
	   hard territory.
      ii. Allow some way for the user to add a new session to the CD
         containing the non-free firmware.
	 * No idea how this could work, but it does prove that drunken
	   late night discussions at DebConf are good for something.
	 * Wouldn't address any firmware that needs to go in the initrd,
	   ie, CD driver firmware.
      iii. Require additional media (floppy, usb key) or network.
	 * Assumes that the drivers for the that don't need non-free
	   firmware and that the machine supports floppy, usb or network.
      iiii. Ship a separate non-free CD.
         * Which then becomes the one everyone uses because it works, as
	   with the non-free netboot image above.
	 * Does bad things to our CD/DVD disk space requirements.
      Also, in the case of a CD that needs non-free firmware, we have to
      provide the installer with a way to get not just udebs for the
      firmware, but debs for it, for the installed system. This
      complicates all of the above approaches significantly.
    c. CD or network, etc install where the disk drive needs non-free
      firmware. If we have 1, 2, and 3 done, this isn't a large issue,
      but yet another complexifying case.
    d. Install _from_ hard disk (internal or USB), where the disk needs
      non-free firmware.
      This is probably the easiest installation media for a user to
      modify to add non-free firmware, so it may be amoung the easier
      cases to handle.
5. Implementing anything in 5 is a lot of work. Implementing it all
   will be pretty atrocious. My guess is still 6 months of solid work to
   implent a credible subset of 5, just like it has been all along.
6. We have no clear idea as to which of these possibilities is feasable
   or the right way to go.
7. People seem to find it much more rewarding to work on fixing bugs in
   d-i and adding spiffy new features like hard drive encryption and GUI
   installers than on firmware splitting. And more power to them..
   (The work done for the nslu2 provides a small counterpoint to this.)

It's worth noting that all of the above also applies to including
non-free kernel modules in the installer, although AFAIK we don't have
many if any of those in a form suitable for d-i in the archive.

see shy jo

Attachment: signature.asc
Description: Digital signature

Reply to: