* Kernel GPL Violations and How to Research
@ 2004-02-10 4:53 Gidon
2004-02-10 19:20 ` Matthew Dharm
2004-02-13 19:02 ` Pavel Machek
0 siblings, 2 replies; 6+ messages in thread
From: Gidon @ 2004-02-10 4:53 UTC (permalink / raw)
To: linux-kernel
Greetings,
I am unsure as to where to begin with this, but I have found a project
that I believe contains Linux kernel code and is not honouring the
requirements of the GPL. I will not disclose the name of the project to
anyone but the main Kernel developers or legal counsel because I do not
want thousands of angry emails disparaging the project in question. My
goal in this matter is to identify and make as certain as possible that:
1) A violation actually exists
2) To see the matter resolved through education regarding the terms of
the license of the Linux kernel code
3) To have any code if it is indeed violating the GPL license to be
replaced or removed
4) Failing number three, to see the Kernel's license honoured and if not
ensuring that the proper people have enough information to move forward
with any necessary steps to see that it is
I have already contacted the legal counsel for the FSF for advice as
well as the previous maintainer of the file / code in question that I
believe has been misappropriated. Both suggested I further research the
issue in detail and that my initial findings "looked bad" for the
project in question. However, during further research it has come to
attention that it is rather difficult to confirm whether or not a
particular program is using GPL'd code.
So what I am writing to ask, is what is the best way to ascertain
whether or not a binary (in this case a "kernel image" of this project)
contains GPL'd code or functions. So far I have found nearly a hundred
identical (down to formatting specifiers, punctuation, etc.) or nearly
identical error messages that consistently match areas of Linux i386
arch specific kernel code or drivers as well as matching function names,
using the "strings" program on their Kernel image.
It is my belief (and hope) at this point that the project in question is
violating the GPL, but out of ignorance rather than intentional
disregard for the license of Linux kernel code.
Any assistance from a Kernel maintainer or other qualified individual
that is willing to help me discreetly in this matter would be greatly
appreciated.
Thanks,
--
I am subscribed to this mailing list. It is not necessary to CC me.
Thank you. -Gidon
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Kernel GPL Violations and How to Research
2004-02-10 4:53 Kernel GPL Violations and How to Research Gidon
@ 2004-02-10 19:20 ` Matthew Dharm
2004-02-10 21:49 ` Gidon
2004-02-13 19:02 ` Pavel Machek
1 sibling, 1 reply; 6+ messages in thread
From: Matthew Dharm @ 2004-02-10 19:20 UTC (permalink / raw)
To: Gidon; +Cc: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 1430 bytes --]
On Mon, Feb 09, 2004 at 10:53:50PM -0600, Gidon wrote:
> So what I am writing to ask, is what is the best way to ascertain
> whether or not a binary (in this case a "kernel image" of this project)
> contains GPL'd code or functions. So far I have found nearly a hundred
> identical (down to formatting specifiers, punctuation, etc.) or nearly
> identical error messages that consistently match areas of Linux i386
> arch specific kernel code or drivers as well as matching function names,
> using the "strings" program on their Kernel image.
Usually for me, the next step is to disassemble their object code for
symbol information using objdump.
You should be able to get some function names, variable names, etc. from
that -- if those match the kernel code in question, that's about as good a
"smoking gun" as you can expect to find. 'strings' isn't as good for
function names.
As a final level of analysis, you can always look at the compiled binary
code -- if you think they are using a _reasonably_ compatible compiler, you
might actually be able to find long sections of identical or near-identical
assembly (modulo loop unrolling, etc. which you should be able to identify
by hand.)
Matt
--
Matthew Dharm Home: mdharm-usb@one-eyed-alien.net
Maintainer, Linux USB Mass Storage Driver
It's monday. It must be monday.
-- Greg
User Friendly, 5/4/1998
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Kernel GPL Violations and How to Research
2004-02-10 19:20 ` Matthew Dharm
@ 2004-02-10 21:49 ` Gidon
2004-02-10 21:52 ` Matthew Dharm
0 siblings, 1 reply; 6+ messages in thread
From: Gidon @ 2004-02-10 21:49 UTC (permalink / raw)
To: Matthew Dharm; +Cc: linux-kernel
On Tue, 2004-02-10 at 13:20, Matthew Dharm wrote:
> As a final level of analysis, you can always look at the compiled binary
> code -- if you think they are using a _reasonably_ compatible compiler, you
> might actually be able to find long sections of identical or near-identical
> assembly (modulo loop unrolling, etc. which you should be able to identify
> by hand.)
Your advice is appreciated. I will do some further research using
objdump. I believe they use gcc.
One thing I am unsure of is how to approach them and ensure at the same
time that the problem is taken care of. Another words, if I show them
what's wrong, they may simply obfuscate it (although at this time I hope
not) and then I have no way to easily prove anything anymore...
--
I am subscribed to this mailing list. It is not necessary to CC me.
Thank you. -Gidon
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Kernel GPL Violations and How to Research
2004-02-10 21:49 ` Gidon
@ 2004-02-10 21:52 ` Matthew Dharm
2004-02-10 22:07 ` Gidon
0 siblings, 1 reply; 6+ messages in thread
From: Matthew Dharm @ 2004-02-10 21:52 UTC (permalink / raw)
To: Gidon; +Cc: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 1297 bytes --]
On Tue, Feb 10, 2004 at 03:49:56PM -0600, Gidon wrote:
> On Tue, 2004-02-10 at 13:20, Matthew Dharm wrote:
> > As a final level of analysis, you can always look at the compiled binary
> > code -- if you think they are using a _reasonably_ compatible compiler, you
> > might actually be able to find long sections of identical or near-identical
> > assembly (modulo loop unrolling, etc. which you should be able to identify
> > by hand.)
>
> Your advice is appreciated. I will do some further research using
> objdump. I believe they use gcc.
>
> One thing I am unsure of is how to approach them and ensure at the same
> time that the problem is taken care of. Another words, if I show them
> what's wrong, they may simply obfuscate it (although at this time I hope
> not) and then I have no way to easily prove anything anymore...
Obfuscation can obscure the names of functions, but generally not string
constants or the structure of functions calling other functions.
Tho, if it comes to that point, you need a lawyer.
Matt
--
Matthew Dharm Home: mdharm-usb@one-eyed-alien.net
Maintainer, Linux USB Mass Storage Driver
What, are you one of those Microsoft-bashing Linux freaks?
-- Customer to Greg
User Friendly, 2/10/1999
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Kernel GPL Violations and How to Research
2004-02-10 21:52 ` Matthew Dharm
@ 2004-02-10 22:07 ` Gidon
0 siblings, 0 replies; 6+ messages in thread
From: Gidon @ 2004-02-10 22:07 UTC (permalink / raw)
To: Matthew Dharm; +Cc: linux-kernel
On Tue, 2004-02-10 at 15:52, Matthew Dharm wrote:
> Obfuscation can obscure the names of functions, but generally not string
> constants or the structure of functions calling other functions.
Sadly, objdump turns up nothing really interesting. The kernel image is
in i386-linux a.out format. This is all it gives me for headers:
SOME.FILE: file format a.out-i386-linux
SOME.FILE
architecture: i386, flags 0x000001be:
EXEC_P, HAS_LINENO, HAS_DEBUG, HAS_SYMS, HAS_LOCALS, WP_TEXT, D_PAGED
start address 0x00100020
Sections:
Idx Name Size VMA LMA File off Algn
0 .text 00079fc0 00000020 00000020 00000020 2**2
CONTENTS, ALLOC, LOAD, CODE
1 .data 0002a000 0007a000 0007a000 00079fe0 2**2
CONTENTS, ALLOC, LOAD, DATA
2 .bss 00018004 000a4000 000a4000 00000000 2**2
ALLOC
It is easier to read some of the function names and other things using
objdump's -s option, but beyond that it's not much more useful than
strings. It appears that I will have to get medieval on it.
--
I am subscribed to this mailing list. It is not necessary to CC me.
Thank you. -Gidon
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Kernel GPL Violations and How to Research
2004-02-10 4:53 Kernel GPL Violations and How to Research Gidon
2004-02-10 19:20 ` Matthew Dharm
@ 2004-02-13 19:02 ` Pavel Machek
1 sibling, 0 replies; 6+ messages in thread
From: Pavel Machek @ 2004-02-13 19:02 UTC (permalink / raw)
To: Gidon; +Cc: linux-kernel
Hi!
> So what I am writing to ask, is what is the best way to ascertain
> whether or not a binary (in this case a "kernel image" of this project)
> contains GPL'd code or functions. So far I have found nearly a hundred
> identical (down to formatting specifiers, punctuation, etc.) or nearly
> identical error messages that consistently match areas of Linux i386
> arch specific kernel code or drivers as well as matching function names,
> using the "strings" program on their Kernel image.
At this point you can be pretty sure they are violating GPL. Archive binary
they provide, and ask them for the sources.
(Drivers may come from BSD, but arch-i386 is probably not.)
--
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2004-02-15 15:22 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-02-10 4:53 Kernel GPL Violations and How to Research Gidon
2004-02-10 19:20 ` Matthew Dharm
2004-02-10 21:49 ` Gidon
2004-02-10 21:52 ` Matthew Dharm
2004-02-10 22:07 ` Gidon
2004-02-13 19:02 ` Pavel Machek
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®