[TUHS] Comparing Linux code

[TUHS] Comparing Linux code

[José R. Valverde]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 4628 bytes --]

Pardon me for posting not being a subscriber, I already subscribe to too
many lists and I prefer to readd the archives at Minnie.

I've used the procedures described in

	http://www.rickbradley.com/chron/20030619/

to compare the code in Linux with the code of Solaris. There are a few
striking comments shared by .c files, some actually containing "jokes". 
However.

	Note that I'll NOT comment on anything I've seen in the Solaris
code. I'll only talk of my own experience and what LINUX/BSD code says.

Matches for [argh urg not set but urp changed a sensible implementation should n
ever do this but rfc793 doesnt prohibit the change so we have to deal with it]:
***SOLARIS SOURCE ID REMOVED***
./drivers/net/slhc.c

	Looks like the possible 'joke' shared code. Code inspection confirms.
	Linux code states that slhc code is (c) by BSD.
	4.4BSD-Lite contains the code in ./sys/net/slcompress.c
	The same code appears first in 4.3BSD in the same file.
	This is NOT therefore SUN/ATT/SCO code, so I guess I can safely comment 
on it.
	This looks like one of those infamous source files from BSD whose 
copyright comments where stripped before the BSD/ATT lawsuit. SCO might
preserve the original, pre-lawsuit ATT code (without the (c) notice) and 
_believe_ it to be theirs. Actually it makes sense in the UNIX sellout
turmoil after the lawsuit that the BSD copyrights were forgotten to be
merged back in the code.

	Should it be so, then perhaps SCO zealots did the so much aired
comparison UNIX/Linux but did not care to check their own source code 
against BSD, thus slipping on this one?

	There is another source file which _might_ be contaminated, but I
can't tell in which direction this might have happened. I won't venture
breaking confidentiality agreements, but this I believe I can say: I know 
from experinece this file has suffered extense enhancements during the '90s, 
most of which were done by independent developers for Suns. The LINUX comments 
identify the author as an independent developer of world fame in the area 
indicating the routines were originally developed for SUN and DEC, so if 
SCO has any claims it might only be by "license contamination" (i.e. any 
independent addition must belong to me no matter how indirect because I say 
so). Actually it might be that Sun and DEC added the changes contributed to
them and provided them back to the UNIX reference source. In that case, 
SCO will have a hard time to claim the code belongs to them and they are 
not stealing other people's contributed code.

	Furthermore, if they still claim it's theirs 'cos of license 
contamination, they will put a hard stress on UNIX vendors: in the '90s
some vendors survived mainly because of specialized market niches (e.g. MBONE
on Sun, graphics on SGI, etc..): everybody in some field would use the same 
system, users would contribute fixes to them, and this gave them an advantage. 
Now, if people see that contributing to any system will make them lose 
rights over their own code, in the future they won't tie themselves to any 
specific vendor, and vendors will lose the opportunity of taking advantage
of specialized user groups to increase their competitivity. Now, imagine
where would Sun be if they had never been able to differentiate themselves
as, say, the 'dot com' company during the Internet boom.

	Were I SCO I'd think twice before hampering licensees ability to
capitalize on market niche differentiations because of claims on independent,
free code developed by _their_ users.

	All this, assuming, of course, these are the files in dispute.

	So far, and assuming these are the files, it mostly looks like external
additions to SCO code that lost the original copyright references. It is
understandable that SCO modern engineers ignore what happened before the ATT/BSD
trial, or even ignore the original author of code reverted back by UNIX licensees,
and that ignoring who wrote what, they may believe it is all theirs.

	But, if these were the files, they'll have a hard time. First for not
checking correctly their claims (agains say, BSD code), second for not 
acknowledging nor keeping track of original authors of contributed code,
and finally for claiming ownership of code that does not belong to them.

	Other files share some odd small comment, often it looks like pure
chance, machine/vendor dependent code (probably not ATT/SCO therefore) or 
common sense, so I didn't investigate those any further.

				j

-- 
	These opinions are mine and only mine. Hey man, I saw them first!

			    José R. Valverde

	De nada sirve la Inteligencia Artificial cuando falta la Natural

[TUHS] Comparing Linux code

[Wesley Parish]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 6030 bytes --]

On Wed, 09 Jul 2003 21:06, Jos�R. Valverde wrote:
> Pardon me for posting not being a subscriber, I already subscribe to too
> many lists and I prefer to readd the archives at Minnie.
>
> I've used the procedures described in
>
> 	http://www.rickbradley.com/chron/20030619/
>
> to compare the code in Linux with the code of Solaris. There are a few
> striking comments shared by .c files, some actually containing "jokes".
> However.
>
> 	Note that I'll NOT comment on anything I've seen in the Solaris
> code. I'll only talk of my own experience and what LINUX/BSD code says.
>
> Matches for [argh urg not set but urp changed a sensible implementation
> should n ever do this but rfc793 doesnt prohibit the change so we have to
> deal with it]: ***SOLARIS SOURCE ID REMOVED***
> ./drivers/net/slhc.c
>
> 	Looks like the possible 'joke' shared code. Code inspection confirms.
> 	Linux code states that slhc code is (c) by BSD.
> 	4.4BSD-Lite contains the code in ./sys/net/slcompress.c
> 	The same code appears first in 4.3BSD in the same file.
> 	This is NOT therefore SUN/ATT/SCO code, so I guess I can safely comment
> on it.
> 	This looks like one of those infamous source files from BSD whose
> copyright comments where stripped before the BSD/ATT lawsuit. SCO might
> preserve the original, pre-lawsuit ATT code (without the (c) notice) and
> _believe_ it to be theirs. Actually it makes sense in the UNIX sellout
> turmoil after the lawsuit that the BSD copyrights were forgotten to be
> merged back in the code.
>
> 	Should it be so, then perhaps SCO zealots did the so much aired
> comparison UNIX/Linux but did not care to check their own source code
> against BSD, thus slipping on this one?

The term for that, in relation to something that clearly is a matter of 
peoples' reputations, business survivability, etc, is "due diligence".

>
> 	There is another source file which _might_ be contaminated, but I
> can't tell in which direction this might have happened. I won't venture
> breaking confidentiality agreements, but this I believe I can say: I know
> from experinece this file has suffered extense enhancements during the
> '90s, most of which were done by independent developers for Suns. The LINUX
> comments identify the author as an independent developer of world fame in
> the area indicating the routines were originally developed for SUN and DEC,
> so if SCO has any claims it might only be by "license contamination" (i.e.
> any independent addition must belong to me no matter how indirect because I
> say so). 

That is truly "viral licensing".  GPL at least has the grace and honesty to be 
up-front about it, and only if the binaries get published.  Real "viral 
licensing' acts much the way virii do - beneath the skin, out of sight.

Actually it might be that Sun and DEC added the changes
> contributed to them and provided them back to the UNIX reference source. In
> that case, SCO will have a hard time to claim the code belongs to them and
> they are not stealing other people's contributed code.

That is pretty much what I allege SCO is in fact doing.  By extending the 
meaning of "derived" to include practically anything, from just 
sniffing/looking at an AT&T letterhead to copying the whole kit and caboodle, 
they have rendered their contentions null and void, AFAIC.

>
> 	Furthermore, if they still claim it's theirs 'cos of license
> contamination, they will put a hard stress on UNIX vendors: in the '90s
> some vendors survived mainly because of specialized market niches (e.g.
> MBONE on Sun, graphics on SGI, etc..): everybody in some field would use
> the same system, users would contribute fixes to them, and this gave them
> an advantage. Now, if people see that contributing to any system will make
> them lose rights over their own code, in the future they won't tie
> themselves to any specific vendor, and vendors will lose the opportunity of
> taking advantage of specialized user groups to increase their
> competitivity. 

Which is the problem with MS's "Shared Source" - developers are staying away 
from it in droves, because nobody can do anything even remotely useful with 
the source code.

Now, imagine where would Sun be if they had never been able
> to differentiate themselves as, say, the 'dot com' company during the
> Internet boom.
>
> 	Were I SCO I'd think twice before hampering licensees ability to
> capitalize on market niche differentiations because of claims on
> independent, free code developed by _their_ users.
>
> 	All this, assuming, of course, these are the files in dispute.
>
> 	So far, and assuming these are the files, it mostly looks like external
> additions to SCO code that lost the original copyright references. It is
> understandable that SCO modern engineers ignore what happened before the
> ATT/BSD trial, or even ignore the original author of code reverted back by
> UNIX licensees, and that ignoring who wrote what, they may believe it is
> all theirs.

"Due diligence" of course.  You can take out an airline on that basis (Air New 
Zealand springs to mind), much less a little company like SCO's.  And "due 
diligence" is the more positive approach to it - a vengeful approach talks of 
"wilful deception", "fraudulent claims", "defamation of character", and 
suchlike.  "Lack of due diligence" is mild.

>
> 	But, if these were the files, they'll have a hard time. First for not
> checking correctly their claims (agains say, BSD code), second for not
> acknowledging nor keeping track of original authors of contributed code,
> and finally for claiming ownership of code that does not belong to them.
>
> 	Other files share some odd small comment, often it looks like pure
> chance, machine/vendor dependent code (probably not ATT/SCO therefore) or
> common sense, so I didn't investigate those any further.
>
> 				j
Wesley Parish
-- 
Mau e ki, "He aha te mea nui?"
You ask, "What is the most important thing?"
Maku e ki, "He tangata, he tangata, he tangata."
I reply, "It is people, it is people, it is people."