Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 6 Oct 2006 10:34:07 -0700
From:      Chuck Swiger <cswiger@mac.com>
To:        "Constantine A. Murenin" <mureninc@gmail.com>
Cc:        FreeBSD Mailing List <freebsd-questions@freebsd.org>
Subject:   Re: ipw(4) and iwi(4): Intel's Pro Wireless firmware licensing problems
Message-ID:  <1A4EA09D-4BAD-4968-8500-43A765CA0988@mac.com>
In-Reply-To: <f34ca13c0610051931g76a5b58cp4c16eaaef740cd22@mail.gmail.com>
References:  <f34ca13c0610041946h7dfaa05cyf3296798b215405e@mail.gmail.com> <DBC71CAC-9850-4598-94B2-346CE37A4BC4@mac.com> <f34ca13c0610051931g76a5b58cp4c16eaaef740cd22@mail.gmail.com>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
On Oct 5, 2006, at 7:31 PM, Constantine A. Murenin wrote:
> On 05/10/06, Chuck Swiger <cswiger@mac.com> wrote:
>> On Oct 4, 2006, at 7:46 PM, Constantine A. Murenin wrote:
>> > Why are none of the manual pages of FreeBSD say anything about why
>> > Intel Wireless devices do not work by default?
>> >
>> > http://www.freebsd.org/cgi/man.cgi?query=3Dipw
>> > http://www.freebsd.org/cgi/man.cgi?query=3Diwi
>>
>> The manpages you've linked to explicitly state:
>>
>> This driver requires firmware to be loaded before it will
>> work.  You need to obtain ipwcontrol(8) from the IPW web page
>> listed below to accomplish loading the firmware before ifconfig(8) =20=

>> will work.
>>
>> Is there some part of this which is unclear to you, Constantine?
>
> Yes, Chuck, some part is indeed unclear to me, precisely the part that
> explains why does one have to go into that much trouble to have a
> working system.

That was explained below.  You might not like the reasons, or agree =20
with them, but your claim that the FreeBSD manpages do not say =20
anything about the need for firmware is obviously mistaken.

>> There's no need to be curious about the matter; the Intel Pro
>> Wireless adaptors, like many other brands of wireless adaptors, use a
>> software-controlled radio which is capable of broadcasting at higher
>> power levels and/or at frequencies outside of those allocated for
>> 802.11 connectivity for specific regulatory domains.  The US FCC,
>> along with other regulatory agencies in Europe such as ETSI and
>> elsewhere, require that end-users not have completely open access to
>> these radios to prevent problems from deliberate misuse such as
>> interference with other frequency bands.
>
> Yes, regulatory bodies, of cause, table specific requirements that
> must be satisfied by systems that utilise RF, i.e. the manufacturer
> must make reasonable attempt to prevent users from using non-permitted
> frequencies.
>
> Not permitting the firmware to be redistributed has nothing to do with
> the FCC, however.

That's right.  Intel permits you to redistribute their firmware under =20=

the terms of their license.

>> This isn't a matter of choice on Intel's part; if you want this
>> situation to change, you're going to have to obtain changes in the
>> radio-frequency laws and policies in the US and a number of other
>> countries first.
>
> No, firmware redistribution is ENTIRELY up to Intel. I want the
> firmware to be available under a BSD or ISC licence, just as with
> Ralink. Intel's firmware is already available, but under a different
> licence. Where does the FCC say that Intel must distribute firmware
> under a non-OSS-friendly licence?

The BSD license and all other OSS-friendly licenses permit the user =20
to modify the software and redistribute that modified version as a =20
derivative work.  A modified version of the firmware has not received =20=

FCC certification-- see Title 47 of the Code of Federal Regulations, =20
Chapter I, section 15 in general, and specificly:

http://www.access.gpo.gov/nara/cfr/waisidx_05/47cfr15_05.html

"Sec. 15.21  Information to user.

     The users manual or instruction manual for an intentional or
unintentional radiator shall caution the user that changes or
modifications not expressly approved by the party responsible for
compliance could void the user's authority to operate the equipment."

"Sec. 15.202  Certified operating frequency range.

     Client devices that operate in a master/client network may be
certified if they have the capability of operating outside permissible
part 15 frequency bands, provided they operate on only permissible part
15 frequencies under the control of the master device with which they
communicate. Master devices marketed within the United States must be
limited to operation on permissible part 15 frequencies. Client devices
that can also act as master devices must meet the requirements of a
master device."

Also see:

http://www.fcc.gov/cgb/consumerfacts/unauthorizedradio.html

"Section 301 of the Communications Act of 1934 prohibits the =93use or =20=

operation of any apparatus for the transmission of energy or =20
communications or signals by radio=94 without a license issued by the =20=

Federal Communications Commission (FCC). Thus, generally, in order to =20=

use or operate a radio station, the Communications Act requires that =20
you first obtain a license by the FCC.
However, there are certain limited exceptions. For example, the FCC =20
has provided blanket authorization to operators of Citizens Band (CB) =20=

radios, radio control stations, domestic ship and aircraft radios and =20=

certain other types of devices. This blanket authorization means that =20=

operators of these radio facilities are not required to have =20
individual station licenses. Operators are required to operate their =20
stations in a manner consistent with the FCC=92s operational and =20
technical rules for those services. Failure to do so could be =20
considered an unauthorized operation."

>> Again, is there some part of this that is unclear or which you fail
>> to understand?
>
> Yes, precicely, I don't understand why you think FCC requires Intel to
> not release the firmware under a BSD-like licence.

If Intel's wireless adaptors were not capable of operating beyond the =20=

power and frequency limits specified by the FCC and ETSI, they =20
probably would have more flexibility-- but that is just a guess.

>> It might suit OpenBSD's advocacy purposes to deliberately
>> misrepresent Intel's position, but doing so is unfair and is not
>> especially helpful to the FreeBSD community, which does have somewhat
>> decent relations with vendors like Intel, Lucent, Aironet, Broadcomm,
>> and so forth.
>>
>> As to the point raised above, the firmware license actually does
>> permit an individual user, including an OS developer, to copy and
>> redistribute the software to others, so long as the recepient agrees
>> to the license terms:
>>
>> "LICENSE. You may copy and use the Software, subject to these
>> conditions:
>> 1. This Software is licensed for use only in conjunction with Intel
>> component products. Use of the Software in conjunction with non-Intel
>> component products is not licensed hereunder.
>
> So if I don't have an Intel Wireless in the system, is it still legal
> to have the firmware in my system files?

Presumably that would be copyright infringement, but talk to your =20
lawyer if you want a qualified opinion.

>> 2. You may not copy, modify, rent, sell, distribute or transfer any
>> part of the Software except as provided in this Agreement, and you =20=

>> agree to
>> prevent unauthorized copying of the Software.
>> 3. You may not reverse engineer, decompile, or disassemble the =20
>> Software.
>
> What's exactly the purpose of this term, if reverse engineering is
> permitted under many jurisdictions? Is it just to scare potentional
> reverse-engineers?

Reverse-engineering software is permitted in many jurisdictions, but =20
it does not grant you the right to violate the terms of the original =20
license; it is a way of letting you write your own software which you =20=

can license as you please.

Open-source licenses permit "reverse engineering"; indeed, by making =20
the sources available, they do all they can to facilitate other =20
people using and modifying the software.  The IWI firmware license =20
forbids "reverse engineering" because because Intel doesn't want to =20
be held liable for people modifying and misusing their wireless =20
adaptors outside of certified configurations.

>> If a project such as OpenBSD wishes to redistribute the software,
>> then it would probably be considered an Independent Software Vendor,
>> and again the firmware license grants permission to redistribute the
>> Intel Pro Wireless software, under the following terms:
> [ ... ]
>
> Chuck, if the licence is as good as you make it sound,

The license is what it is.

I have said nothing about approving it as a "good license", and I =20
have no special interest in promoting it or Intel's products.  While =20
I have been an active member of the OSI's <license-=20
discuss@opensource.org> mailing list for several years, it is obvious =20=

that the Intel firmware license would not comply with the OSD and =20
would never be considered an Open Source license.

> would you tell me why FreeBSD, OpenBSD, Debian GNU/Linux and a lot =20
> of other systems
> do not include the firmware in the base system?

I'm a FreeBSD contributor and I maintain a number of ports, but I =20
don't speak for FreeBSD (or Intel, OpenBSD, or other projects).  In =20
the case of FreeBSD, IMHO we have no desire to include firmware under =20=

a restrictive license into the base system.

Instead, we handle such cases by putting them into the ports tree and =20=

providing a mechanism (a shell script which looks for the user to =20
agree to the terms of the proprietary license) for the user to =20
install the firmware if they choose to do so.

> If you think downloading firmwares and accepting tonnes of EUAs is
> completely normal, then why is fxp(4) firmware/microcode/whatever it's
> called in fxp(4) is included in every OpenBSD and FreeBSD release?

The fxp(4) firmware is used by an ethernet NIC, which is not subject =20
to the same regulatory process and requirements that the software =20
radio in a 802.11 wireless adaptor is.

--=20
-Chuck




Want to link to this message? Use this URL: <http://docs.FreeBSD.org/cgi/mid.cgi?1A4EA09D-4BAD-4968-8500-43A765CA0988>