| |||||||||||||
|
| |||||||||||||
Dealing with the regulatorsDealing with the regulatorsPosted Jan 26, 2007 1:43 UTC (Fri) by JoeBuck (subscriber, #2330)Parent article: A report from the Linux wireless developers meeting There should be some way to convince regulators that we can solve this without mandating closed source. After all, tinkerers can already build pure-hardware devices that violate FCC regulations (or the equivalent in wahtever country you are in), and we don't ban the sale of discrete resistors, capacitors, and inductors. But someone might build an oscillator that knocks out radio reception! The answer is that the end user who does that violates the regs. Perhaps something can be worked out with the FCC and other regulators that resembles the crypto-export compromise, where both sides understand the others' needs. Here's one possibility: separate out a constraint mechanism (e.g. limitations on frequencies and power to be used) from the driver itself, and design drivers to check constraints before reconfiguring the device. Constraints files can be kept separate, so that if you take your computer to a different country where the unlicensed wireless bands are different, you'd load a new constraints file to keep you legal in the new country. There could be a separate set of constraints that keep you from setting fire to the device (if some combinations of paramaters would cause excessive power consumption, for example). The code that actually enforces the constraints could be GPL, and could contain an advisory note that a user who changes the file might risk violation of radio regulations, not for the act of changing the file, but of possibly exceeding legal operating specs. The author and distributor would not be forbidding the end user from modifying the file(s), so the license would not be violated. As IANAL, I don't know whether it would be possible for some governments to only certify the device if some piece of the driver were unmodified. If the user is still permitted to distribute the code, modify it (with prominent notices saying it's been changed as the GPL requires), and distribute the result, maybe it's no violation of the GPL for a third party (a government) to say you can't operate a device that has a radio transmitter if the little piece that restricts the parameters has been changed. But we might be able to live with that.
(Log in to post comments)
Dealing with the regulators Posted Jan 26, 2007 13:11 UTC (Fri) by NAR (subscriber, #1313) [Link] maybe it's no violation of the GPL for a third party (a government) to say you can't operate a device that has a radio transmitter if the little piece that restricts the parameters has been changed.I guess not, but I'm not sure if it's legal to distribute the modified (uncertified) device which operates outside of the proper frequencies. I mean a couple of years ago a lots of people here bought devices which enabled them to watch HBO on cable even if they were not subscribed (and were not paying, of course). Even though the usage of such device is the thing that causes harm, I think the selling of such devices was also banned. But this could be a wrong analogy.
Dealing with the regulators Posted Jan 26, 2007 23:12 UTC (Fri) by proski (subscriber, #104) [Link] I think it's irrelevant. The problem with wireless cards is transmission on unauthorized frequencies on open air, and your example involves reception on the cable. Both the media and the mode of operation are different.
Dealing with the regulators Posted Jan 29, 2007 9:12 UTC (Mon) by cate (subscriber, #1359) [Link] Don't use strong word as illegal. Do you see authorities that enforces such rules? (and IANAL, AFAIK frequencies are not defined in laws but in very low level of legal hierarchy.) So should it be illegal to use your wireless connection on your laptop outside your country?
Dealing with the regulators Posted Jan 31, 2007 1:57 UTC (Wed) by proski (subscriber, #104) [Link] I didn't use the word "illegal". "unauthorized" doesn't necessarily imply that it's against the law.
FLOSS drivers are not a problem. The hardware vendors are the problem Posted Jan 26, 2007 15:17 UTC (Fri) by dwheeler (guest, #1216) [Link] Those are good ideas if having free-libre/open source software drivers was a problem. But it's not.The Free Software Foundation's information on wireless cards notes that the Ralink 2500/RT2400 and Realtek RTL8180 chips work well, which are in lots of cards (e.g., the Asus WL-107G PCMCIA card). As far as I can tell, the FCC doesn't actually forbid FLOSS releases. It's just an excuse by the makers.
FLOSS drivers are not a problem. The hardware vendors are the problem Posted Jan 26, 2007 17:43 UTC (Fri) by odie (guest, #738) [Link] Also worth noting that while the Intel chips run proprietary firmware, the drivers are GPL and work beautifully (at least the ipw2100). I personally don't mind too much running proprietary firmware on a wireless chip, as it is already an untrusted link.
FLOSS drivers are not a problem. The hardware vendors are the problem Posted Jan 26, 2007 18:30 UTC (Fri) by bronson (subscriber, #4806) [Link] The FCC also doesn't actually permit them. There are a number of rules that may imply that open source drivers are forbidden, or they may not. It will be up to a court to rule.
... and not a single vendor wants to be on the wrong side of that decision. So, for them, it's best to err on the side of caution.
FLOSS drivers are not a problem. The hardware vendors are the problem Posted Jan 27, 2007 0:12 UTC (Sat) by i3839 (subscriber, #31386) [Link] Binaries are the same as source code, except slightly harder to read and modify. I don't see how you can forbid one without the other in all fairness.
FLOSS drivers are not a problem. The hardware vendors are the problem Posted Feb 1, 2007 17:41 UTC (Thu) by bronson (subscriber, #4806) [Link] Let's be clear: no manufacturer actually forbids open source drivers. They just refuse to provide open drivers themselves. Why? Because that would be instant culpability if the FCC decides to interpret the currently ambiguous rules in a very unfriendly manner.
So, instead of opening themselves up to that risk, they simply do nothing. It's a terrible state of affairs. I wish I knew of something that would kock this logjam loose.
this sounds just like the state of ISDN a few years ago Posted Jan 27, 2007 2:01 UTC (Sat) by dlang (✭ supporter ✭, #313) [Link] various countries wouldn't allow opensource ISDN drivers due to the restrictions by the telco's about the equipment that could be plugged into their network), and the community worked around that by writing a set of drivers and getting them approved. after a few false starts things seem to be settled nowdays.
someone should research the history of this and what it took to make things work to see if a similar path can be followed by wireless
this sounds just like the state of ISDN a few years ago Posted Feb 1, 2007 15:02 UTC (Thu) by dion (subscriber, #2764) [Link] I guess the ISDN driver problem was solved by three things:
1) European telcos were privatized, so they lost their exclusive access to the copper and much of the BS simply went away, we have the EU to thank for this.
2) Prices on equipment dropped and the pressure to use winmodem like devices lessened, so a simple serial driver could be used in stead.
3) People stopped using ISDN because 64kbit/s just isn't so sexy any more.
this sounds just like the state of ISDN a few years ago Posted Feb 2, 2007 12:56 UTC (Fri) by laf0rge (subscriber, #6469) [Link] I completely agree, and I have addressed this fact (in netdev circles) before.
With isdn4linux, there was one vendor (ELSA?) who funded the certification/approval process for one specific i4l version. It took quite a bit of time, since they actually tested all the protocol state transitions, etc.
After this was done, this actually was a business advantage to the vendor. The stack was only certified for their card[s]. So anyone deploying i4l in a commercial environment wanted to use their cards. Obviously with passive ISDN cards, all other cards would also behave exactly identical - but they were missing regulatory approval.
Obviously, using a later i4l version and/or applying bugfixes to the source code also voids the approval, and in order to use it legally, you would need to re-certify.
|
|
||||||||||||