The Digital Millennium Copyright Act does not apply to using a virtual CPUID under VM. But regardless of the reason, you should always read a license before you sign anything. Although, unless they have specific language the specifically disallows you to use the software under VM using a virtual CPUID, then you are quite safe.
Brian On Thu, 8 Mar 2018 17:54:17 +0000, Seymour J Metz <sme...@gmu.edu> wrote: >Even without an explicit license clause there's the issue of the DMCA. It's >always best to read the license and communicate concerns prior to signing. > >The issue is strictly a legal one; you've been able to specify the virtual >CPUID since old man Noach cornered the market in Gopher Wood. > > >-- >Shmuel (Seymour J.) Metz >http://mason.gmu.edu/~smetz3 > >________________________________________ >From: IBM Mainframe Discussion List <IBM-MAIN@listserv.ua.edu> on behalf of >Brian Westerman <brian_wester...@syzygyinc.com> >Sent: Thursday, March 8, 2018 12:21 AM >To: IBM-MAIN@listserv.ua.edu >Subject: Re: Product license key program > >No violation is performed, unless the vendor specifically prohibits it (which >I doubt anyone would do). Simulating the CPU serial has existed under VM for >as long as I can remember. There is no violation from doing this as the z/OS >CVT freely identifies that it's an "emulated" system. Most key modules check >for this and it's up to the vendor to decide whether or not to allow it and >under what circumstances and for how long. > >Brian > > On Wed, 7 Mar 2018 16:16:40 +0000, Seymour J Metz <sme...@gmu.edu> wrote: > >>Simulating the CPUID may viotate the license agreement. If you're going to >>use keys, explicitly address the issue. >> >> >>-- >>Shmuel (Seymour J.) Metz >>http://mason.gmu.edu/~smetz3 >> >>________________________________________ >>From: IBM Mainframe Discussion List <IBM-MAIN@listserv.ua.edu> on behalf of >>Brian Westerman <brian_wester...@syzygyinc.com> >>Sent: Wednesday, March 7, 2018 12:57 AM >>To: IBM-MAIN@listserv.ua.edu >>Subject: Re: Product license key program >> >>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 >> >>---------------------------------------------------------------------- >>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 > >---------------------------------------------------------------------- >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
