* [PATCH] b43/b43legacy - Credit Broadcom with enabling the development of the drivers @ 2010-09-19 18:40 David Woodhouse 2010-09-20 16:36 ` Gábor Stefanik 0 siblings, 1 reply; 17+ messages in thread From: David Woodhouse @ 2010-09-19 18:40 UTC (permalink / raw) To: b43-dev, linux-wireless Broadcom seem bizarrely paranoid about the legal consequences of "enabling" users to violate regulatory requirements. For some reason they seem to think that an open source driver is more of a problem than a closed-source driver. Even though it's often actually *easier* for end-users to use a hex editor to NOP out certain conditional jumps or change constants used in comparisons for regulatory enforcement, than it is for them to patch and rebuild an open source driver. The reverse engineering is hard, of course, but the end-users don't have to do that for themselves -- they only need to follow instructions like 'set the byte at 0x4572 to 0x90'. More to the point, the reverse-engineering part is required *anyway* in order to document the hardware so we can write the open source drivers. We couldn't do an open driver without *first* knowing enough about the closed one that we can bypass the regulatory code in it. Everything we do in the b43 and b43legacy drivers is enabled by Broadcom's original binary-only drivers. So let's make that 'enablement' by Broadcom's binary drivers clear in our source code -- in the hope that it'll narrow the 'risk gap' that they falsely perceive between open and closed source drivers. Or failing that, in the hope that it'll give their crack-addled lawyers aneurysms, and they'll hire some saner ones to replace them. Signed-off-by: David Woodhouse <dwmw2@infradead.org> --- I'd like to see the b43 reverse engineering folks release more such instructions on bypassing the regulatory requirements (boosting TX power, using wrong channels, etc.) in the Windows and OSX drivers; that would be another good way to demonstrate how crack-inspired the Broadcom position on closed vs. open drivers is. drivers/net/wireless/b43/debugfs.c | 3 +++ drivers/net/wireless/b43/dma.c | 3 +++ drivers/net/wireless/b43/leds.c | 3 +++ drivers/net/wireless/b43/lo.c | 3 +++ drivers/net/wireless/b43/main.c | 3 +++ drivers/net/wireless/b43/main.h | 3 +++ drivers/net/wireless/b43/pcmcia.c | 3 +++ drivers/net/wireless/b43/phy_a.c | 3 +++ drivers/net/wireless/b43/phy_common.c | 3 +++ drivers/net/wireless/b43/phy_g.c | 3 +++ drivers/net/wireless/b43/phy_lp.c | 3 +++ drivers/net/wireless/b43/phy_n.c | 3 +++ drivers/net/wireless/b43/pio.c | 3 +++ drivers/net/wireless/b43/rfkill.c | 3 +++ drivers/net/wireless/b43/sdio.c | 4 ++++ drivers/net/wireless/b43/sysfs.c | 3 +++ drivers/net/wireless/b43/tables.c | 3 +++ drivers/net/wireless/b43/tables_lpphy.c | 3 +++ drivers/net/wireless/b43/tables_nphy.c | 3 +++ drivers/net/wireless/b43/wa.c | 3 +++ drivers/net/wireless/b43/xmit.c | 3 +++ drivers/net/wireless/b43legacy/debugfs.c | 3 +++ drivers/net/wireless/b43legacy/dma.c | 3 +++ drivers/net/wireless/b43legacy/ilt.c | 3 +++ drivers/net/wireless/b43legacy/leds.c | 3 +++ drivers/net/wireless/b43legacy/main.c | 3 +++ drivers/net/wireless/b43legacy/main.h | 3 +++ drivers/net/wireless/b43legacy/phy.c | 3 +++ drivers/net/wireless/b43legacy/phy.h | 3 +++ drivers/net/wireless/b43legacy/pio.c | 3 +++ drivers/net/wireless/b43legacy/radio.c | 3 +++ drivers/net/wireless/b43legacy/radio.h | 3 +++ drivers/net/wireless/b43legacy/rfkill.c | 3 +++ drivers/net/wireless/b43legacy/sysfs.c | 3 +++ drivers/net/wireless/b43legacy/xmit.c | 3 +++ 35 files changed, 106 insertions(+), 0 deletions(-) diff --git a/drivers/net/wireless/b43/debugfs.c b/drivers/net/wireless/b43/debugfs.c index 80b19a4..8f573fb 100644 --- a/drivers/net/wireless/b43/debugfs.c +++ b/drivers/net/wireless/b43/debugfs.c @@ -21,6 +21,9 @@ the Free Software Foundation, Inc., 51 Franklin Steet, Fifth Floor, Boston, MA 02110-1301, USA. + + Broadcom enabled the development of this driver, by providing all required + hardware information in the form of binary software drivers. */ #include <linux/fs.h> diff --git a/drivers/net/wireless/b43/dma.c b/drivers/net/wireless/b43/dma.c index 10d0aaf..5d53092 100644 --- a/drivers/net/wireless/b43/dma.c +++ b/drivers/net/wireless/b43/dma.c @@ -25,6 +25,9 @@ the Free Software Foundation, Inc., 51 Franklin Steet, Fifth Floor, Boston, MA 02110-1301, USA. + + Broadcom enabled the development of this driver, by providing all required + hardware information in the form of binary software drivers. */ #include "b43.h" diff --git a/drivers/net/wireless/b43/leds.c b/drivers/net/wireless/b43/leds.c index c587115..7be31f8 100644 --- a/drivers/net/wireless/b43/leds.c +++ b/drivers/net/wireless/b43/leds.c @@ -24,6 +24,9 @@ the Free Software Foundation, Inc., 51 Franklin Steet, Fifth Floor, Boston, MA 02110-1301, USA. + + Broadcom enabled the development of this driver, by providing all required + hardware information in the form of binary software drivers. */ #include "b43.h" diff --git a/drivers/net/wireless/b43/lo.c b/drivers/net/wireless/b43/lo.c index 94e4f13..de98656 100644 --- a/drivers/net/wireless/b43/lo.c +++ b/drivers/net/wireless/b43/lo.c @@ -25,6 +25,9 @@ the Free Software Foundation, Inc., 51 Franklin Steet, Fifth Floor, Boston, MA 02110-1301, USA. + + Broadcom enabled the development of this driver, by providing all required + hardware information in the form of binary software drivers. */ #include "b43.h" diff --git a/drivers/net/wireless/b43/main.c b/drivers/net/wireless/b43/main.c index 20631ae..882fe74 100644 --- a/drivers/net/wireless/b43/main.c +++ b/drivers/net/wireless/b43/main.c @@ -29,6 +29,9 @@ the Free Software Foundation, Inc., 51 Franklin Steet, Fifth Floor, Boston, MA 02110-1301, USA. + + Broadcom enabled the development of this driver, by providing all required + hardware information in the form of binary software drivers. */ #include <linux/delay.h> diff --git a/drivers/net/wireless/b43/main.h b/drivers/net/wireless/b43/main.h index 40db036..5260069 100644 --- a/drivers/net/wireless/b43/main.h +++ b/drivers/net/wireless/b43/main.h @@ -26,6 +26,9 @@ the Free Software Foundation, Inc., 51 Franklin Steet, Fifth Floor, Boston, MA 02110-1301, USA. + + Broadcom enabled the development of this driver, by providing all required + hardware information in the form of binary software drivers. */ #ifndef B43_MAIN_H_ diff --git a/drivers/net/wireless/b43/pcmcia.c b/drivers/net/wireless/b43/pcmcia.c index dfbc41d..36abc3d 100644 --- a/drivers/net/wireless/b43/pcmcia.c +++ b/drivers/net/wireless/b43/pcmcia.c @@ -19,6 +19,9 @@ the Free Software Foundation, Inc., 51 Franklin Steet, Fifth Floor, Boston, MA 02110-1301, USA. + + Broadcom enabled the development of this driver, by providing all required + hardware information in the form of binary software drivers. */ #include "pcmcia.h" diff --git a/drivers/net/wireless/b43/phy_a.c b/drivers/net/wireless/b43/phy_a.c index b6428ec..45a6909 100644 --- a/drivers/net/wireless/b43/phy_a.c +++ b/drivers/net/wireless/b43/phy_a.c @@ -24,6 +24,9 @@ the Free Software Foundation, Inc., 51 Franklin Steet, Fifth Floor, Boston, MA 02110-1301, USA. + + Broadcom enabled the development of this driver, by providing all required + hardware information in the form of binary software drivers. */ #include <linux/slab.h> diff --git a/drivers/net/wireless/b43/phy_common.c b/drivers/net/wireless/b43/phy_common.c index 8f7d7ef..e46e852 100644 --- a/drivers/net/wireless/b43/phy_common.c +++ b/drivers/net/wireless/b43/phy_common.c @@ -24,6 +24,9 @@ the Free Software Foundation, Inc., 51 Franklin Steet, Fifth Floor, Boston, MA 02110-1301, USA. + + Broadcom enabled the development of this driver, by providing all required + hardware information in the form of binary software drivers. */ #include "phy_common.h" diff --git a/drivers/net/wireless/b43/phy_g.c b/drivers/net/wireless/b43/phy_g.c index 0dc33b6..f703c4e 100644 --- a/drivers/net/wireless/b43/phy_g.c +++ b/drivers/net/wireless/b43/phy_g.c @@ -24,6 +24,9 @@ the Free Software Foundation, Inc., 51 Franklin Steet, Fifth Floor, Boston, MA 02110-1301, USA. + + Broadcom enabled the development of this driver, by providing all required + hardware information in the form of binary software drivers. */ #include "b43.h" diff --git a/drivers/net/wireless/b43/phy_lp.c b/drivers/net/wireless/b43/phy_lp.c index fd50eb1..92a06ae 100644 --- a/drivers/net/wireless/b43/phy_lp.c +++ b/drivers/net/wireless/b43/phy_lp.c @@ -21,6 +21,9 @@ the Free Software Foundation, Inc., 51 Franklin Steet, Fifth Floor, Boston, MA 02110-1301, USA. + + Broadcom enabled the development of this driver, by providing all required + hardware information in the form of binary software drivers. */ #include <linux/slab.h> diff --git a/drivers/net/wireless/b43/phy_n.c b/drivers/net/wireless/b43/phy_n.c index 5a72570..29d909d 100644 --- a/drivers/net/wireless/b43/phy_n.c +++ b/drivers/net/wireless/b43/phy_n.c @@ -20,6 +20,9 @@ the Free Software Foundation, Inc., 51 Franklin Steet, Fifth Floor, Boston, MA 02110-1301, USA. + + Broadcom enabled the development of this driver, by providing all required + hardware information in the form of binary software drivers. */ #include <linux/delay.h> diff --git a/drivers/net/wireless/b43/pio.c b/drivers/net/wireless/b43/pio.c index aa12273..cc45579 100644 --- a/drivers/net/wireless/b43/pio.c +++ b/drivers/net/wireless/b43/pio.c @@ -21,6 +21,9 @@ the Free Software Foundation, Inc., 51 Franklin Steet, Fifth Floor, Boston, MA 02110-1301, USA. + + Broadcom enabled the development of this driver, by providing all required + hardware information in the form of binary software drivers. */ #include "b43.h" diff --git a/drivers/net/wireless/b43/rfkill.c b/drivers/net/wireless/b43/rfkill.c index 78016ae..5874d03 100644 --- a/drivers/net/wireless/b43/rfkill.c +++ b/drivers/net/wireless/b43/rfkill.c @@ -20,6 +20,9 @@ the Free Software Foundation, Inc., 51 Franklin Steet, Fifth Floor, Boston, MA 02110-1301, USA. + + Broadcom enabled the development of this driver, by providing all required + hardware information in the form of binary software drivers. */ #include "b43.h" diff --git a/drivers/net/wireless/b43/sdio.c b/drivers/net/wireless/b43/sdio.c index 45933cf..a4f676c 100644 --- a/drivers/net/wireless/b43/sdio.c +++ b/drivers/net/wireless/b43/sdio.c @@ -10,6 +10,10 @@ * it under the terms of the GNU General Public License as published by * the Free Software Foundation; either version 2 of the License, or (at * your option) any later version. + * + * + * Broadcom enabled the development of this driver, by providing all required + * hardware information in the form of binary software drivers. */ #include <linux/kernel.h> diff --git a/drivers/net/wireless/b43/sysfs.c b/drivers/net/wireless/b43/sysfs.c index f1ae4e0..e9d7df2 100644 --- a/drivers/net/wireless/b43/sysfs.c +++ b/drivers/net/wireless/b43/sysfs.c @@ -21,6 +21,9 @@ the Free Software Foundation, Inc., 51 Franklin Steet, Fifth Floor, Boston, MA 02110-1301, USA. + + Broadcom enabled the development of this driver, by providing all required + hardware information in the form of binary software drivers. */ #include <linux/capability.h> diff --git a/drivers/net/wireless/b43/tables.c b/drivers/net/wireless/b43/tables.c index 1ef9a64..2d09230 100644 --- a/drivers/net/wireless/b43/tables.c +++ b/drivers/net/wireless/b43/tables.c @@ -23,6 +23,9 @@ the Free Software Foundation, Inc., 51 Franklin Steet, Fifth Floor, Boston, MA 02110-1301, USA. + + Broadcom enabled the development of this driver, by providing all required + hardware information in the form of binary software drivers. */ #include "b43.h" diff --git a/drivers/net/wireless/b43/tables_lpphy.c b/drivers/net/wireless/b43/tables_lpphy.c index 61027ee..cf86624 100644 --- a/drivers/net/wireless/b43/tables_lpphy.c +++ b/drivers/net/wireless/b43/tables_lpphy.c @@ -21,6 +21,9 @@ the Free Software Foundation, Inc., 51 Franklin Steet, Fifth Floor, Boston, MA 02110-1301, USA. + + Broadcom enabled the development of this driver, by providing all required + hardware information in the form of binary software drivers. */ #include "b43.h" diff --git a/drivers/net/wireless/b43/tables_nphy.c b/drivers/net/wireless/b43/tables_nphy.c index d96e870..d6af589 100644 --- a/drivers/net/wireless/b43/tables_nphy.c +++ b/drivers/net/wireless/b43/tables_nphy.c @@ -20,6 +20,9 @@ the Free Software Foundation, Inc., 51 Franklin Steet, Fifth Floor, Boston, MA 02110-1301, USA. + + Broadcom enabled the development of this driver, by providing all required + hardware information in the form of binary software drivers. */ #include "b43.h" diff --git a/drivers/net/wireless/b43/wa.c b/drivers/net/wireless/b43/wa.c index 9a335da..ef56e6e 100644 --- a/drivers/net/wireless/b43/wa.c +++ b/drivers/net/wireless/b43/wa.c @@ -22,6 +22,9 @@ the Free Software Foundation, Inc., 51 Franklin Steet, Fifth Floor, Boston, MA 02110-1301, USA. + + Broadcom enabled the development of this driver, by providing all required + hardware information in the form of binary software drivers. */ #include "b43.h" diff --git a/drivers/net/wireless/b43/xmit.c b/drivers/net/wireless/b43/xmit.c index e6b0528..c9f1cc7 100644 --- a/drivers/net/wireless/b43/xmit.c +++ b/drivers/net/wireless/b43/xmit.c @@ -25,6 +25,9 @@ the Free Software Foundation, Inc., 51 Franklin Steet, Fifth Floor, Boston, MA 02110-1301, USA. + + Broadcom enabled the development of this driver, by providing all required + hardware information in the form of binary software drivers. */ #include "xmit.h" diff --git a/drivers/net/wireless/b43legacy/debugfs.c b/drivers/net/wireless/b43legacy/debugfs.c index 1f85ac5..76c430d 100644 --- a/drivers/net/wireless/b43legacy/debugfs.c +++ b/drivers/net/wireless/b43legacy/debugfs.c @@ -21,6 +21,9 @@ the Free Software Foundation, Inc., 51 Franklin Steet, Fifth Floor, Boston, MA 02110-1301, USA. + + Broadcom enabled the development of this driver, by providing all required + hardware information in the form of binary software drivers. */ #include <linux/fs.h> diff --git a/drivers/net/wireless/b43legacy/dma.c b/drivers/net/wireless/b43legacy/dma.c index e03e01d..d738335 100644 --- a/drivers/net/wireless/b43legacy/dma.c +++ b/drivers/net/wireless/b43legacy/dma.c @@ -25,6 +25,9 @@ the Free Software Foundation, Inc., 51 Franklin Steet, Fifth Floor, Boston, MA 02110-1301, USA. + + Broadcom enabled the development of this driver, by providing all required + hardware information in the form of binary software drivers. */ #include "b43legacy.h" diff --git a/drivers/net/wireless/b43legacy/ilt.c b/drivers/net/wireless/b43legacy/ilt.c index a849078..2c64050 100644 --- a/drivers/net/wireless/b43legacy/ilt.c +++ b/drivers/net/wireless/b43legacy/ilt.c @@ -23,6 +23,9 @@ the Free Software Foundation, Inc., 51 Franklin Steet, Fifth Floor, Boston, MA 02110-1301, USA. + + Broadcom enabled the development of this driver, by providing all required + hardware information in the form of binary software drivers. */ #include "b43legacy.h" diff --git a/drivers/net/wireless/b43legacy/leds.c b/drivers/net/wireless/b43legacy/leds.c index 37e9be8..151986c 100644 --- a/drivers/net/wireless/b43legacy/leds.c +++ b/drivers/net/wireless/b43legacy/leds.c @@ -24,6 +24,9 @@ the Free Software Foundation, Inc., 51 Franklin Steet, Fifth Floor, Boston, MA 02110-1301, USA. + + Broadcom enabled the development of this driver, by providing all required + hardware information in the form of binary software drivers. */ #include "b43legacy.h" diff --git a/drivers/net/wireless/b43legacy/main.c b/drivers/net/wireless/b43legacy/main.c index 1713f5f..f673229 100644 --- a/drivers/net/wireless/b43legacy/main.c +++ b/drivers/net/wireless/b43legacy/main.c @@ -27,6 +27,9 @@ * the Free Software Foundation, Inc., 51 Franklin Steet, Fifth Floor, * Boston, MA 02110-1301, USA. * + * + * Broadcom enabled the development of this driver, by providing all required + * hardware information in the form of binary software drivers. */ #include <linux/delay.h> diff --git a/drivers/net/wireless/b43legacy/main.h b/drivers/net/wireless/b43legacy/main.h index 1f0e2e37..a0697346 100644 --- a/drivers/net/wireless/b43legacy/main.h +++ b/drivers/net/wireless/b43legacy/main.h @@ -27,6 +27,9 @@ the Free Software Foundation, Inc., 51 Franklin Steet, Fifth Floor, Boston, MA 02110-1301, USA. + + Broadcom enabled the development of this driver, by providing all required + hardware information in the form of binary software drivers. */ #ifndef B43legacy_MAIN_H_ diff --git a/drivers/net/wireless/b43legacy/phy.c b/drivers/net/wireless/b43legacy/phy.c index 35033dd..87b18e5 100644 --- a/drivers/net/wireless/b43legacy/phy.c +++ b/drivers/net/wireless/b43legacy/phy.c @@ -27,6 +27,9 @@ the Free Software Foundation, Inc., 51 Franklin Steet, Fifth Floor, Boston, MA 02110-1301, USA. + + Broadcom enabled the development of this driver, by providing all required + hardware information in the form of binary software drivers. */ #include <linux/delay.h> diff --git a/drivers/net/wireless/b43legacy/phy.h b/drivers/net/wireless/b43legacy/phy.h index ecbe409..14462e0 100644 --- a/drivers/net/wireless/b43legacy/phy.h +++ b/drivers/net/wireless/b43legacy/phy.h @@ -27,6 +27,9 @@ the Free Software Foundation, Inc., 51 Franklin Steet, Fifth Floor, Boston, MA 02110-1301, USA. + + Broadcom enabled the development of this driver, by providing all required + hardware information in the form of binary software drivers. */ #ifndef B43legacy_PHY_H_ diff --git a/drivers/net/wireless/b43legacy/pio.c b/drivers/net/wireless/b43legacy/pio.c index b033b0e..4642a36 100644 --- a/drivers/net/wireless/b43legacy/pio.c +++ b/drivers/net/wireless/b43legacy/pio.c @@ -21,6 +21,9 @@ the Free Software Foundation, Inc., 51 Franklin Steet, Fifth Floor, Boston, MA 02110-1301, USA. + + Broadcom enabled the development of this driver, by providing all required + hardware information in the form of binary software drivers. */ #include "b43legacy.h" diff --git a/drivers/net/wireless/b43legacy/radio.c b/drivers/net/wireless/b43legacy/radio.c index 2df545c..e6c1bec 100644 --- a/drivers/net/wireless/b43legacy/radio.c +++ b/drivers/net/wireless/b43legacy/radio.c @@ -27,6 +27,9 @@ the Free Software Foundation, Inc., 51 Franklin Steet, Fifth Floor, Boston, MA 02110-1301, USA. + + Broadcom enabled the development of this driver, by providing all required + hardware information in the form of binary software drivers. */ #include <linux/delay.h> diff --git a/drivers/net/wireless/b43legacy/radio.h b/drivers/net/wireless/b43legacy/radio.h index ec4de28..e74f3d8 100644 --- a/drivers/net/wireless/b43legacy/radio.h +++ b/drivers/net/wireless/b43legacy/radio.h @@ -26,6 +26,9 @@ the Free Software Foundation, Inc., 51 Franklin Steet, Fifth Floor, Boston, MA 02110-1301, USA. + + Broadcom enabled the development of this driver, by providing all required + hardware information in the form of binary software drivers. */ #ifndef B43legacy_RADIO_H_ diff --git a/drivers/net/wireless/b43legacy/rfkill.c b/drivers/net/wireless/b43legacy/rfkill.c index d579df7..77b46c9 100644 --- a/drivers/net/wireless/b43legacy/rfkill.c +++ b/drivers/net/wireless/b43legacy/rfkill.c @@ -20,6 +20,9 @@ the Free Software Foundation, Inc., 51 Franklin Steet, Fifth Floor, Boston, MA 02110-1301, USA. + + Broadcom enabled the development of this driver, by providing all required + hardware information in the form of binary software drivers. */ #include "radio.h" diff --git a/drivers/net/wireless/b43legacy/sysfs.c b/drivers/net/wireless/b43legacy/sysfs.c index 56c384f..f741778 100644 --- a/drivers/net/wireless/b43legacy/sysfs.c +++ b/drivers/net/wireless/b43legacy/sysfs.c @@ -21,6 +21,9 @@ the Free Software Foundation, Inc., 51 Franklin Steet, Fifth Floor, Boston, MA 02110-1301, USA. + + Broadcom enabled the development of this driver, by providing all required + hardware information in the form of binary software drivers. */ #include "sysfs.h" diff --git a/drivers/net/wireless/b43legacy/xmit.c b/drivers/net/wireless/b43legacy/xmit.c index 7d177d9..384ff7e 100644 --- a/drivers/net/wireless/b43legacy/xmit.c +++ b/drivers/net/wireless/b43legacy/xmit.c @@ -26,6 +26,9 @@ the Free Software Foundation, Inc., 51 Franklin Steet, Fifth Floor, Boston, MA 02110-1301, USA. + + Broadcom enabled the development of this driver, by providing all required + hardware information in the form of binary software drivers. */ #include <net/dst.h> -- 1.7.2.2 ^ permalink raw reply related [flat|nested] 17+ messages in thread
* [PATCH] b43/b43legacy - Credit Broadcom with enabling the development of the drivers 2010-09-19 18:40 [PATCH] b43/b43legacy - Credit Broadcom with enabling the development of the drivers David Woodhouse @ 2010-09-20 16:36 ` Gábor Stefanik 2010-09-20 16:56 ` Luis R. Rodriguez 2010-09-20 21:42 ` David Woodhouse 0 siblings, 2 replies; 17+ messages in thread From: Gábor Stefanik @ 2010-09-20 16:36 UTC (permalink / raw) To: David Woodhouse; +Cc: b43-dev, linux-wireless On Sun, Sep 19, 2010 at 8:40 PM, David Woodhouse <dwmw2@infradead.org> wrote: > Broadcom seem bizarrely paranoid about the legal consequences of > "enabling" users to violate regulatory requirements. > > For some reason they seem to think that an open source driver is more of > a problem than a closed-source driver. Even though it's often actually > *easier* for end-users to use a hex editor to NOP out certain conditional > jumps or change constants used in comparisons for regulatory enforcement, > than it is for them to patch and rebuild an open source driver. > > The reverse engineering is hard, of course, but the end-users don't have > to do that for themselves -- they only need to follow instructions like > 'set the byte at 0x4572 to 0x90'. More to the point, the reverse-engineering > part is required *anyway* in order to document the hardware so we can write > the open source drivers. We couldn't do an open driver without *first* > knowing enough about the closed one that we can bypass the regulatory > code in it. > > Everything we do in the b43 and b43legacy drivers is enabled by > Broadcom's original binary-only drivers. > > So let's make that 'enablement' by Broadcom's binary drivers clear in > our source code -- in the hope that it'll narrow the 'risk gap' that > they falsely perceive between open and closed source drivers. > > Or failing that, in the hope that it'll give their crack-addled lawyers > aneurysms, and they'll hire some saner ones to replace them. > > Signed-off-by: David Woodhouse <dwmw2@infradead.org> > --- > I'd like to see the b43 reverse engineering folks release more such > instructions on bypassing the regulatory requirements (boosting TX > power, using wrong channels, etc.) in the Windows and OSX drivers; that > would be another good way to demonstrate how crack-inspired the Broadcom > position on closed vs. open drivers is. Only one problem: the license agreement of these drivers explicitly forbids any reverse-engineering for any purpose. One can debate a lot about whether these are enforceable - however, in the US, a similar case (though that one was about resale, rather than reverse-engineering) was recently decided in the plaintiff's favor. And I believe Broadcom would indeed sue if they thought they were risking their FCC approval by not doing so. > > > ?drivers/net/wireless/b43/debugfs.c ? ? ? | ? ?3 +++ > ?drivers/net/wireless/b43/dma.c ? ? ? ? ? | ? ?3 +++ > ?drivers/net/wireless/b43/leds.c ? ? ? ? ?| ? ?3 +++ > ?drivers/net/wireless/b43/lo.c ? ? ? ? ? ?| ? ?3 +++ > ?drivers/net/wireless/b43/main.c ? ? ? ? ?| ? ?3 +++ > ?drivers/net/wireless/b43/main.h ? ? ? ? ?| ? ?3 +++ > ?drivers/net/wireless/b43/pcmcia.c ? ? ? ?| ? ?3 +++ > ?drivers/net/wireless/b43/phy_a.c ? ? ? ? | ? ?3 +++ > ?drivers/net/wireless/b43/phy_common.c ? ?| ? ?3 +++ > ?drivers/net/wireless/b43/phy_g.c ? ? ? ? | ? ?3 +++ > ?drivers/net/wireless/b43/phy_lp.c ? ? ? ?| ? ?3 +++ > ?drivers/net/wireless/b43/phy_n.c ? ? ? ? | ? ?3 +++ > ?drivers/net/wireless/b43/pio.c ? ? ? ? ? | ? ?3 +++ > ?drivers/net/wireless/b43/rfkill.c ? ? ? ?| ? ?3 +++ > ?drivers/net/wireless/b43/sdio.c ? ? ? ? ?| ? ?4 ++++ > ?drivers/net/wireless/b43/sysfs.c ? ? ? ? | ? ?3 +++ > ?drivers/net/wireless/b43/tables.c ? ? ? ?| ? ?3 +++ > ?drivers/net/wireless/b43/tables_lpphy.c ?| ? ?3 +++ > ?drivers/net/wireless/b43/tables_nphy.c ? | ? ?3 +++ > ?drivers/net/wireless/b43/wa.c ? ? ? ? ? ?| ? ?3 +++ > ?drivers/net/wireless/b43/xmit.c ? ? ? ? ?| ? ?3 +++ > ?drivers/net/wireless/b43legacy/debugfs.c | ? ?3 +++ > ?drivers/net/wireless/b43legacy/dma.c ? ? | ? ?3 +++ > ?drivers/net/wireless/b43legacy/ilt.c ? ? | ? ?3 +++ > ?drivers/net/wireless/b43legacy/leds.c ? ?| ? ?3 +++ > ?drivers/net/wireless/b43legacy/main.c ? ?| ? ?3 +++ > ?drivers/net/wireless/b43legacy/main.h ? ?| ? ?3 +++ > ?drivers/net/wireless/b43legacy/phy.c ? ? | ? ?3 +++ > ?drivers/net/wireless/b43legacy/phy.h ? ? | ? ?3 +++ > ?drivers/net/wireless/b43legacy/pio.c ? ? | ? ?3 +++ > ?drivers/net/wireless/b43legacy/radio.c ? | ? ?3 +++ > ?drivers/net/wireless/b43legacy/radio.h ? | ? ?3 +++ > ?drivers/net/wireless/b43legacy/rfkill.c ?| ? ?3 +++ > ?drivers/net/wireless/b43legacy/sysfs.c ? | ? ?3 +++ > ?drivers/net/wireless/b43legacy/xmit.c ? ?| ? ?3 +++ > ?35 files changed, 106 insertions(+), 0 deletions(-) > > diff --git a/drivers/net/wireless/b43/debugfs.c b/drivers/net/wireless/b43/debugfs.c > index 80b19a4..8f573fb 100644 > --- a/drivers/net/wireless/b43/debugfs.c > +++ b/drivers/net/wireless/b43/debugfs.c > @@ -21,6 +21,9 @@ > ? the Free Software Foundation, Inc., 51 Franklin Steet, Fifth Floor, > ? Boston, MA 02110-1301, USA. > > + > + ?Broadcom enabled the development of this driver, by providing all required > + ?hardware information in the form of binary software drivers. > ?*/ > > ?#include <linux/fs.h> > diff --git a/drivers/net/wireless/b43/dma.c b/drivers/net/wireless/b43/dma.c > index 10d0aaf..5d53092 100644 > --- a/drivers/net/wireless/b43/dma.c > +++ b/drivers/net/wireless/b43/dma.c > @@ -25,6 +25,9 @@ > ? the Free Software Foundation, Inc., 51 Franklin Steet, Fifth Floor, > ? Boston, MA 02110-1301, USA. > > + > + ?Broadcom enabled the development of this driver, by providing all required > + ?hardware information in the form of binary software drivers. > ?*/ > > ?#include "b43.h" > diff --git a/drivers/net/wireless/b43/leds.c b/drivers/net/wireless/b43/leds.c > index c587115..7be31f8 100644 > --- a/drivers/net/wireless/b43/leds.c > +++ b/drivers/net/wireless/b43/leds.c > @@ -24,6 +24,9 @@ > ? the Free Software Foundation, Inc., 51 Franklin Steet, Fifth Floor, > ? Boston, MA 02110-1301, USA. > > + > + ?Broadcom enabled the development of this driver, by providing all required > + ?hardware information in the form of binary software drivers. > ?*/ > > ?#include "b43.h" > diff --git a/drivers/net/wireless/b43/lo.c b/drivers/net/wireless/b43/lo.c > index 94e4f13..de98656 100644 > --- a/drivers/net/wireless/b43/lo.c > +++ b/drivers/net/wireless/b43/lo.c > @@ -25,6 +25,9 @@ > ? the Free Software Foundation, Inc., 51 Franklin Steet, Fifth Floor, > ? Boston, MA 02110-1301, USA. > > + > + ?Broadcom enabled the development of this driver, by providing all required > + ?hardware information in the form of binary software drivers. > ?*/ > > ?#include "b43.h" > diff --git a/drivers/net/wireless/b43/main.c b/drivers/net/wireless/b43/main.c > index 20631ae..882fe74 100644 > --- a/drivers/net/wireless/b43/main.c > +++ b/drivers/net/wireless/b43/main.c > @@ -29,6 +29,9 @@ > ? the Free Software Foundation, Inc., 51 Franklin Steet, Fifth Floor, > ? Boston, MA 02110-1301, USA. > > + > + ?Broadcom enabled the development of this driver, by providing all required > + ?hardware information in the form of binary software drivers. > ?*/ > > ?#include <linux/delay.h> > diff --git a/drivers/net/wireless/b43/main.h b/drivers/net/wireless/b43/main.h > index 40db036..5260069 100644 > --- a/drivers/net/wireless/b43/main.h > +++ b/drivers/net/wireless/b43/main.h > @@ -26,6 +26,9 @@ > ? the Free Software Foundation, Inc., 51 Franklin Steet, Fifth Floor, > ? Boston, MA 02110-1301, USA. > > + > + ?Broadcom enabled the development of this driver, by providing all required > + ?hardware information in the form of binary software drivers. > ?*/ > > ?#ifndef B43_MAIN_H_ > diff --git a/drivers/net/wireless/b43/pcmcia.c b/drivers/net/wireless/b43/pcmcia.c > index dfbc41d..36abc3d 100644 > --- a/drivers/net/wireless/b43/pcmcia.c > +++ b/drivers/net/wireless/b43/pcmcia.c > @@ -19,6 +19,9 @@ > ? the Free Software Foundation, Inc., 51 Franklin Steet, Fifth Floor, > ? Boston, MA 02110-1301, USA. > > + > + ?Broadcom enabled the development of this driver, by providing all required > + ?hardware information in the form of binary software drivers. > ?*/ > > ?#include "pcmcia.h" > diff --git a/drivers/net/wireless/b43/phy_a.c b/drivers/net/wireless/b43/phy_a.c > index b6428ec..45a6909 100644 > --- a/drivers/net/wireless/b43/phy_a.c > +++ b/drivers/net/wireless/b43/phy_a.c > @@ -24,6 +24,9 @@ > ? the Free Software Foundation, Inc., 51 Franklin Steet, Fifth Floor, > ? Boston, MA 02110-1301, USA. > > + > + ?Broadcom enabled the development of this driver, by providing all required > + ?hardware information in the form of binary software drivers. > ?*/ > > ?#include <linux/slab.h> > diff --git a/drivers/net/wireless/b43/phy_common.c b/drivers/net/wireless/b43/phy_common.c > index 8f7d7ef..e46e852 100644 > --- a/drivers/net/wireless/b43/phy_common.c > +++ b/drivers/net/wireless/b43/phy_common.c > @@ -24,6 +24,9 @@ > ? the Free Software Foundation, Inc., 51 Franklin Steet, Fifth Floor, > ? Boston, MA 02110-1301, USA. > > + > + ?Broadcom enabled the development of this driver, by providing all required > + ?hardware information in the form of binary software drivers. > ?*/ > > ?#include "phy_common.h" > diff --git a/drivers/net/wireless/b43/phy_g.c b/drivers/net/wireless/b43/phy_g.c > index 0dc33b6..f703c4e 100644 > --- a/drivers/net/wireless/b43/phy_g.c > +++ b/drivers/net/wireless/b43/phy_g.c > @@ -24,6 +24,9 @@ > ? the Free Software Foundation, Inc., 51 Franklin Steet, Fifth Floor, > ? Boston, MA 02110-1301, USA. > > + > + ?Broadcom enabled the development of this driver, by providing all required > + ?hardware information in the form of binary software drivers. > ?*/ > > ?#include "b43.h" > diff --git a/drivers/net/wireless/b43/phy_lp.c b/drivers/net/wireless/b43/phy_lp.c > index fd50eb1..92a06ae 100644 > --- a/drivers/net/wireless/b43/phy_lp.c > +++ b/drivers/net/wireless/b43/phy_lp.c > @@ -21,6 +21,9 @@ > ? the Free Software Foundation, Inc., 51 Franklin Steet, Fifth Floor, > ? Boston, MA 02110-1301, USA. > > + > + ?Broadcom enabled the development of this driver, by providing all required > + ?hardware information in the form of binary software drivers. > ?*/ > > ?#include <linux/slab.h> > diff --git a/drivers/net/wireless/b43/phy_n.c b/drivers/net/wireless/b43/phy_n.c > index 5a72570..29d909d 100644 > --- a/drivers/net/wireless/b43/phy_n.c > +++ b/drivers/net/wireless/b43/phy_n.c > @@ -20,6 +20,9 @@ > ? the Free Software Foundation, Inc., 51 Franklin Steet, Fifth Floor, > ? Boston, MA 02110-1301, USA. > > + > + ?Broadcom enabled the development of this driver, by providing all required > + ?hardware information in the form of binary software drivers. > ?*/ > > ?#include <linux/delay.h> > diff --git a/drivers/net/wireless/b43/pio.c b/drivers/net/wireless/b43/pio.c > index aa12273..cc45579 100644 > --- a/drivers/net/wireless/b43/pio.c > +++ b/drivers/net/wireless/b43/pio.c > @@ -21,6 +21,9 @@ > ? the Free Software Foundation, Inc., 51 Franklin Steet, Fifth Floor, > ? Boston, MA 02110-1301, USA. > > + > + ?Broadcom enabled the development of this driver, by providing all required > + ?hardware information in the form of binary software drivers. > ?*/ > > ?#include "b43.h" > diff --git a/drivers/net/wireless/b43/rfkill.c b/drivers/net/wireless/b43/rfkill.c > index 78016ae..5874d03 100644 > --- a/drivers/net/wireless/b43/rfkill.c > +++ b/drivers/net/wireless/b43/rfkill.c > @@ -20,6 +20,9 @@ > ? the Free Software Foundation, Inc., 51 Franklin Steet, Fifth Floor, > ? Boston, MA 02110-1301, USA. > > + > + ?Broadcom enabled the development of this driver, by providing all required > + ?hardware information in the form of binary software drivers. > ?*/ > > ?#include "b43.h" > diff --git a/drivers/net/wireless/b43/sdio.c b/drivers/net/wireless/b43/sdio.c > index 45933cf..a4f676c 100644 > --- a/drivers/net/wireless/b43/sdio.c > +++ b/drivers/net/wireless/b43/sdio.c > @@ -10,6 +10,10 @@ > ?* it under the terms of the GNU General Public License as published by > ?* the Free Software Foundation; either version 2 of the License, or (at > ?* your option) any later version. > + * > + * > + * Broadcom enabled the development of this driver, by providing all required > + * hardware information in the form of binary software drivers. > ?*/ > > ?#include <linux/kernel.h> > diff --git a/drivers/net/wireless/b43/sysfs.c b/drivers/net/wireless/b43/sysfs.c > index f1ae4e0..e9d7df2 100644 > --- a/drivers/net/wireless/b43/sysfs.c > +++ b/drivers/net/wireless/b43/sysfs.c > @@ -21,6 +21,9 @@ > ? the Free Software Foundation, Inc., 51 Franklin Steet, Fifth Floor, > ? Boston, MA 02110-1301, USA. > > + > + ?Broadcom enabled the development of this driver, by providing all required > + ?hardware information in the form of binary software drivers. > ?*/ > > ?#include <linux/capability.h> > diff --git a/drivers/net/wireless/b43/tables.c b/drivers/net/wireless/b43/tables.c > index 1ef9a64..2d09230 100644 > --- a/drivers/net/wireless/b43/tables.c > +++ b/drivers/net/wireless/b43/tables.c > @@ -23,6 +23,9 @@ > ? the Free Software Foundation, Inc., 51 Franklin Steet, Fifth Floor, > ? Boston, MA 02110-1301, USA. > > + > + ?Broadcom enabled the development of this driver, by providing all required > + ?hardware information in the form of binary software drivers. > ?*/ > > ?#include "b43.h" > diff --git a/drivers/net/wireless/b43/tables_lpphy.c b/drivers/net/wireless/b43/tables_lpphy.c > index 61027ee..cf86624 100644 > --- a/drivers/net/wireless/b43/tables_lpphy.c > +++ b/drivers/net/wireless/b43/tables_lpphy.c > @@ -21,6 +21,9 @@ > ? the Free Software Foundation, Inc., 51 Franklin Steet, Fifth Floor, > ? Boston, MA 02110-1301, USA. > > + > + ?Broadcom enabled the development of this driver, by providing all required > + ?hardware information in the form of binary software drivers. > ?*/ > > ?#include "b43.h" > diff --git a/drivers/net/wireless/b43/tables_nphy.c b/drivers/net/wireless/b43/tables_nphy.c > index d96e870..d6af589 100644 > --- a/drivers/net/wireless/b43/tables_nphy.c > +++ b/drivers/net/wireless/b43/tables_nphy.c > @@ -20,6 +20,9 @@ > ? the Free Software Foundation, Inc., 51 Franklin Steet, Fifth Floor, > ? Boston, MA 02110-1301, USA. > > + > + ?Broadcom enabled the development of this driver, by providing all required > + ?hardware information in the form of binary software drivers. > ?*/ > > ?#include "b43.h" > diff --git a/drivers/net/wireless/b43/wa.c b/drivers/net/wireless/b43/wa.c > index 9a335da..ef56e6e 100644 > --- a/drivers/net/wireless/b43/wa.c > +++ b/drivers/net/wireless/b43/wa.c > @@ -22,6 +22,9 @@ > ? the Free Software Foundation, Inc., 51 Franklin Steet, Fifth Floor, > ? Boston, MA 02110-1301, USA. > > + > + ?Broadcom enabled the development of this driver, by providing all required > + ?hardware information in the form of binary software drivers. > ?*/ > > ?#include "b43.h" > diff --git a/drivers/net/wireless/b43/xmit.c b/drivers/net/wireless/b43/xmit.c > index e6b0528..c9f1cc7 100644 > --- a/drivers/net/wireless/b43/xmit.c > +++ b/drivers/net/wireless/b43/xmit.c > @@ -25,6 +25,9 @@ > ? the Free Software Foundation, Inc., 51 Franklin Steet, Fifth Floor, > ? Boston, MA 02110-1301, USA. > > + > + ?Broadcom enabled the development of this driver, by providing all required > + ?hardware information in the form of binary software drivers. > ?*/ > > ?#include "xmit.h" > diff --git a/drivers/net/wireless/b43legacy/debugfs.c b/drivers/net/wireless/b43legacy/debugfs.c > index 1f85ac5..76c430d 100644 > --- a/drivers/net/wireless/b43legacy/debugfs.c > +++ b/drivers/net/wireless/b43legacy/debugfs.c > @@ -21,6 +21,9 @@ > ? the Free Software Foundation, Inc., 51 Franklin Steet, Fifth Floor, > ? Boston, MA 02110-1301, USA. > > + > + ?Broadcom enabled the development of this driver, by providing all required > + ?hardware information in the form of binary software drivers. > ?*/ > > ?#include <linux/fs.h> > diff --git a/drivers/net/wireless/b43legacy/dma.c b/drivers/net/wireless/b43legacy/dma.c > index e03e01d..d738335 100644 > --- a/drivers/net/wireless/b43legacy/dma.c > +++ b/drivers/net/wireless/b43legacy/dma.c > @@ -25,6 +25,9 @@ > ? the Free Software Foundation, Inc., 51 Franklin Steet, Fifth Floor, > ? Boston, MA 02110-1301, USA. > > + > + ?Broadcom enabled the development of this driver, by providing all required > + ?hardware information in the form of binary software drivers. > ?*/ > > ?#include "b43legacy.h" > diff --git a/drivers/net/wireless/b43legacy/ilt.c b/drivers/net/wireless/b43legacy/ilt.c > index a849078..2c64050 100644 > --- a/drivers/net/wireless/b43legacy/ilt.c > +++ b/drivers/net/wireless/b43legacy/ilt.c > @@ -23,6 +23,9 @@ > ? the Free Software Foundation, Inc., 51 Franklin Steet, Fifth Floor, > ? Boston, MA 02110-1301, USA. > > + > + ?Broadcom enabled the development of this driver, by providing all required > + ?hardware information in the form of binary software drivers. > ?*/ > > ?#include "b43legacy.h" > diff --git a/drivers/net/wireless/b43legacy/leds.c b/drivers/net/wireless/b43legacy/leds.c > index 37e9be8..151986c 100644 > --- a/drivers/net/wireless/b43legacy/leds.c > +++ b/drivers/net/wireless/b43legacy/leds.c > @@ -24,6 +24,9 @@ > ? the Free Software Foundation, Inc., 51 Franklin Steet, Fifth Floor, > ? Boston, MA 02110-1301, USA. > > + > + ?Broadcom enabled the development of this driver, by providing all required > + ?hardware information in the form of binary software drivers. > ?*/ > > ?#include "b43legacy.h" > diff --git a/drivers/net/wireless/b43legacy/main.c b/drivers/net/wireless/b43legacy/main.c > index 1713f5f..f673229 100644 > --- a/drivers/net/wireless/b43legacy/main.c > +++ b/drivers/net/wireless/b43legacy/main.c > @@ -27,6 +27,9 @@ > ?* ?the Free Software Foundation, Inc., 51 Franklin Steet, Fifth Floor, > ?* ?Boston, MA 02110-1301, USA. > ?* > + * > + * Broadcom enabled the development of this driver, by providing all required > + * hardware information in the form of binary software drivers. > ?*/ > > ?#include <linux/delay.h> > diff --git a/drivers/net/wireless/b43legacy/main.h b/drivers/net/wireless/b43legacy/main.h > index 1f0e2e37..a0697346 100644 > --- a/drivers/net/wireless/b43legacy/main.h > +++ b/drivers/net/wireless/b43legacy/main.h > @@ -27,6 +27,9 @@ > ? the Free Software Foundation, Inc., 51 Franklin Steet, Fifth Floor, > ? Boston, MA 02110-1301, USA. > > + > + ?Broadcom enabled the development of this driver, by providing all required > + ?hardware information in the form of binary software drivers. > ?*/ > > ?#ifndef B43legacy_MAIN_H_ > diff --git a/drivers/net/wireless/b43legacy/phy.c b/drivers/net/wireless/b43legacy/phy.c > index 35033dd..87b18e5 100644 > --- a/drivers/net/wireless/b43legacy/phy.c > +++ b/drivers/net/wireless/b43legacy/phy.c > @@ -27,6 +27,9 @@ > ? the Free Software Foundation, Inc., 51 Franklin Steet, Fifth Floor, > ? Boston, MA 02110-1301, USA. > > + > + ?Broadcom enabled the development of this driver, by providing all required > + ?hardware information in the form of binary software drivers. > ?*/ > > ?#include <linux/delay.h> > diff --git a/drivers/net/wireless/b43legacy/phy.h b/drivers/net/wireless/b43legacy/phy.h > index ecbe409..14462e0 100644 > --- a/drivers/net/wireless/b43legacy/phy.h > +++ b/drivers/net/wireless/b43legacy/phy.h > @@ -27,6 +27,9 @@ > ? the Free Software Foundation, Inc., 51 Franklin Steet, Fifth Floor, > ? Boston, MA 02110-1301, USA. > > + > + ?Broadcom enabled the development of this driver, by providing all required > + ?hardware information in the form of binary software drivers. > ?*/ > > ?#ifndef B43legacy_PHY_H_ > diff --git a/drivers/net/wireless/b43legacy/pio.c b/drivers/net/wireless/b43legacy/pio.c > index b033b0e..4642a36 100644 > --- a/drivers/net/wireless/b43legacy/pio.c > +++ b/drivers/net/wireless/b43legacy/pio.c > @@ -21,6 +21,9 @@ > ? the Free Software Foundation, Inc., 51 Franklin Steet, Fifth Floor, > ? Boston, MA 02110-1301, USA. > > + > + ?Broadcom enabled the development of this driver, by providing all required > + ?hardware information in the form of binary software drivers. > ?*/ > > ?#include "b43legacy.h" > diff --git a/drivers/net/wireless/b43legacy/radio.c b/drivers/net/wireless/b43legacy/radio.c > index 2df545c..e6c1bec 100644 > --- a/drivers/net/wireless/b43legacy/radio.c > +++ b/drivers/net/wireless/b43legacy/radio.c > @@ -27,6 +27,9 @@ > ? the Free Software Foundation, Inc., 51 Franklin Steet, Fifth Floor, > ? Boston, MA 02110-1301, USA. > > + > + ?Broadcom enabled the development of this driver, by providing all required > + ?hardware information in the form of binary software drivers. > ?*/ > > ?#include <linux/delay.h> > diff --git a/drivers/net/wireless/b43legacy/radio.h b/drivers/net/wireless/b43legacy/radio.h > index ec4de28..e74f3d8 100644 > --- a/drivers/net/wireless/b43legacy/radio.h > +++ b/drivers/net/wireless/b43legacy/radio.h > @@ -26,6 +26,9 @@ > ? the Free Software Foundation, Inc., 51 Franklin Steet, Fifth Floor, > ? Boston, MA 02110-1301, USA. > > + > + ?Broadcom enabled the development of this driver, by providing all required > + ?hardware information in the form of binary software drivers. > ?*/ > > ?#ifndef B43legacy_RADIO_H_ > diff --git a/drivers/net/wireless/b43legacy/rfkill.c b/drivers/net/wireless/b43legacy/rfkill.c > index d579df7..77b46c9 100644 > --- a/drivers/net/wireless/b43legacy/rfkill.c > +++ b/drivers/net/wireless/b43legacy/rfkill.c > @@ -20,6 +20,9 @@ > ? the Free Software Foundation, Inc., 51 Franklin Steet, Fifth Floor, > ? Boston, MA 02110-1301, USA. > > + > + ?Broadcom enabled the development of this driver, by providing all required > + ?hardware information in the form of binary software drivers. > ?*/ > > ?#include "radio.h" > diff --git a/drivers/net/wireless/b43legacy/sysfs.c b/drivers/net/wireless/b43legacy/sysfs.c > index 56c384f..f741778 100644 > --- a/drivers/net/wireless/b43legacy/sysfs.c > +++ b/drivers/net/wireless/b43legacy/sysfs.c > @@ -21,6 +21,9 @@ > ? the Free Software Foundation, Inc., 51 Franklin Steet, Fifth Floor, > ? Boston, MA 02110-1301, USA. > > + > + ?Broadcom enabled the development of this driver, by providing all required > + ?hardware information in the form of binary software drivers. > ?*/ > > ?#include "sysfs.h" > diff --git a/drivers/net/wireless/b43legacy/xmit.c b/drivers/net/wireless/b43legacy/xmit.c > index 7d177d9..384ff7e 100644 > --- a/drivers/net/wireless/b43legacy/xmit.c > +++ b/drivers/net/wireless/b43legacy/xmit.c > @@ -26,6 +26,9 @@ > ? the Free Software Foundation, Inc., 51 Franklin Steet, Fifth Floor, > ? Boston, MA 02110-1301, USA. > > + > + ?Broadcom enabled the development of this driver, by providing all required > + ?hardware information in the form of binary software drivers. > ?*/ > > ?#include <net/dst.h> > -- > 1.7.2.2 > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-wireless" in > the body of a message to majordomo at vger.kernel.org > More majordomo info at ?http://vger.kernel.org/majordomo-info.html > -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) ^ permalink raw reply [flat|nested] 17+ messages in thread
* [PATCH] b43/b43legacy - Credit Broadcom with enabling the development of the drivers 2010-09-20 16:36 ` Gábor Stefanik @ 2010-09-20 16:56 ` Luis R. Rodriguez 2010-09-20 19:02 ` Ehud Gavron 2010-09-20 21:42 ` David Woodhouse 1 sibling, 1 reply; 17+ messages in thread From: Luis R. Rodriguez @ 2010-09-20 16:56 UTC (permalink / raw) To: Gábor Stefanik; +Cc: David Woodhouse, b43-dev, linux-wireless 2010/9/20 G?bor Stefanik <netrolller.3d@gmail.com>: > On Sun, Sep 19, 2010 at 8:40 PM, David Woodhouse <dwmw2@infradead.org> wrote: >> Broadcom seem bizarrely paranoid about the legal consequences of >> "enabling" users to violate regulatory requirements. >> >> For some reason they seem to think that an open source driver is more of >> a problem than a closed-source driver. Even though it's often actually >> *easier* for end-users to use a hex editor to NOP out certain conditional >> jumps or change constants used in comparisons for regulatory enforcement, >> than it is for them to patch and rebuild an open source driver. >> >> The reverse engineering is hard, of course, but the end-users don't have >> to do that for themselves -- they only need to follow instructions like >> 'set the byte at 0x4572 to 0x90'. More to the point, the reverse-engineering >> part is required *anyway* in order to document the hardware so we can write >> the open source drivers. We couldn't do an open driver without *first* >> knowing enough about the closed one that we can bypass the regulatory >> code in it. >> >> Everything we do in the b43 and b43legacy drivers is enabled by >> Broadcom's original binary-only drivers. >> >> So let's make that 'enablement' by Broadcom's binary drivers clear in >> our source code -- in the hope that it'll narrow the 'risk gap' that >> they falsely perceive between open and closed source drivers. >> >> Or failing that, in the hope that it'll give their crack-addled lawyers >> aneurysms, and they'll hire some saner ones to replace them. >> >> Signed-off-by: David Woodhouse <dwmw2@infradead.org> >> --- >> I'd like to see the b43 reverse engineering folks release more such >> instructions on bypassing the regulatory requirements (boosting TX >> power, using wrong channels, etc.) in the Windows and OSX drivers; that >> would be another good way to demonstrate how crack-inspired the Broadcom >> position on closed vs. open drivers is. > > Only one problem: the license agreement of these drivers explicitly > forbids any reverse-engineering for any purpose. One can debate a lot > about whether these are enforceable - however, in the US, a similar > case (though that one was about resale, rather than > reverse-engineering) was recently decided in the plaintiff's favor. > And I believe Broadcom would indeed sue if they thought they were > risking their FCC approval by not doing so. As silly as some legal department's position may be I still believe we should not promote breaking regulatory rules and a few of us respect these ideas [1] in order to help bring traction and relationship with vendors [1]. Although we know its possible we simply won't allow patches upstream which break regulatory considerations and vendors are encouraged to help with this and in case they don't we have a framework to already provide some help with some central regulatory control. What hackers do out-of-tree is up to them but within Linux we should respect regulatory considerations. The truth of the matter is current legislation simply is out of date, the change that we need is a shift in liability down to the user for modified supported drivers / firmware much like a person renting a golf cart can run over someone or cause a huge accident with it. Until then different vendors' legal departments will take on different positions and dance all around this doing as big of a show as possible, and while I do think some legal departments positions are extremely naive, the best approach really is to ignore them and lead by example and providing real solutions to the actual problems so that when and if legislation ever does consider a change its clear that there is a path for a change. We need to build a strong consensus towards this slowly. [1] http://wireless.kernel.org/en/developers/Regulatory/statement Luis ^ permalink raw reply [flat|nested] 17+ messages in thread
* [PATCH] b43/b43legacy - Credit Broadcom with enabling the development of the drivers 2010-09-20 16:56 ` Luis R. Rodriguez @ 2010-09-20 19:02 ` Ehud Gavron 2010-09-20 19:09 ` Luis R. Rodriguez 0 siblings, 1 reply; 17+ messages in thread From: Ehud Gavron @ 2010-09-20 19:02 UTC (permalink / raw) To: b43-dev On 09/20/2010 09:56 AM, Luis R. Rodriguez wrote: > 2010/9/20 G?bor Stefanik<netrolller.3d@gmail.com>: > >> On Sun, Sep 19, 2010 at 8:40 PM, David Woodhouse<dwmw2@infradead.org> wrote: >> >>> Broadcom seem bizarrely paranoid about the legal consequences of >>> "enabling" users to violate regulatory requirements. >>> >>> For some reason they seem to think that an open source driver is more of >>> a problem than a closed-source driver. Even though it's often actually >>> *easier* for end-users to use a hex editor to NOP out certain conditional >>> jumps or change constants used in comparisons for regulatory enforcement, >>> than it is for them to patch and rebuild an open source driver. >>> >>> The reverse engineering is hard, of course, but the end-users don't have >>> to do that for themselves -- they only need to follow instructions like >>> 'set the byte at 0x4572 to 0x90'. More to the point, the reverse-engineering >>> part is required *anyway* in order to document the hardware so we can write >>> the open source drivers. We couldn't do an open driver without *first* >>> knowing enough about the closed one that we can bypass the regulatory >>> code in it. >>> >>> Everything we do in the b43 and b43legacy drivers is enabled by >>> Broadcom's original binary-only drivers. >>> >>> So let's make that 'enablement' by Broadcom's binary drivers clear in >>> our source code -- in the hope that it'll narrow the 'risk gap' that >>> they falsely perceive between open and closed source drivers. >>> >>> Or failing that, in the hope that it'll give their crack-addled lawyers >>> aneurysms, and they'll hire some saner ones to replace them. >>> >>> Signed-off-by: David Woodhouse<dwmw2@infradead.org> >>> --- >>> I'd like to see the b43 reverse engineering folks release more such >>> instructions on bypassing the regulatory requirements (boosting TX >>> power, using wrong channels, etc.) in the Windows and OSX drivers; that >>> would be another good way to demonstrate how crack-inspired the Broadcom >>> position on closed vs. open drivers is. >>> >> Only one problem: the license agreement of these drivers explicitly >> forbids any reverse-engineering for any purpose. One can debate a lot >> about whether these are enforceable - however, in the US, a similar >> case (though that one was about resale, rather than >> reverse-engineering) was recently decided in the plaintiff's favor. >> And I believe Broadcom would indeed sue if they thought they were >> risking their FCC approval by not doing so. >> > As silly as some legal department's position may be I still believe we > should not promote breaking regulatory rules and a few of us respect > these ideas [1] in order to help bring traction and relationship with > vendors [1]. Although we know its possible we simply won't allow > patches upstream which break regulatory considerations and vendors are > encouraged to help with this and in case they don't we have a > framework to already provide some help with some central regulatory > control. What hackers do out-of-tree is up to them but within Linux we > should respect regulatory considerations. > > The truth of the matter is current legislation simply is out of date, > the change that we need is a shift in liability down to the user for > modified supported drivers / firmware much like a person renting a > golf cart can run over someone or cause a huge accident with it. Until > then different vendors' legal departments will take on different > positions and dance all around this doing as big of a show as > possible, and while I do think some legal departments positions are > extremely naive, the best approach really is to ignore them and lead > by example and providing real solutions to the actual problems so that > when and if legislation ever does consider a change its clear that > there is a path for a change. We need to build a strong consensus > towards this slowly. > > [1] http://wireless.kernel.org/en/developers/Regulatory/statement > > Luis > > _______________________________________________ > b43-dev mailing list > b43-dev at lists.infradead.org > http://lists.infradead.org/mailman/listinfo/b43-dev > Sorry to include so much... but I wanted to ensure the full context is here. We [coders, developers, testers, users] have no responsibility to weight the VARIOUS and MYRIAD laws that are DIFFERENT the world over. It is up to use (see above) to put together a codebase that allows the hardware to do what it's supposed to. We do not prevent people from using channels/frequencies to which they shouldn't IF THEY CHOOSE TO DO SO. We do not prevent people from downloading copyright content they shouldn't IF THEY CHOOSE TO DO SO. We do not prevent people from viewing images unlawful where they are IF THEY CHOOSE TO DO SO. Please let's not confuse B43 (provide software to make Broadcom's hardware work in Linux) with some LEGAL thing. That's a slippery slope we DON'T want to take, HAVE NOT taken, and SHOULD NOT take. Ehud "Stick to software. Leave lawyering to the lawyers. They'll screw it up anyway." Gavron Tucson AZ US SOL-3 MW-1 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5507 bytes Desc: S/MIME Cryptographic Signature URL: <http://lists.infradead.org/pipermail/b43-dev/attachments/20100920/3de27dd1/attachment.p7s> ^ permalink raw reply [flat|nested] 17+ messages in thread
* [PATCH] b43/b43legacy - Credit Broadcom with enabling the development of the drivers 2010-09-20 19:02 ` Ehud Gavron @ 2010-09-20 19:09 ` Luis R. Rodriguez 2010-09-20 21:22 ` Ehud Gavron 0 siblings, 1 reply; 17+ messages in thread From: Luis R. Rodriguez @ 2010-09-20 19:09 UTC (permalink / raw) To: b43-dev On Mon, Sep 20, 2010 at 12:02 PM, Ehud Gavron <gavron@wetwork.net> wrote: > > > On 09/20/2010 09:56 AM, Luis R. Rodriguez wrote: >> >> 2010/9/20 G?bor Stefanik<netrolller.3d@gmail.com>: >> >>> >>> On Sun, Sep 19, 2010 at 8:40 PM, David Woodhouse<dwmw2@infradead.org> >>> ?wrote: >>> >>>> >>>> Broadcom seem bizarrely paranoid about the legal consequences of >>>> "enabling" users to violate regulatory requirements. >>>> >>>> For some reason they seem to think that an open source driver is more of >>>> a problem than a closed-source driver. Even though it's often actually >>>> *easier* for end-users to use a hex editor to NOP out certain >>>> conditional >>>> jumps or change constants used in comparisons for regulatory >>>> enforcement, >>>> than it is for them to patch and rebuild an open source driver. >>>> >>>> The reverse engineering is hard, of course, but the end-users don't have >>>> to do that for themselves -- they only need to follow instructions like >>>> 'set the byte at 0x4572 to 0x90'. More to the point, the >>>> reverse-engineering >>>> part is required *anyway* in order to document the hardware so we can >>>> write >>>> the open source drivers. We couldn't do an open driver without *first* >>>> knowing enough about the closed one that we can bypass the regulatory >>>> code in it. >>>> >>>> Everything we do in the b43 and b43legacy drivers is enabled by >>>> Broadcom's original binary-only drivers. >>>> >>>> So let's make that 'enablement' by Broadcom's binary drivers clear in >>>> our source code -- in the hope that it'll narrow the 'risk gap' that >>>> they falsely perceive between open and closed source drivers. >>>> >>>> Or failing that, in the hope that it'll give their crack-addled lawyers >>>> aneurysms, and they'll hire some saner ones to replace them. >>>> >>>> Signed-off-by: David Woodhouse<dwmw2@infradead.org> >>>> --- >>>> I'd like to see the b43 reverse engineering folks release more such >>>> instructions on bypassing the regulatory requirements (boosting TX >>>> power, using wrong channels, etc.) in the Windows and OSX drivers; that >>>> would be another good way to demonstrate how crack-inspired the Broadcom >>>> position on closed vs. open drivers is. >>>> >>> >>> Only one problem: the license agreement of these drivers explicitly >>> forbids any reverse-engineering for any purpose. One can debate a lot >>> about whether these are enforceable - however, in the US, a similar >>> case (though that one was about resale, rather than >>> reverse-engineering) was recently decided in the plaintiff's favor. >>> And I believe Broadcom would indeed sue if they thought they were >>> risking their FCC approval by not doing so. >>> >> >> As silly as some legal department's position may be I still believe we >> should not promote breaking regulatory rules and a few of us respect >> these ideas [1] in order to help bring traction and relationship with >> vendors [1]. Although we know its possible we simply won't allow >> patches upstream which break regulatory considerations and vendors are >> encouraged to help with this and in case they don't we have a >> framework to already provide some help with some central regulatory >> control. What hackers do out-of-tree is up to them but within Linux we >> should respect regulatory considerations. >> >> The truth of the matter is current legislation simply is out of date, >> the change that we need is a shift in liability down to the user for >> modified supported drivers / firmware much like a person renting a >> golf cart can run over someone or cause a huge accident with it. Until >> then different vendors' legal departments will take on different >> positions and dance all around this doing as big of a show as >> possible, and while I do think some legal departments positions are >> extremely naive, the best approach really is to ignore them and lead >> by example and providing real solutions to the actual problems so that >> when and if legislation ever does consider a change its clear that >> there is a path for a change. We need to build a strong consensus >> towards this slowly. >> >> [1] http://wireless.kernel.org/en/developers/Regulatory/statement > Sorry to include so much... but I wanted to ensure the full context is here. > > We [coders, developers, testers, users] have no responsibility to weight the > VARIOUS and MYRIAD laws that are DIFFERENT the world over. That's exactly the problem, no one had the business motivation to really try to solve how to really deal with regulatory considerations with FOSS, and average developers simply wanted a solution. Its easier said than done. If you deal with regulatory considerations as a community effort then a path becomes clearer as to how to deal with these issues. The reason why current legislation doesn't seem to make sense is because it does not, but just because a law doesn't make sense it does not enable vendors to ignore it. So the best you can do in the meantime is really be proactive by working on real technical solutions. We are not dealing with legal issues on Linux, we are dealing with engineering solutions, and trust me, we're light years ahead of other OSes because of this now. Luis ^ permalink raw reply [flat|nested] 17+ messages in thread
* [PATCH] b43/b43legacy - Credit Broadcom with enabling the development of the drivers 2010-09-20 19:09 ` Luis R. Rodriguez @ 2010-09-20 21:22 ` Ehud Gavron 2010-09-20 21:33 ` Luis R. Rodriguez 0 siblings, 1 reply; 17+ messages in thread From: Ehud Gavron @ 2010-09-20 21:22 UTC (permalink / raw) To: b43-dev On 09/20/2010 12:09 PM, Luis R. Rodriguez wrote: ...trimmed > That's exactly the problem, no one had the business motivation to > really try to solve how to really deal with regulatory considerations > with FOSS, and average developers simply wanted a solution. Its easier > said than done. If you deal with regulatory considerations as a > community effort then a path becomes clearer as to how to deal with > these issues. The reason why current legislation doesn't seem to make > sense is because it does not, but just because a law doesn't make > sense it does not enable vendors to ignore it. So the best you can do > in the meantime is really be proactive by working on real technical > solutions. > > It is not up to us to "...deal with regulatory considerations..." The "best we can do" is code, and that's what coders do. The lawyers can do what lawyers do.* > We are not dealing with legal issues on Linux, we are dealing with > engineering solutions, and trust me, we're light years ahead of other > OSes because of this now. > > Luis > Light year is a measure of distance. You mean "years"... and we're ahead of others because we're not wasting our time on legal crap. Let the lawyers do that. E * Disclosures: I am not a lawyer. I haven't coded in months. I used to do VMS kernel code. -- -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.infradead.org/pipermail/b43-dev/attachments/20100920/a7bd8119/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: ehudwetworkcontactqrcode.png Type: image/png Size: 1007 bytes Desc: not available URL: <http://lists.infradead.org/pipermail/b43-dev/attachments/20100920/a7bd8119/attachment.png> -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5507 bytes Desc: S/MIME Cryptographic Signature URL: <http://lists.infradead.org/pipermail/b43-dev/attachments/20100920/a7bd8119/attachment.p7s> ^ permalink raw reply [flat|nested] 17+ messages in thread
* [PATCH] b43/b43legacy - Credit Broadcom with enabling the development of the drivers 2010-09-20 21:22 ` Ehud Gavron @ 2010-09-20 21:33 ` Luis R. Rodriguez 2010-09-20 21:51 ` Ehud Gavron 0 siblings, 1 reply; 17+ messages in thread From: Luis R. Rodriguez @ 2010-09-20 21:33 UTC (permalink / raw) To: b43-dev Please avoid HTML e-mails. On Mon, Sep 20, 2010 at 2:22 PM, Ehud Gavron <gavron@wetwork.net> wrote: > > It is not up to us to "...deal with regulatory considerations..." No, you see, that's wrong because no one else was, we started getting upstream support from companies only once we found decent solutions for regulatory. So as much as you want to bark that we don't need to deal with them I can already prove to you that you were wrong. If you don't you simply don't get support, if you do, then you accelerate the pace of adoption for Linux. One way or another the changes have to happen, how you manage to get the changes done will highly affect how soon you'll get support. > The "best we can do" is code, and that's what coders do.? The lawyers can do what lawyers do.* And what do you want to code? Piece of shit reverse engineered quality code? I guarantee you if you get proper vendor support the quality of the drivers improves considerably. > and we're ahead of others because we're not wasting our time on legal crap. No, we are ahead because we envision the path to enhancing radio capabilities and dynamic communication. The regulatory solutions in place in Linux help with regulatory considerations but as a side effect it also paves the way for next generation radio technologies. Luis ^ permalink raw reply [flat|nested] 17+ messages in thread
* [PATCH] b43/b43legacy - Credit Broadcom with enabling the development of the drivers 2010-09-20 21:33 ` Luis R. Rodriguez @ 2010-09-20 21:51 ` Ehud Gavron 2010-09-21 4:01 ` Peter Stuge 0 siblings, 1 reply; 17+ messages in thread From: Ehud Gavron @ 2010-09-20 21:51 UTC (permalink / raw) To: b43-dev On 09/20/2010 02:33 PM, Luis R. Rodriguez wrote: > Please avoid HTML e-mails. > Luis, when I read your first post I thought "Ignore this guy" but then I gave you the benefit of the doubt. Yeah absolutely no HTML. Please avoid giving me commands when you're not my CO. > On Mon, Sep 20, 2010 at 2:22 PM, Ehud Gavron<gavron@wetwork.net> wrote: > >> It is not up to us to "...deal with regulatory considerations..." >> > No, you see, that's wrong because no one else was, That isn't a sentence, and makes no sense if I try to figure out what you intended. > we started getting upstream support from companies "We" got no such thing. > only once we found decent solutions for regulatory. I think there's a noun missing from there, baby. > So as much as you want to bark Woof woof, baby. > that we don't need to deal with them I can already prove to you that you were wrong. I "were" wrong? Cool. So now I'm not. Cool. Thanks. > If you don't you simply don't get support, if you do, then you accelerate the > pace of adoption for Linux. One way or another the changes have to > happen, how you manage to get the changes done will highly affect how > soon you'll get support. > Yeah. Like my older brothers used to say: It's time for you to go to bed. E > >> The "best we can do" is code, and that's what coders do. The lawyers can do what lawyers do.* >> > And what do you want to code? Piece of shit reverse engineered quality > code? I guarantee you if you get proper vendor support the quality of > the drivers improves considerably. > > >> and we're ahead of others because we're not wasting our time on legal crap. >> > No, we are ahead because we envision the path to enhancing radio > capabilities and dynamic communication. The regulatory solutions in > place in Linux help with regulatory considerations but as a side > effect it also paves the way for next generation radio technologies. > > Luis > -- -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5507 bytes Desc: S/MIME Cryptographic Signature URL: <http://lists.infradead.org/pipermail/b43-dev/attachments/20100920/b9a7ebf7/attachment.p7s> ^ permalink raw reply [flat|nested] 17+ messages in thread
* [PATCH] b43/b43legacy - Credit Broadcom with enabling the development of the drivers 2010-09-20 21:51 ` Ehud Gavron @ 2010-09-21 4:01 ` Peter Stuge 2010-09-21 4:24 ` Baybal Ni 0 siblings, 1 reply; 17+ messages in thread From: Peter Stuge @ 2010-09-21 4:01 UTC (permalink / raw) To: b43-dev Ehud Gavron wrote: >>> It is not up to us to "...deal with regulatory considerations..." >> >> No, you see, that's wrong because no one else was, > > That .. > makes no sense if I try to figure out what you intended. I agree with you both. Developers are good at development and in an ideal world that's what we should focus on. Unfortunately our world is not always ideal, so a project such as Linux can get honest (if young) interest from vendors when developers not only do development but do it with vendors' problems in mind. It's certainly not "up to us" - but I think we benefit from stepping up and solving the problem. Being a technical guy you could say that I'm not a fan of artificial limitations, and clearly writing code to *support* such limitations will add some overhead. But on the other hand I have to play the cards I've been dealt if I want to stay in the game, as do vendors, and I think it is nice that Linux solves the (legal) problem for now. I certainly agree that it is a kludge fix and in the wrong place. Unfortunately fixing the law where it is broken takes a long time. :\ The root of problem is the law, but by enabling those who need (or want) to comply with (old, broken) regulation we can get them more involved in Linux and that gets us technical, political and business advantages over other projects that may have been considered alternatives. In the short term it can be bumpy to get a new vendor involved but in the long term I, like Luis, think that it is a win. By applying our development skills to *how* they can comply we can also make sure that we only make compromises where required, and maybe we can even offer something for brand new technology developments. Finally, to play nice with the relevant authorities I think the choice to enable self-policing (if you will) by default makes sense. Of course it must be easy to change for those who want to or need to, and I believe that it is. > It's time for you to go to bed. It sure looked like Luis was in a hurry when he wrote the email. It wasn't the best english I've seen and neither is mine. I guess that he felt that it was important to reply, to try to clarify his point and his reasoning, so that you would have a better chance of seeing the issue also from his point of view. //Peter -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://lists.infradead.org/pipermail/b43-dev/attachments/20100921/a3a28356/attachment-0001.sig> ^ permalink raw reply [flat|nested] 17+ messages in thread
* [PATCH] b43/b43legacy - Credit Broadcom with enabling the development of the drivers 2010-09-21 4:01 ` Peter Stuge @ 2010-09-21 4:24 ` Baybal Ni 2010-09-21 4:44 ` Peter Stuge 2010-09-21 22:38 ` Larry Finger 0 siblings, 2 replies; 17+ messages in thread From: Baybal Ni @ 2010-09-21 4:24 UTC (permalink / raw) To: b43-dev Actually, it's totally legal to write any software for wireless hardware. The only legal limitations are on manufacturer's side rather than on consumer's side. And existence of "hackable" drivers doesn't affect manufacturers approval by FTC in any way. If FTC workers are retarded to a degree that they rate emission rates basing on software, it's nobody's fault beside themselves. It's totally legal to "hack" radio equipment to operate outside of license's diapason, the only criminal liability comes if you try to impair operations of emergency services and military communication systems. Not to mention the fact that the most of world's 480 countries are living outside of "ITUdom" of the developed world, which means that they doesn't have even most "common" radio regulations. On 20 September 2010 21:01, Peter Stuge <peter@stuge.se> wrote: > Ehud Gavron wrote: >>>> It is not up to us to "...deal with regulatory considerations..." >>> >>> No, you see, that's wrong because no one else was, >> >> That > .. >> makes no sense if I try to figure out what you intended. > > I agree with you both. > > Developers are good at development and in an ideal world that's what > we should focus on. Unfortunately our world is not always ideal, so a > project such as Linux can get honest (if young) interest from vendors > when developers not only do development but do it with vendors' > problems in mind. > > It's certainly not "up to us" - but I think we benefit from stepping > up and solving the problem. > > Being a technical guy you could say that I'm not a fan of artificial > limitations, and clearly writing code to *support* such limitations > will add some overhead. But on the other hand I have to play the > cards I've been dealt if I want to stay in the game, as do vendors, > and I think it is nice that Linux solves the (legal) problem for now. > I certainly agree that it is a kludge fix and in the wrong place. > Unfortunately fixing the law where it is broken takes a long time. :\ > > The root of problem is the law, but by enabling those who need (or > want) to comply with (old, broken) regulation we can get them more > involved in Linux and that gets us technical, political and business > advantages over other projects that may have been considered > alternatives. In the short term it can be bumpy to get a new vendor > involved but in the long term I, like Luis, think that it is a win. > > By applying our development skills to *how* they can comply we can > also make sure that we only make compromises where required, and > maybe we can even offer something for brand new technology > developments. Finally, to play nice with the relevant authorities I > think the choice to enable self-policing (if you will) by default > makes sense. Of course it must be easy to change for those who want > to or need to, and I believe that it is. > > >> It's time for you to go to bed. > > It sure looked like Luis was in a hurry when he wrote the email. It > wasn't the best english I've seen and neither is mine. I guess that > he felt that it was important to reply, to try to clarify his point > and his reasoning, so that you would have a better chance of seeing > the issue also from his point of view. > > > //Peter > > _______________________________________________ > b43-dev mailing list > b43-dev at lists.infradead.org > http://lists.infradead.org/mailman/listinfo/b43-dev > > ^ permalink raw reply [flat|nested] 17+ messages in thread
* [PATCH] b43/b43legacy - Credit Broadcom with enabling the development of the drivers 2010-09-21 4:24 ` Baybal Ni @ 2010-09-21 4:44 ` Peter Stuge 2010-09-21 22:38 ` Larry Finger 1 sibling, 0 replies; 17+ messages in thread From: Peter Stuge @ 2010-09-21 4:44 UTC (permalink / raw) To: b43-dev Baybal Ni wrote: > criminal liability comes if you try to impair operations of > emergency services and military communication systems. I guess this is a big deal for the 5GHz radios which can share spectrum with radar systems. It's a good point that regulations differ a lot around the world. //Peter ^ permalink raw reply [flat|nested] 17+ messages in thread
* [PATCH] b43/b43legacy - Credit Broadcom with enabling the development of the drivers 2010-09-21 4:24 ` Baybal Ni 2010-09-21 4:44 ` Peter Stuge @ 2010-09-21 22:38 ` Larry Finger 2010-09-22 5:05 ` Michael Büsch 2010-09-22 11:07 ` David Woodhouse 1 sibling, 2 replies; 17+ messages in thread From: Larry Finger @ 2010-09-21 22:38 UTC (permalink / raw) To: b43-dev NACK on the patch that started this thread. Broadcom got caught violating the GPL and had to provide the binary drivers to compensate for that. They did not provide anything voluntarily. Larry -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.infradead.org/pipermail/b43-dev/attachments/20100921/a2b4f8d6/attachment.html> ^ permalink raw reply [flat|nested] 17+ messages in thread
* [PATCH] b43/b43legacy - Credit Broadcom with enabling the development of the drivers 2010-09-21 22:38 ` Larry Finger @ 2010-09-22 5:05 ` Michael Büsch 2010-09-22 11:14 ` David Woodhouse 2010-09-22 11:07 ` David Woodhouse 1 sibling, 1 reply; 17+ messages in thread From: Michael Büsch @ 2010-09-22 5:05 UTC (permalink / raw) To: b43-dev On Tue, 2010-09-21 at 15:38 -0700, Larry Finger wrote: > > NACK on the patch that started this thread. Broadcom got caught > violating the GPL and had to provide the binary drivers to compensate > for that. They did not provide anything voluntarily. Hm, I actually planned to not reply to this thread, but I think I do have to comment on that one. :) I'm not speaking for Broadcom or anybody else. However, I think first of all Broadcom wasn't caught of anything. (I guess you are talking about the WRT issue, right?). It's the _vendors_ who violated the GPL. Second thing is that I do not think it's possible at all to compensate for a GPL violation by providing binary object code. I don't have to explain why this is the case. It's obvious. Back to the original patch. I do think that David is misunderstood here. I also misunderstood him when we talked about that earlier. Here's the original comment again: + 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. In the end, I am not interested in these legal fights at all. So I do not have an opinion on whether the patch should be applied or not. I am only interested in technical issues and I'll leave the rest to others who might know better (or not). -- Greetings Michael. ^ permalink raw reply [flat|nested] 17+ messages in thread
* [PATCH] b43/b43legacy - Credit Broadcom with enabling the development of the drivers 2010-09-22 5:05 ` Michael Büsch @ 2010-09-22 11:14 ` David Woodhouse 2010-09-22 17:26 ` Luis R. Rodriguez 0 siblings, 1 reply; 17+ messages in thread From: David Woodhouse @ 2010-09-22 11:14 UTC (permalink / raw) To: b43-dev 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. -- dwmw2 ^ permalink raw reply [flat|nested] 17+ messages in thread
* [PATCH] b43/b43legacy - Credit Broadcom with enabling the development of the drivers 2010-09-22 11:14 ` David Woodhouse @ 2010-09-22 17:26 ` Luis R. Rodriguez 0 siblings, 0 replies; 17+ messages in thread From: Luis R. Rodriguez @ 2010-09-22 17:26 UTC (permalink / raw) To: b43-dev On Wed, Sep 22, 2010 at 4:14 AM, David Woodhouse <dwmw2@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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* [PATCH] b43/b43legacy - Credit Broadcom with enabling the development of the drivers 2010-09-21 22:38 ` Larry Finger 2010-09-22 5:05 ` Michael Büsch @ 2010-09-22 11:07 ` David Woodhouse 1 sibling, 0 replies; 17+ messages in thread From: David Woodhouse @ 2010-09-22 11:07 UTC (permalink / raw) To: b43-dev On Tue, 2010-09-21 at 15:38 -0700, Larry Finger wrote: > > NACK on the patch that started this thread. Broadcom got caught > violating the GPL and had to provide the binary drivers to compensate > for that. Um, that makes *absolutely* no sense. Providing a binary driver doesn't satisfy any GPL requirements at all, and can *never* do so. The GPL *never* requires you to distribute binaries. It merely states (for covered works) that *if* you distribute binaries, you must also distribute the corresponding source code. The GPL is not relevant to this particular conversation. Broadcom provided binary drivers (for Windows, Mac OS *and* Linux) because without them, they couldn't sell their hardware. Who buys hardware they can't use? > They did not provide anything voluntarily. Of course they provided the binary drivers voluntarily. Nobody brings a product to market without drivers. I think you may have missed the point. Broadcom are scared of being seen to 'enable' the open source drivers which handle regulatory requirements in software. They're *so* scared of this that they don't even want to make the older firmware available, in binary form, under a licence which allows it to be freely distributed on its own... because that *might* be usable under Linux with the open source driver. But they seem to have missed the point that by designing the hardware that way and shipping their binary drivers which show us how it works, they have *already* enabled those drivers in a much more significant way. And the sky *hasn't* fallen on their head. The point in the patch is to make it abundantly clear that Broadcom were instrumental, even if unintentionally so, in the development of the open source driver that they're so scared of. And thus *hopefully* go some way to reducing their paranoia, and reducing the internal credibility of their crack-inspired lawyers who think the world will end if they 'enable' the open source driver in any way whatsoever. -- dwmw2 ^ permalink raw reply [flat|nested] 17+ messages in thread
* [PATCH] b43/b43legacy - Credit Broadcom with enabling the development of the drivers 2010-09-20 16:36 ` Gábor Stefanik 2010-09-20 16:56 ` Luis R. Rodriguez @ 2010-09-20 21:42 ` David Woodhouse 1 sibling, 0 replies; 17+ messages in thread From: David Woodhouse @ 2010-09-20 21:42 UTC (permalink / raw) To: Gábor Stefanik; +Cc: b43-dev, linux-wireless On Mon, 2010-09-20 at 18:36 +0200, G?bor Stefanik wrote: > Only one problem: the license agreement of these drivers explicitly > forbids any reverse-engineering for any purpose. Which is kind of irrelevant, since the law already prohibits you from violating the regulatory framework. Making it *also* a potential copyright violation (except where it's deemed unenforceable) really doesn't make a blind bit of difference, surely? > One can debate a lot about whether these are enforceable - however, in > the US, a similar case (though that one was about resale, rather than > reverse-engineering) was recently decided in the plaintiff's favor. I don't believe the reverse engineering was done in the US, was it? > And I believe Broadcom would indeed sue if they thought they were > risking their FCC approval by not doing so. I don't see how it really affects their FCC approval. The fact that they do the regulatory enforcement in software is what enables you to trivially bypass it. You are breaking the law by hacking the driver to violate the rules. You knew that anyway -- it really shouldn't make any difference if they *also* tell you it's illegal to hack the driver. And it doesn't change the fact that they have made it possible. -- dwmw2 ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2010-09-22 17:26 UTC | newest] Thread overview: 17+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2010-09-19 18:40 [PATCH] b43/b43legacy - Credit Broadcom with enabling the development of the drivers David Woodhouse 2010-09-20 16:36 ` Gábor Stefanik 2010-09-20 16:56 ` Luis R. Rodriguez 2010-09-20 19:02 ` Ehud Gavron 2010-09-20 19:09 ` Luis R. Rodriguez 2010-09-20 21:22 ` Ehud Gavron 2010-09-20 21:33 ` Luis R. Rodriguez 2010-09-20 21:51 ` Ehud Gavron 2010-09-21 4:01 ` Peter Stuge 2010-09-21 4:24 ` Baybal Ni 2010-09-21 4:44 ` Peter Stuge 2010-09-21 22:38 ` Larry Finger 2010-09-22 5:05 ` Michael Büsch 2010-09-22 11:14 ` David Woodhouse 2010-09-22 17:26 ` Luis R. Rodriguez 2010-09-22 11:07 ` David Woodhouse 2010-09-20 21:42 ` David Woodhouse
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).
