First Analyst Impressed By SCO's 'Proof'(OT)

older
Re: [SLE] Apache & php on Suse 8.2...

Fred A. Miller

7 Jun 2003 7 Jun '03

03:49

First Analyst Impressed By SCO's 'Proof' An analyst says it appears that some parts of SCO Unix and Linux are indeed cut from the same mold. informationweek.com/story/showArticle.jhtml?articleID=10300314 -- Powered by SuSE Linux 8.2 Pro & KMail 1.5.1 Never forget: At Microsoft, the engineering department are the Ferengi... The marketing and legal departments are the Borg!

Show replies by date

James Mohr

7 Jun 7 Jun

11:01

New subject: [SLE] First Analyst Impressed By SCO's 'Proof'(OT)

On Saturday 07 June 2003 05:49, Fred A. Miller wrote:

...

First Analyst Impressed By SCO's 'Proof'

An analyst says it appears that some parts of SCO Unix and Linux are indeed cut from the same mold.

informationweek.com/story/showArticle.jhtml?articleID=10300314

Assuming that is true, then I see it more of a problem for Linux in general, as opposed to IBM. Caldera needs to prove that it could have **only** come from IBM and not from an unhappy (former) employee. Further they also have to prove the "direction" this code went. The analyst said "The fact that these appear to be transposed from Unix System V into Linux I find to be very damaging." That implies that Linux code was take from the System V code and not the other way around or not both taken from the same source. It *could* be the exact same source code that was at the heart of the BSD/ATT lawsuit and it **really** is the same code. The analyst said ""It appears to be the same". Another key point is that the "same" does not mean "identical". However, despite what Caldera says about "mathmatical probably of null" of developing the "same code", there are probably algorithms in there that have been used over and over again for 30 years, so it is not unlikely that they "appear" to be the same. Another issue is the culpability of the Linux developers. Take the recent case of the marijuana grower in California. There was a reasonable expectation on his part that what he was doing was legal. If there is a "reasonable expectation" on the part of the the Linux developers that code someone provided was legal, then maybe there is no culpability. Regards, jimmo -- --------------------------------------- "Be more concerned with your character than with your reputation. Your character is what you really are while your reputation is merely what others think you are." -- John Wooden --------------------------------------- Be sure to visit the Linux Tutorial: http://www.linux-tutorial.info --------------------------------------- NOTE: All messages sent to me in response to my posts to newsgroups, mailing lists or forums are subject to reposting.

Peter B Van Campen

15:15

New subject: [SLE] First Analyst Impressed By SCO's 'Proof'(OT)

See Cringley this week. He says that SCO/Caldera put it there themselves!! http://www.pbs.org/cringely/pulpit/pulpit20030605.html I can attest to what he says about IBM! PeterB On Saturday 07 June 2003 06:01, James Mohr wrote:

...

On Saturday 07 June 2003 05:49, Fred A. Miller wrote:

...
First Analyst Impressed By SCO's 'Proof'

An analyst says it appears that some parts of SCO Unix and Linux are indeed cut from the same mold.

informationweek.com/story/showArticle.jhtml?articleID=10300314

Assuming that is true, then I see it more of a problem for Linux in general, as opposed to IBM. Caldera needs to prove that it could have **only** come from IBM and not from an unhappy (former) employee. Further they also have to prove the "direction" this code went. The analyst said "The fact that these appear to be transposed from Unix System V into Linux I find to be very damaging." That implies that Linux code was take from the System V code and not the other way around or not both taken from the same source. It *could* be the exact same source code that was at the heart of the BSD/ATT lawsuit and it **really** is the same code.

The analyst said ""It appears to be the same". Another key point is that the "same" does not mean "identical". However, despite what Caldera says about "mathmatical probably of null" of developing the "same code", there are probably algorithms in there that have been used over and over again for 30 years, so it is not unlikely that they "appear" to be the same.

Another issue is the culpability of the Linux developers. Take the recent case of the marijuana grower in California. There was a reasonable expectation on his part that what he was doing was legal. If there is a "reasonable expectation" on the part of the the Linux developers that code someone provided was legal, then maybe there is no culpability.

Regards,

jimmo

-- --------------------------------------- "Be more concerned with your character than with your reputation. Your character is what you really are while your reputation is merely what others think you are." -- John Wooden --------------------------------------- Be sure to visit the Linux Tutorial: http://www.linux-tutorial.info --------------------------------------- NOTE: All messages sent to me in response to my posts to newsgroups, mailing lists or forums are subject to reposting.

-- -- Proud to use SuSE Linux since 5.2 Loving using SuSE Linux 8.2 May 2003, Munich, Germany ordered 15,000 Workstation Lic for SuSE 8.2, despite M$ cutting their bid to $0.10 on the Dollar This will be remembered MyBlog http://vancampen.org/blog/ --

James Mohr

20:06

New subject: [SLE] First Analyst Impressed By SCO's 'Proof'(OT)

On Saturday 07 June 2003 17:15, Peter B Van Campen wrote:

...

See Cringley this week. He says that SCO/Caldera put it there themselves!!

http://www.pbs.org/cringely/pulpit/pulpit20030605.html

I can attest to what he says about IBM!

PeterB

Thanks for that one! Although I cannot prove it, my experience with some of the developers says to me that they are no so stupid as to blindly put code into the kernel (or anywhere else) without knowing where it came from. Maybe they didn't now it was right out of the Caldera UNIX source, but they at least know the name of the person who submitted it. If that person ever had a @caldera.com or @sco.com email address then I would guess all bets are off. I could imagine that it would be through out if you found and Caldera or SCO name *anywhere* in the code. Hmmmmm. Regards, jimmo -- --------------------------------------- "Be more concerned with your character than with your reputation. Your character is what you really are while your reputation is merely what others think you are." -- John Wooden --------------------------------------- Be sure to visit the Linux Tutorial: http://www.linux-tutorial.info --------------------------------------- NOTE: All messages sent to me in response to my posts to newsgroups, mailing lists or forums are subject to reposting.

Curtis Rey

8 Jun 8 Jun

07:11

New subject: [SLE] First Analyst Impressed By SCO's 'Proof'(OT)

On Saturday 07 June 2003 13:06, James Mohr wrote:

...

On Saturday 07 June 2003 17:15, Peter B Van Campen wrote:

...
See Cringley this week. He says that SCO/Caldera put it there themselves!!

http://www.pbs.org/cringely/pulpit/pulpit20030605.html

I can attest to what he says about IBM!

PeterB

Thanks for that one!

Although I cannot prove it, my experience with some of the developers says to me that they are no so stupid as to blindly put code into the kernel (or anywhere else) without knowing where it came from. Maybe they didn't now it was right out of the Caldera UNIX source, but they at least know the name of the person who submitted it. If that person ever had a @caldera.com or @sco.com email address then I would guess all bets are off. I could imagine that it would be through out if you found and Caldera or SCO name *anywhere* in the code.

Hmmmmm.

Regards,

jimmo

From: file:/usr/src/linux-2.4.20.SuSE/include/abi/sco/types.h #/* # * Copyright (c) 2001 Caldera Deutschland GmbH. #* Copyright (c) 2001 Christoph Hellwig. #* All rights reserved. #* #* This program is free software; you can redistribute it and/or modify #* it under the terms of the GNU General Public License as published by #* the Free Software Foundation; either version 2 of the License, or #* (at your option) any later version. #* #* This program is distributed in the hope that it will be useful, #* but WITHOUT ANY WARRANTY; without even the implied warranty of #* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the #* GNU General Public License for more details. #* #* You should have received a copy of the GNU General Public License # * along with this program; if not, write to the Free Software #* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA #*/ ##ifndef _ABI_SCO_TYPES_H ##define _ABI_SCO_TYPES_H ##ident "%W% %G%" #/* # * SCO OpenServer type declarations. #*/ ##include ##include ##include ##include #typedef int16_t sco_dev_t; #typedef u_int32_t sco_ino_t; #typedef u_int16_t sco_mode_t; #typedef int16_t sco_nlink_t; #typedef u_int16_t sco_uid_t; #typedef u_int16_t sco_gid_t; #typedef int32_t sco_off_t; #typedef int32_t sco_time_t; #struct sco_statvfs { # u_int32_t f_bsize; # u_int32_t f_frsize; # u_int32_t f_blocks; # u_int32_t f_bfree; # u_int32_t f_bavail; # u_int32_t f_files; # u_int32_t f_free; # u_int32_t f_favail; # u_int32_t f_sid; # char f_basetype[16]; # u_int32_t f_flag; # u_int32_t f_namemax; # char f_fstr[32]; # u_int32_t f_filler[16]; #}; #/* # * Stub for now, as we still have a 16 bit dev_t. # */ #static __inline sco_dev_t #linux_to_sco_dev_t(dev_t dev) #{ # return dev; #} #/* # * If we thought we were in a short inode environment we are # * probably already too late - getdents() will have likely # * already assumed short inodes and "fixed" anything with # * a zero low word (because it must match stat() which must # * match read() on a directory). # * # * We will just have to go along with it. # */ #static __inline sco_ino_t #linux_to_sco_ino_t(ino_t ino) #{ # if (!(current->personality & SHORT_INODE)) # return ino; # if ((u_long)ino & 0xffff) # return ino; # return 0xfffffffe; #} #/* # * SCO user/group IDs are the same as the old linux ones. # */ #static __inline sco_uid_t #linux_to_sco_uid_t(uid_t uid) #{ # return NEW_TO_OLD_UID(uid); #} #static __inline sco_gid_t #linux_to_sco_gid_t(gid_t gid) #{ # return NEW_TO_OLD_GID(gid); #} #endif /* _ABI_SCO_TYPES_H */ ########################################################################### And from sysent.h Christoph Hellwig and on, and on. Just get the changelogs for the kernels and do a search for Caldera, SCO, Hellwig, or any other name the is found with the results for "Caldera, SCO" and then search those name as well. I'm betting that much of this is due to contribs by Caldera/SCOX personal. Regardless of whether or not McBride and company authorized this, or are or are not aware of it being there. If it is found that Caldera/SCO devs or persons otherwise made it known/contribed/shown then they fail the conditions related to taking the needed steps to assure that it was not made common knowledge and have failed to be dilgent in protecting that which they may have desired to. Under U.S. statutes doing this would automatically forfeit any IP/patent/copyright claims under the protection of the statutes and provisions therein. I strongly suggest that this is very (repeat very) likely the case. I think that unless there's code that McBride and company claims is in the kernel and it isn't referenced in any of the changelogs or submission records then this could be a problem. But If it is shown that said violating code is referenced to one of SCO's devs or employees then the case/claims are mute and SCO is in a heap of sh**! Cheers, Curtis

Hans Forbrich

06:37

New subject: [SLE] First Analyst Impressed By SCO's 'Proof'(OT)

Curtis Rey wrote:

...

<snip> I strongly suggest that this is very (repeat very) likely the case. I think that unless there's code that McBride and company claims is in the kernel and it isn't referenced in any of the changelogs or submission records then this could be a problem. But If it is shown that said violating code is referenced to one of SCO's devs or employees then the case/claims are mute and SCO is in a heap of sh**!

So should someone perhaps be documenting all the locations in the code that have references to SCO (and perhaps other keywords, like UNIX)? For x-ref purposes? And perhaps trying to determine the date the reference first shows up? I'd guess there would be a bouncing of dates between the first Linux entry and the first Unix entry, ie. cross-pollination, not uni-directional pollination. (And I'd guess that there is sufficient GPL'd code in UNIX that UNIX itself is in violation of GPL.)

James Mohr

12:41

New subject: [SLE] First Analyst Impressed By SCO's 'Proof'(OT)

On Sunday 08 June 2003 08:37, Hans Forbrich wrote: <snip>

...

I'd guess there would be a bouncing of dates between the first Linux entry and the first Unix entry, ie. cross-pollination, not uni-directional pollination. (And I'd guess that there is sufficient GPL'd code in UNIX that UNIX itself is in violation of GPL.)

I wouldn't be surprised if that is one reason why Caldera is keeping secret exactly what they are basing the claim. I doubt that the IBM lawyers are so stupid as not to evaluate the timeline as to when the code got where. However, the so-called "analyst" that looked at the code was probably not looking at any time line but "Oh, the code is the same. Since the UNIX source is priopriatary, the Linux *must* have taken it from there". (Or some other such nonsense). Personally, I think that IBM might still have a fight ahead, since it may need to prove in court that they were not the source. However, finding all of the SCO and Caldera references made me feel a lot better. First, a (possible) source of "contamination" is pretty clear and pretty obviously this person knew the insides of the UNIX code. Second, since it is "the cat is out of the bad" issue for Linux in general, I don't see how Caldera could get away with anything involving end users. Regards, jimmo -- --------------------------------------- "Be more concerned with your character than with your reputation. Your character is what you really are while your reputation is merely what others think you are." -- John Wooden --------------------------------------- Be sure to visit the Linux Tutorial: http://www.linux-tutorial.info --------------------------------------- NOTE: All messages sent to me in response to my posts to newsgroups, mailing lists or forums are subject to reposting.

Curtis Rey

20:37

New subject: [SLE] First Analyst Impressed By SCO's 'Proof' - LONG (OT)

On Sunday 08 June 2003 05:41, James Mohr wrote:

...

On Sunday 08 June 2003 08:37, Hans Forbrich wrote: <snip>

...
I'd guess there would be a bouncing of dates between the first Linux entry and the first Unix entry, ie. cross-pollination, not uni-directional pollination. (And I'd guess that there is sufficient GPL'd code in UNIX that UNIX itself is in violation of GPL.)

I wouldn't be surprised if that is one reason why Caldera is keeping secret exactly what they are basing the claim. I doubt that the IBM lawyers are so stupid as not to evaluate the timeline as to when the code got where. However, the so-called "analyst" that looked at the code was probably not looking at any time line but "Oh, the code is the same. Since the UNIX source is priopriatary, the Linux *must* have taken it from there". (Or some other such nonsense).

Personally, I think that IBM might still have a fight ahead, since it may need to prove in court that they were not the source. However, finding all of the SCO and Caldera references made me feel a lot better. First, a (possible) source of "contamination" is pretty clear and pretty obviously this person knew the insides of the UNIX code. Second, since it is "the cat is out of the bad" issue for Linux in general, I don't see how Caldera could get away with anything involving end users.

Regards,

jimmo

Please excuse the lenght of this post. However, a google search for "SCO Hellwig Caldera Linux " produces 194 results. As you read down the list one can confirm the existing relationship with SCO developers and Linux developers. Also, near the end of this post the is reference to IA-64 development. To the point, there is questions about code and api's that are available that are directly evident of developer access to said code and api's revolving around the Unix and ia-64 question. It is also evident that most, and apperently a significant amount of this was readliy available and that SCO was playing both sides of the fence - developing for both Unix and Linux code bases. References to SCO in Linux kernels http://hypermail.idiosynkrasia.net/linux-kernel/archived/2001/week48/0130.ht... 2.4.16-pre1 file system bug From: Abraham vd Merwe (abraham@2d3d.co.za) Date: Mon Nov 26 2001 - 15:56:33 EET Hi! I mounted 2 vxfs (Veritas / SCO UnixWare) partitions and typed ls in the mounted directories. This is the result:................. Re: 2.4.16-pre1 file system bug From: Christoph Hellwig (hch@ns.caldera.de) Date: Mon Nov 26 2001 - 16:00:48 EET In article <20011126155633.A370@crystal.2d3d.co.za> you wrote:

...

Hi! I mounted 2 vxfs (Veritas / SCO UnixWare) partitions and typed ls in the mounted directories. This is the result:

Please add the line EXTRA_CFLAGS := -DDIAGNOSTIC to fs/freevxfs/Makefile and send me the dmesg output of the recompiled kernel. Christoph ################################################################ http://vipul.net/codd/suse5.2.R.html Code Contribution Distribution for S.u.S.E. 5.2 ----------------------------------------------- Package Name: suse5.2.codd Package Size: +514659722 bytes. 3166. keithr@sco.com 1871. larryp@sco.com 3029. belal@sco.com kernelnewbies.org/kernels/rh73/SOURCES/linux-2.4.17-linux-abi.patch linux-2.4-17-linux-abi.patch Christoph Hellwig Christoph Hellwig +2002-01-03 Christoph Hellwig + + linux-abi2.4.17.0 + + * rework/cleanup lcall7 syscall handling + * make sure x.out sections aren't loaded into illegal areas + * fix SVR4 mmap() to always assume post-SunOS4 behaviour + +2001-11-24 Christoph Hellwig + + linux-abi-2.4.15.0 + + * simplify wyse socket handling, use native syscalls directly where + possibles else use normal calling conventions + * fix compilation for non-i386 machines (Olaf Hering) + * fix alignment checks in binfmt_xout (based on patch by Joerg Ahrens) + * rewrite abi_brk: fix (theoretical) races, check for page alignment + * don't try to take a non-existant lock in xnx_nap, cleanup xnx_nap. + * fix value reported by sysi86(SI86MEM). +2001-10-04 Christoph Hellwig + + linux-abi 2.4.10.0 + + * add MODULE_DESCRIPTION/MODULE_AUTHOR/MODULE_LICENSE tags + * don't use alternate prefix for directories (David Mosberger) + * fix non-modular buil + * cleanup stat handling + | use Alexander Viro's kstat concept + | all emulations now have their own xstat implementations + | fixed overflows + * add full-fledged types.h headers for all peronalities + +2001-08-06 Christoph Hellwig + + linux-abi 2.4.9.0 + + * fix missing solaris socket exports + * move Xenix support from ibcs to sco module, + make unconditional + * UnixWare LFS fixes + * make the actual code work on the Alan Cox tree + +2001-08-06 Christoph Hellwig + + linux-abi 2.4.7.0 + + * some final polishing for segmented 286 x.out binaries (Joerg Ahrens) + * fix SPX handling (again) + * fix setpgrp and cleanup procids while we're at it + * update SCO syscall table to match OSR506a + +2001-07-19 Christoph Hellwig + + linux-abi 2.4.6.1 + + * rewritten /dev/socksys handling + * fix more non-x86 breakage (Olaf Hering) + * port solaris native sockets from sparc64 + * add sysctl support for runtime-tweaking + * add cxenix to the ibcs sysent table for Xenix/386 (Jürgen Günther) + * (re)add support for segmented x.out binaries (Joerg Ahrens) + | I probably broke it while rebasing against -CURRENT + * reject IRIX binaries on mips32 (David Woodhouse) + +2001-07-09 Christoph Hellwig + + linux-abi 2.4.6.0 + + * svr4/signal.c typo fix + * make cxenix debug printk's less verbose (Christian Lademann) + * misc small bugfixes (Christian Lademann) + * compile fixes for !CONFIG_ABI on non-x86 architectures + +2001-06-18 Christoph Hellwig + + linux-abi 2.4.5.1 + + * rewrite of abi_sigsuspend() to make it work as expected + * fix cxenix syscall table + * actually initialize socksys + +2001-06-09 Christoph Hellwig + + linux-abi 2.4.5.0 + + * rewrite of kernel exec_domain support + * make faking of SCO utsname information configurable + * get rid of SYS() and sysfunc_p (Arjan van de Ven) + * fix socket families (Stephan Springl) + * fix SCO signal mapping (Stephan Springl) + * fix SCO (and Wyse) error mapping + * continued source tree restructuring + +2001-04-31 Christoph Hellwig + + linux-abi 2.4.4.0 + + * disable tracing by default + * rewrite of the SYSV IPC code + * add support for SCO OpenServer 5 ELF binaries + * fix an error in binfmt_coff that does not clear the return value + * provide generic template macros for stat and friends + * start of source tree reorganization + +2001-03-30 Christoph Hellwig + + linux-abi 2.4.3.0 + + * fix shared library support for COFF + * x.out is now supported (again) + * redo setting of personality based on ELF headers + * get rid of CONFIG_ABI_TRACE (and a lot of nasty ifdefs) + * added documentation, mostly from iBCS + diff -Nru a/Documentation/abi/ChangeLog.ibcs b/Documentation/abi/ChangeLog.ibcs --- /dev/null Wed Dec 31 16:00:00 1969 +++ b/Documentation/abi/ChangeLog.ibcs Thu Jan 3 20:09:33 2002 ########################################################### http://lwn.net/2001/1122/a/linux-abi.php3 From: Christoph Hellwig To: linux-abi-devel@lists.sourceforge.net Subject: [ANNOUNCE] Linux-ABI 2.4.14.0 Date: Sun, 18 Nov 2001 19:40:27 +0100 The Linux-ABI 2.4.14.0 release for Linux 2.4.14 is now available. This is G o o g l e's cache of http://www.mail-archive.com/users@lists.caldera.com/msg17430.html. Re: SCO Linux on Unisys Servers From: James Bonnet Subject: Re: SCO Linux on Unisys Servers Date: Thu, 23 Jan 2003 08:12:30 -0800 Christoph Hellwig wrote: On Thu, Jan 23, 2003 at 10:02:31AM -0600, Shawn L Johnston wrote: Article on the register http://theregister.co.uk/content/61/28982.html The support code hass been in the SuSE^H^H^H^HUL for quite a while now, so this isn't exactly an surprise (except that they actually chose SCO as their UL brand instead of SuSE). Well gee.. Glad you clarified that for all of us... -j --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@lists.caldera.com Archive: http://www.mail-archive.com/users@lists.caldera.com SCO Linux on Unisys Servers, Shawn L Johnston Re: SCO Linux on Unisys Servers, Christoph Hellwig Re: SCO Linux on Unisys Servers, James Bonnet Linux Comes to Unisys Servers (via SCO) http://theregister.co.uk/content/61/28982.html http://www.linuxjournal.com/article.php?sid=6879 Torvalds cited a linux-kernel mailing list (lkml) posting from Christoph Hellwig, a former employee at SCO, then called Caldera. Hellwig points out the impracticality of actually getting copied code from UnixWare accepted by the tough critics on the mailing list. "The kernel internals are so different that you'd need a big glue layer to actually make it work and you can guess how that would be ripped apart in a usual lkml review", Hellwig wrote. ######################################################### https://external-lists.vasoftware.com/archives/linux-ia64/2001-October/00237... [Linux-ia64] where did gABI go? Doug Beattie dbb@caldera.com Tue, 30 Oct 2001 08:32:39 -0700 Previous message: [Linux-ia64] where did gABI go? Next message: [Linux-ia64] Re: Lion problems with 2.4.13... Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] David: The materials you are looking for are currently available at the link Christoph has noted below. They will be changing soon however. When they do I will make sure the link to this and other ones from SCO are updated on the LSB specification references page so they can be followed/found. In the future bookmark "http://www.linuxbase.org/spec/" to start drilling down to find the references. Doug Christoph Hellwig wrote:

...

On Mon, Oct 29, 2001 at 05:30:50PM -0800, David Mosberger wrote:

...
The page at http://www.sco.com/developer/gabi/2000-07-17/ no longer exists. Can someone tell me where the System V ABI pages moved to? I did a quick search on caldera.com, but the search engine on that site didn't produce anything meaningful.

http://stage.caldera.com/developer/gabi/

Christoph

-- Of course it doesn't work. We've performed a software upgrade.

_______________________________________________ Linux-IA64 mailing list Linux-IA64@linuxia64.org http://lists.linuxia64.org/lists/listinfo/linux-ia64

-- Douglas B. Beattie ------------------ Linux Test Architect - Caldera, Inc. dbb@caldera.com http://stage.caldera.com/developer/gabi/1998-04-29/contents.html System V Application Binary Interface - DRAFT - April 29, 1998 http://stage.caldera.com/developer/gabi/2000-07-17/contents.html System V Application Binary Interface - DRAFT - 22 June 2000 http://stage.caldera.com/developer/gabi/2001-04-24/contents.html System V Application Binary Interface - DRAFT - 24 April 2001 http://stage.caldera.com/developer/gabi/latest/contents.html System V Application Binary Interface - DRAFT - 24 April 2001 The Linux abi is a patch to the linux kernel that allows a linux system to run foreign binaries. This was developed and written by Christoph Hellwig and Joerg Ahrens as a follow on to the iBCS/iBCS2 project written for the older 2.2.x kernel by Mike Jagdis. ############################################################### http://linux-abi.sourceforge.net/Main-text.html Currently supported binaries are: SCO OpenServer SCO OpenDesktop SCO Unix 3.x SCO Xenix 386 SCO Xenix 286 (with userspace x286 emul) SCO UnixWare 7 Caldera OpenUnix 8 SUN Solaris 2 System V Release 3 (SVR3) System V Release 4 (SVR4) Wyse V/386 ISC Interactive Unix ONLY THE INTEL i386 platform is currently supported ############################################################ http://dbforums.com/arch/183/2003/3/714031 YES!!! - SCO Group Slaps IBM with $1B Suit ############################################################# I garner that further searches and refinements on this and similar subjects will produce further evidence of on-going access to SCO unix knowledge base, code, api's and the ongoing help/contribs by various SCO personal to both ia32 and ia64 developments. It appears, at least on a cursory level that up until lately SCO was actively involved in both the 32 and 64 bit development. I further submit that perhaps once SCO found that other systems were preferred for implimentation over SCO's products that they decided to pull this stunt. Cheers, Curtis.

James Mohr

10:14

New subject: [SLE] First Analyst Impressed By SCO's 'Proof'(OT)

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 * 1.01 18 Feb 2000, Tigran Aivazian * 1.02 21 Feb 2000, Tigran Aivazian * 1.03 29 Feb 2000, Tigran Aivazian Note the dates. This is "new" SCO. Intestingly enough, these are early 2000 and by 03 Aug 2000, he was listed as "Tigran Aivazian ". 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 -- --------------------------------------- "Be more concerned with your character than with your reputation. Your character is what you really are while your reputation is merely what others think you are." -- John Wooden --------------------------------------- Be sure to visit the Linux Tutorial: http://www.linux-tutorial.info --------------------------------------- NOTE: All messages sent to me in response to my posts to newsgroups, mailing lists or forums are subject to reposting.

Curtis Rey

11:36

New subject: [SLE] First Analyst Impressed By SCO's 'Proof'(OT)

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 * 1.01 18 Feb 2000, Tigran Aivazian * 1.02 21 Feb 2000, Tigran Aivazian * 1.03 29 Feb 2000, Tigran Aivazian

Note the dates. This is "new" SCO. Intestingly enough, these are early 2000 and by 03 Aug 2000, he was listed as "Tigran Aivazian ". 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.

7637

Age (days ago)

7638

Last active (days ago)

List overview

Download

9 comments

5 participants

participants (5)

Curtis Rey
Fred A. Miller
Hans Forbrich
James Mohr
Peter B Van Campen