On Tue, 2008-10-21 at 14:36 -0700, Thomas Bushnell BSG wrote: > On Tue, 2008-10-21 at 16:27 -0500, William Pitcock wrote: > > On Tue, 2008-10-21 at 14:20 -0700, Thomas Bushnell BSG wrote: > > > On Tue, 2008-10-21 at 23:28 +0300, Kalle Kivimaa wrote: > > > > Would it be a good compromise between SCs #1, #3 and #4 if we made an > > > > exhaustive list of non-free bits in main, and make it our goal that the > > > > list gets smaller between each release and not to add anything to > > > > that list? > > > > > > I would be entirely happy with that. But I have just been told by > > > William Pitcock that apparently we are required somehow to support new > > > hardware with non-free software too. So it's not a decreasing list, > > > it's an accordion list with no real commitment to the DFSG at all. > > > > Do not put words into my mouth. I simply stated that user experience is > > an important factor, and that if free drivers (*FREE*) which depend on > > non-free firmware are available, and the firmware is inline, then it > > should not block Lenny's release. > > Huh? So you would be willing to agree to a rule that we never add > anything new to the list of non-free bits? In the kernel itself, yes. Provided that: * the kernel framework for loading firmware is used for drivers depending on non-free firmware, and * that firmware is available in non-free via firmware-nonfree Infact, once I have time, I intend to start pushing patches upstream to make this happen. But this is going to take another kernel release cycle... if we intend to release Lenny with 2.6.26, than this is not an option. For hardware where this is an unacceptable solution, rewriting the driver to not use the firmware may still be possible. William
Attachment:
signature.asc
Description: This is a digitally signed message part