Where was Gopher Wood? Is that near Norwegian Wood? What kind of market did they have that Noah cornered? Or was Noach someone different?
Inquiring minds want to know. On Thu, Mar 8, 2018 at 12:54 PM, 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 violate 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 > -- zMan -- "I've got a mainframe and I'm not afraid to use it" ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
