Path: utzoo!utgpu!water!watmath!clyde!att!gargoyle!tank!nucsrl!gore
From: gore@eecs.nwu.edu (Jacob Gore)
Newsgroups: comp.sys.next
Subject: Re: Re: NeXT's BIG 3.5" mistake.
Message-ID: <12670005@eecs.nwu.edu>
Date: 26 Oct 88 22:07:05 GMT
References: <4192@pitt.UUCP>
Organization: Northwestern U, Evanston IL, USA
Lines: 38

/ comp.sys.next / bzs@encore.com (Barry Shein) / Oct 25, 1988 /
>>>The scheme has several advantages: ... (2) developers
>>>would actually get paid for every active copy ...
>>
>>Oh no, they wouldn't.  They would get paid for every DORMANT copy, since it
>>will tie the software down to a workstation.
>
>[The student would] call a phone number and give a charge card number for
>the magic cookie and the card number would be charged. I don't know
>that the ethernet address was at all relevant, it could just as easily
>be a serial number imprinted on the disk to be read to the operator.
>It's not like authentication is a big issue, you are going to get
>charged for the software, right?

Not only is the Ethernet address relevant, it's the key point in my
objection.

Sure, you'll be charged for the software -- for activating one copy of it.
What the software vendors don't want you to do then is be able to use that
copy more than once at a time.  At least the more reasonable software
vendors have this attitude.

The unreasonable vendors (who are, alas, the majority currently) don't want
you to use it on more than one machine, period.  If you want to use
HerbaCalc (not a real product... as far as I know :-) on workstation A, you
pay for it.  If you come back tomorrow, and workstation A is busy, so you
want to use workstation B instead, then you better pay for another copy of
HerbaCalc for that workstation.  THAT is what tieing the software to an
Ethernet address does.  It is despicable, but that's how it's often done.

Tieing it to a serial number on the disk presents another problem: the disk
becomes a copy-protection gadget.  The "evils" of those damned things have
been rehashed over and over on Usenet, so I don't dare get into it at any
depth.  The obvious disadvantage: how do you run a program distributed on
disk 1 concurrently with a program distributed on disk 2?

Jacob Gore				Gore@EECS.NWU.Edu
Northwestern Univ., EECS Dept.		{oddjob,gargoyle,att}!nucsrl!gore