wireless (was Re: 2.6.18 -mm merge plans)

wireless (was Re: 2.6.18 -mm merge plans)

[Jeff Garzik]

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

Re: wireless (was Re: 2.6.18 -mm merge plans)

[Andrew Morton]

On Sun, 4 Jun 2006 21:06:36 -0400
Jeff Garzik <jeff@garzik.org> 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.

Re: wireless (was Re: 2.6.18 -mm merge plans)

[Andreas Mohr]

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 <jeff@garzik.org> 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.

Re: wireless (was Re: 2.6.18 -mm merge plans)

[Arjan van de Ven]

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 <jeff@garzik.org> 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.

Re: wireless (was Re: 2.6.18 -mm merge plans)

[Alan Cox]

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

Re: wireless (was Re: 2.6.18 -mm merge plans)

[Arjan van de Ven]

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).

Re: wireless (was Re: 2.6.18 -mm merge plans)

[Alan Cox]

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

Re: wireless (was Re: 2.6.18 -mm merge plans)

[Pavel Machek]

Hi!

> > >  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 th?ngs.
> 
> oh don't get me wrong, it's important to not copy from the original.
> (even if that original did copy from linux ;)

Well, if original did copy from linux, it surely is GPLed and case
closed, no? Being sued from vendor not respecting the GPL would
probably only do harm to them.

Like US courts are crazy, but hopefully not _that_ crazy.
							Pavel
-- 
Thanks for all the (sleeping) penguins.

Re: wireless (was Re: 2.6.18 -mm merge plans)

[Christoph Hellwig]

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.

Re: wireless (was Re: 2.6.18 -mm merge plans)

[Jeff Garzik]

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

Re: wireless (was Re: 2.6.18 -mm merge plans)

[Arjan van de Ven]

> 
> 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.

Re: wireless (was Re: 2.6.18 -mm merge plans)

[Jeff Garzik]

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

Linux kernel and laws

[Adrian Bunk]

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

Re: Linux kernel and laws

[linux-os (Dick Johnson)]

On Mon, 5 Jun 2006, Adrian Bunk wrote:

> 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

If the kernel represented simply a knowledge base, then the burden
about whether or not someone could use it used to rest entirely
upon the user. That's why some Pacific rim governments are reportedly
fire-walling information.

In most western cultures, knowledge was not a crime. For many years,
someone could write a book, telling you how to kill somebody and,
as long as he didn't carry it out, he could not be held culpable.

Recently, in the US and some other countries, knowledge has become
criminalized. If you know how to defeat copy protection, and
you are not in a protected industry, you could be tried and
convicted of a federal crime.

That's one of the reasons why there are now no general guidelines
about kernel code, or any intellectual property use, for that matter.
The conditions could occur where the government thinks that you
know too much and are, therefore, a threat to "national security".

So, again, see a lawyer. The fact that you sought and accepted
legal opinion may in the future be your only viable defense as
governments bring charges against you! Sorry state of affairs for
sure.

Cheers,
Dick Johnson
Penguin : Linux version 2.6.16.4 on an i686 machine (5592.88 BogoMips).
New book: http://www.AbominableFirebug.com/
_
\x1a\x04

****************************************************************
The information transmitted in this message is confidential and may be privileged.  Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.

Re: Linux kernel and laws

[Evgeniy Polyakov]

On Mon, Jun 05, 2006 at 04:02:26PM +0200, Adrian Bunk (bunk@stusta.de) wrote:
> > Far too many people have a careless "U.S.A. laws suck, merge it anyway"
> > attitude.
> 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?

Btw, did kernel hackers consulted with Papua New Guinea or bloody
Russian laws? It is possible that they have a law which forbids to write 
open source code. So we should stop Linux kernel development and completely 
remove it's sources from the Internet ASAP.

P.S. It is explicitly permitted to make reverse engineering in Russia.

-- 
	Evgeniy Polyakov

Re: wireless (was Re: 2.6.18 -mm merge plans)

[John W. Linville]

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

Re: wireless (was Re: 2.6.18 -mm merge plans)

[Christoph Hellwig]

On Mon, Jun 05, 2006 at 09:27:37AM -0400, John W. Linville wrote:
> 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).

duh, didn't know that wasn't in -mm.  we want the softmac version of course.

Re: wireless (was Re: 2.6.18 -mm merge plans)

[Arjan van de Ven]

> 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)

Re: wireless (was Re: 2.6.18 -mm merge plans)

[Alan Cox]

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

ACX100 (softmac-based) driver ready to merge, but is it legal? -- Re: wireless (was Re: 2.6.18 -mm merge plans)

[John W. Linville]

On Mon, Jun 05, 2006 at 05:24:51PM +0100, Alan Cox wrote:
> 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.

I apologize for the long copy list.  I have tried to include all
known interested parties.

This is a follow-up to a thread started by Andrew a few weeks ago
about what should be merged for 2.6.18.  One of the topics he cited
was the ACX100 driver which he has carried in -mm for quite some time.
I have a slightly different (softmac based) version of that driver
in wireless-2.6 which I think is worth merging now.

In the aforementioned thread, some questions were raised about the
legality of the ACX100 driver (i.e. tiacx) code base, but no one
had any specific points other than that it is not 100% "clean room"
derived.  Others point-out that this is not strictly a requirement.
The matter dropped without a strong defense from the tiacx team.

I hereby invite the tiacx team to defend their work by making public,
affirmative statements indicating a) how they produced their code; and,
b) that they have the legal right to license it as part of the Linux
kernel under the GPL.  As an incentive to this, I have already made
the necessary preparations for this driver to be merged immediately.

This is the softmac-based tiacx that has been in wireless-2.6 for
some time, with the addition of a few patches that akpm had in -mm
which I did not previously have.  For easy review, a tarball with
the full driver is available here:

	http://www.kernel.org/pub/linux/kernel/people/linville/tiacx.tar.gz

A git pull request follows.  I am confident that if the legal status
of this code can be confirmed, it will be merged upstream ASAP.

Comments welcome!

Thanks,

John

---

The following changes since commit 70a332b048e4d90635dfa47fc5d91cf87b5cc3a5:
  John W. Linville:
        softmac: fix build-break from 881ee6999d66c8fc903b429b73bbe6045b38c549

are found in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git tiacx

Andreas Mohr:
      tiacx: implement much more flexible firmware statistics parsing

Andrew Morton:
      tiacx: pci build fix

Carlos Martin:
      tiacx: fix breakage of "Get rid of circular list of adev's"
      tiacx: split module into acx-common + acx-pci + acx-usb

Denis Vlasenko:
      acxsm: merge from acx 0.3.32
      tiacx: revert "neither PCI nor USB is selected" change
      tiacx: Change acx_ioctl_{get,set}_encode to use kernel 80211 stack
      fix tiacx on alpha
      tiacx: fix attribute packed warnings

John W. Linville:
      wireless: add acx driver
      tiacx: Let only ACX_PCI/ACX_USB be user-visible
      tiacx: support ia64

 drivers/net/wireless/Kconfig             |    1 
 drivers/net/wireless/Makefile            |    2 
 drivers/net/wireless/tiacx/Changelog     |  114 
 drivers/net/wireless/tiacx/Kconfig       |   65 
 drivers/net/wireless/tiacx/Makefile      |    6 
 drivers/net/wireless/tiacx/README        |   61 
 drivers/net/wireless/tiacx/acx.h         |   11 
 drivers/net/wireless/tiacx/acx_config.h  |   40 
 drivers/net/wireless/tiacx/acx_func.h    |  598 ++
 drivers/net/wireless/tiacx/acx_struct.h  | 2048 ++++++++
 drivers/net/wireless/tiacx/common.c      | 7542 ++++++++++++++++++++++++++++++
 drivers/net/wireless/tiacx/ioctl.c       | 2738 +++++++++++
 drivers/net/wireless/tiacx/pci.c         | 4243 +++++++++++++++++
 drivers/net/wireless/tiacx/setrate.c     |  213 +
 drivers/net/wireless/tiacx/usb.c         | 1954 ++++++++
 drivers/net/wireless/tiacx/wlan.c        |  422 ++
 drivers/net/wireless/tiacx/wlan_compat.h |  267 +
 drivers/net/wireless/tiacx/wlan_hdr.h    |  497 ++
 drivers/net/wireless/tiacx/wlan_mgmt.h   |  582 ++
 19 files changed, 21404 insertions(+), 0 deletions(-)
 create mode 100644 drivers/net/wireless/tiacx/Changelog
 create mode 100644 drivers/net/wireless/tiacx/Kconfig
 create mode 100644 drivers/net/wireless/tiacx/Makefile
 create mode 100644 drivers/net/wireless/tiacx/README
 create mode 100644 drivers/net/wireless/tiacx/acx.h
 create mode 100644 drivers/net/wireless/tiacx/acx_config.h
 create mode 100644 drivers/net/wireless/tiacx/acx_func.h
 create mode 100644 drivers/net/wireless/tiacx/acx_struct.h
 create mode 100644 drivers/net/wireless/tiacx/common.c
 create mode 100644 drivers/net/wireless/tiacx/ioctl.c
 create mode 100644 drivers/net/wireless/tiacx/pci.c
 create mode 100644 drivers/net/wireless/tiacx/setrate.c
 create mode 100644 drivers/net/wireless/tiacx/usb.c
 create mode 100644 drivers/net/wireless/tiacx/wlan.c
 create mode 100644 drivers/net/wireless/tiacx/wlan_compat.h
 create mode 100644 drivers/net/wireless/tiacx/wlan_hdr.h
 create mode 100644 drivers/net/wireless/tiacx/wlan_mgmt.h

The complete (history-free) is available here:

	http://www.kernel.org/pub/linux/kernel/people/linville/tiacx.patch.gz

-- 
John W. Linville
linville@tuxdriver.com

Re: [Acx100-users] Denis Vlasenko, where are you? (mail bounced)

[Andreas Mohr]

Hi,

On Thu, Jun 29, 2006 at 10:42:39AM -0400, John W. Linville wrote:
> If anyone knows how to get in touch w/ Denis, I'd appreciate it...

He sent me (and few other addresses) his new address recently
(*important* mails only!):

vda.linux AT a server called googlemail.com

(he got a new job and moved)

Andreas Mohr

Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

Re: ACX100 (softmac-based) driver ready to merge, but is it legal?

[Denis Vlasenko]

On Thursday 29 June 2006 16:26, John W. Linville wrote:
> I apologize for the long copy list.  I have tried to include all
> known interested parties.
> 
> This is a follow-up to a thread started by Andrew a few weeks ago
> about what should be merged for 2.6.18.  One of the topics he cited
> was the ACX100 driver which he has carried in -mm for quite some time.
> I have a slightly different (softmac based) version of that driver
> in wireless-2.6 which I think is worth merging now.
> 
> In the aforementioned thread, some questions were raised about the
> legality of the ACX100 driver (i.e. tiacx) code base, but no one
> had any specific points other than that it is not 100% "clean room"
> derived.  Others point-out that this is not strictly a requirement.
> The matter dropped without a strong defense from the tiacx team.
>
> I hereby invite the tiacx team to defend their work by making public,
> affirmative statements indicating a) how they produced their code; and,
> b) that they have the legal right to license it as part of the Linux
> kernel under the GPL.  As an incentive to this, I have already made
> the necessary preparations for this driver to be merged immediately.

About the part of the acx code which was done by me:
I was working upon the already existing acx driver.

I do not know how it was developed before I started to play with it,
but I certainly never worked for TI and did not receive any code
or documents from TI (I was asking for the documentation,
but there was no answer).

I realize that this info is not enough to determine whether tiacx
driver is "clean" legalese-wise.
--
vda