Following Andrew Morton [interview [1]]'s overview of what will likely be merged into the 2.6.18 kernel [story [2]], 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 [3]] referred to issues with the pwc camera driver [story [4]] 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 [5] [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 [6] [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 [7] [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/ [8] 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 [9]
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 [10] [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
Related Links:
- Archive of above thread [11]
- KernelTrap interview with Andrew Morton [12]
- KernelTrap interview with Alan Cox [13]