[comp.os.vms] System Id Registers, License Enforcement, etc...& A FLAME!

rlb@rtpark.rtp.ge.COM (Bob Boyd 8*565-3627 11-Aug-1987 1656) (08/11/87)

Keywords: copy protection, SID register, license enforcement

There have been a lot of questions about identifying cpus and such.

I  have  some  VERY  strong  opinions  about  copy protecting software for mass
distribution.

Let me express first of all that I am not opposed to  people  protecting  their
investment.    I think every software vendor(DEC included) should be encouraged
to:

   1. Make their software easy to install.

   2. Make it  EASY  for  user  installations  to  comply  with  licensing
      restrictions.

   3. Make their software insensitive to hardware revisions.

   4. Make  their  software  capable  of being licensed to run on multiple
      cpus from one copy(particularly for clusters).

   5. Provide a customer controllable capability to run the package  on  a
      backup processor while the licensed processor is down.  This kind of
      capability needs to be EASY to use -- not require 15 different  keys
      having  to  be typed in after calling up the vendor!!!  I can't have
      my whole staff tied up typing in new keys for each of  20  different
      packages that might have to be switched to another cpu!

It  is  trivial  for  a  package  to  be  tied  to  the cpu serial number.  The
information is available through a call to SYS$GETSYI requesting the SID item.

The biggest problem with this is that the SID has lots of stuff in  it  besides
the Serial Number.  ONLY THE 15 LOW ORDER BITS CONTAIN THE SERIAL NUMBER!!!!

***** FLAME ON *****

ANYONE  USING  THE  WHOLE  32  BITS  FOR  A MATCH IS SAYING "I WON'T LET YOU BE
PROPERLY SERVICED BY YOUR FIELD SERVICE ORGANIZATION WITHOUT FIRST  GETTING  AN
UPDATE  FROM  ME" -- this is RIDICULOUS - anyone who is going to the trouble to
use this number should exercise the responsibility to obtain a VAX ARCHITECTURE
HANDBOOK and VAX HARDWARE HANDBOOK and STUDY the layout of the SID register!!

Recently  we  have  been  bitten  by  2 packages:  Teradyne's LASAR package and
ECAD's IC Design Verification package.  LASAR croaked after a revision  to  our
VAX 8800 console to correct a number of problems we have had.  They had to send
us a new "customer data file" -- which took 3 days to arrive --  they  couldn't
give  us  something  over  the phone, they didn't think to ask to send it to my
home address over the weekend, etc....!@#$%#@#!

IF YOU WON'T CONVINCE YOURSELF TO TRUST YOUR CUSTOMER SYSTEM ADMINISTRATORS  TO
TRY TO ABIDE BY THE CONTRACT, AT LEAST DO THE JOB RIGHT.

***** FLAME OFF *****

GE  normally negotiates an extra clause in contracts with ALL software vendors.
This clause says something to the effect that GE will be licensed and  able  to
run  the  package  on  a  temporary basis on a backup cpu in the event that the
licensed cpu is unavailable due to failure or required maintenance.

In a turnkey environment it is extremely important that switching to the backup
cpu not take a monumental effort.  There are many ways to accomplish this.  One
is to try trusting the system administrators at customer sites.  Some  packages
are  secured  by  the distribution of keys that go into a site description file
maintained by the site administrator.  We have through  the  use  of  ACLS  and
SYSTEM  RIGHTS  made  it  very  easy  to be sure that we are complying with the
license.  We also have a 15 to 30 second operation that is all that is required
to make the switch (in our cluster) should the licensed cpu fail.

We  have  used  this  approach  on  software  purchased from DEC, Unilogic, and
others.  It works GREAT!  I will be glad to send the command procedure  and  an
example control data file to anyone who wants it.

Essentially  what  we do is set up an identifier for each licensed package.  At
boot time on each cpu a procedure is invoked that  reads  the  license  control
data  file.   This procedure determines which licenses are to be enabled on the
current node.  If a machine goes down, all that needs to be done on  the  other
cpus  is  to  run  the procedure again, and it will re-determine which licenses
should be enabled due to the abscence of the down cpu.

On each executable and/or control file that is essential to  the  execution  of
licensed packages we place an ACL which has the following form:
(IDENTIFIER=<package>_ADMINISTRATOR,
        OPTIONS=PROTECTED,ACCESS=READ+WRITE+DELETE+CONTROL)
(IDENTIFIER=<package>_LICENSE[+batch or other mode restrictions],
        OPTIONS=PROTECTED,ACCESS=EXECUTE) (or READ if data only file)
(IDENTIFIER=[*,*],ACCESS=NONE)

The  2  identifiers  that  must  be  created  are  <package>_ADMINISTRATOR  and
<package>_LICENSE.

Again if you would like to get a copy of our LICENSE.COM, please let  me  know.
It  is  currently  about  200  lines  of  DCL.    I  would  be  glad  to see an
implementation in Fortran, Pascal, or C. If enough people ask for it I'll  just
post it to INFO-VAX.
-----------------------------------------------------------------
 Bob Boyd                     Usenet:    rlb@rtpark.rtp.ge.com
 GE Microelectronics Ctr.     Voice:     (919)549-3627
 POB 13049, MS 7T3-01         GE DIALCOMM:  8*565-3627
 RTP, NC 27709-3049           GE DECnet: RTPARK::RLB