2008/9/19 Ignacio Vazquez-Abrams <ivazqueznet@xxxxxxxxx>: [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. -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
