home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / os / vms / 14137 < prev    next >
Encoding:
Internet Message Format  |  1992-08-26  |  3.2 KB
  1. Path: sparky!uunet!cis.ohio-state.edu!ucbvax!TGV.COM!adelman
  2. From: adelman@TGV.COM (Kenneth Adelman)
  3. Newsgroups: comp.os.vms
  4. Subject: Re: PAKGEN software (Was: will lmf will alpha?)
  5. Message-ID: <920825150920.226001bf@TGV.COM>
  6. Date: 25 Aug 92 23:03:22 GMT
  7. Sender: daemon@ucbvax.BERKELEY.EDU
  8. Reply-To: Adelman@TGV.COM (Kenneth Adelman)
  9. Distribution: world
  10. Organization: The Internet
  11. Lines: 57
  12.  
  13. > I couldn't agree more.  And all of us should pressure our vendors to abandon
  14. > custom key/authorization code implementations for LMF.
  15.  
  16.     As a vendor which has shipped over 20,000 PAKs and thousands of
  17. pieces of media in the past three months I can tell you that LMF has
  18. been a godsend.  MultiNet V3.1 was the first software we released
  19. which supported LMF, and also the first software distributed on
  20. CD-ROM.  Prior to the release we sent out a customer questionaire
  21. detailing our records of each customers' configuration and inviting
  22. them to get any errors corrected prior to the release; this resulted
  23. in a minimum of problems caused by incorrect PAKs being issued.  It
  24. also made distribution on CD-ROM possible, as well as opened a lot of
  25. opportunities for customers to evaluate products which they hadn't yet
  26. licensed but were available on the CD-ROM, and removed a prior problem
  27. we had with mixed configurations in a cluster (some products licensed
  28. for some machines).
  29.  
  30.     Do our customers like it?  Well, we only hear the complaints;
  31. license management tools are primarily for the vendor's benefit and
  32. the customer pays the administrative cost(s) associated with entering
  33. the license data.  The customer needs to consider, however, that the
  34. result is that we can provide better service; the purchase of a new
  35. product no longer requires the shipment of new media and
  36. re-installation of the product.  I suspect that our customers prefer
  37. LMF to some other scheme of similar functionality; they already know
  38. how to use LMF (as is demonstrated by the relatively infrequent "What
  39. do I do with this PAK?" support call).
  40.  
  41.     After three months of experience from the vendor side of LMF
  42. we have absolutely no regrets about having used it and wished we'd
  43. used it earlier.
  44.  
  45. > How about pressuring DEC to abandon the truely RIDICULOUS price for the
  46. > PAK generation software? or to provide a reasonably priced, publically
  47. > accessible, PAK generation service?  or to allow some third party to set
  48. > up such a service?
  49.  
  50.     Only the list price is steep. If you're a DEC Independent
  51. Software Vendor (ISV) you get a substantial discount off the list
  52. price. I'd say that so far we've spend about $0.20/PAK for the PAKs
  53. we've generated. Very reasonable. I believe anyone who write software
  54. for DEC computers can become an ISV (call 800-DEC-ISVN).
  55.  
  56. > The PAK generator prices are too bad if you can resell.  DOes the contract prohi
  57. > |bit your
  58. > reselling pak generation?
  59.  
  60.     I don't recall if it prevents you from reselling a PAK generation
  61. service, but it would be with your producer code.  One license for
  62. PAKGEN gives you one PAK which has a product token of which
  63. PRODUCER/ISSUER pair you're allowed to issue PAKs under.  For example,
  64. our PAK has a product token of "TGV~TGV". I don't see how any software
  65. vendor would find such a service an advantage (in price) over doing
  66. it in house (with full control).
  67.  
  68.                             Ken
  69.  
  70.