From: David Miller <davem@davemloft.net>
To: thinkinginbinary@gmail.com
Cc: linux-kernel@vger.kernel.org, dl8bcu@dl8bcu.de,
alon.barlev@gmail.com, s0348365@sms.ed.ac.uk,
linville@tuxdriver.com, joesmidt@byu.net
Subject: Re: Will there be Intel Wireless 3945ABG support?
Date: Tue, 11 Jul 2006 18:10:01 -0700 (PDT) [thread overview]
Message-ID: <20060711.181001.11575463.davem@davemloft.net> (raw)
In-Reply-To: <20060712004212.GA26712@phoenix>
From: Thomas Tuttle <thinkinginbinary@gmail.com>
Date: Tue, 11 Jul 2006 20:42:12 -0400
> Frankly, I'm annoyed that, if Intel understood the full extent of the
> problem, that they didn't take a better approach and simply give the
> card a set of legal values. It doesn't need to understand the
> subtleties of what they mean. It just needs to know frequencies 1, 2,
> and 3 are okay, but not 4, 5, and 6, and that the max power is xx dBm.
You miss many important issues in your diatribe. I don't like the
situation either, but I hold this position understanding the
conditions (both technical and legal) under which companies such as
Atheros and Intel must operate.
First off, the reason these radios are fully programmable, not fixed
in on-board firmware or likewise, is so that people doing "special
stuff" outside the normal operating frequencies and power levels, and
have a license to do so, can use these wireless chips out of the box.
Otherwise custom boards would need to be produced and that is
prohibitively expensive and restrictive for what some of these
folks want to do.
Such companies can thus provide firmware or drivers that operate
within a customer's specially licensed frequency or power range once
that customer proves they do indeed have a license from the FCC to use
it.
Secondarily, it is up to lawyers, not you, to decide what is a safe
manner for the maker of a wireless chipset to abide by the FCC
regulations. And across the board, lawyers representing these
companies and other entities seem to agree that providing the full
source code to a wireless chip driver's radio programming makes
it "user-modifiable", whereas hiding the radio programming behind
a binary-only blob or firmware satisfies the FCC requirements.
And if you think they haven't invested any effort to look into
alternatives that will satisfy both the FCC and the open source crowd,
think again. You can be sure they've spent a lot of time thinking
about how to deal with this. It is absurd to say things which suggest
that these guys are sitting around twiddling their thumbs about the
issue, and think the current state of affairs is ok.
It's not a matter of "impossible" vs. "possible" to modify the
frequencies and power levels outside of the allowed range, rather it's
a matter of making it "difficult enough" for an end user to modify
these restrictions.
As long as it's Intel's or Atheros's ass that gets reamed by the FCC
for running afoul of the radio frequency regulations, they will not be
posting the source code to program their radios. On the other hand,
if it happens to get legally reverse engineered, then unless these
companies assisted in that reverse engineering effort, the FCC really
couldn't go after them. Such companies would also not be able to
participate in maintainence of a driver for their chips containing
the reverse engineered components. However, we've dealt with that
kind of situation just fine in the past :)
So we will be in this endless loop finding ways to legally reverse
engineer binary blobs to get fully free wireless drivers, until the
FCC regulation situation is rectified.
next prev parent reply other threads:[~2006-07-12 1:09 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-07-11 16:32 Will there be Intel Wireless 3945ABG support? Joseph Michael Smidt
2006-07-11 16:47 ` Otavio Salvador
2006-07-11 17:12 ` John W. Linville
2006-07-11 18:09 ` Alistair John Strachan
2006-07-11 18:25 ` Alon Bar-Lev
2006-07-11 18:43 ` Alistair John Strachan
2006-07-11 18:55 ` Alan Cox
2006-07-11 19:18 ` Matthieu CASTET
2006-07-11 20:22 ` Daniel Bonekeeper
2006-07-11 22:22 ` Matthew Garrett
2006-07-11 23:54 ` H. Peter Anvin
2006-07-12 0:04 ` Matthew Garrett
2006-07-12 0:35 ` James Ketrenos
2006-07-12 1:19 ` David Miller
2006-07-12 11:30 ` Alan Cox
2006-07-12 17:17 ` Alon Bar-Lev
2006-07-12 22:09 ` David Schwartz
2006-07-11 20:16 ` Thorsten Kranzkowski
2006-07-12 0:42 ` Thomas Tuttle
2006-07-12 0:57 ` H. Peter Anvin
2006-07-12 1:10 ` David Miller [this message]
2006-07-12 1:15 ` Valdis.Kletnieks
2006-07-12 8:19 ` Alistair John Strachan
2006-07-12 8:23 ` Alistair John Strachan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20060711.181001.11575463.davem@davemloft.net \
--to=davem@davemloft.net \
--cc=alon.barlev@gmail.com \
--cc=dl8bcu@dl8bcu.de \
--cc=joesmidt@byu.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linville@tuxdriver.com \
--cc=s0348365@sms.ed.ac.uk \
--cc=thinkinginbinary@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox