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 http://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]
On Tue, Mar 1, 2011 at 11:49 PM, <[email protected]> wrote:
> 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 http://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,
please note, this is a staging driver.
cc'ing gregkh.
> 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.
the code is from ralink.
> 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/
>
--
Thanks,
//richard
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.
Regards,
- Ted
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
<resend adding lkml back on, somehow it got dropped on the thread, which
isn't good...>
On Tue, Mar 01, 2011 at 06:38:12PM -0800, [email protected] wrote:
> > On Wed, Mar 02, 2011 at 12:30:45AM +0100, richard -rw- weinberger wrote:
>
>
> >> 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.
> >
> > 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.
What was the license that the code was originaly released under? I see
it on your web site as "public domain" which I think means the companies
involved felt it was safe to put into their drivers, and as such, it
should be also safe to put it into the kernel under the GPL, right?
Was the code published anywhere else (i.e. in the spec itself)?
> 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.
That's not good at all. I'll be glad to remove these files, but the
original license of this code should be determined first, right?
thanks,
greg k-h
On Wed, Mar 02, 2011 at 01:52:04PM -0800, 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.
The problem is the code is on a public web site that says "this code is
in the public domain." I'm not going to go into the whole "what does
public domain really mean" argument here, but I think the people who
took that code and put it into their drivers have a valid assumption
that they did so properly.
thanks,
greg k-h
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
http://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
On 03/03/2011 09:29 PM, David Johnston wrote:
> 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
> http://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.
First of all, thank you (both for the code and for being reasonable.)
It sounds like this might simply have been an honest misreading.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
On Thu, Mar 3, 2011 at 10:34 PM, H. Peter Anvin <[email protected]> wrote:
> On 03/03/2011 09:29 PM, David Johnston wrote:
>> 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
>> http://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.
>
> 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.
-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 ?
Yinghai
On 03/04/2011 02:16 PM, Yinghai Lu wrote:
> On Thu, Mar 3, 2011 at 10:34 PM, H. Peter Anvin <[email protected]> wrote:
>> On 03/03/2011 09:29 PM, David Johnston wrote:
>>> 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
>>> http://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.
>>
>> 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.
>
> -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 ?
>
It's a staging driver for a reason...
-hpa