Hi,
I read at linuxwireless.org that "madwifi is not fully open source".
If I understand correctly, this is because they put the radio-related code
in a binary module, to meet regulatory requirements.
If so, all the other drivers, which are not marked as "not fully open source",
did release their RF code as open source ? How could that be ?
Wouldn't they have regulatory problems ?
What should a new vendor, planning to write a driver, do ? Open Source
everything, and expect legal issues, or release RF code as binary-only ?
Thanks!!
Budhee
"ext Dan Williams" <[email protected]> writes:
>> If I understand correctly, this is because they put the radio-related code
>> in a binary module, to meet regulatory requirements.
>
> To meet _their__interpretation_ of regulatory requirements.
lwn.net had an article about this:
http://lwn.net/Articles/240840/
--
Kalle Valo
On Tue, 2008-02-12 at 00:27 +0200, Budhee Jamaich wrote:
> Hi,
>
> I read at linuxwireless.org that "madwifi is not fully open source".
Correct.
> If I understand correctly, this is because they put the radio-related code
> in a binary module, to meet regulatory requirements.
To meet _their__interpretation_ of regulatory requirements. Theirs is
not the only interpretation that exists, and other vendors like Intel
and zydas interpret the requirements differently and have implemented
different approaches to the regulatory issues.
> If so, all the other drivers, which are not marked as "not fully open source",
> did release their RF code as open source ? How could that be ?
> Wouldn't they have regulatory problems ?
Not opening the RF regulatory code is the solution that Atheros took. I
can't (off the top of my head) think of any other vendor who has done
this. Other vendors are much more open-source friendly while still
following what they believe is a sufficient interpretation of the
regulations.
> What should a new vendor, planning to write a driver, do ? Open Source
> everything, and expect legal issues, or release RF code as binary-only ?
Talk to your lawyers. You do not necessarily have legal issues if you
open the RF regulatory code, but you must talk to your own lawyers to
find out what's best for your company. You have a few options (not
limited to the following):
1) Make the RF regulatory code a closed, binary module like Atheros has
done that is linked directly into the kernel module. Your module is
probably illegal (again, consult your lawyer on linking non-GPL code to
GPL code), and your driver _certainly_ will not be accepted by the
upstream kernel. Your hardware will have to be reverse-engineered by
the open source community to produce a free driver and people will
dislike you and your company :)
2) Keep your RF regulatory code open and hook it into the mac80211
regulatory framework like most other open drivers are doing. Again,
consult your lawyers on whether or not they feel this is an acceptable
solution. Your driver can be accepted into the upstream kernel, hordes
of developers will improve your driver for you, and everyone is happy.
3) Put your RF regulatory code into the _firmware_ of your device (this
is what Intel has done with 3945 and 4965 parts). This is very
acceptable, but still be sure to consult your lawyers. Your driver can
be accepted into the upstream kernel, hordes of developers will improve
your driver for you, and everyone is happy.
The problem is only when the closed code is running on the _host_ CPU
and linked to GPL kernel code, like Atheros has done with madwifi. This
has caused the current ath5k effort, which uses a reverse-engineered
open HAL which has just been accepted into the upstream 2.6.25 kernel.
Whatever code is in firmware is not subject to the GPL-related linkage
legal issues like madwifi is.
If you do have firmware for your device, _please_ consider using a
license like Intel has for their 2100, 2200, 2915, 3945, and 4965
devices that permits redistribution of the microcode. You can
_certainly_ still protect your company's intellectual property and also
allow unlimited redistribution of the microcode. This means that users
will not have to search out your firmware or run "cutter" tools on it,
but can have it installed by default and have your hardware work out of
the box! Many happy users.
If you want to see the license, download and uncompress this:
http://intellinuxwireless.org/iwlwifi/downloads/iwlwifi-4965-ucode-4.44.1.20.tgz
Hope this helps, feel free to ask further questions if some things
aren't clear enough.
Dan
> So it seems like your three options translate to:
> 1. full Open Source: happy Open Source developers (+), can't
> sell device (big -)
> 2. firmware RF code: happy FOSS ppl (+), can sell device
> (+), depends on chip design...(not always
> possible)
> 3. RF blob: mad FOSS ppl (- but can live with if no other
> option), can sell device(+)
If your device really doesn't have a firmware (some claim
firmware is necessary to ensure real-time properties of the
protocol) then you could also do:
4. write the driver for Windows in the usual, close source
form, "leak" or give docs to some Linux developers and
let they write the driver for the device. FCC can't object,
you didn't wrote the driver :-)
Chances are actually quite high that the Linux people write a
better driver than you :-)
Did you know about Greg Kroah-Hahn's "driver for free" incentive?
http://www.kroah.com/log/linux/free_drivers.html
> Not opening the RF regulatory code is the solution that Atheros took. I
> can't (off the top of my head) think of any other vendor who has done
> this. Other vendors are much more open-source friendly while still
> following what they believe is a sufficient interpretation of the
> regulations.
>
There are also vendors that haven't even provided any driver for
linux/bsd. At least Atheros provided us with a driver that worked (and
it worked pretty well/helped on net80211 stack etc) and on the early
days they even provided support on the lists. Let's be more easy on
them, they also did what their lawyers told them ;-)
--
GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick
On Tue, Feb 12, 2008 at 10:13:47AM +0100, Holger Schurig wrote:
> 4. write the driver for Windows in the usual, close source
> form, "leak" or give docs to some Linux developers and
> let they write the driver for the device. FCC can't object,
> you didn't wrote the driver :-)
"FCC can't object"...this is only true to a point. Sure, AFAIK the
FCC can do nothing to discipline the software developer in question.
However, the FCC retains broad discretionary authority over the
hardware manufacturer. So if a driver appeared that enabled "bad
things" to happen with certain hardware, regulators might revoke
that device's certification. This would be very expensive for a
manufacturer and is the root of all wireless vendor non-cooperation.
FWIW, my opinion is that this should be resolvable from a business
perspective. The existence of an open source driver should represent
a quantifiable financial risk -- a risk that is already present
in some form anyway due to the existence of people with reverse
engineering skills. Any decent business is good at managing risk,
and any number of (re-)insurance firms exist to handle the finances
involved with that. It seems to me that a business should be able to
insure against potential losses at a rate that is more than offset by
the gains of being strong in the burgeoning Linux market. Of course,
if I were a brilliant business man...well, YMMV... :-)
John
--
John W. Linville
[email protected]
On 12/02/2008, Holger Schurig <[email protected]> wrote:
> If your device really doesn't have a firmware (some claim
> firmware is necessary to ensure real-time properties of the
> protocol) then you could also do:
>
> 4. write the driver for Windows in the usual, close source
> form, "leak" or give docs to some Linux developers and
> let they write the driver for the device. FCC can't object,
> you didn't wrote the driver :-)
I don't see any reason (except finaincial) for a chip to have what is
currently, for many drivers, in firmware, already in a
ROM/EEPROM/Flash on the device.
Firmware upgrades can be made via some upgrade tool (please provide
such a tool for linux, too, even if closed source).
> Chances are actually quite high that the Linux people write a
> better driver than you :-)
>
>
> Did you know about Greg Kroah-Hahn's "driver for free" incentive?
> http://www.kroah.com/log/linux/free_drivers.html
I think the canonical place for wireless drivers is
http://linuxwireless.org/en/vendors/DriverDevelopment
--
Regards,
EddyP
=============================================
"Imagination is more important than knowledge" A.Einstein
On Tue, Feb 12, 2008 at 9:17 AM, John W. Linville
<[email protected]> wrote:
> On Tue, Feb 12, 2008 at 10:13:47AM +0100, Holger Schurig wrote:
>
> > 4. write the driver for Windows in the usual, close source
> > form, "leak" or give docs to some Linux developers and
> > let they write the driver for the device. FCC can't object,
> > you didn't wrote the driver :-)
>
> "FCC can't object"...this is only true to a point. Sure, AFAIK the
> FCC can do nothing to discipline the software developer in question.
> However, the FCC retains broad discretionary authority over the
> hardware manufacturer. So if a driver appeared that enabled "bad
> things" to happen with certain hardware, regulators might revoke
> that device's certification. This would be very expensive for a
> manufacturer and is the root of all wireless vendor non-cooperation.
>
> FWIW, my opinion is that this should be resolvable from a business
> perspective. The existence of an open source driver should represent
> a quantifiable financial risk -- a risk that is already present
> in some form anyway due to the existence of people with reverse
> engineering skills. Any decent business is good at managing risk,
> and any number of (re-)insurance firms exist to handle the finances
> involved with that. It seems to me that a business should be able to
> insure against potential losses at a rate that is more than offset by
> the gains of being strong in the burgeoning Linux market. Of course,
> if I were a brilliant business man...well, YMMV... :-)
Warning: IANAL
I'd think all modern wireless companies would incur a potential risk
then -- whether they support FOSS or not. So I'd think most companies
would need this insurance right now.
But lets talk some common sense. SDRs are driving the industry,
whether they are certified under part 15 rules or not as even firmware
can be reversed engineered. This and the fact that I see pure SDRs
(GNU Radio) are being used in the latest wireless research [1] seems
to indicate they are the wave of the future and we should simply focus
on trying to enhance regulatory bodies instead of ignoring the issue.
Now when I rent a car and move it out of the company's lot I could
technically just drive in a rush and run over a lot of people at the
local Starbucks, lets say being heavily inspired after playing Grand
Theft Auto. Legally I am responsible, not the Car rental company and
maybe not even the game maker company which provided inspiration.
Common sense tells me that it is very silly that wireless companies or
their direct-customers (OEMs) could be held liable for use of
unsupported drivers or modified drivers which make their hardware
behave in manners in which they were not intended for. IMHO the person
who makes the device operate out-of-bounds of the supported or
acceptable legal regulatory laws should be held liable, not the
company -- as would be the case if I go off in a driving rampage with
my next car rental. That piece of legislation is what I think needs
updating instead of playing along the the more proven-incorrectly
security-by-obscurity approach that some vendors have followed after
interpretation of regulatory laws. Because anyway if certifying under
part 15 rules my interpretation is you are certifying the hardware and
not the software so -- AFAICT this certification is software agnostic.
If we want to talk about not being able to support the software then
lets talk about SDRs as those are the rules that apply when strictly
leaving software to handle a fine grain level of hardware operation.
There is a common problem in the wireless industry and that is fear of
getting labelled under SDR. Stop being afraid and use common sense.
And yes, of course, its easy for me to say that as I don't have a
wireless business or am part of of one. But I have previously made
suggestions as to how to sanely work through this problem in the short
term and in the long run. In the short term embrace a central
regulatory domain agent in the Operating System and in the long run
help shape legislation to pave the way for SDRs, in ways that actually
makes sense, not just out of fear.
Let me also remind you a section of GPLv2 perhaps overlooked:
"This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details."
Now quoting directly from GPLv2 preamble[2] :
"Also, for each author's protection and ours, we want to make certain
that everyone understands that there is no warranty for this free
software. If the software is modified by someone else and passed on, we
want its recipients to know that what they have is not the original, so
that any problems introduced by others will not reflect on the original
authors' reputations."
So you can do what you can but offer no warranty for it, you can stand
behind what is in place and patches that lie ahead for your driver.
[1] http://orbit-lab.org/wiki/Documentation/GNURadio
[2] http://www.fsf.org/licensing/licenses/info/GPLv2.html
Luis
On Tue, Feb 12, 2008 at 10:45:40AM +0200, Budhee Jamaich wrote:
> First - thank you for the detailed response!
Yes, thanks Dan!
> So even if a vendor is willng to completely Open Source it's code,
> having FCC troubles
> is a serious problem.
The answer of course is "it depends". For example, depending on the
device it might be possible to provide code to configure the device
in "good" ways without necessarily revealing how to configure it in
"bad" ways...YMMV. This may be more or less difficult depending on
the exact details of your hardware design.
> Is there any vendor who walked this path ? complete Open Source RF code ?
> If yes, has it's chip got FCC certified ?
The rtl8180 driver does not use any firmware and is completely open
source. The driver code contains lots of "magic number" tables related
to initializing and configuring the device. I don't know enough
about the hardware to tell you if the hardware is flexible enough
to be easily forced into non-compliant power or frequency settings,
so I can't really characterize the risk to Realtek.
I do know that Realtek supported rtl8180 driver development with
datasheets and access to developers. Presumably they feel that
whatever risk there is is acceptable to their business.
Hth!
John
--
John W. Linville
[email protected]
Hi Dan,
First - thank you for the detailed response!
I have some further questions:
On Feb 12, 2008 12:48 AM, Dan Williams <[email protected]> wrote:
> On Tue, 2008-02-12 at 00:27 +0200, Budhee Jamaich wrote:
> > What should a new vendor, planning to write a driver, do ? Open Source
> > everything, and expect legal issues, or release RF code as binary-only ?
>
> Talk to your lawyers. You do not necessarily have legal issues if you
> open the RF regulatory code,
>From reading SFLC's and LWN's analysis of the situation (Thanks Kalle for
pointing me to it) I get the opposite impression. Seems like a vendor will
have to "demonstrate sufficient robustness with a fully free-software
implementation",
and that it "could still get certification. But it would not be easy".
So even if a vendor is willng to completely Open Source it's code,
having FCC troubles
is a serious problem.
>
> 2) Keep your RF regulatory code open and hook it into the mac80211
> regulatory framework like most other open drivers are doing. Again,
> consult your lawyers on whether or not they feel this is an acceptable
> solution. Your driver can be accepted into the upstream kernel, hordes
> of developers will improve your driver for you, and everyone is happy.
Is there any vendor who walked this path ? complete Open Source RF code ?
If yes, has it's chip got FCC certified ?
>
> 3) Put your RF regulatory code into the _firmware_ of your device (this
> is what Intel has done with 3945 and 4965 parts). This is very
> acceptable, but still be sure to consult your lawyers. Your driver can
> be accepted into the upstream kernel, hordes of developers will improve
> your driver for you, and everyone is happy.
Seems like a good option, but only if the design of the chip support
it (CCIIW pls).
If this idea is not supported in the hardware, we are left with the other
two options, both of each are not optimal.
So it seems like your three options translate to:
1. full Open Source: happy Open Source developers (+), can't sell device (big -)
2. firmware RF code: happy FOSS ppl (+), can sell device (+), depends on
chip design...(not always possible)
3. RF blob: mad FOSS ppl (- but can live with if no other option), can
sell device(+)
> Hope this helps, feel free to ask further questions if some things
> aren't clear enough.
Greatly helps, thanks again,
Budhee.
>
> Dan
>
>