Re: D-Link and Linux: A match made in Hell?

From: Rick Moen (rick_at_linuxmafia.com)
Date: 12/30/04 

Date: Wed, 29 Dec 2004 23:20:38 GMT

Timothy J. Bogart <tbogart@frii.net> wrote:

> So, you did not cite an FCC 'rule' which makes it illegal to have open
> source drivers. As expected.

The matter really does need to be FAQed, since there's a lot of dubious
information on the subject.

Near as I can tell, the real underlying facts are these: the USA's FCC
does have rules requiring that services stay within their assigned
frequency bands and not exceed their mandated effective isotropic
radiated power (EIRP) limits. Manufacturers of wireless equipment are
mindful of those restrictions, and probably wary of giving customer easy
means to violate either frequency or power restrictions, lest they be
held liable on some theory of secondary liability. (Manufacturers are
responsible for complying with FCC's Part 15 rules section 247[1] as to
EIRP, and with frequency assignments elsewhere in Part 15.)

When IEEE finished the 802.11g standard, for example, the spec included
14 channels in the 2.4GHz band, but FCC allows use of only 11 of those
for WiFi service.[2] So, any card capable of 802.11g has the physical
capability to use all 14 channels, but the released drivers restrict the
card to the FCC's 11 channels.

Some recent cards (e.g., Prism GT, Duette, and Indigo ones) package the
card's low-level programming in the previously mentioned "binary
firmware images". These are blobs of binary that would otherwise have
been _in_ firmware (as it is in, say, my old Lucent Orinoco 802.11b
card), but the manufacturer elected to save money on the ROMs in this
fashion.

This in itself isn't a big problem: One just configures the hotplug
system to lob the binary image into the card at initialisation time.[3]
The only real problem is that the manufacturers basically never bother
issuing permission for the public to redistribute those binary blobs[4],
so most distributions, not wanting to step into a legal quagmire, don't
include them. Which in turn forces each user to hunt them down
independently and install them into /etc/hotplug locally.

Note that the "firmware image" is not a driver; it has no OS dependencies.
Equipped with such an image file and rudimentary information about how
to load it, one could code a driver, either open source or not, for any
operating sytsem.

[http://ipw2200.sourceforge.net/ :]

> So I looked at the ipw stuff. Duh. It is the Intel stuff. They don't
> release full documentation for their stuff. The firmware is from Intel
> and you have to agree to an Intel license agreement to use it. Not pure
> GPL.

The fact that the IPW firmware images are binary-only and restricted to
be lawful only in use with Intel hardware isn't a huge problem: The
firmware code stored inside my Lucent Orinoco is, in effect, just as
restricted -- as is, most likely, the ROM BIOS code stored inside your
motherboard and mine. Otherwise, the licence is non-transferrable and
bars use in reverse-engineering but at least allows distribution to
users. So, unlike many such images (e.g., Intersil's for the Prism
chips), it could be lawfully included in Linux distribution media.

Having source code to that firmware, or to an independent
reverse-engineering of that code, would be nice but is certainly not
essential for the hardware's full usability on Linux or any other OS --
not any more than it's necessary to have your motherboard's ROM BIOS
code to run open-source OSes on it.

Anyhow, your overall point is well-taken: As far as I can see, nothing in
FCC's ruling precludes developing and using fully open source drivers,
per se. Most manufacturers are being uncooperative for reasons of their
own; probably not explicit policy but just inertia and fear of even
indirect association with coders modifying their firmware to increase
EIRP and/or change the frequencies used.

[1] http://www.wi-fiplanet.com/tutorials/article.php/1428941
[2] http://www.webopedia.com/quick_ref/WLANStandards.asp
[3] http://wiki.tryphon.org/Prism54
[4] http://lwn.net/Articles/108716/?format=printable 

-- 
Cheers,                                      Hardware:  The part you kick.
Rick Moen                                    Software:  The part you boot.
rick@linuxmafia.com

Relevant Pages

  • Re: [PATCH 1/3] firmware: allow firmware files to be built into kernel image
    ... Most drivers, when built as a module, would want their firmware images ... to be in the module and not in the kernel image. ...
    (Linux-Kernel)
  • Re: [GIT *] Allow request_firmware() to be satisfied from in-kernel, use it in more drivers.
    ... Provides a method for firmware files to be built into the kernel, ... In doing that, mark fw->data as 'const', and fix a few drivers to cope. ...
    (Linux-Kernel)
  • RE: cd writer does not recognize blank cd
    ... To roll back the drivers .. ... Use the Infotool to verify the media your drive can use, firmware version, ... use it to create a report that can be cut and pasted to a post, use the ASPI ... That is what I see on my system and both my optical drives are working ...
    (microsoft.public.windowsxp.hardware)
  • Re: Why Im going back to windows from Suse.
    ... > required to develop the additional firmware required for their product to ... write the drivers for them for free. ... One mail will not hurt them. ... Two mails will not hurt them. ...
    (alt.os.linux.suse)
  • Re: Sony DRX-820UL no drivers
    ... The software disk that is included only has Nero Software on it. ... windows then says that it doesn't have any available drivers for it. ... Firmware upgrade would be great, but you can't update the firmware ... they claim Windows should install them automatically). ...
    (microsoft.public.windowsxp.hardware)