Yeah, I knew that. But between the irrelevance and Random Capitals I couldn't resist. English, ya know...native speakers don't have an excuse for not being able to use it effectively, eh?
On Fri, Mar 9, 2018 at 2:21 AM, Mike Schwab <mike.a.sch...@gmail.com> wrote: > https://en.wikipedia.org/wiki/Gopher_wood > The wood used in Noah's Ark. Location believed to be Eastern Turkey > or Northern Iraq > > On Thu, Mar 8, 2018 at 9:40 PM, zMan <zedgarhoo...@gmail.com> wrote: > > 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 > > > > -- > Mike A Schwab, Springfield IL USA > Where do Forest Rangers go to get away from it all? > > ---------------------------------------------------------------------- > 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
