On Wed, Sep 22, 2010 at 4:14 AM, David Woodhouse <dw...@infradead.org> wrote:
> On Wed, 2010-09-22 at 07:05 +0200, Michael Büsch wrote:
>>
>> + Broadcom enabled the development of this driver, by providing all required
>> + hardware information in the form of binary software drivers.
>>
>> Let me rephrase the comment a little bit. I will not change the
>> meaning :)
>>
>> + Certain lawyers are wrong, and this driver proves it.
>> + http://tinyurl.com/ybl83uw
>>
>> That's basically all it says. No more, no less.
>
> Fairly close :)
>
> But it's a little more than that. It's more like:
>
> + I know you're scared that the world will end if you 'enable' this
> + driver in any way... but *look* -- you've actually been 'enabling'
> + if from the very beginning, and you haven't been eaten by a grue
> + yet. So please get over your stupid paranoia, and work with us
> + sensibly for once. Which would include:
> + - letting us have permission to distribute the firmware.
> + - giving us the odd hint about how to fix/improve the driver.
> + - merging your new driver with the existing one, if appropriate.
> + - etc.
>
> It does us no harm to make it explicitly clear that the driver
> development was 'enabled' by what Broadcom published. And if it has
> *any* chance of showing the paranoid factions in Broadcom that their
> fears are baseless, it has the potential to be helpful.
There even some more technical arguments which can help clear the fuzz
from paranoia. There are two options:
1) Do nothing
This was already done and when this is done this actually turns
out putting
a vendor in the worst situation since it creates huge
independent motivation
by the community to reverse engineer drivers. This yields both
lower quality
drivers and likely regulatory-broken drivers.
2) Work upstream
You proactively accept that although security through obscurity
can hold back a few people, with enough motivation its pointless, and
you can actually end up in better place by working with proper
technical solutions
to the regulatory problem by engaging with developers
Working upstream also preps you to start considering future changes we
can use in legislation to help innovate, enhance and enable wireless
communications further, which is really the purpose behind regulatory
agencies. The trouble behind these problems is the technical solutions
are not clear -- but I believe we are leading this with the work we've
put into the Linux kernel, and technically, this can also be reused on
other Operating Systems, and I'm encouraging that.
Luis
_______________________________________________
b43-dev mailing list
b43-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/b43-dev
