Preventing date rollback

[Greg Pavlov]

    [  I assume, given the newgroup that this was posted to, that we are
       not talking about MS DOS-based software packages ]

In article <333 at bria>,  writes:
> 
> That is because the user is most likely NOT interested in protecting the
> interests of the vendor.
> 
  Most sys admins and/or the people responsible for choosing a particular 
  package ARE very concerned with the vendor's interests:  you don't want
  a package you bet your company's long-term health on to be "orphaned".

>>We recently invoked the "roll back the clock" function to allow the continued 
                                                                      ^^^^^^^^^
> >execution of one protected program because the update the vendor gave us to 
   ^^^^^^^^^
> >restore functionality required us to install an OS software upgrade that we 
> >aren't ready to install...
> 
> While unfortunate that your vendor wouldn't be able to help you without an OS
> upgrade, that is sometimes the cost of improvement.
                                         ^^^^^^^^^^^
> 
  Hunh ????  I think that you are trying too hard to prove that the "customer
  is always wrong".

  We, unfortunately, have had to play the clock game also - for software we pur-
  chased and pay support fees for - due to messed up "validation strings".
  Didn't do much for our transaction logging, inter-site communications, etc.

> >Software protection schemes that are tied to system hardware numbers.....
> 
> If you are doing something like swapping motherboards, then simply let the
> software company know in advance what you are doing, and I'm sure they'll 
> accomodate you.  If you want to take the attitude of "why should I have to 
> call someone else when I'm changing something on my machine", then you're
> living in a vacuum, and your expectations will never be met.
> 
  I think that a vendor who truly believes this is guilty of living in a vacuum
  (or doesn't think too much of his software).  A lot of us jump through hoops
  to try to keep our applications up as close to 100% of the time as possible:
  it's in our customer contracts/agreements/whatever.  We DON'T KNOW "in advance
  that a cpu board will fail and if/when it does, what the replacement's number
  will be.  
  
> If the copy protection causes daily interference in one's life, then I
> would say that the protection was a hassle, and dump the product.  


  I've never seen/lived one that wasn't and a significant minority of them
  were destructive to our operation in one way or another.
> 
> Gee, my view of the world is rather bleak, isn't it? :-)
> -- 
> Michael Stefanik, Systems Engineer (JOAT), Briareus Corporation

  Is the lack of a spokesman disclaimer here significant ?


   pavlov at stewart.fstrf.org