On Dec 16, 2010, Richard Stallman <r...@gnu.org> wrote: > It sounds like the new Debian version of Linux will recommend > specific nonfree firmware programs, which is undesirable.
Yup. Debian didn't take the additional step of moving the drivers that require non-Free firmware to contrib where they belong per their own rules. Hopefully they will get there eventually. > The change is to obfuscate the names of the firmware files in the > Linux source code. The “in the source code” was something I was not entirely sure about. It could be done, and it would be much easier to do, if some intermediate layer obfuscated the names before issuing requests to userland. It would be easier not just because we'd have fewer blob names to mangle, but also because some blob names are computed with preprocessor macros, or even run-time sprintfs, involving version numbers of expected blobs or so. It's not that it would be impossible to incrementally compute the hash the way we designed, but it would be much harder. Also, implementing it this way, rather than as something internal to request_firmware(), would make it very unlikely that it is accepted upstream. OTOH, keeping blob names as they are in Linux source code, but mangling them in requests to users, might still be perceived as inducing users to install the non-Free Software, if they go look at the source code instead of just looking at the syslog messages. I'm undecided about which way to go. Now, if the latter approach (mangling blob names in the request, but not in the source code per se) is acceptable, an even simpler approach might work: one with even greater odds of being accepted upstream: introducing some means for userland to tell the kernel which pieces of firmware are available, so that the kernel does not even ask for those that aren't. I've been thinking about these options because AFAICT distros such as Fedora are leaning towards offering users more choice as to which pieces of firmware to install, what licenses to use, etc, but they're planning to do so in userland: the userland hotplug script called by the kernel to load a piece of firmware would obtain information about it from configured repositories and offer users (or not) the choice of installing it if it's not installed yet. I don't think this comes even close to addressing the problem that the kernel induces users to install non-Free Software, although it can mask it to some extent, and defer the filtering to userland. The reason I'm bringing this up is that, just like the move to request_firmware upstream, it's something we may end up having to live with and adjust our behavior to, so we might as well plan ahead of time how to cope with it, and how to design our solution so that it doesn't clash with upstream changes. > Alexandre, how is progress on this? None other than planning so far. In fact, I've been meaning to write about these issues for a while to get some feedback from other interested parties, but hadn't got to before you prompted me to do so. I'd like very much to have this implemented in time for 2.6.38 (late Mar/early Apr 2011, considering that 2.6.37 should be out by late Dec/early Jan), and I'd love to have this in a git repository rather than as deblobbing scripts, but a solution for the problem of creating a git repository that can track Linux upstream without carrying the non-Free bits that the Linux git repository carries has so far eluded me. Any git experts willing to contribute expertise to this end? Or perhaps users of other git-compatible DVCS that could help us get the behavior we need? Say, if bzr could track Linux git repos while enabling us to filter out the non-Free bits from the history, we might solve our problem and promote a GNU DVCS at the same time. -- Alexandre Oliva, freedom fighter http://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer