[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Fedora not "free" enough for GNU?



2008/9/19 Ignacio Vazquez-Abrams <ivazqueznet gmail com>:
[snip]
> 1) Regulatory issues
>
> Hardware vendors need to prevent end-users from modifying the firmware
> so that the hardware can not be driven outside legal ranges.

This doesn't actually work:  I've modified the binary firmware of a
popular wireless card to force the card below the 2.4 GHz ISM
allocation. (As an amateur radio operator I'm legally authorized to do
so in any case, but the firmware is an ineffective measure and to
whatever limited extent that it is effective it interferes with what
I'm legally permitted to do, likewise it often forces incorrect
operation in other regulatory domains)

In the US at least the requirement for FCC type certification is that
you demonstrate your device will not operate in a way which does not
conform with the regulations and can not be trivially modified to do
so.

Since this will be re-occuring problem for free software we should be
making an effort for the FCC to accept that needing to recompile
source is roughly equal to binary firmware in terms of its
(in)effectiveness for this purpose.  The position I'd take to a
manufacturer is "help us convince the FCC that source is sufficient,
or we'll convince the FCC that firmware is not".

For ISM band devices (WiFi, bluetooth, etc) manufacturers can *always*
ensure regulatory compliance by including an appropriate hardware
bandpass filter (which should also making the device less noisy and
less subject to interference, i.e. better. But it adds cost).

For some other devices (cellular modems) the exact behavior of the MAC
may also be relevant for regulatory compliance. These couldn't be
solved with the addition of a better bandpass filter but I've never
seen one where the code wasn't in ROM.

There is a lurking BiggerQuestion(tm) here:

What happens when someone decides that things like with-source PDF
readers are not in compliance with the law because they can be
modified to  ignore "do not print", "do not modify" bits?  US Law [17
USC 12 ยง 1201(k)(1)(a)] already forbids the trafficking of certain
classes of hardware which to not play along with certain copy control
schemes, it would not be surprising to see future legislation extend
similar requirement to software which would be fundamentally and
irreconcilably incompatible with the terms of the GPL (v3 at least).
The knowledge of how to address regulatory incompatibilities with free
software is a skill our communities will need for the future, so we
should learn it now while it's less urgent.

> 2) Intellectual "Property" issues
> Hardware vendors don't want other hardware vendors to know how they run
> their hardware so that their design can't be copied or stolen.

Other people pointed it out already, this reason just sucks. I don't
fault you for saying it, because it is true but Fedora does not ship
proprietary applications, and the exact same reasoning would apply.

> 3) Inability to build
>
> Firmware is usually code for some PLD or ASIC, which needs specialized
> (and EXPENSIVE) compilers to build. Most people are unlikely to be able
> to turn the source into the firmware.

'usually'?  No. As far as I can tell much of the actual firmware
(rather than simple arrays of registers) is code for various
micro-controllers.  In most cases it was probably coded in C or the
relevant assembly.  (ASIC's are only programmable if they implement
there own microcode engine, and it might well be that there is no
source)

I do not doubt that there are a few CPLD and FPGA images out there, I
know of one FPGA image in alsa-firmware.  FPGA images will almost
always be sourced from verilog or VHDL. Both are widely known
languages.  There are zero-cost commercial grade tools for compiling
this stuff.   Fedora ships packages which have verilog and vhdl in
their source (GNURadio, for example).

(Other people already made good arguments that source is useful even
in a read-only context, etc)

I think it would be very useful to classify all the various bits of
binary firmware and identify what it is, why the source is not
available, etc. Even if none of it is removed. If someone begins work
on such a project please ping me.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]