LKML thread about (re)moving firmware within the kernel

[David Woodhouse]

On Fri, 2008-05-30 at 23:16 -0300, Alexandre Oliva wrote:
> I mentioned before there's an ongoing thread on LKML about David
> Woodhouse's project to move kernel blobs to a separate directory (and
> package).
> 
> I'd like to post a response along these lines to LKML, and I'd
> appreciate suggestions on how to improve it, or whether you think it's
> a terrible idea (as far as software freedom is concerned) to post
> something like this.

I'm a little confused about what you intend to achieve with your mail.
Can you briefly highlight, in your own words:

1. Who the target audience of your mail is.
2. What they currently think about firmware blobs.
3. What _their_ concerns are.
4. How your mail addresses _their_ concerns
5. How your mail will thus affect their opinion
6. What you hope the outcome of your mail will be


> > First of all, IIRC last time Debian discussed the issue of non-Free
> > firmware in the kernel, they decided they wanted to ship it.  DavidM,
> > to the best of my knowledge, your assumption that Debian would be
> > interested in a change like this for the reasons you seem to assume it
> > would be is unwarranted.

They actually _wanted_ to ship it? Certainly not in the kernel proper.
They _wanted_ to move it to non-free, at least. But since they didn't
have the technical means to do that in a fashion which would allow
people the choice of continuing to use the affected drivers, they chose
not to split it out.

We have a similar situation with Fedora. We _want_ to ship the firmware
separately, so that we can do 'Freedom' spins of Fedora which don't
include it at all. But for now we can't realistically do that. That's
why I embarked on the wide-scale conversion to request_firmware() to
move blobs out of the kernel.

Then Fedora and Debian _can_ ship a Free kernel, by default.

> > On May 29, 2008, David Miller <davem at davemloft.net> wrote:
> > 
> > > At least from my perspective this looks like a transfer of burdon from
> > > the folks who want to rip the firmware out, to those of us who find
> > > high value in the firmware staying in the tree.
> > 
> > That's a mistaken assumption.  Please let me explain why.  First, I'll
> > provide some credentials, so that you can tell I know what I'm talking
> > about.

Here, you're responding to a technical concern with rhetoric. Dave is
concerned that this will be a technically retrograde step for him,
because he wants to build kernels which combine driver and firmware
together as one.

My approach is to write code to make his life easier once we move the
non-Free code out of the kernel, and reassure him that his use case
won't break. Yours is to lecture him on a topic which is uninteresting
to him. Which do you think is most likely to affect his opinion?

> > Moving non-Free firmware within, or even out of, the linux tree,
> > doesn't advance our goal at all.  

Having Fedora and Debian ship a Free kernel doesn't advance your goal?
Yet it was your attempts to get Fedora to ship such a kernel which
prompted me to do what I'm doing now.... I'm confused.

> > As long as the Linux project is
> > tolerant to the inclusion of non-Free Software in its sources,
> > monitoring and clean-up efforts along the lines of the Linux-libre
> > project will be necessary for 100% Free distros.  No matter how much
> > progress DavidW makes in moving some pieces of non-Free firmware into
> > a separate directory, or even into a separate tarball, this won't
> > affect the other pieces of non-Free Software that do exist in the
> > kernel source tree, and it won't stop other such pieces from being
> > introduced.

But Alex, there _are_ no other pieces of non-Free software in the
kernel. How could there possibly be? Firmware blobs have _always_ been a
special case.

> > Now, since very many lead Linux developers don't care about software
> > freedom, and go wild in anti-fundamentalist fundamentalism when they
> > smell freedom concerns in the air, the odds that any such committment
> > could come out of this group are negative.  Therefore, we have to keep
> > on maintaining this parallel project.

I disagree, strongly. What other pieces of non-Free software are likely
to get added to the kernel, once the policy is established that firmware
lives elsewhere?

> > Given the above, moving or removing non-Free firmware from the kernel
> > doesn't help us at all.  Quite the opposite.  It makes more work for
> > us.  Firmwares at locations encoded in our deblobbing scripts will no
> > longer be there, so the scripts will have to be adjusted.  Patterns
> > that match them may have to be changed.  The time spent pretty much
> > every day tracking tarballs, .minor, -rc and -git patches, and
> > cleaning them up (such that we can build binaries for 100% Free
> > distros, such as gNewSense, BLAG, dyne:bolic, and Freed distros such
> > as freed-ora, freed-ebian, uhurubuntu) would go up, rather than down,
> > at least during this transition.  So, no, this doesn't even save us
> > work.  Whatever you might it could save is already done and automated.

That seems like nonsense to me, too. The 'deblob' scripts need updating
from kernel to kernel anyway, and we're rapidly getting to the point
where all you need to do is 'rm -rf firmware/'.

And from there, we want to move the firmware directory into a separate
tarball. You plan to answer DaveM's technical concerns about that plan
with rhetoric -- do you really think that's going to help?

> > I.e., a step backward would be the most substantial consequence of
> > this change.  No wonder I'm not exactly excited about taking part in
> > this development.  Even though I agree it's technically superior, its
> > most substantial use would be to facilitate the distribution and use
> > of software that is detrimental to my goals.

I disagree. What it facilitates is _choice_. People would have the
_choice_ to distribute and use non-Free software, or not, as they see
fit. Where previously they were forced to either do so, or manually
strip it out for themselves. And the distributions had the choice of
doing so, or removing functionality that users require.

This whole thing is being done to advance your goal, which I share in
this particular instance. And it looks like you intend to argue
_against_ its inclusion.

> > > As soon as we have firmware converted to ihex files in the kernel source
> > > tree, I'll set up a 'shadow' git tree like my kernel-headers tree, which
> > > automatically follows the linux-2.6.git tree commit by commit, and
> > > contains just the results you'd get from 'make firmware_install'.
> > 
> > A word of caution: a little bit of the firwmare in the kernel is
> > actually under the GPL (as in actual source code, not just
> > pre-compiled streams of numbers), and it would be advisable to not
> > maintain its binaries too distant from the corresponding sources.

Yeah, I've been getting to some of those. I think once we have it in a
separate repo, we can do a build system for it.

-- 
dwmw2