SCO License security - another flame

[Paul Barton-Davis]

Last night, working "off-campus" as they say, I tried to move a bunch
of device driver files, application development directories and other
stuff from one system to another. Problem - company has 2 licenses for
SCO Unix/386, not 3. The intention was to get this new box up as a
replacement for the one the work was originally carried out on, and
then revert the old version back to DROS. Because of this, we had
"re"installed license copy #2 on the new box, figuring that
duplication for a few hours for the purpose of copying out own files
from one disk to another was legitimate. After several diskettes
worth of cpio-ing, we gave up and decided to hook both systems
together on the net, and nfs mount one on the other. Problem - I
should have remembered the posting on this from before.

As a result, I am now intimately familiar with SCO's copy daemon (cpd)
that is a prerequisite to running any network software on an SCO
system. What of source happened, as readers with even moderately short
memories will recall, is that I got a message saying "message detected
from system with duplicate license". Under some circumstances, the box
then locks up.

\begin{Mr. Angry}
What is it with SCO that makes them think they are this special that
they have to intoduce this type of system ? What happened to honor
systems and all that ? This sucks, big big time. Not because we wanted
to violate our license agreement, but because we needed to move from
one box to another (with different drives), I get to spend an extra 4
hours, first figuring out what the f*** was going on, and then doing a
3rd party NFS copy (onto the first licensed system) and back again.

At the place I worked before UW, we used ISC and purchased licenses
for every copy we used. However, we shipped several systems out at at
time to clients, and used dd to do complete disk copies, avoiding the
ridiculous overhead of having to reinstall both Unix and our
applications. Hence, pretty much every system we ever shipped (or used
internally) was derived from *one copy* even though we had licenses
for many more. You can probably see why there is *NO* chance
whatsoever of that company EVER buying SCO. They actually have several
complete Unix root+usr+tmp partitions as dd'ed files on read-write
opticals - wanna new system: just format the disk, and dd the relevant
system straight onto it. Quick, efficient, easy and generally
foolproof.

I understand SCO's desire to restrict copying, but a tcp/ip daemon
that messes with the O/S when it detects multiple licenses is a
disgusting and extremely un-VAR-friendly way to do it. In revenge, I
have contemplated disassembling cpd, patching the binary, and making
this new version available to anyone that asks ... (just kidding, maybe).

Now, of course, the old system is running DOS, the new system (with
the 2nd license) is up and running, and all is well. But boy, do I get
mad at 1am when I have to deal with yet another "SCO value added
extension" whose primary purpose seems to be to question my honesty
and as a side effect, make my life more difficult. If SCO paid the
same attention to security that ISC did to a bug-free TCP/IP, we'd
all be better off. And, yes, you can interpret that last one any way
you want.

\end{Mr. Angry}
-- 
Paul Barton-Davis <pauld at cs.washington.edu> UW Computer Science Lab	 

"People cannot cooperate towards common goals if they are forced to
 compete with each other in order to guarantee their own survival."