home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / sys / next / programm / 7839 < prev    next >
Encoding:
Internet Message Format  |  1992-12-21  |  3.1 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: 19 Dec 1992 14:30:49 GMT
  6. Organization: University of Maryland, College Park
  7. Lines: 51
  8. Message-ID: <1gvbmpINN2ne@ni.umd.edu>
  9. References: <1992Dec17.230932.16643@jarvis.csri.toronto.edu> <1gte4tINNs3r@ni.umd.edu> <1992Dec18.163540.21795@jarvis.csri.toronto.edu>
  10. NNTP-Posting-Host: sayshell.umd.edu
  11.  
  12. In article <1992Dec18.163540.21795@jarvis.csri.toronto.edu> ematias@dgp.toronto.edu (Edgar Matias) writes:
  13.  
  14. >Well, I know for a fact that at least one of my customers has 
  15. >violated the trust.  However, I like your scheme.  Question is:
  16. >What do you do if/when you find a pirated copy?  Has it happend you
  17. >you yet?
  18.  
  19. The goal of the scheme that I use is to make is clear WHO was licensed
  20. to use the software; that is to identify the owner of the "license
  21. key" information.  The idea was that people would be less likely to
  22. share the copy of software that they bought if it can be traced back
  23. to them.  All you can do is make is easier for the basically
  24. trustworthy person to abide by the terms of his license.  Given enough
  25. effort, any of these schemes can be broken.
  26.  
  27. In the case of my software, this "license key" information is a text
  28. file which contains in plain text the owner of the software as well as
  29. what features of the software are enabled, and expiration dates, etc.
  30. It is secured in such a way to make it easy to detect when the file
  31. has been modified, so the user can't just make his own file.  Perhaps
  32. what I should do is imbed there user's phone number, VISA card number
  33. and other personal information in the file to make it less likely to
  34. be shared with his buddies.
  35.  
  36. Of course, my license key file approach is a bit more unwieldy since I
  37. have to build one for each user.  Alternatively, you can use a long
  38. string of characters to carry some of the information such as a unique
  39. serial number, features, and expiration.  You can then crank these out
  40. mechanically and still have a serial number to associate with the
  41. original user.
  42.  
  43. What do you do when you find a pirated copy?  Well, I'm not a lawyer,
  44. and I don't play one on the net.  I do have my own personal
  45. bloodsucker, er, lawyer that I pay good money to for advice.  So
  46. should you if you are seriously concerned about such issues.  There
  47. is, of course, legal recourse against the original licensee of the
  48. software and the pirate for violating the terms of the license and for
  49. copyright violation.  How effective is this?  It all depends how much
  50. time, effort and money you want to expend to pursue it.
  51.  
  52. Has it happend to me yet?  I don't think this is a question I'd answer
  53. in public.
  54.  
  55. Look, what you really need is to tie the operation of the program to
  56. the "owner" of the program in such a way that the user has to invest
  57. some valuable interest that he doesn't want to share.  Perhaps his
  58. credit card number?  Perhaps his RSA private key?  Public key
  59. cryptography and digital signatures could be just the technology to
  60. effectively deal with this problem.
  61.  
  62. louie
  63.