Fedora not "free" enough for GNU?

[Yaakov Nemoy]

On Sun, Sep 7, 2008 at 7:44 PM, Michel Salim <michel.sylvan at gmail.com> wrote:
> On Sun, Sep 7, 2008 at 7:36 PM, Conrad Meyer <konrad at tylerc.org> wrote:
>> Quoth Gregory Maxwell:
>>> On Sun, Sep 7, 2008 at 3:54 PM, Andrew Haley <aph at redhat.com> wrote:
>>> > Gregory Maxwell wrote:
>>> >
>>> >> The notion that firmware ought to be free isn't absurd: It doesn't
>>> >> take much effort to find examples of firmware imposing unreasonable
>>> >> limits on users, or firmware containing nasty hidden security bugs.
>>> >
>>> > Just to get away from the ethics flame^H^H^H^H^Hdiscussion for a
>>> > moment...
>>> >
>>> > This makes me think of a really interesting question: security-
>>> > critical organizations presumably have to make use of commercially
>>> > available computers just like the rest of us.  Someone somewhere
>>> > must have thought about the issues of binary firmware blobs for
>>> > video and network hardware and their potential to leak data,
>>> > either deliberately or accidentally.  One of the many nice things
>>> > about free software is the fact that it's reasonably easy to inspect
>>> > it for security analysis; binary blobs weaken that.
>>>
>>> There are two broad classes of 'security-critical organizations', real
>>> ones and pretenders. Most are pretenders, they fail to consider issues
>>> like this, then when it fails they show that they tried really hard
>>> and thus it isn't their fault.  Real ones consider these issues, and
>>> demand manufacturers comply with various security standards  which
>>> validate the security of the hardware/firmware.  Manufacturers often
>>> fail to actually do a good job of this, and can get away with it
>>> because bad security looks just like good security. ... so then when
>>> it fails the security-critical organization points to the standards
>>> that were violated, thus demonstrating the breech was not their fault.
>>>  :) :)
>>>
>>> I've found two blobs I use on my systems, one of them very obviously
>>> is a FPGA image, another one is appears to be software for a small
>>> micro-controller.  I'm not so sure that the FSF would consider the
>>> FPGA image software, but I don't know that they've considered this
>>> issue in the context of OS-shipped blobs (in fact, I've heard FPGAs !=
>>> software from them in the past), I think the vast majority of the
>>> blobs distributed in fedora are software for an embedded general
>>> purpose CPU and not FPGA images (generally FPGAs are enough of an
>>> additional per-unit cost thet you don't see them in mass market
>>> devices). (RME hammerfall firmware is the FPGA image, incidentally).
>>>
>>> As was pointed out here, a spin could be created easily enough.  It
>>> would make the FSF happy, as well as some number of other people (it
>>> would make me happy, if for no other reason than I'd get a better
>>> understanding of which of these blobs I'm actually using).
>>
>> The spin's already been created, it's called BLAG.
>>
> That's not really a spin, though, that's a derivative distribution?
> The idea of my original flame^H^H^H^H^Hquestion is to see what minimal
> changes we can adopt to make GNU happy. If it's too intrusive then of
> course it's not really worth it.
>
> A spin can only contain packages that are taken from Fedora proper,
> thus at the minimum we'd need a blob-free kernel. Isolating the other
> firmware packages should be easier.

Having looked through a number of the blag packages, a good majority
of the changes is rebranding components like anaconda.

There are a number of changes though that definitely make it qualify
as a derivative, such as choosing jack over pulseaudio.

-Yaakov