From owner-freebsd-current@FreeBSD.ORG Thu Jul 24 20:21:43 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0DD2537B401 for ; Thu, 24 Jul 2003 20:21:43 -0700 (PDT) Received: from topperwein.pennasoft.com (user194.net105.oh.sprint-hsd.net [65.164.21.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id B689543F75 for ; Thu, 24 Jul 2003 20:21:41 -0700 (PDT) (envelope-from behanna@behanna.org) Received: from topperwein.pennasoft.com (topperwein.pennasoft.com [192.168.168.10])h6P3LeED031101 for ; Thu, 24 Jul 2003 23:21:40 -0400 (EDT) (envelope-from behanna@behanna.org) Date: Thu, 24 Jul 2003 23:21:35 -0400 (EDT) From: Chris BeHanna Sender: behanna@topperwein.pennasoft.com To: freebsd-current@freebsd.org In-Reply-To: <20030723223007.AD92C5D07@ptavv.es.net> Message-ID: <20030724231947.I30706@topperwein.pennasoft.com> References: <20030723223007.AD92C5D07@ptavv.es.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: We have ath, now what about Broadcom? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: chris@behanna.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2003 03:21:43 -0000 On Wed, 23 Jul 2003, Kevin Oberman wrote: > > From: "Matthew Emmerton" > > Date: Wed, 23 Jul 2003 18:21:23 -0400 > > > > > The folks at Broadcom have not been willing to release any information > > > on their 800.11g chips for fear of violating FCC regs. The required > > > NDA would prohibit the release of the source. You can program > > > both the transmit power and frequency if you have this. (I make no > > > claim as to whether their concerns have any validity.) > > > > > > For that reason there has been no open-source support for these chips. > > > > Why would Broadcom be scared? Obviously it's the _driver_ that controls the > > power/freq output of the chip, so the responsibility of staying within FCC > > regs is that of the driver authors. Of course, the "no warranty" aspects of > > open source drivers turns a blind eye to liability, but would things really > > come back to Broadcom? > > The logic is simple. the FCC hold the manufacturer responsible for > improper RF from any product. The Broadcom chip makes it easy to > generate illegal RF if you know where to poke. Can't they just redact that information from the spec.? -- Chris BeHanna Software Engineer (Remove "bogus" before responding.) chris@behanna.org I was raised by a pack of wild corn dogs.