[linux-elitists] More info - actual source of SCO code -
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 [220.127.116.11])
> by redline.kinz.org (8.11.6/8.11.6) with SMTP id h589Zsf04979
> for <email@example.com>; Sun, 8 Jun 2003 05:35:56 -0400
> list-post: <mailto:firstname.lastname@example.org>
> X-Message-Number-for-archive: 148844
> From: Curtis Rey <email@example.com>
> 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 <firstname.lastname@example.org>
> > * 1.01 18 Feb 2000, Tigran Aivazian <email@example.com>
> > * 1.02 21 Feb 2000, Tigran Aivazian <firstname.lastname@example.org>
> > * 1.03 29 Feb 2000, Tigran Aivazian <email@example.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
> > <firstname.lastname@example.org>". 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. email@example.com
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