Re: ipw(4) and iwi(4): Intel's Pro Wireless firmware licensing problems
On 06/10/06, Chuck Swiger <[EMAIL PROTECTED]> wrote: On Oct 5, 2006, at 7:31 PM, Constantine A. Murenin wrote: > On 05/10/06, Chuck Swiger <[EMAIL PROTECTED]> 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=ipw >> > http://www.freebsd.org/cgi/man.cgi?query=iwi >> >> 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) >> 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 with them, but your claim that the FreeBSD manpages do not say anything about the need for firmware is obviously mistaken. How is the claim obviously mistaken if the man-page DO NOT say what's the reason that the firmware must be downloaded from a web-site? >> 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 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 to modify the software and redistribute that modified version as a derivative work. A modified version of the firmware has not received FCC certification-- see Title 47 of the Code of Federal Regulations, 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." Right, this means a notice on the device or supporting documentation. It does not require a legal term in the firmware's licence. "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 "use or operation of any apparatus for the transmission of energy or communications or signals by radio" without a license issued by the Federal Communications Commission (FCC). Thus, generally, in order to use or operate a radio station, the Communications Act requires that you first obtain a
Re: ipw(4) and iwi(4): Intel's Pro Wireless firmware licensingproblems
On 05/10/06, Matt Emmerton <[EMAIL PROTECTED]> wrote: > On 05/10/06, Chuck Swiger <[EMAIL PROTECTED]> 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=ipw > > > http://www.freebsd.org/cgi/man.cgi?query=iwi > > > > 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) 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. It's required by Intel's choice of licence for the firmware for that wireless NIC. Where did you find that in the man-pages? > Not permitting the firmware to be redistributed has nothing to do with > the FCC, however. > 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? It doesn't. However, most licences allow derivative works to be created outside of Intel's control. If one of these derivative work allows the device to be used in a manner that violates FCC rules and regulations, Intel remains liable because they a) the provider of the hardware device in question and b) the provider of the initial software (that spawned the derivative work) As I see it, no matter what Intel does, a) and b) will always be the case -- reverse-engineering efforts still have to use Intel's original software to produce any viable results. I.e. by extending your argument slightly further, Intel is screwed anyway. There is nothing stopping Intel from releasing the firmware, except for the legal fear that the FCC will hold them accountable for illegal acts performed with their device. Even if the original document does not allow one to distribute derivative works, anyone can still post complicated instructions on modifying Intel's binaries such that the device violates the law. I strongly doubt FCC would hold Intel accountable if any user follows those complicated instructions, as it's almost impossible for Intel to control those kind of things. Intel should not write their own law, they should just make sure that customers are unlikely to disrespect FCCs laws. FCC laws, on the other hand, never say that manufacturers have to keep completely secret anything about their wireless devices. Distributing the very same firmware that already available under another licence doesn't have anything to do with one's ability to respect or disrespect the FCC laws. Put it the other way around -- if Intel doesn't distribute the firmware on terms acceptable to the end user, then it basically _forces_ the user to come up with their own firmware, or use some alternative firmwares. And what if alternative firmwares violate FCC? Then who's fault is that? It is now clearly Intel's fault, because they've made it legally difficult for the user to use the original Intel firmware. I.e. Intel is better off distributing the firmware under a BSD or ISC licence, unless it wants problems with their devices with the FCC. Cheers, Constantine. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ipw(4) and iwi(4): Intel's Pro Wireless firmware licensing problems
On 05/10/06, Chuck Swiger <[EMAIL PROTECTED]> 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=ipw > http://www.freebsd.org/cgi/man.cgi?query=iwi 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) 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. > If you are curious as to why things are the way they are, I suggest > that you check the problems that are described in the misc@openbsd.org > mailing list, and contact Intel people and say what you think about > their user-unfriendly policy in regards to Intel Pro Wireless > firmwares, which are REQUIRED to be loaded from the OS before the > device functions, i.e. the OS developers must be allowed to freely > distribute the firmware in order for the devices to work > out-of-the-box. 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. 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? 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. > For some recent information about Intel being an Open Source Fraud, > see http://marc.theaimsgroup.com/?l=openbsd- > misc&m=115960734026283&w=2. The firmware license for these devices has never been submitted to the OSI board for approval as an Open Source license, and I have never seen Intel claim that this license is an Open Source license. 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? 2. You may not copy, modify, rent, sell, distribute or transfer any part of the Software except as provided in this Agreement, and you agree to prevent unauthorized copying of the Software. 3. You may not reverse engineer, decompile, or disassemble the 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? 4. You may not sublicense the Software. 5. The Software may contain the software or other property of third party suppliers. [ ... ] You may transfer the Software only if a copy of this license accompanies the Software and the recipient agrees to be fully bound by these terms." If a p
ipw(4) and iwi(4): Intel's Pro Wireless firmware licensing problems
Hi, My acquaintance with Unix started with FreeBSD, which I used for quite a while before discovering OpenBSD. I now mostly use OpenBSD, and I was wondering of how many FreeBSD users are aware about the licensing restrictions of Intel Pro Wireless family of wireless adapters? 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=ipw http://www.freebsd.org/cgi/man.cgi?query=iwi If you are curious as to why things are the way they are, I suggest that you check the problems that are described in the misc@openbsd.org mailing list, and contact Intel people and say what you think about their user-unfriendly policy in regards to Intel Pro Wireless firmwares, which are REQUIRED to be loaded from the OS before the device functions, i.e. the OS developers must be allowed to freely distribute the firmware in order for the devices to work out-of-the-box. For some recent information about Intel being an Open Source Fraud, see http://marc.theaimsgroup.com/?l=openbsd-misc&m=115960734026283&w=2. Cheers, Constantine. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: wikipedia article
On 11/06/06, Hámorszky Balázs <[EMAIL PROTECTED]> wrote: I'm looking for some help on an article on wikipedia. http://en.wikipedia.org/wiki/Comparison_of_open_source_operating_systems Whilst there, what about another important article that seems to have a Linux POV? http://en.wikipedia.org/wiki/Comparison_of_Open_Source_Wireless_Drivers ;) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ee(1): why Backspace doesn't work as expected if $TERM=xterm?
On 07 Dec 2005 09:27:48 -0500, Lowell Gilbert <[EMAIL PROTECTED]> wrote: > "Constantine A. Murenin" <[EMAIL PROTECTED]> writes: > > > Hello, > > > > When I ssh my FreeBSD 4.8 machine and try to use ee(1), I always > > notice that Backspace erases the following character, not the previous > > one. On the contrary, I've noticed that it does not do that when I > > login via console. > > > > So I decided to play with the value of $TERM. > > > > By default, when I ssh FreeBSD via PuTTY or Apple Terminal, I have the > > TERM variable set to "xterm" or "xterm-color". When I tried to > > manually change $TERM on FreeBSD and run ee, using "setenv TERM vt102 > > && ee test.txt", then Backspace key in ee(1) did behave as expected. > > > > Please, notice that Backspace does behave as expected in tcsh, it's > > only ee(1) that shows this problem. > > > > How do I fix it without changing $TERM? > > Offhand, it sounds as though your terminal programs aren't really > emulating xterms perfectly. Look for adjustments on how they map the > backspace key... They map it perfectly fine as 127, it's only FreeBSD's ee(1) that has this problem, tcsh and others work fine. Notice that ee(1) on OpenBSD from ports works fine from the very same terminals (PuTTY etc). Problem exists only with FreeBSD's ee(1). Cheers, Constantine. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ee(1): why Backspace doesn't work as expected if $TERM=xterm?
Hello, When I ssh my FreeBSD 4.8 machine and try to use ee(1), I always notice that Backspace erases the following character, not the previous one. On the contrary, I've noticed that it does not do that when I login via console. So I decided to play with the value of $TERM. By default, when I ssh FreeBSD via PuTTY or Apple Terminal, I have the TERM variable set to "xterm" or "xterm-color". When I tried to manually change $TERM on FreeBSD and run ee, using "setenv TERM vt102 && ee test.txt", then Backspace key in ee(1) did behave as expected. Please, notice that Backspace does behave as expected in tcsh, it's only ee(1) that shows this problem. How do I fix it without changing $TERM? Thanks, Constantine. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
healthd does not show the correct temperature
Hello, The healthd does not seem to show the correct temperature on my system. Right after the start-up, BIOS usually shows around 31 centigrade for the motherboard and 21 for the processor. However, this is what the healthdc is usually showing right after the start-up of the FreeBSD after the start-up of the computer: host.name 62.0 15.0 69.0 3096 1.46 1.50 3.31 5.03 11.86 -11.62 -4.80 Then after a few minutes of ideling, BIOS would show the temperature of the processor at around 30 or 35. healthdc shows this: host.name 72.0 38.0 70.5 3096 1.46 1.50 3.31 5.03 11.86 -11.62 -4.80 UPDATE: Above lines refer to the standard heatsink and Intel Pentium 1.8A Northwood processor. Right now, as I have installed Zalman Fan Mate 1, the healthd does not show the speed of the processors fan, while BIOS still shows it at around 1500 rpm. He is what I get if I run `healthd -d`: %healthd -d * Hardware Information * WinBond Chip: W83627HF Temp.= 68.0, 51.5, 70.0; Rot.=0,0,0 Vcore = 1.46, 1.50; Volt. = 3.33, 5.03, 11.86, -11.62, -4.85 Temp.= 67.0, 51.5, 70.0; Rot.=0,0,0 Vcore = 1.46, 1.50; Volt. = 3.33, 5.03, 11.86, -11.62, -4.80 Temp.= 67.0, 51.5, 70.0; Rot.=0,0,0 Vcore = 1.46, 1.52; Volt. = 3.33, 5.03, 11.86, -11.62, -4.80 Temp.= 67.0, 51.5, 70.0; Rot.=0,0,0 Vcore = 1.46, 1.50; Volt. = 3.33, 5.03, 11.86, -11.62, -4.80 Thanks, Constantine. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Doug Richardson is (probably) back online
On Mon, 21 Mar 2005 20:45:10 -0700, Ben Goren <[EMAIL PROTECTED]> wrote: > On 2005 Mar 21, at 4:47 PM, Constantine A. Murenin wrote: > > > In reading any document, one should never undoubtedly believe > > everything it says. :-) > > I don't believe you. I told ya! :-) P.S. I had a multiple-choice test in philosophy; in the true/false section of the test, the following question was given: The answer to this question is false. a. True b. False (c) 2004 Dr. Wisnewski. :-) Cheers, Constantine. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
