Re: [GNU-linux-libre] Free firmware - A redefinition of the term and a new metric for it's measurement.

[Maxim Cournoyer]

Hi,

Christopher Howard <address@hidden> writes:

> Hi David, I don't agree that just being given a redistributable blob is
> any wonderful thing. What you end up with down the road (and this is
> where we are now) is systems that need several (or many) blobs that only
> the providing company understands and controls. Usually these blobs are
> in control of critical or highly desirable functionality. You don't know
> for sure what the blobs do or whether or not they have security
> vulnerabilities. And sometimes the blobs come with restrict licensing
> allowing distribution but not allowing you to reverse engineer.
>

+1. I don't see how having blobs helps security at all. David, you
mentioned that having blobs could help manufacturers fix security issues
(human errors) in their products; while true, this is a double-edged
sword; it could also be used to insert spyware or whatnot, and very
easily (simply release a new version of the blob for distribution,
advertising it as bringing "fixes").

I think the FSF's position, as expressed in their "Respects Your
Freedom" certification guidelines [0], is reasonable given the current
state of things. Basically it says that "All the product software must
be free software.", but grants some exceptions for software equivalent
to hardware (e.g., fixed in ROM and non-upgradable) [1] and which runs
on "secondary embedded processors" (which can include firmware built
into I/O devices).

For the time being, the hardware we use is closed. Just as we
reluctantly accept to use non-free hardware for the time being, we can
reluctantly accept to use non-free software which is equivalent to
hardware. Whether the non-free firmware is stored as a loadable blob or
in the ROM of a device doesn't change the fact that it's non-free. The
subtlety is whether this firmware is used as hardware (upgradable) or
software (easily replaced or extended). The later puts more control in
the hands of the manufacturer, which is why the former is preferred.

The RYF criteria page also states that they "want users to be able to
upgrade and control the software on as many levels as possible.". In
other words, a device with completely free firmware is more valued than a
device with a closed firmware used as hardware, as it should be.

Finally, preferring built-in, closed firmware to loadable blobs (closed
firmware) could be seen as an incentive for manufacturers to release
their firmware as free software (user-upgradable): releasing it as free
software enables them to fix things (in a transparent manner) after the
product is launched, which reduces risk (if the firmware is
non-upgradable, the product could have to be recalled in case a serious
problem is later found with it).

> For firmware development to be practical, you want more than
> documentation. You want source code. Also (for embedded development) you
> want a tool chain. You might have the source code but find it near
> impossible to build because you don't have a good tool chain.
>

The RYF criteria includes a "Compilation" (all the software must be
buildable using free tools) and "Documentation", so this is at least
summarily covered.

> Yeah, with documentation, you might be able to engineer the source code
> and tool chain... but it might take you 3+ years, and then only if
> enough people are interested. And by that time no one will want the
> hardware anymore. This isn't a moderately annoying problem for x86, but
> it is a major problem for tablets, cell phones, and other embedded
> development.
>
> The companies that should be the rewarded are the ones that release
> firmware, source code, and tool chain. E.g., Thinkpenguin and the TPE-R1100.
>

Indeed, we ought to put our money where our mouth is, i.e. back the
companies which are helping the cause of free software/hardware.

My two cents,

Maxim


[0] http://www.fsf.org/resources/hw/endorsement/criteria

[1] The "fixed" part is not worded directly in the RYF criteria, but
from the anti-tivoization clause found in the GPLv3, I would expect that
this is how they would consider the matter.

signature.asc
Description: PGP signature