Re: [GNU-linux-libre] The "Free" Kernel In Debian Squeeze

[Alexandre Oliva]

On Dec 16, 2010, Richard Stallman <address@hidden> 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