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 <[email protected]> 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 <[email protected]> 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 <[email protected]> on behalf >> of Brian Westerman <[email protected]> >> Sent: Thursday, March 8, 2018 12:21 AM >> To: [email protected] >> 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 <[email protected]> >> 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 <[email protected]> on behalf >> of Brian Westerman <[email protected]> >> >Sent: Wednesday, March 7, 2018 12:57 AM >> >To: [email protected] >> >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) < >> [email protected]> 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 [email protected] with the message: INFO IBM-MAIN >> > >> >---------------------------------------------------------------------- >> >For IBM-MAIN subscribe / signoff / archive access instructions, >> >send email to [email protected] with the message: INFO IBM-MAIN >> > >> >---------------------------------------------------------------------- >> >For IBM-MAIN subscribe / signoff / archive access instructions, >> >send email to [email protected] with the message: INFO IBM-MAIN >> >> ---------------------------------------------------------------------- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to [email protected] with the message: INFO IBM-MAIN >> >> ---------------------------------------------------------------------- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to [email protected] 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 [email protected] 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 [email protected] with the message: INFO IBM-MAIN
