[TUHS] Fwd: Helping in the battle against SCO

[TUHS] Fwd: Helping in the battle against SCO

[Matthew Mastracci]

What about comparing SVR1/2 to 2.4.x?  SCO seems to be picking on the 
early 2.4.x codebase.  This should also pick up the SGI code comments in 
the malloc() function that were recently publicized, though I'm not sure 
which version Linus removed the code from.

Matt.

[TUHS] Fwd: Helping in the battle against SCO

[Warren Toomey]

On Wed, Sep 10, 2003 at 02:18:15PM -0600, Matthew Mastracci wrote:
> What about comparing SVR1/2 to 2.4.x?  SCO seems to be picking on the 
> early 2.4.x codebase.  This should also pick up the SGI code comments in 
> the malloc() function that were recently publicized, though I'm not sure 
> which version Linus removed the code from.
> Matt.

Yes we can do this. But I'm suspecting that SCO has found lots of BSD
code in both Linux and their codebase. SysVR2 didn't have any networking,
so we probably won't get much similarity. Anyway, we can try!

	Warren

[TUHS] Fwd: Helping in the battle against SCO

[M. Warner Losh]

In message: <20030915204355.EB9311E5D at minnie.tuhs.org>
            norman at nose.cs.utoronto.ca (Norman Wilson) writes:
: tracking it all down and trying to declare where each line came from,

In BSD land, we can do that.  We have cvs annotate.  Looks like the
stubborn refusal to use source code control, and to have only a few
people putting things together makes it a lot harder to track things
down after the fact.  Good call that.

Warner

[TUHS] Fwd: Helping in the battle against SCO

[Norman Wilson]

Andru Luvisi:

  If SCO holds up a piece of common code and the good guys have no
  response, that is bad.

  If SCO holds up a piece of common code and the good guys already know
  that it actually came from BSD, and are prepared to demonstrate such,
  that is good.

  If SCO holds up a piece of common code and the good guys already know
  that it was contributed to Linux by SCO/Caldera themselves, and are
  prepared to demonstrate such, that is good.

  If there is infringing code, it should be taken out of Linux as quickly
  as possible.

======

I'll grant all those points, but if the idea is to defang SCO, the
effort still seems fruitless to me.

System V and Linux both contain appallingly large volumes of code.
(On a list that discusses the UNIX of the 1970s, perhaps I can say
that without creating undue ruckus.)  The odds are that quite a
lot of the code is similar.  Should we really spend months and months
tracking it all down and trying to declare where each line came from,
or should we wait until SCO declares a specific set of cases that matter
(as they must do sooner or later or abandon the court battle)?

When one is faced with an enormous set of possible computations, of
which only a handful are likely to be needed in the end, lazy evaluation
is usually the better choice.

It does seem sensible to me for the Linux community to do its best to
hunt down any infringing code, and to try to assess whether there's a
serious problem lurking that nobody had noticed.  But that ought to be
a matter of basic ethics, having nothing to do with SCO.  I doubt it
is likely to make much difference to the court battle anyway: SCO's
claim is that the infringing code is there now, that it was put there
deliberately at IBM's instigation to do harm to them, and that the harm
already exists; removing it now won't change any of that.  I think it's
a good idea to remove any infringements that are there now, even if they
are trivial ones; but let's not fool ourselves that it will pull SCO's
fangs to do so.

Norman Wilson
Toronto ON

[TUHS] Fwd: Helping in the battle against SCO

[Greg Lehey]

On Wednesday, 10 September 2003 at 17:41:49 -0700, Andru Luvisi wrote:
> On Wed, 10 Sep 2003, Norman Wilson wrote:
>> I don't see how any diffing we do will make any difference
>> `in the battle against SCO.'
> [snip]
>
> Some ways that I can see it being a good thing to do:
>
>   If SCO holds up a piece of common code and the good guys have no
>   response, that is bad.

Agreed.  That doesn't apply to either piece of code they've shown so
far.  This is http://www.lemis.com/grog/SCO/code-comparison.html
again.

>   If SCO holds up a piece of common code and the good guys already
>   know that it actually came from BSD, and are prepared to
>   demonstrate such, that is good.

That's the second example :-) The question I've asked SCO is: how
could you have missed the Berkeley license agreement at the beginning
of this file?  SCO have backed off claiming that this is System V
code, and claim it's just an example of their code comparison
techniques.  But on slide 15 of their presentation
(http://www.vangennip.nl/perens/SCOsource_Briefing_II.2.pdf), they
clearly claim that it's System V code.  This suggests that SCO have
recognized their error, though they haven't yet had the decency to
apologize to the BSD community.

Greg
--
Finger grog at lemis.com for PGP public key
See complete headers for address and phone numbers

[TUHS] Fwd: Helping in the battle against SCO

[Greg Lehey]

On Wednesday, 10 September 2003 at 19:59:07 -0400, Norman Wilson wrote:
> I don't see how any diffing we do will make any difference `in the
> battle against SCO.'

It could.  There's a lot of confusion out there.  The people on this
list have a much better understanding of the technical issues than
just about any other group of people I can think of.

> If we find cases in which Linux has incorporated System V licensed
> code, that will certainly be meaningful; but if, as seems likely, we
> don't, SCO can just say their tools are better than hours.

FWIW, the first example that SCO showed in Las Vegas on 18 August does
appear to be derived from System V.3 malloc().  See
http://www.lemis.com/grog/SCO/code-comparison.html for the details.
Also, if anybody else can confirm or deny my analysis based on code
inspection, I'd be *very* grateful.

Summary: the first example showed a slightly modified version of Third
Edition malloc() being used for a slightly different purpose in the
SGI ia64 port only.  The slight modifications tracked those in System
V.3, suggesting that SGI derived their code from System V, and not
from an earlier version.  On the other hand, the differences in System
V.3 were removed again, and in fact the Linux community had already
removed the entire code before SCO "revealed" it.

> And besides, it is SCO who have brought the complaint, so both
> legally and ethically it's up to SCO to prove the case, not up to
> others to disprove it, no matter what fearsome roars SCO emit.

No question.

Greg
--
Finger grog at lemis.com for PGP public key
See complete headers for address and phone numbers

[TUHS] Fwd: Helping in the battle against SCO

[Andru Luvisi]

On Wed, 10 Sep 2003, Norman Wilson wrote:
> I don't see how any diffing we do will make any difference
> `in the battle against SCO.'
[snip]

Some ways that I can see it being a good thing to do:

  If SCO holds up a piece of common code and the good guys have no
  response, that is bad.

  If SCO holds up a piece of common code and the good guys already know
  that it actually came from BSD, and are prepared to demonstrate such,
  that is good.

  If SCO holds up a piece of common code and the good guys already know
  that it was contributed to Linux by SCO/Caldera themselves, and are
  prepared to demonstrate such, that is good.

  If there is infringing code, it should be taken out of Linux as quickly
  as possible.

Andru
-- 
Andru Luvisi

Quote Of The Moment:
  Heisenberg may have been here.

[TUHS] Fwd: Helping in the battle against SCO

[Norman Wilson]

I don't see how any diffing we do will make any difference
`in the battle against SCO.'  If we find cases in which Linux
has incorporated System V licensed code, that will certainly
be meaningful; but if, as seems likely, we don't, SCO can
just say their tools are better than hours.  And besides, it
is SCO who have brought the complaint, so both legally and
ethically it's up to SCO to prove the case, not up to others
to disprove it, no matter what fearsome roars SCO emit.

Comparisons done by others are certainly interesting, and I
don't want to discourage anyone from doing them; just don't
expect it to make any difference to the lawyers.  (Not that
I'm one, of course.)

Norman Wilson
Toronto ON

[TUHS] Fwd: Helping in the battle against SCO

[Maciek Bieszczad]

Here are my results of a comment analysis between the contents of Linux
kernel 2.5.73 and SVR1 + SVR2.

Matches for [number of array dimensions in auxiliary entry]:
./include/linux/coff.h
./sysv/tape1/include/syms.h
./sysv/tape1/src/head/syms.h
./vaxsysv/vax-svr1/src/cmd/adb/vax/a.out.h
./vaxsysv/vax-svr1/src/head/syms.h

Matches for [info about tv section in auxent of symbol tv]:
./arch/ppc/boot/include/rs6000.h
./include/linux/coff.h
./sysv/tape1/include/syms.h
./sysv/tape1/src/head/syms.h
./vaxsysv/vax-svr1/src/cmd/adb/vax/a.out.h
./vaxsysv/vax-svr1/src/head/syms.h

Matches for [number of characters in a symbol name]:
./include/linux/coff.h
./sysv/tape1/include/syms.h
./sysv/tape1/src/head/syms.h
./vaxsysv/vax-svr1/src/cmd/adb/vax/a.out.h
./vaxsysv/vax-svr1/src/head/syms.h

Matches for [text size in bytes padded to fw bdry]:
./arch/ppc/boot/include/rs6000.h
./include/linux/coff.h
./sysv/tape1/include/aouthdr.h
./sysv/tape1/src/head/aouthdr.h
./vaxsysv/vax-svr1/src/cmd/adb/vax/a.out.h
./vaxsysv/vax-svr1/src/head/aouthdr.h

Matches for [number of characters in a file name]:
./include/linux/coff.h
./sysv/tape1/include/syms.h
./sysv/tape1/src/head/syms.h
./vaxsysv/vax-svr1/src/cmd/adb/vax/a.out.h
./vaxsysv/vax-svr1/src/head/syms.h

Matches for [file ptr to raw data for section]:
./arch/mips/boot/ecoff.h
./arch/ppc/boot/include/rs6000.h
./include/linux/coff.h
./sysv/tape1/include/scnhdr.h
./sysv/tape1/src/head/scnhdr.h
./vaxsysv/vax-svr1/src/cmd/adb/vax/a.out.h
./vaxsysv/vax-svr1/src/head/scnhdr.h

Matches for [base of data used for this file]:
./arch/mips/boot/ecoff.h
./arch/ppc/boot/include/rs6000.h
./include/linux/coff.h
./sysv/tape1/include/aouthdr.h
./sysv/tape1/src/head/aouthdr.h
./vaxsysv/vax-svr1/src/cmd/adb/vax/a.out.h
./vaxsysv/vax-svr1/src/head/aouthdr.h

Matches for [base of text used for this file]:
./arch/mips/boot/ecoff.h
./arch/ppc/boot/include/rs6000.h
./include/linux/coff.h
./sysv/tape1/include/aouthdr.h
./sysv/tape1/src/head/aouthdr.h
./vaxsysv/vax-svr1/src/cmd/adb/vax/a.out.h
./vaxsysv/vax-svr1/src/head/aouthdr.h

--
Maciek (macbiesz at optonline.net)

[TUHS] Fwd: Helping in the battle against SCO

[Warren Toomey]

All,
	This e-mail below was prompted by an interview I gave about
the SCO thing for an Australian paper:
http://www.theage.com.au/articles/2003/09/09/1062902037394.html

----- Forwarded message from Ulrik Petersen <emdros at yahoo.dk> -----
Date: Tue, 9 Sep 2003 19:44:51 +0200 (CEST)
From: Ulrik Petersen <emdros@yahoo.dk>
Subject: Helping in the battle against SCO

I saw a recent article in the Sydney Morning Herald in
which a Dr. Warren Toomey (presumably you?) was quoted
as saying that the TUHS has several members who have
access to old copies of UNIX source code.  

Please ask these people to try out one of the three
"shredders" which can compare sourcecode from Linux
with other sourcecode, and, if possible, analyze and
publish the results.

One of these shredders is written by Eric S. Raymond. 
Here is a link to an article in which he calls for
action by people with access to UNIX sourcecode:

http://www.eweek.com/article2/0,4149,1257617,00.asp

The program itself can be found here:

http://www.catb.org/~esr/comparator/

Regards,
Ulrik Petersen, Denmark
----- End forwarded message -----

Anyway, I think it's a good idea, so I'd like to hear from people
who have access to recent AT&T code. My GPG and PGP keys are at
http://minnie.tuhs.org/warren.html and on most keyservers if you
so wish to use them.

Thanks,
	Warren