Following Andrew Morton [interview]'s overview of what will likely be merged into the 2.6.18 kernel [story], several developers discussed the legality of the ACX1xx wireless driver. Jeff Garzik began the discussion, "I've never had technical objections to merging this, just AFAIK it had a highly questionable origin, namely being reverse-engineered in a non-clean-room environment that might leave Linux legally vulnerable." Andreas Mohr explained that the open source driver was implemented by the same people that reverse engineered a binary-only driver available at one time in some Linux distributions, "this might fail to comply with usual 'clean-room' practices (e.g. one party examining a driver and then a separate party implementing a new driver with the data gained from examining the original driver)".

The legal necessity of using the "clean-room" method for reverse engineering a driver was called into question. Arjan van de Ven noted, "the 'clean room' thing is ONLY a USA thing, and is not even required in the USA. It is a 'we want to be extra safe in the USA' thing only." Alan Cox [interview] referred to issues with the pwc camera driver [story] as an example and replied, "which is an extremely important detail especially if you have been reverse engineering another driver for the same or similar OS where it is likely that people will retain knowledge and copy rather than re-implement things." Christoph Hellwig took another stance, "please don't let this reverse engineering idiocy hinder wireless driver adoption, we're already falling far behind openbsd who are very successfully reverse engineering lots of wireless chipsets." Jeff Garzik cautioned, "being overzealous about merging drivers without first checking the legal ramifications is a good way to torpedo Linux. Far too many people have a careless 'U.S.A. laws suck, merge it anyway' attitude."

From: Jeff Garzik [email blocked]
To: Andrew Morton [email blocked]
Subject: wireless (was Re: 2.6.18 -mm merge plans)
Date:	Sun, 4 Jun 2006 21:06:36 -0400

On Sun, Jun 04, 2006 at 01:50:11PM -0700, Andrew Morton wrote:
> acx1xx-wireless-driver.patch
> fix-tiacx-on-alpha.patch
> tiacx-fix-attribute-packed-warnings.patch
> tiacx-pci-build-fix.patch
> tiacx-ia64-fix.patch
> 
>   It is about time we did something with this large and presumably useful
>   wireless driver.

I've never had technical objections to merging this, just AFAIK it had a
highly questionable origin, namely being reverse-engineered in a
non-clean-room environment that might leave Linux legally vulnerable.

If we can clear that hurdle, by all means pass it on to John Linville
and get it moving towards upstream.

	Jeff



From: Andrew Morton [email blocked]
Subject: Re: wireless (was Re: 2.6.18 -mm merge plans)
Date:	Sun, 4 Jun 2006 18:15:15 -0700

On Sun, 4 Jun 2006 21:06:36 -0400
Jeff Garzik [email blocked] wrote:

> On Sun, Jun 04, 2006 at 01:50:11PM -0700, Andrew Morton wrote:
> > acx1xx-wireless-driver.patch
> > fix-tiacx-on-alpha.patch
> > tiacx-fix-attribute-packed-warnings.patch
> > tiacx-pci-build-fix.patch
> > tiacx-ia64-fix.patch
> > 
> >   It is about time we did something with this large and presumably useful
> >   wireless driver.
> 
> I've never had technical objections to merging this, just AFAIK it had a
> highly questionable origin, namely being reverse-engineered in a
> non-clean-room environment that might leave Linux legally vulnerable.

I never knew that.

<reads changelog>
<reads website>
<reads wiki>

I still don't know that.  Denis, do you know the details?

> If we can clear that hurdle, by all means pass it on to John Linville
> and get it moving towards upstream.

OK, thanks.



From: Andreas Mohr [email blocked]
Subject: Re: wireless (was Re: 2.6.18 -mm merge plans)
Date:	Mon, 5 Jun 2006 10:33:21 +0200

Hi,

On Sun, Jun 04, 2006 at 06:15:15PM -0700, Andrew Morton wrote:
> On Sun, 4 Jun 2006 21:06:36 -0400
> Jeff Garzik [email blocked] wrote:
> > >   It is about time we did something with this large and presumably useful
> > >   wireless driver.
> > 
> > I've never had technical objections to merging this, just AFAIK it had a
> > highly questionable origin, namely being reverse-engineered in a
> > non-clean-room environment that might leave Linux legally vulnerable.
> 
> I never knew that.
> 
> <reads changelog>
> <reads website>
> <reads wiki>
> 
> I still don't know that.  Denis, do you know the details?

The acx100 project was started by about 5 people examining the various
acx100 binary Linux driver "releases" for distro kernels around 2.4.18 etc.
Since this might fail to comply with usual "clean-room" practices
(e.g. one party examining a driver and then a separate party implementing
a new driver with the data gained from examining the original driver),
it may fail to be seen as acceptable for Linux inclusion.

Since missing kernel inclusion is both a maintenance overhead and
(most importantly!) a huge user-level issue, I'd see this as a big problem.

In case there are development-unrelated obstacles against kernel inclusion,
I see (at least?) two possibilities:

a) asking TI to sprinkle our driver effort with the (ahem) holy penguin pee
   required to have it blessed sufficiently for kernel inclusion (preferrably
   in combination with nice firmware blob licensing and specs for those
   chipsets would be nice)
   This might be a problem given that Theo de Raadt and many other people had
   fun repeatedly trying to contact TI for a useful statement concerning WLAN
   support.

b) abandoning our unfortunately not as blessed as intended (stability,
   community involvement, ...) big-effort driver efforts ("3 years and still
   going strong...") [1] and suggesting donating about 100000 OEM WLAN cards
   equipped with TI chipsets to various beautiful landfills in various
   countries ;-)

Whichever way this irons out, at this point I'm quite indifferent to what
happens, given that I really don't feel like spending too many endless weekends
with hardware and driver puzzles any more in exchange for rather dubious gains.
There's also a lot of fun in generic Linux kernel hacking, so...

Andreas Mohr

[1] we're *still* having issues with spotty ACK reception and radio
temperature drift recalibration on those unsupported chipsets,
which requires quite some focused development efforts and close examination
of WLAN traffic in order to really find out what the heck is going wrong here.
And please note that there's now the newer TNETW1450 chipset variant (most
prominently used by AVM hardware with its initial x86-only Linux USB2.0 driver)
with similar support issues which would require even more development.



From: Arjan van de Ven [email blocked]
Subject: Re: wireless (was Re: 2.6.18 -mm merge plans)
Date:	Mon, 05 Jun 2006 10:45:09 +0200

On Mon, 2006-06-05 at 10:33 +0200, Andreas Mohr wrote:
> Hi,
> 
> On Sun, Jun 04, 2006 at 06:15:15PM -0700, Andrew Morton wrote:
> > On Sun, 4 Jun 2006 21:06:36 -0400
> > Jeff Garzik [email blocked] wrote:
> > > >   It is about time we did something with this large and presumably useful
> > > >   wireless driver.
> > > 
> > > I've never had technical objections to merging this, just AFAIK it had a
> > > highly questionable origin, namely being reverse-engineered in a
> > > non-clean-room environment that might leave Linux legally vulnerable.
> > 
> > I never knew that.
> > 
> > <reads changelog>
> > <reads website>
> > <reads wiki>
> > 
> > I still don't know that.  Denis, do you know the details?
> 
> The acx100 project was started by about 5 people examining the various
> acx100 binary Linux driver "releases" for distro kernels around 2.4.18 etc.
> Since this might fail to comply with usual "clean-room" practices
> (e.g. one party examining a driver and then a separate party implementing
> a new driver with the data gained from examining the original driver),
> it may fail to be seen as acceptable for Linux inclusion.

I disagree there (not speaking for any company just for myself here):
the "clean room" thing is ONLY a USA thing, and is not even required in
the USA. It is a "we want to be extra safe in the USA" thing only. Eg if
you want to be tripple safe and do this in the USA, the clean room is a
good way to be sure.

If you do things in europe or elsewhere, and/or as long as you don't
copy from the original, only use it to learn how it works, you should be
fine as well. It's just that a cleanroom approach is a sure way to prove
you didn't copy. That's all.

If "clean room" now is a requirement for a driver to hit the kernel,
then we need to remove about half the drivers in the kernel I suspect;
that'd just be silly.


I would say that as long as you and the others can certify that you
didn't copy from the original driver, but only used it to learn how it
worked, the kernel should be fine with it.



From: Alan Cox [email blocked]
Subject: Re: wireless (was Re: 2.6.18 -mm merge plans)
Date:	Mon, 05 Jun 2006 11:26:55 +0100

Ar Llu, 2006-06-05 am 10:45 +0200, ysgrifennodd Arjan van de Ven:
>  It's just that a cleanroom approach is a sure way to prove
> you didn't copy. That's all.

Which is an extremely important detail especially if you have been
reverse engineering another driver for the same or similar OS where it
is likely that people will retain knowledge and copy rather than
re-implement things.

We've had "fun" with this before and the pwc camera driver. I don't want
to see a repeat of that.

Alan



From: Arjan van de Ven [email blocked]
Subject: Re: wireless (was Re: 2.6.18 -mm merge plans)
Date:	Mon, 05 Jun 2006 12:35:29 +0200

On Mon, 2006-06-05 at 11:26 +0100, Alan Cox wrote:
> Ar Llu, 2006-06-05 am 10:45 +0200, ysgrifennodd Arjan van de Ven:
> >  It's just that a cleanroom approach is a sure way to prove
> > you didn't copy. That's all.
> 
> Which is an extremely important detail especially if you have been
> reverse engineering another driver for the same or similar OS where it
> is likely that people will retain knowledge and copy rather than
> re-implement things.

oh don't get me wrong, it's important to not copy from the original.
(even if that original did copy from linux ;)


> We've had "fun" with this before and the pwc camera driver. I don't want
> to see a repeat of that.

yet at the same time, the cleanroom approach is not the ONLY way to do
it right. And making following that exact approach a strict requirement
is just silly. And it would mean we'd need to remove quite a few drivers
from the tree if you follow that logic.

And to be fair the pwc camera driver was just a guy with a personality
problem rather than any real legal standing. 

Again doing things right is important. But I would say that if you do
the rev-engineering in Europe, just being careful and avoiding copying
should be enough (well and certifying that you were in fact careful and
didn't do any copying).



From: Alan Cox [email blocked]
Subject: Re: wireless (was Re: 2.6.18 -mm merge plans)
Date:	Mon, 05 Jun 2006 11:59:53 +0100

Ar Llu, 2006-06-05 am 12:35 +0200, ysgrifennodd Arjan van de Ven:
> And to be fair the pwc camera driver was just a guy with a personality
> problem rather than any real legal standing. 

I must disagree there having reviewed the code in question and been
directly involved in the fallout. 

Alan


From: Christoph Hellwig [email blocked]
Subject: Re: wireless (was Re: 2.6.18 -mm merge plans)
Date:	Mon, 5 Jun 2006 09:54:51 +0100

On Sun, Jun 04, 2006 at 09:06:36PM -0400, Jeff Garzik wrote:
> On Sun, Jun 04, 2006 at 01:50:11PM -0700, Andrew Morton wrote:
> > acx1xx-wireless-driver.patch
> > fix-tiacx-on-alpha.patch
> > tiacx-fix-attribute-packed-warnings.patch
> > tiacx-pci-build-fix.patch
> > tiacx-ia64-fix.patch
> > 
> >   It is about time we did something with this large and presumably useful
> >   wireless driver.
> 
> I've never had technical objections to merging this, just AFAIK it had a
> highly questionable origin, namely being reverse-engineered in a
> non-clean-room environment that might leave Linux legally vulnerable.

As are at leasdt a fourth of linux drivers.  Andrew, please just go ahead
and merge it (I'll do another review ASAP).

Please don't let this reverse engineering idiocy hinder wireless driver
adoption, we're already falling far behind openbsd who are very successfull
reverse engineering lots of wireless chipsets.



From: Jeff Garzik [email blocked]
Subject: Re: wireless (was Re: 2.6.18 -mm merge plans)
Date:	Mon, 5 Jun 2006 08:33:04 -0400

On Mon, Jun 05, 2006 at 09:54:51AM +0100, Christoph Hellwig wrote:
> On Sun, Jun 04, 2006 at 09:06:36PM -0400, Jeff Garzik wrote:
> > On Sun, Jun 04, 2006 at 01:50:11PM -0700, Andrew Morton wrote:
> > > acx1xx-wireless-driver.patch
> > > fix-tiacx-on-alpha.patch
> > > tiacx-fix-attribute-packed-warnings.patch
> > > tiacx-pci-build-fix.patch
> > > tiacx-ia64-fix.patch
> > > 
> > >   It is about time we did something with this large and presumably useful
> > >   wireless driver.
> > 
> > I've never had technical objections to merging this, just AFAIK it had a
> > highly questionable origin, namely being reverse-engineered in a
> > non-clean-room environment that might leave Linux legally vulnerable.
> 
> As are at leasdt a fourth of linux drivers.  Andrew, please just go ahead

Hardly.  The -vast majority- of drivers I've dealt with in my time
hacking the kernel are either blessed by the vendor, or are of
unquestionably legal origin.

It's a good thing I pay attention to this issue, too, Mr. Just Go Ahead
And Merge It.


> Please don't let this reverse engineering idiocy hinder wireless driver
> adoption, we're already falling far behind openbsd who are very successfull
> reverse engineering lots of wireless chipsets.

Thanks for your highly professional, legal opinion :)

	Jeff



From: Arjan van de Ven [email blocked]
Subject: Re: wireless (was Re: 2.6.18 -mm merge plans)
Date:	Mon, 05 Jun 2006 14:48:27 +0200


> 
> It's a good thing I pay attention to this issue, too, Mr. Just Go Ahead
> And Merge It.

dude, name calling is way out of line here.

Why is it a good thing you are blocking this driver? Do you have ANY
indication AT ALL that there is anything fishy about it?
(and don't say "they didn't follow cleanroom procedure", because you
know that cleanroom is not the only way to do reverse engineering
properly).

Paying attention to proper reverse engineering is good. Being
overzealous is not.



From: Jeff Garzik [email blocked]
Subject: Re: wireless (was Re: 2.6.18 -mm merge plans)
Date:	Mon, 5 Jun 2006 08:52:35 -0400

On Mon, Jun 05, 2006 at 02:48:27PM +0200, Arjan van de Ven wrote:
> Why is it a good thing you are blocking this driver? Do you have ANY
> indication AT ALL that there is anything fishy about it?

Yes.


> Paying attention to proper reverse engineering is good. Being
> overzealous is not.

Being overzealous about merging drivers without first checking the legal
ramifications is a good way to torpedo Linux.

Far too many people have a careless "U.S.A. laws suck, merge it anyway"
attitude.

	Jeff



From: Adrian Bunk [email blocked]
Subject: Linux kernel and laws
Date:	Mon, 5 Jun 2006 16:02:26 +0200

On Mon, Jun 05, 2006 at 08:52:35AM -0400, Jeff Garzik wrote:
>...
> > Paying attention to proper reverse engineering is good. Being
> > overzealous is not.
> 
> Being overzealous about merging drivers without first checking the legal
> ramifications is a good way to torpedo Linux.
> 
> Far too many people have a careless "U.S.A. laws suck, merge it anyway"
> attitude.

Independent of this issue:

An interesting question is how to handle legal issues properly.

Where is the borderline for rejecting code due to legal issues?
Might not be 100% correct according to laws in the USA.
Might not be 100% correct according to laws in Germany.
Might not be 100% correct according to laws in Finland.
Might not be 100% correct according to laws in Norway.
Might not be 100% correct according to laws in Brasil.
Might not be 100% correct according to laws in Japan.
Might not be 100% correct according to laws in India.
Might not be 100% correct according to laws in Russia.
Might not be 100% correct according to laws in China.
Might not be 100% correct according to laws in Saudi Arabia.
Might not be 100% correct according to laws in Iran.

For me living in Germany, none of these laws except for the German one 
has any relevance.

I've never seen people on this list pointing to probable problems with 
Chinese laws although these laws are relevant for four times as many 
people as US laws.

If someone would state a submission to the kernel might have issues 
according to Chinese laws, or Iranian laws, or Russian laws, would this 
be enough for keeping code out of the kernel?

This might sound like a theoretical question, but e.g. considering that 
the kernel contains cryptography code it's a question that might have 
wide practical implications.

> 	Jeff

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed


From: "John W. Linville" [email blocked]
Subject: Re: wireless (was Re: 2.6.18 -mm merge plans)
Date:	Mon, 5 Jun 2006 09:27:37 -0400

On Mon, Jun 05, 2006 at 09:54:51AM +0100, Christoph Hellwig wrote:
> On Sun, Jun 04, 2006 at 09:06:36PM -0400, Jeff Garzik wrote:
> > On Sun, Jun 04, 2006 at 01:50:11PM -0700, Andrew Morton wrote:
> > > acx1xx-wireless-driver.patch
> > > fix-tiacx-on-alpha.patch
> > > tiacx-fix-attribute-packed-warnings.patch
> > > tiacx-pci-build-fix.patch
> > > tiacx-ia64-fix.patch
> > > 
> > >   It is about time we did something with this large and presumably useful
> > >   wireless driver.
> > 
> > I've never had technical objections to merging this, just AFAIK it had a
> > highly questionable origin, namely being reverse-engineered in a
> > non-clean-room environment that might leave Linux legally vulnerable.
> 
> As are at leasdt a fourth of linux drivers.  Andrew, please just go ahead
> and merge it (I'll do another review ASAP).

Actually, I was planning to merge the softmac-based version for 2.6.18.
It looks like I may want some of Andrew's patches on top (ia64, alpha, etc).

http://www.kernel.org/pub/linux/kernel/people/linville/wireless-2.6/master/

	0003-wireless-add-acx-driver.txt
	0004-acxsm-merge-from-acx-0.3.32.txt
	0005-tiacx-Let-only-ACX_PCI-ACX_USB-be-user-visible.txt
	0007-tiacx-revert-neither-PCI-nor-USB-is-selected-change.txt
	0008-tiacx-implement-much-more-flexible-firmware-statistics-parsing.txt
	0009-tiacx-Change-acx_ioctl_-get-set-_encode-to-use-kernel-80211-stack.txt
	0010-tiacx-fix-breakage-of-Get-rid-of-circular-list-of-adev-s.txt
	0011-tiacx-split-module-into-acx-common-acx-pci-acx-usb.txt

Of course, I didn't know there were serious concerns about this
driver's origin.  I hope we aren't confusing this with the atheros
driver...?

> Please don't let this reverse engineering idiocy hinder wireless driver
> adoption, we're already falling far behind openbsd who are very successfull
> reverse engineering lots of wireless chipsets.

This bugbear does seem to keep visiting us.  It is a bit of a
minefield.

I'm inclined to think that Christoph and Arjan are right, that we
have been too cautious.  Of course, neither of these fine gentlemen
are known for their timidity... :-)

Does not the Signed-off-by: line on a patch submission give us some
level of "good faith" protection?

I'm tempted to take contributors at their word, that they have produced
their own work and not copied from others.  What else do we need?

John
-- 
John W. Linville
linville@tuxdriver.com



From: Arjan van de Ven [email blocked]
Subject: Re: wireless (was Re: 2.6.18 -mm merge plans)
Date:	Mon, 05 Jun 2006 15:42:04 +0200


> Of course, I didn't know there were serious concerns about this
> driver's origin.  I hope we aren't confusing this with the atheros
> driver...?
> 
> > Please don't let this reverse engineering idiocy hinder wireless driver
> > adoption, we're already falling far behind openbsd who are very successfull
> > reverse engineering lots of wireless chipsets.
> 
> This bugbear does seem to keep visiting us.  It is a bit of a
> minefield.
> 
> I'm inclined to think that Christoph and Arjan are right, that we
> have been too cautious.  Of course, neither of these fine gentlemen
> are known for their timidity... :-)
> 
> Does not the Signed-off-by: line on a patch submission give us some
> level of "good faith" protection?

I would suggest asking them an explicit "did you copy anything" and make
sure their "we didn't copy" answer is in the description of the original
patch submission.
> 
> I'm tempted to take contributors at their word, that they have produced
> their own work and not copied from others.  What else do we need?

to a large degree that's all you can do. (of course you can look at the
code for something that looks "obviously not from here" as well, and we
all tend to do that anyway since such stuff tends to highly violate
coding style anyway)



From: Alan Cox [email blocked]
Subject: Re: wireless (was Re: 2.6.18 -mm merge plans)
Date:	Mon, 05 Jun 2006 17:24:51 +0100

Ar Llu, 2006-06-05 am 09:27 -0400, ysgrifennodd John W. Linville:
> Does not the Signed-off-by: line on a patch submission give us some
> level of "good faith" protection?
> 
> I'm tempted to take contributors at their word, that they have produced
> their own work and not copied from others.  What else do we need?

To keep an eye out for problems. Given the questions raised the tiacx
people need to clarify their position and someone needs to look into it.
Until that is done it certainly isn't "good faith" any more.

Alan

• Archive of above thread
• KernelTrap interview with Andrew Morton
• KernelTrap interview with Alan Cox