linux-kernel - Re: Why is my copyright code in the linux kernel?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 03 Mar 2011 21:29:44 -0800
From:	David Johnston <dj@...dhat.com>
To:	"H. Peter Anvin" <hpa@...or.com>, tytso@....edu,
	richard.weinberger@...il.com, linux-kernel@...r.kernel.org,
	gregkh@...e.de
Subject: Re: Why is my copyright code in the linux kernel?

On 3/2/2011 1:52 PM, H. Peter Anvin wrote:
> On 03/01/2011 03:54 PM, Ted Ts'o wrote:
>> On Wed, Mar 02, 2011 at 12:30:45AM +0100, richard -rw- weinberger wrote:
>>>> You will see a remarkable resemblance to parts of
>>>> linux-2.6.36.2/drivers/staging/rt2860/common/cmm_aes.c. E.G. the AES code,
>>> please note, this is a staging driver.
>> It's not even the primary driver.  Is there anything that this driver
>> provides that isn't provided by the upstream supported, mainline
>> rt2x00 project?  I.e., can we just delete the staging driver?
>>
>> If we are going to keep the staging driver for some reason, one of the
>> things that should be added to the TODO list would be delete its
>> driver-specific AES code and replace it with calls to the kernel's
>> generic AES code, which among other things, has the advantage that it
>> can take advantage of the AES-NI instructions provided on more modern
>> x86 CPU's.
>>
>>>> I'd like to know who is an appropriate person to discuss this with.
>>> the code is from ralink.
>> David, you might want to contact ralink directly, since it's likely
>> they are distributing that driver with your AES code in other places
>> besides just in the mainstream kernel sources.  Even if we delete the
>> code in the staging tree, they might be distributing that driver still
>> via other means.
>>
> I think it's more fundamental than that.  If ralink -- or anyone else --
> submitted a plagiarized driver to the staging tree, we should remove it
> immediately unless the copyright holder (David in this case) is willing
> to allow us to retain it while things are sorted out.
>
> And yes, David still needs to contact ralink about sorting out the
> violation.
>
> Finally, obviously, a proper Linux driver should use the AES facilities
> in the kernel crypto core.
>
> 	-hpa
Yes I am willing to allow you to retain it.
I guess, to be all legalese..
     I herein permit you to use any 802.11 related C code taken from the 
www.deadhat.com website, in the linux kernel, and to publish it under 
the terms of version 2 of the GNU General Public License.

Yes I've emailed ralink and VIA. I hope they're nice people.

DJ



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/