[linux-elitists] More info - actual source of SCO code -

Jeff Kinz jkinz@kinz.org
Mon Jun 9 07:43:53 PDT 2003


I'm reposting this from the SUSE email list

> Received: from lists.suse.com (lists.suse.com [217.9.113.69])
> 	by redline.kinz.org (8.11.6/8.11.6) with SMTP id h589Zsf04979
> 	for <jkinz@kinz.org>; Sun, 8 Jun 2003 05:35:56 -0400
> list-post: <mailto:suse-linux-e@suse.com>
> X-Message-Number-for-archive: 148844
> From: Curtis Rey <crrey@charter.net>
> Date: Sun, 8 Jun 2003 04:36:51 -0700
> 
> On Sunday 08 June 2003 03:14, James Mohr wrote:
> > This is just too good to be true:
> >
> > jimmo@saturn:/usr/src/linux> grep sco.com ./arch/i386/kernel/microcode.c
> >  *      1.0     16 Feb 2000, Tigran Aivazian <tigran@sco.com>
> >  *      1.01    18 Feb 2000, Tigran Aivazian <tigran@sco.com>
> >  *      1.02    21 Feb 2000, Tigran Aivazian <tigran@sco.com>
> >  *      1.03    29 Feb 2000, Tigran Aivazian <tigran@sco.com>
> >
> > Note the dates. This is "new" SCO. Intestingly enough, these are early 2000
> > and by  03 Aug 2000, he was listed as  "Tigran Aivazian
> > <tigran@veritas.com>". You might not think that it makes a difference.
> > However, once at Veritas, he contributed code to ./fs/bfs/inode.c,
> > ./fs/proc/kcore.c and ./net/socket.c. While at SCO he was in the
> > "Escalations Research Group" for SCO UK.
> >
> > Also check out the "Linux Kernel 2.4 Internals". It's the *same* guy. (
> > Christoph Hellwig of  caldera.de also contributed to this docment).
> > So here we have a kernel expert who contributes code to the Linux kernel
> > while still at SCO (things like "Tigran Aivazian :  fixed "0.00 in
> > /proc/uptime on SMP" bug."). He contributes a great deal to the Linux
> > kernel. He posts to all sorts of kernel and other mailing lists (google his
> > name).
> >
> > Now you are going to say that the **only** place the UNIX code could have
> > possible come from is IBM. Hmmmm. Hmmmmm. Okay, the gun is not smoking, but
> > in my opinion it is pretty warm.
> >
> > regards,
> >
> > jimmo
> 
> Now the trick to it all.  Once you find the associations with SCO 
> devs/personel that did contribs to anything coded in Linux, kernel and all.  
> Then you take what you have found and see what else these individual did for 
> SCO, BSD, Unix, Novell, etc, etc, etc..
> 
> The point being is this.  Say the one of these guys not only contribute to the 
> Linux kernel, but also do work on SCO's Unix wares.  This is especially 
> telling if any of the code done in both Unix and Linux dealt with the same or 
> similar stuff... Say, fs/inode work that is in both nix and the penguin.  
> Then it could be reasonably argued that this individual had working knowledge 
> of what worked in both and then the diferentiations would be a matter of 
> fineties and difficult to argue in terms of exclusion based on licenses, 
> contract, and "rights to access and use".  
> 
> It would be safe to say that he would also have discussed other matters with 
> the other devs (read non-SCO) and then given ideas or direction related to 
> his knowledge of coding for Unix to solve a problem for/with another dev in 
> Linux.  This gets fairly convoluted and the clear definition of IP 
> infringement slips further into obscurity because the SCO dev freely gave 
> information and code to Linux.
> 
> Once again, the contention of McBride is that IBM gave Unix code to Linux 
> developers, or IBM devs donated code during certain key moments in the 
> development cycle.  McBrides wants to insist that this was done on the sly or 
> without proper permission.  But, If said code was intrinsically common 
> knowledge to devs outside of IBM because a SCO dev mentions code methods, 
> theory, or actual documentations then McBride is essentially screwed.
> 
> Once again.  The key to keeping intellectual property is to restrict the use, 
> access, and even knowledge about it.  If SCO didn't see fit to inform their 
> devs what was in and out of bounds, or better yet, didn't secure documents, 
> archives, tar files, etc, etc.... In otherwords Lock down the code.  Then 
> it's highly questionable that someone used in an improper way.  You can't 
> have it both ways,  You can't argue that people are "stealing" you code when 
> your own developers are blabbing about or handing it out.
>  
> Note.  M$ doesn't give anyone "access" to source without very stringent 
> guidelines and restrictions.  It is never put into a 3rd party ware unless 
> it's M$ approved and bought, paid, and signed for.  Just think,  If an M$ dev 
> was helping devolpers for a 2nd or 3rd party.  What do you think would be 
> written into it?  Not a weak statement about all rights reserved tied into 
> the GPL.  It would be bound by a NDA, EULA, License, Term of Use, etc.  And 
> let's not even think about an M$ dev contributing to a 3rd party competing 
> products (which is what SCO has now Labelled Linux). without the permission 
> of M$.  The M$ dev would be out of a job, deep in debt to both the lawers and 
> M$  - because M$ would fire, sue, and blacklist him.
> 
> SCO not only actively contributed the developers and code,  But made no 
> efforts to restrict the use of it AFAICT- Not until they were about to go 
> belly up and decided to milk IBM for a buyout/tort settlement.  
> 
> It's beyond fishy and borders on outright fraudulent.  I think the Linux 
> community should start a massive campaign to see what of SCO's is in Linux 
> and then find out how similar it is to Unix and I bet the common bond will be 
> the developers or fairly unrestricted access to Unix code and knowledge via 
> the SCO devs.  It's especially damning if SCO devs posted Unix code straight 
> to the kernel CVS repos, or listed in a changelog as fix with reference to 
> said code that matched Unix code.   This would be useful to say the least.
> 
> Like I said, U.S. Law states that once the owner lets the cat out of the back, 
> ownership is essentially a non-issue and it becomes common knowledge.  
> Intellectual property equates to a substantial amount of secrecy and 
> protective efforts.  Fail there and it becomes all but an outright non-issue.
> 
> Cheers, Curtis.
> 

-- 
Jeff Kinz, Open-PC, Emergent Research,  Hudson, MA.  jkinz@kinz.org
copyright 2003.  Use is restricted. Any use is an 
acceptance of the offer at http://www.kinz.org/policy.html.
Don't forget to change your password often.



More information about the linux-elitists mailing list