home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / sys / next / programm / 7823 < prev    next >
Encoding:
Internet Message Format  |  1992-12-21  |  2.2 KB
  1. Path: sparky!uunet!haven.umd.edu!ni.umd.edu!sayshell.umd.edu!louie
  2. From: louie@sayshell.umd.edu (Louis A. Mamakos)
  3. Newsgroups: comp.sys.next.programmer
  4. Subject: Re: Using the serial # in ROM as a copy protection mechanism...?
  5. Date: 18 Dec 1992 21:00:13 GMT
  6. Organization: University of Maryland, College Park
  7. Lines: 35
  8. Message-ID: <1gte4tINNs3r@ni.umd.edu>
  9. References: <1992Dec17.230932.16643@jarvis.csri.toronto.edu>
  10. NNTP-Posting-Host: sayshell.umd.edu
  11.  
  12. In article <1992Dec17.230932.16643@jarvis.csri.toronto.edu> ematias@dgp.toronto.edu (Edgar Matias) writes:
  13. >A thread is just starting up on comp.sys.mac.programmer on the idea of
  14. >using a computer's serial number embedded in a ROM chip as a means of
  15. >uniquely identifying a given computer.  This could easily be used in
  16. >a copy protection scheme.  I'm told NeXT computers work that way and
  17. >I wonder what all of you think of this kind of copy protection?
  18.  
  19. I can tell that I was most pissed off when I had my CPU board replaced
  20. under warrantee, and my copy of Mathematica stopped working.
  21.  
  22. >Does is work well?  Is it annoying when machine servicing is required?
  23. >Is the chip soldered to the board?  What do you all think?
  24.  
  25. No, the aforementioned event prompted me to patch the kernel to return
  26. the old serial number.  Is it soldered on?  I don't know.  It would be
  27. nice if the serial number/ethernet address device was in a socket, so
  28. that when hardware is repaired or replaced, the address can stay with
  29. the user.  The service people don't seem to do this; or at least no in
  30. my experience.
  31.  
  32. >I think it's a pretty good idea and could solve a lot of problems in
  33. >the software industry.  I seem to be one of the few people in
  34. >comp.sys.mac.programmer who thinks so.  What have been your
  35. >experiences?
  36.  
  37. You either trust your users or not.  The approach that I like is to
  38. give the user some piece of information that needs to be supplied to
  39. enable the application.  This piece of information uniquely identified
  40. the *owner* of the software.  That way, if it gets "loose", you know
  41. who to trace it back to, and thus who violated the terms of the
  42. software license agreement.  This is the approach that I like, and the
  43. one that I use for the software that I write.
  44.  
  45. louie
  46.  
  47.