Why is my copyright code in the linux kernel?

I was surprised to find code that is mine in Linux.

Following the advice in the REPORTING_BUGS file, I'm sending this email here, for want of knowledge of a better contact.

In 2002, I published code at www.deadhat.com to generate cryptographic vectors to aid in the development of IEEE 802.11i, a spec for which I was a contributor.

One example can be found here:
http://www.deadhat.com/wlancrypto/ccm1.2.c

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,

the MIC header code and some ancillary functions.

However my header with my name and copyright has been removed. A different copyright has been added and it has been licensed under the GPL without my knowledge.

I am a happy user of Linux, I don't want to cause trouble and I'd be quite honored to have some of my code in the kernel, so I'm not demanding the immediate removal of this code. I'm willing to GPL my code if necessary, but I do require proper attribution and acknowledgment of my copyright on my code

I'd like to know who is an appropriate person to discuss this with.

Thank you,
David Johnston
[email protected]

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

Quoted 2 lines

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.

Quoted 1 line

I'd like to know who is an appropriate person to discuss this with.

the code is from ralink.

Quoted 4 lines · richard -rw- weinberger

Quoted 2 lines

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.

Quoted 2 lines

Quoted 1 line

I'd like to know who is an appropriate person to discuss this with.

Quoted 1 line

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.

Quoted 19 lines · Ted Ts'o

Quoted 4 lines · richard -rw- weinberger

Quoted 2 lines

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.

Quoted 2 lines

Quoted 1 line

I'd like to know who is an appropriate person to discuss this with.

Quoted 8 lines

Quoted 1 line

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.

Quoted 15 lines · Ted Ts'o

Quoted 3 lines · richard -rw- weinberger

Quoted 2 lines

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.

Quoted 8 lines

Quoted 2 lines

Quoted 1 line

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.

Quoted 6 lines · David Johnston

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.

Quoted 1 line

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

First of all, thank you (both for the code and for being reasonable.)

It sounds like this might simply have been an honest misreading.

Quoted 7 lines · H. Peter Anvin

Quoted 6 lines · David Johnston

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.

Quoted 6 lines

Quoted 1 line

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

First of all, thank you (both for the code and for being reasonable.)

It sounds like this might simply have been an honest misreading.

interesting.

in the git history, some functions take IN/OUT macro.

(quoted diff) +0 -3

-VOID AES_GTK_KEY_UNWRAP(IN UCHAR * key,
-                       OUT UCHAR * plaintext,
-                       IN UINT32 c_len, IN UCHAR * ciphertext)

so they had driver for other os at first, and ported that one to Linux later ?

Quoted 11 lines · richard -rw- weinberger

Quoted 3 lines

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.

Quoted 4 lines

Regards,

- Ted

Thank you. I will contact ralink after I work out who to contact. I'm not particularly looking for any code to be deleted, just to have my copyright in the header if it is to remain. I will happily GPL those parts that are my code if necessary. While ralink might be misrepresenting the copyright (and VIA - see below) it's kernel.org that's distributing it.

The code is in use in proprietary 802.11 and 802.16 products from a few companies. So it is reasonably important that the Linux kernel isn't propagating false copyright information about it. I granted permission to some companies to use the code when they asked, but never ralink or VIA.

As far as the quality of the code - I never wrote the code for production purposes. It's pedagogical code, which is why it is so byte oriented. In a standards setting body writing crypto specs, it's really easy to lose track of which end is which. There are more compact, more efficient ways to write it, not that performance matters much for 802.11i session key set up algorithms.

I've done a little digging and I've found my code in other places in the current stable kernel 2.6.37.2 that I just downloaded:
drivers/staging/rtl8712/rtl871x_security.c - AES & TKIP Key mixing and MIC. drivers/staging/rt2860/common/cmm_tkip.c - TKIP key mixing and MIC. drivers/staging/vt6656/tkip.c - TKIP Key mixing code

The latter being from VIA, interestingly claiming 1996 copyright on code I wrote in 2001/2002 for an algorithm that didn't exist in 1996.