The problem with just using a date, is that the software could be moved to any machine and duplicated any number of times and you would never know about it to keep it from being unlawfully duplicated without payment.
This doesn't mean that you don't trust your clients. In effect, while some might argue, it's really just like locking your car or your home or having a bike lock. Lets say that you generate your software and the people at company "X" pay the license until January of 2020. In the mean time, 40 people who used to work for company "X", decide that it's soooo good that they want to take it to their new site with them. That would be great if you got revenue from that movement, but you can't unless they call you and tell you that they moved the software and their "new" company would like to license it. Also, maybe the people at company "X" decide that they want to defray the cost of the software they licensed from you, so they sell copies on the internet to other sites. It will run until January of 2020, so there is nothing to keep it from happening. I'm not saying that every client is dishonest, but it only takes one person to make it bad for you. Admittedly, this is probably a bit far fetched, but it's late and I'm tired. :) On the other hand, if you had a check in your module for the CPU Serial number, (and machine type or LPAR name, or any of several limiting factors), the client is in no way harmed or inconvenienced, because it will operate as before with no impediments, save that the software can't be "moved" without your permission. This should not cause any problems with DR testing or a real disaster because most, (if not all) DR sites run under VM and will simulate the serials and MT for just this purpose. You can also check for running under VM and disallow it (or generate warnings), but that is not normally necessary and gets away from the point I'm making. Also, your key code needs to take into account that the site might have multiple physical processors (separate mainframes), so you want to make sure that your "key" code supports multiple entries. This will also be useful for those sites that use "friend" arrangements for their DR sites (other companies who share each other's sites as Disaster Recovery sites for each other). You can/should also add code that temporarily allows the product to function when the key doesn't match, for use as a trial or for when "stuff" happens that the site for some reason needs to use the code on another box "temporarily". You can limit it for a period of time, or number of uses, or whatever you think is reasonable, it's your software, you make the rules, while generating messages that let the site know in no uncertain terms that the the license is not "currently valid". There are lots of nice features you can add to the key process, and you can do as many vendors have and set up a web page to generate "emergency" keys for, well.... emergencies. The reason is because "stuff happens" and no one is happy if the product can't be used for some reasonable reason and they can't contact the vendor until the next day because no one happens to be on call that night. If you are going to implement keys, you might as well do it right and make sure you test-test-test the process before you send it out to your client(s). It's a good way to lose them if you mess up something like this. All sites will understand the necessity of you having keys in your software, but no one will understand if it isn't rock solid. It's such a little nit to implement correctly, but all it takes is one error in the key generation program to ruin your day. Brian On Tue, 6 Mar 2018 21:02:37 +0000, Savor, Thomas (Alpharetta) <thomas.sa...@fiserv.com> wrote: >Brian, > >Never thought about Using CPUID and/or machine type as part of a software key. > >Generally speaking we try to stay away from tying application to any kind of >machine. >Our application is typical Cobol/Asm, Batch/CICS and VSAM/DB2 system. >Cobol 5 was first change in years that required major changes to our >application. >Usually a change to the Operating System has no effect on application >executing properly. > >But having said that, since I didn’t know really what makes up a key and how >they work, this is an interesting change in direction and thinking. >Thanks for the ideas. > >And thanks for the ofrer of help....I will almost certainly need it. > >Thanks, > >Tom Savor > >---------------------------------------------------------------------- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
