Re: Product license key program

[zMan]

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 +, 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 s 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 limiti

Re: Product license key program

[Mike Schwab]

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 +, 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 s 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 ph

Re: Product license key program

[Brian Westerman]

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 +, 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 +, 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 s 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 eac

Re: Product license key program

[zMan]

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 +, 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 s 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 us

Re: Product license key program

[Seymour J Metz]

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 +, 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 s 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, 
>wel

Re: Product license key program

[Brian Westerman]

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 +, 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 s 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 sol

Re: Product license key program

[Seymour J Metz]

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 s 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 +, 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 w

Re: Product license key program

[Mike Schwab]

Don't forget about sites needing to replace a mainframe with a newer
model, or upgrading their existing hardware to faster processors or
more processors within the unit (I.E. same device type but different
model).

On Tue, Mar 6, 2018 at 11:57 PM, Brian Westerman
 wrote:
> 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 s 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 +, Savor, Thomas (Alpharetta) 
>  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 helpI will almost certainly need it.
>>
>>Thanks,
>>
>>Tom Savor
>>

Re: Product license key program

[Brian Westerman]

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 s 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 +, Savor, Thomas (Alpharetta) 
 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 helpI 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

Re: Product license key program

[Savor, Thomas (Alpharetta)]

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 offer of helpI 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

Re: Product license key program

[Brian Westerman]

Tom

As for adding keys to your software, yes, I believe it's a good thing, but you 
have to remember that simply locking up your software really, really tight is 
not a good solution.  They idea is to balance protecting your software but not 
putting the screws in so tight that the client can't use it properly.

It's really really easy to get the CPU serial number programmatically, and IBM 
even has a service you can call to get the machine information from an 
authorized or non-authorized environment.  You can get it from COBOL as well as 
via C.  

As for protection, many vendors simply "scramble" the characters of the CPUID 
and the "expiration date" they want to assign among either a bunch of useless 
characters or keep single bytes all over the place within your program, then 
you get the CPU serial (and machine type information if you want to use that 
also), and the current date, then you simply compare the values you know (the 
CPUID and other data you authorized in your program), with the values you just 
got from the system you are executing on.  If they don't match (serial number, 
etc.) then you can just send a message that you have expired or just end 
without saying anything (which is very unhelpful).  Then if that matches, you 
compare the dates, and if it's within the end date you allowed, then you just 
go on as if nothing happened.  If you are getting close to the date (i.e. the 
last 30 days) then you can put out a "warning" message that you will expire 
soon.  You can (and probably should) add code to allow "grace" period.  

Now, if you want to get really fancy, you can take the information that you 
normally would have kept within your code, and instead place it in a key record 
(some encrypted record that you provide to the user to make available to your 
program, either in a dataset or as a parm to the execution.  You program should 
then have some decryption code that checks the provided key information against 
the execution time information (CPUID, MACHINE Type, current date), just like 
the previous method, except that you have externalized the "key" and can 
replace it very easily for your client.

The encryption method can be a secure one (128bit or 256 bit secure method or 
you can devise your own encryption code, even something as simple as inverting 
each character by some known amount and also having scrambled up the order of 
the information is probably more than enough to do what you want.  After all, 
most sites are not really trying to steal your code, and besides a really 
concerted and smart person with enough time can break your encryption anyway, 
but the idea is really just to remove the temptation to keep copies of your 
code and/or sell them to other people.

I have literally seen probably 100 (or more) different ways of implementing the 
code, and everyone has their favorites and everyone thinks that theirs is the 
best (but I know mine is), and there is no real "right" way to do it.

If you need help setting up the code to get the information from the system 
during execution, let me know and I'll help you, as for coming up with the 
encryption code, you probably want to do that yourself so that you know that no 
one else will give your method away.  But if you need help I can help you there 
as well.  It's really very simple once you know where to get the information at 
run time.

What you will notice is that once you are able to get the data from the system, 
it becomes more addictive and you will want to start getting things like the 
jobname of the job that is executing you, or the owning userid and such.  The 
skys the limit once you start down that road.

Just remember that you don't need to go overboard. You certain can if you want, 
but protection doesn't have to be overly complex to be effective.

Brian  

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Product license key program

[Wayne Bickerdike]

BobL said:

 *   I have to disagree on Compuware products.  We have a bunch, and the
License administration application works fine.  We just go into the panels,
set DR mode, and we're good for 14 (?) days.   For us at least, it's a very
workable solution for DR.*

Spoken like a systems programmer!

The License panel asks for Port Number, Host Name, Host Address, TCP STC
name.

Remember that the DR user is not always you.

I had to look all this up, because it's not my gig. But our guys who deal
with vendors and licences hate the process.


On Tue, Mar 6, 2018 at 3:56 AM, Lester, Bob <bles...@ofiglobal.com> wrote:

> Hi Wayne,
>
>  I have to disagree on Compuware products.  We have a bunch, and the
> License administration application works fine.  We just go into the panels,
> set DR mode, and we're good for 14 (?) days.   For us at least, it's a very
> workable solution for DR.
>
> Thanks!
> BobL
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Wayne Bickerdike
> Sent: Sunday, March 4, 2018 1:25 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Product license key program [ EXTERNAL ]
>
> We always have issues during DR with licence keys.
>
> Worst vendor is Compuware, convoluted process and activation procedure.
>
> We like to expose "novice" users to the DR process, it's a test of
> documentation and process, not systems skills.
>
> One vendor had the cheek to tell us to give more warning. I told them we
> are testing you as much as DR.
>
> Don't mind CA, they don't disable just give warnings.
>
> On Mon, Mar 5, 2018 at 6:55 AM, Seymour J Metz <sme...@gmu.edu> wrote:
>
> >  1. BTDT,GTS - I'm not talking ideology or abstract theory, but history.
> > Vendor promises are worthless when push comes to shove.
> >
> >  2. In the incidents I was referring to we *did* get the keys in advance;
> > they didn't work and the vendor failed to respond within the
> > contractually
> > guarantied time window. That's why I asked about how you handled
> > DR tests.
> >
> >  3. I'm not concerned with the customer who has delayed renewing, I'm
> > concerned with the customer who is fully paid up and doesn't get
> > what he paid for.
> >
> >  4. "To indemnify for or from what exactly?" The cost of the DR
> > facilities that could be
> > tested because of the bad keys would have been a start.
> >
> >  5. "what associated risk?  The risk that they will not pay their
> > license fee and therefore
> >  lose the use of the software?"
> >
> > More straw dummies. Stop trying to put words in my mouth.
> >
> >  6. "you are assuming that the Key or the requirement thereof will
> > somehow, through the
> >  fault of the "key", cause an outage. ".
> >
> > No, *you* are assuming that I don't have empirical evidence. See
> > item
> > 2 above.
> >
> >  7. "4) What about it?  They paid for the key, it's implemented, and
> > it works."
> > Were that true I wouldn't have commented. We paid for the keys, it
> > was implemented
> > and it *didn't* work.
> >
> >  8. "and not a generation issue or some other purely human factor?"
> > From the customer perspective the vendor is a black box; he doesn't
> > care whether the outage cased by the vendor was due to hardware,
> > software or human error.
> >
> >  9. "I don't think most vendors try to tell the client what metrics to
> > use in
> >  evaluation (aside from CA maybe:))"
> >
> > CA never had the nerve to patronizingly dismiss our concerns. They
> > accepted
> > them as legitimate and addressed them as best they could.
> >
> > 10. "6) What danger inherent in the enforcement method? "
> > See item 2 above.
> >
> > 11. "The key works or it doesn't, if it doesn't, either it expired, the
> > software has been altered or changed or it never worked in the
> > first place. "
> > How do you propose that the customer tests whether a DR key works
> prior
> > to going to the DR site and testing?
> >
> > 12. " I really don't mean to sound flippant, but sending software out
> > without keys
> > would be similar (maybe only to me) as Ford sending out all of
> > their cars without
> >  an ignition key or secure button. "
> > Only to you; Ford doesn't try to lock its customer out of the car.
> >
> > Bottom line: keys are ba

Re: Product license key program

[David Boyes]

> Back to the keys question, I've tried to figure out how to even have keys in 
> the application system.  
> Places that I've worked at, there have been times when getting paid for our 
> software or services has been difficult to collect, so what about keys ??
> Well, that becomes a challenge when we have always delivered the code to the 
> customer...not really sure how to do that.

I've always liked the approach that DEC used for VMS software: engineer a 
common license database and a set of tools to manipulate it, and create a way 
to check if the license was valid for the machine in question that was usable 
from every supported programming language on the system. Everybody pretty much 
had a gentleman's agreement that this was the way to control software usage, 
and DEC actively discouraged products and vendors that didn't play nice. Their 
tool had the ability to lock software to a specific machine, CPUtype, number of 
users, and about a dozen other things, and had options for how long to tolerate 
running without a license and a whole lot more. You could audit your licenses 
by running the LICENSE command and all your licenses from all your vendors were 
in one place. The same system was used for the OS and applications alike, and 
the license file could contain multiple licenses for the same product that 
could be queried to determine which license to use on this system (it was 
designed for clustered machines). 

IBM made an abortive attempt at something like this back in the 80s, but 
inserted IBM into the licensing process in a stupid way. Predictably, it got 
shot down by the ISVs who didn't want to change their code and/or have IBM 
involved in their licensing. Perhaps it's time to try again -- I know I 
wouldn't mind having such a thing available, and I detest inventing and/or 
dealing with stuff like this. Just have the OS vendor do it correctly once; 
they're in the best position to architect it to fit the underlying system best, 
and it generally isn't a performance or functionality critical thing so there 
isn't likely to be a need to allow replacement systems.

 


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Product license key program

[Jesse 1 Robinson]

I’m sympathetic to a vendor's need for keys. A (long gone) shop I worked in 
suffered the grab-and-run of a well-known product from its licensed location to 
an unlicensed one. Thanks to a rogue operator who I guess wanted to make his 
day to day job a little easier and figured out how to do a copy over NJE. ISV 
threw a fit, wanted an extraordinary penalty. Not from the miscreant himself of 
course. 

We now deal with many ISVs. Most of the big ones plus some dogies as well. We 
do frequent DR tests as we own the DR environment. I'm not aware that our keys 
in general include the DR machine, but everything works. Warnings are fine; I 
personally appreciate the reminder that I'm running a DR system, which 
otherwise looks exactly like production.

Our biggest concern is getting renewal keys in time to keep a product from 
imploding. That issue is seldom the fault of the ISV. Can you spell bean 
counter?

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Savor, Thomas (Alpharetta)
Sent: Monday, March 05, 2018 2:23 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Product license key program

That's the problem. If you give customer Source code, they can get around the 
key.
The only thing I could think of, was to only deliver object to certain Batch 
and Online modules that never change.  Sort of Black Box those modules.

On the contract thingwell in our case at the time, it was a software sell 
and a bunch of mods we did for this Turkish Bank.  They owed us around 1 
million dollars...then they decided not to pay at all...all support for them 
ended.  The problem was that it was a State Owned Bankso we had to eat it.
It was a hard lesson to learn.

But even the keys, it was fascinating to see these keys.  I've tried to 
understand how in the World these workedi've seen a zap before to extended 
a product from now to next yearnow the zap looked like a couple of LA's 
applied to a module...and the product extended to next year.  But you don’t 
find ANY dates in this program, so how this is done has always been "Magic". 

Thanks,

Tom Savor


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Grinsell, Don
Sent: Monday, March 05, 2018 4:23 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Product license key program

Tom,

I guess it all depends on your contract terms.  If the software requires a key 
to run, then you should be able to get paid for delivering an updated key.  If 
you are delivering source code, well any competent programmer could probably 
circumvent your key logic and be prepared to face the consequences if you 
choose to audit them.  On the other hand, if the license key is for support, 
then they have rights to use the software as delivered, but upgrades or help 
would require an active subscription easily verified on your end.  

Regards,

Don

--
 
Donald Grinsell, Systems Programmer
Enterprise Technology Services Bureau
SITSD/Montana Department of Administration
406.444.2983 (D)


"It was as true as taxes is.  And nothing's truer than them."
~ Charles Dickens (1812-70)

> -Original Message-
> From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On 
> Behalf Of Savor, Thomas (Alpharetta)
> Sent: Monday, March 05, 2018 2:01 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Product license key program
> 
> 
> Back to the keys question, I've tried to figure out how to even have 
> keys in the application system.
> Places that I've worked at, there have been times when getting paid 
> for our software or services has been difficult to collect, so what about 
> keys ??
> Well, that becomes a challenge when we have always delivered the code 
> to the customer...not really sure how to do that.
> 
> Thanks,
> 
> Tom Savor


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Product license key program

[Savor, Thomas (Alpharetta)]

That's the problem. If you give customer Source code, they can get around the 
key.
The only thing I could think of, was to only deliver object to certain Batch 
and Online modules that never change.  Sort of Black Box those modules.

On the contract thingwell in our case at the time, it was a software sell 
and a bunch of mods we did for this Turkish Bank.  They owed us around 1 
million dollars...then they decided not to pay at all...all support for them 
ended.  The problem was that it was a State Owned Bankso we had to eat it.
It was a hard lesson to learn.

But even the keys, it was fascinating to see these keys.  I've tried to 
understand how in the World these workedi've seen a zap before to extended 
a product from now to next yearnow the zap looked like a couple of LA's 
applied to a module...and the product extended to next year.  But you don’t 
find ANY dates in this program, so how this is done has always been "Magic". 

Thanks,

Tom Savor


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Grinsell, Don
Sent: Monday, March 05, 2018 4:23 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Product license key program

Tom,

I guess it all depends on your contract terms.  If the software requires a key 
to run, then you should be able to get paid for delivering an updated key.  If 
you are delivering source code, well any competent programmer could probably 
circumvent your key logic and be prepared to face the consequences if you 
choose to audit them.  On the other hand, if the license key is for support, 
then they have rights to use the software as delivered, but upgrades or help 
would require an active subscription easily verified on your end.  

Regards,

Don

--
 
Donald Grinsell, Systems Programmer
Enterprise Technology Services Bureau
SITSD/Montana Department of Administration
406.444.2983 (D)


"It was as true as taxes is.  And nothing's truer than them."
~ Charles Dickens (1812-70)

> -Original Message-
> From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On 
> Behalf Of Savor, Thomas (Alpharetta)
> Sent: Monday, March 05, 2018 2:01 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Product license key program
> 
> 
> Back to the keys question, I've tried to figure out how to even have 
> keys in the application system.
> Places that I've worked at, there have been times when getting paid 
> for our software or services has been difficult to collect, so what about 
> keys ??
> Well, that becomes a challenge when we have always delivered the code 
> to the customer...not really sure how to do that.
> 
> 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

Re: Product license key program

[Savor, Thomas (Alpharetta)]

Your right...my bad.  Spelling is my crutch !!!

Thanks,

Tom Savor

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of J R
Sent: Monday, March 05, 2018 4:21 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Product license key program

I apologize up front for my pedantry.  However, in the context of this argument 
... er ... discussion, it seems apropos:
You typed 'incite' I think you meant 'insight'.
You typed 'site' I think you meant 'cite'  (twice).

Peace!

On Mar 5, 2018, at 16:02, Savor, Thomas (Alpharetta) 
<thomas.sa...@fiserv.com<mailto:thomas.sa...@fiserv.com>> wrote:

I would love to get your incite on something

--
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

Re: Product license key program

[Grinsell, Don]

Tom,

I guess it all depends on your contract terms.  If the software requires a key 
to run, then you should be able to get paid for delivering an updated key.  If 
you are delivering source code, well any competent programmer could probably 
circumvent your key logic and be prepared to face the consequences if you 
choose to audit them.  On the other hand, if the license key is for support, 
then they have rights to use the software as delivered, but upgrades or help 
would require an active subscription easily verified on your end.  

Regards,

Don

--
 
Donald Grinsell, Systems Programmer
Enterprise Technology Services Bureau
SITSD/Montana Department of Administration
406.444.2983 (D)


"It was as true as taxes is.  And nothing's truer than them."
~ Charles Dickens (1812-70)

> -Original Message-
> From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of
> Savor, Thomas (Alpharetta)
> Sent: Monday, March 05, 2018 2:01 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Product license key program
> 
> 
> Back to the keys question, I've tried to figure out how to even have keys in
> the application system.
> Places that I've worked at, there have been times when getting paid for our
> software or services has been difficult to collect, so what about keys ??
> Well, that becomes a challenge when we have always delivered the code to the
> customer...not really sure how to do that.
> 
> 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

Re: Product license key program

[J R]

I apologize up front for my pedantry.  However, in the context of this argument 
... er ... discussion, it seems apropos:
You typed 'incite' I think you meant 'insight'.
You typed 'site' I think you meant 'cite'  (twice).

Peace!

On Mar 5, 2018, at 16:02, Savor, Thomas (Alpharetta) 
> wrote:

I would love to get your incite on something

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Product license key program

[Savor, Thomas (Alpharetta)]

" OK, this discussion has reached the level of diminishing returns."

Man, I guess sothis "was" a very interesting discussion about software keys 
that has dissolved quickly.
Guys, I'm not a systems programmer, never have beenbut I'm kind of the 
Applications systems programmer if that exists.
Anyway, I thought Brian asked very thoughtful questions and asked for an 
opinion about which way to go...not a bunch of crap.   
I don’t know Brian at all, but if I could follow his questions, then they were 
probably pretty well explained.

Then there's SeymourI don’t know you either, but as an observation, you 
remind me of my brother.  He will argue with me about the sky being blue.
Some people "must" argue or correct you about everything...it's like it's their 
job or something.
I would love to get your incite on something without the constant seemingly 
condescending corrections to everything.
You may not mean to be condescending, but you come across that way to me.
If I worked at your shop, I wouldn’t ask you for help even if I knew you knew 
the answer, I wouldn’t want to hear the constant argument 
about what I'm doing.

Seymour, you are probably a genius...But at the end of the day, these constant 
corrections or arguments - Does it really matter ??
I site a couple years ago the constant bitching about UNIX or UCC.  People 
learn something and its called something at a site, as long as everyone 
understands what they are talking about...again, does it matter ?? If you 
alienate people, then they aren’t going to listen to you.  
There was a time when all your answer/emails went to the Trash can...and your 
drifting towards that again.  
Most of the time, when you site a sentence or even a wordI have no clue 
what you are talking about.  

Back to the keys question, I've tried to figure out how to even have keys in 
the application system.  
Places that I've worked at, there have been times when getting paid for our 
software or services has been difficult to collect, so what about keys ??
Well, that becomes a challenge when we have always delivered the code to the 
customer...not really sure how to do that.

Thanks,

Tom Savor

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Product license key program

[Lester, Bob]

+1

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of David Boyes
Sent: Monday, March 5, 2018 11:13 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Product license key program [ EXTERNAL ]

>On 3/5/18, 12:53 PM, "IBM Mainframe Discussion List on behalf of Seymour J 
>Metz" <IBM-MAIN@LISTSERV.UA.EDU on behalf of sme...@gmu.edu> wrote:
 >[.snip.]

OK, this discussion has reached the level of diminishing returns. 

There seems to be a general agreement that the concept of keys is not the 
problem, but the execution of the keying process is. The desirable behavior is 
that the product run without a key for a reasonable transition period to permit 
updates, etc without making it into a critical situation while some other 
critical thing is happening. A nice thing that some vendors provide is an 
automated way to issue a temporary key, followed by a call from the vendor to 
the customer to check in on the use of the temporary key. 

Now, can we go back to the boring usual issues, like Charles originally 
requested several days ago?






--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

This e-mail transmission may contain information that is proprietary, 
privileged and/or confidential and is intended exclusively for the person(s) to 
whom it is addressed. Any use, copying, retention or disclosure by any person 
other than the intended recipient or the intended recipient's designees is 
strictly prohibited. If you are not the intended recipient or their designee, 
please notify the sender immediately by return e-mail and delete all copies. 
OppenheimerFunds may, at its sole discretion, monitor, review, retain and/or 
disclose the content of all email communications.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Product license key program

[David Boyes]

>On 3/5/18, 12:53 PM, "IBM Mainframe Discussion List on behalf of Seymour J 
>Metz"  wrote:
 >[.snip.]

OK, this discussion has reached the level of diminishing returns. 

There seems to be a general agreement that the concept of keys is not the 
problem, but the execution of the keying process is. The desirable behavior is 
that the product run without a key for a reasonable transition period to permit 
updates, etc without making it into a critical situation while some other 
critical thing is happening. A nice thing that some vendors provide is an 
automated way to issue a temporary key, followed by a call from the vendor to 
the customer to check in on the use of the temporary key. 

Now, can we go back to the boring usual issues, like Charles originally 
requested several days ago?






--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Product license key program

[Seymour J Metz]

 1. Been There Done That, Got The Scars

 2.  Whether the vendors were bad or not is irrelevant; the keys were an
additional risk factor.

 3. The issue is risk, not assigning blame.

 4. And I asked you to stop putting words in my mouth.

 5. " than tell me that my promises are "worthless" solely because I'm a 
vendor."
There you go again. If you want me to be civil, then you have to be civil, 
and
that includes not attributing things to me that I didn't write.

 6. "but you must also take into account what the vendor has to be concerned 
with."
No, I don't. If the product doesn't suit my needs then I don't acquire it, 
regardless
of why the vendor made the decisions he made.

 7. " Also, we still don't know that you didn't get "what you paid for"."
Who is we? Those who read my posts instead of going into denial understood.
Which part of " the vendor failed to respond within the contractually  
guarantied time window."
didn't you understand?

 8. " If this were a test and you sent them the information and they sent you a 
bad key, so what?
 Just call them up and get it fixed. "
Why are you pretending to respond to what I wrote when you obviously 
weren't paying attention.
I told you; we did call, the contract required them to responded within a 
stipulated interval
and they didn't.

 9. "If you expected them to be 24x7 and they are not, is that their fault or 
yours?"
When the expectation is based on a contractual requirement that they be 
24x7,
whose fault do you think it is?


--
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: Monday, March 5, 2018 3:02 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: Product license key program

Hi Shmuel,

Sorry to be slow, I don't know what BTDT,GTS means.

Also, this discussion is supposed to be about keys and whether they are 
justified or bad or good or "whatever".  If you had a bad vendor, then whether 
or not they had keys in their software is almost irrelevant.  If the vendor 
screwed up in some way and it was 100% their fault, then shame on them, but you 
should not really blame keys for the rest of your life just because some vendor 
screwed up and didn't call you back in time.

If you have an agreement with a vendor to supply you with DR keys, and you did 
everything you were supposed to do, (i.e. you called them with the "correct" DR 
CPU info, and you notified them as soon as you could that the DR event 
started), then I would have to agree with you that it sounds like they screwed 
up badly if you were without keys for an extended period of time.  By extended 
I mean anything over 30 minutes.  If, on the other hand, you didn't have a good 
DR plan that included contacting your vendors (all of them, whether they have 
keys or not), then you plan is already flawed and any delays you experience are 
partly if not all your own fault.  You might be about to complain that no one 
knows of a disaster ahead of time and calling ahead of time for a DR test is 
not a "real" test of the plan, but you are wrong.  Part of a "good" DR plan is 
supposed to be stuff that you do all the time before the Disaster strikes, 
which is more than just running FDR every day.

I have been part to literally hundreds of DR tests and thankfully only a 
handful of actual disasters.  I was at a foreign country site one day when 
someone tossed a hand grenade into the command tent where the "datacenter" was 
located.  Let me tell you, getting vendors to call you back to the Middle East 
ain't easy, so you have to be sure you have have your DR plan ready to go.

You should have (somewhere in the DR "bible" book) all of the contact 
information for the vendor and someone is "supposed" to make sure it's tested 
periodically for validity, (vendors change offices and numbers too).  Also, if 
your vendor used to be 24x7 and now they aren't, it's your responsibility (as 
part of the DR plan) to know that.  The vendor might have sent out a email 
"blast" to tell you about it 6 months before, but everyone knows that no one 
reads the crap from a vendor so missing it is a possibility that should have 
been addressed int he DR plan.  If it wasn't, then that's also a flawed plan.

I'm not trying to say that your vendor didn't screw up royally.  I'm just 
saying that it's not logical to blame all vendors that use keys for something 
that one vendor did, which may not even be entirely their fault, and if you 
"should" have kept this from happening in your DR plan itself, then you need to 
accept at least part of the responsibility.

Now back to the numbered stuff:

1) Some vendor promises 

Re: Product license key program

[Lester, Bob]

Hi Wayne,

 I have to disagree on Compuware products.  We have a bunch, and the 
License administration application works fine.  We just go into the panels, set 
DR mode, and we're good for 14 (?) days.   For us at least, it's a very 
workable solution for DR.

Thanks!
BobL

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Wayne Bickerdike
Sent: Sunday, March 4, 2018 1:25 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Product license key program [ EXTERNAL ]

We always have issues during DR with licence keys.

Worst vendor is Compuware, convoluted process and activation procedure.

We like to expose "novice" users to the DR process, it's a test of 
documentation and process, not systems skills.

One vendor had the cheek to tell us to give more warning. I told them we are 
testing you as much as DR.

Don't mind CA, they don't disable just give warnings.

On Mon, Mar 5, 2018 at 6:55 AM, Seymour J Metz <sme...@gmu.edu> wrote:

>  1. BTDT,GTS - I'm not talking ideology or abstract theory, but history.
> Vendor promises are worthless when push comes to shove.
>
>  2. In the incidents I was referring to we *did* get the keys in advance;
> they didn't work and the vendor failed to respond within the 
> contractually
> guarantied time window. That's why I asked about how you handled
> DR tests.
>
>  3. I'm not concerned with the customer who has delayed renewing, I'm
> concerned with the customer who is fully paid up and doesn't get 
> what he paid for.
>
>  4. "To indemnify for or from what exactly?" The cost of the DR 
> facilities that could be
> tested because of the bad keys would have been a start.
>
>  5. "what associated risk?  The risk that they will not pay their 
> license fee and therefore
>  lose the use of the software?"
>
> More straw dummies. Stop trying to put words in my mouth.
>
>  6. "you are assuming that the Key or the requirement thereof will 
> somehow, through the
>  fault of the "key", cause an outage. ".
>
> No, *you* are assuming that I don't have empirical evidence. See 
> item
> 2 above.
>
>  7. "4) What about it?  They paid for the key, it's implemented, and 
> it works."
> Were that true I wouldn't have commented. We paid for the keys, it 
> was implemented
> and it *didn't* work.
>
>  8. "and not a generation issue or some other purely human factor?"
> From the customer perspective the vendor is a black box; he doesn't
> care whether the outage cased by the vendor was due to hardware,
> software or human error.
>
>  9. "I don't think most vendors try to tell the client what metrics to 
> use in
>  evaluation (aside from CA maybe:))"
>
> CA never had the nerve to patronizingly dismiss our concerns. They 
> accepted
> them as legitimate and addressed them as best they could.
>
> 10. "6) What danger inherent in the enforcement method? "
> See item 2 above.
>
> 11. "The key works or it doesn't, if it doesn't, either it expired, the
> software has been altered or changed or it never worked in the 
> first place. "
> How do you propose that the customer tests whether a DR key works prior
> to going to the DR site and testing?
>
> 12. " I really don't mean to sound flippant, but sending software out 
> without keys
> would be similar (maybe only to me) as Ford sending out all of 
> their cars without
>  an ignition key or secure button. "
> Only to you; Ford doesn't try to lock its customer out of the car.
>
> Bottom line: keys are bad because historically they have caused 
> problems for legitimate users, often problems that the vendor had 
> promised wouldn't occur.
>
> --
> Shmuel (Seymour J.) Metz
> https://urldefense.proofpoint.com/v2/url?u=http-3A__mason.gmu.edu_-7Es
> metz3=DwIBaQ=huW-Z3760n7oNORvLCN2eJBo4X7nIGCr9Ffht-z0f4k=1KMMjoS
> vFEwY7ZoooplFIrKcOeeTJVI4X6Bc3o6vdK4=1l6hpNNXgTiCCpbDJWg8VLAjcwY3ccs
> 7JKJn3oF8I2A=Ap59KzoG5pNDC3N598NDZ-cKLXf4Aac-cJgMJiZzTDk=
>
> 
> From: IBM Mainframe Discussion List <IBM-MAIN@listserv.ua.edu> on 
> behalf of Brian Westerman <brian_wester...@syzygyinc.com>
> Sent: Saturday, March 3, 2018 1:22 AM
> To: IBM-MAIN@listserv.ua.edu
> Subject: Re: Product license key program
>
> Hi Shmuel,  this is just a friendly discussion, and I know I tend to 
> have a odd sense of humor sometimes, so please don't take any of what 
> I mean as levity as something personal.  I really am trying to 
> understand your point.  If you can convince me that there is some 
> inheren

Re: Product license key program

[Brian Westerman]

>software has been altered or changed or it never worked in the first 
> place. "
>How do you propose that the customer tests whether a DR key works prior 
>to going to the DR site and testing?
>
>12. " I really don't mean to sound flippant, but sending software out without 
>keys 
>would be similar (maybe only to me) as Ford sending out all of their cars 
> without
> an ignition key or secure button. "
>Only to you; Ford doesn't try to lock its customer out of the car.
>
>Bottom line: keys are bad because historically they have caused problems for 
>legitimate users, often problems that the vendor had promised wouldn't occur.
>
>--
>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: Saturday, March 3, 2018 1:22 AM
>To: IBM-MAIN@listserv.ua.edu
>Subject: Re: Product license key program
>
>Hi Shmuel,  this is just a friendly discussion, and I know I tend to have a 
>odd sense of humor sometimes, so please don't take any of what I mean as 
>levity as something personal.  I really am trying to understand your point.  
>If you can convince me that there is some inherent danger in using keys, then 
>I will address the problem and see about coming up with something that removes 
>the danger but still provides protection for the vendor.  Just because vendors 
>have used keys for years (and years) doesn't make it right, nor does it make 
>it wrong, that's why I'm trying to understand your side of this.  I  think I'm 
>fairly smart, and if I had to come up with a substitute for keys, I could 
>probably do it, but I'm sure you understand that I don't want to waste time on 
>something that might be unnecessary.
>
>I have heard people complain from time to time about keys, but normally it's 
>because of something not related to the keys themselves like it was 
>"inconvenient" to get their purchasing department to send the check on time.  
>That stuff happens, but it's not the fault of the keys, and in fact, sadly it 
>tends to make vendors feel better about having the key there in the first 
>place because it's the "reminder" to the client to "pay their bills" on time.  
>I'm sure you can understand that vendors deal with that event all the time, 
>and it's sad to say, but like your local plumber, we/they have "heard it all 
>before".  Sometimes giving the extra 30 days and allowing the client to get a 
>temporary 14 day key after that still isn't enough, and we, (as do most other 
>vendors) have procedures to extend it even more, but at some point you have to 
>be able to "draw the line".
>
>Is that ins some way unreasonable?  If so, why?
>
>Now to the meat of things:
>
>You said "Are you willing to put an indemnification clause in your 
>contracts?".  To indemnify for or from what exactly?
>
>One point on indemnification,and contracts in general, is if both parties of a 
>are not contract equally, or more to the point equitably,  or no "special" 
>compensation for that inequality is clearly defined (this is simple contract 
>law, and yes, unfortunately I do have a law degree and my son is a practicing 
>lawyer), then the clause is invalid, thus, if the site wants to be 
>indemnified, they would have to likewise indemnify the vendor or provide some 
>"special" compensation for that accommodation.  The "special" compensation is 
>not just the "price of the product", so don't say they are "(over) compensated 
>already, so that's the compensation part":).  For instance, (and this event 
>has happened many times to many vendors), if a site were to allow (through 
>their actions or even due to no "action" at all), the vendor's software to be 
>used at another site, even an "alternate" site of their own (but that's 
>getting off the point), and "anything" is "damaged" or "damages" are incurred, 
>including loss of revenue for the vendor (because of the theft of the 
>software), then the site would have to accept full responsibility.
>
>I can't think of any site that would ever agree to that.  Likewise, expecting 
>any vendor to agree to indemnify a site for unforeseen and unspecified 
>damage(s), is never going to be able to be enforceable.  Any unenforceable 
>part of a contract is (by simple definition) not enforceable and therefore 
>invalid.
>
>Why place a clause into a contract that has no chance at all of being 
>enforceable?  it cheapens the contract and the ability of e

Re: Product license key program

[zMan]

I like it. CA should include those.

On Sun, Mar 4, 2018 at 8:36 PM, Paul Gilmartin (π) <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Sun, Mar 04, 2018 at 07:54:25PM -0500, zMan wrote:
> > Like the story a friend tells of working at CIA and having CA-Top Secret,
> > having to explain to an auditor why there were books labeled "TOP SECRET"
> > sitting out on a bookshelf, instead of being stored in a safe!
> >
> That could be solved with a pad of stickers bearing the word "NOT".
>
> -- gil
>
> --
> 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

Re: Product license key program

[π]

On Sun, Mar 04, 2018 at 07:54:25PM -0500, zMan wrote:
> Like the story a friend tells of working at CIA and having CA-Top Secret,
> having to explain to an auditor why there were books labeled "TOP SECRET"
> sitting out on a bookshelf, instead of being stored in a safe!
> 
That could be solved with a pad of stickers bearing the word "NOT".

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Product license key program

[zMan]

Like the story a friend tells of working at CIA and having CA-Top Secret,
having to explain to an auditor why there were books labeled "TOP SECRET"
sitting out on a bookshelf, instead of being stored in a safe!

On Sun, Mar 4, 2018 at 7:30 PM, Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Sun, 4 Mar 2018 20:40:41 +, Seymour J Metz wrote:
>
> >My boss on the government side would pull tapes and tell key people that
> they were dead, then have everyone else continue the test without the
> pulled tapes or "dead" personnel.  That made for a much more reasonable
> test, since in a real disaster bad things happen.
> >
> A beta site of one of our products disabled the volume containing our load
> library
> then issued a shutdown command.  Crashed.  Some shutdown code was
> transient.
> We fixed it.
>
> And an early version signed on with a message on the Operators' console,
> "SECRET;
> property of [vendor]; all rights reserved."  Or something lawyers thought
> we should
> say.  We quickly learned there are some sites where operators are not
> allowed to
> routinely dismiss a message containing the S-word.
>
> -- gil
>
> --
> 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

Re: Product license key program

[Paul Gilmartin]

On Sun, 4 Mar 2018 20:40:41 +, Seymour J Metz wrote:

>My boss on the government side would pull tapes and tell key people that they 
>were dead, then have everyone else continue the test without the pulled tapes 
>or "dead" personnel.  That made for a much more reasonable test, since in a 
>real disaster bad things happen.
> 
A beta site of one of our products disabled the volume containing our load 
library
then issued a shutdown command.  Crashed.  Some shutdown code was transient.
We fixed it.

And an early version signed on with a message on the Operators' console, 
"SECRET;
property of [vendor]; all rights reserved."  Or something lawyers thought we 
should
say.  We quickly learned there are some sites where operators are not allowed to
routinely dismiss a message containing the S-word.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Product license key program

[Charles Mills]

> would be similar (maybe only to me) as Ford sending out all of their cars
without
> an ignition key or secure button. "
>Only to you; Ford doesn't try to lock its customer out of the car.

How about similar to a movie theatre that did not check tickets?

> keys are bad because historically they have caused problems for legitimate
users

Ditto PDSE, virtual storage, and computers in general.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Seymour J Metz
Sent: Sunday, March 4, 2018 11:56 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Product license key program

...
would be similar (maybe only to me) as Ford sending out all of their
cars without
 an ignition key or secure button. "
Only to you; Ford doesn't try to lock its customer out of the car.

Bottom line: keys are bad because historically they have caused problems for
legitimate users, often problems that the vendor had promised wouldn't
occur.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Product license key program

[Seymour J Metz]

My boss on the government side would pull tapes and tell key people that they 
were dead, then have everyone else continue the test without the pulled tapes 
or "dead" personnel.  That made for a much more reasonable test, since in a 
real disaster bad things happen.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List <IBM-MAIN@listserv.ua.edu> on behalf of 
Wayne Bickerdike <wayn...@gmail.com>
Sent: Sunday, March 4, 2018 3:25 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: Product license key program

We always have issues during DR with licence keys.

Worst vendor is Compuware, convoluted process and activation procedure.

We like to expose "novice" users to the DR process, it's a test of
documentation and process, not systems skills.

One vendor had the cheek to tell us to give more warning. I told them we
are testing you as much as DR.

Don't mind CA, they don't disable just give warnings.

On Mon, Mar 5, 2018 at 6:55 AM, Seymour J Metz <sme...@gmu.edu> wrote:

>  1. BTDT,GTS - I'm not talking ideology or abstract theory, but history.
> Vendor promises are worthless when push comes to shove.
>
>  2. In the incidents I was referring to we *did* get the keys in advance;
> they didn't work and the vendor failed to respond within the
> contractually
> guarantied time window. That's why I asked about how you handled
> DR tests.
>
>  3. I'm not concerned with the customer who has delayed renewing, I'm
> concerned with the customer who is fully paid up and doesn't get what
> he paid for.
>
>  4. "To indemnify for or from what exactly?" The cost of the DR facilities
> that could be
> tested because of the bad keys would have been a start.
>
>  5. "what associated risk?  The risk that they will not pay their license
> fee and therefore
>  lose the use of the software?"
>
> More straw dummies. Stop trying to put words in my mouth.
>
>  6. "you are assuming that the Key or the requirement thereof will
> somehow, through the
>  fault of the "key", cause an outage. ".
>
> No, *you* are assuming that I don't have empirical evidence. See item
> 2 above.
>
>  7. "4) What about it?  They paid for the key, it's implemented, and it
> works."
> Were that true I wouldn't have commented. We paid for the keys, it was
> implemented
> and it *didn't* work.
>
>  8. "and not a generation issue or some other purely human factor?"
> From the customer perspective the vendor is a black box; he doesn't
> care whether the outage cased by the vendor was due to hardware,
> software or human error.
>
>  9. "I don't think most vendors try to tell the client what metrics to use
> in
>  evaluation (aside from CA maybe:))"
>
> CA never had the nerve to patronizingly dismiss our concerns. They
> accepted
> them as legitimate and addressed them as best they could.
>
> 10. "6) What danger inherent in the enforcement method? "
> See item 2 above.
>
> 11. "The key works or it doesn't, if it doesn't, either it expired, the
> software has been altered or changed or it never worked in the first
> place. "
> How do you propose that the customer tests whether a DR key works prior
> to going to the DR site and testing?
>
> 12. " I really don't mean to sound flippant, but sending software out
> without keys
> would be similar (maybe only to me) as Ford sending out all of their
> cars without
>  an ignition key or secure button. "
> Only to you; Ford doesn't try to lock its customer out of the car.
>
> Bottom line: keys are bad because historically they have caused problems
> for legitimate users, often problems that the vendor had promised wouldn't
> occur.
>
> --
> 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: Saturday, March 3, 2018 1:22 AM
> To: IBM-MAIN@listserv.ua.edu
> Subject: Re: Product license key program
>
> Hi Shmuel,  this is just a friendly discussion, and I know I tend to have
> a odd sense of humor sometimes, so please don't take any of what I mean as
> levity as something personal.  I really am trying to understand your
> point.  If you can convince me that there is some inherent danger in using
> keys, then I will address the problem and see about coming up with
> something that removes the danger but still provides protection for the
> vendor.  Just because ven

Re: Product license key program

[Wayne Bickerdike]

We always have issues during DR with licence keys.

Worst vendor is Compuware, convoluted process and activation procedure.

We like to expose "novice" users to the DR process, it's a test of
documentation and process, not systems skills.

One vendor had the cheek to tell us to give more warning. I told them we
are testing you as much as DR.

Don't mind CA, they don't disable just give warnings.

On Mon, Mar 5, 2018 at 6:55 AM, Seymour J Metz <sme...@gmu.edu> wrote:

>  1. BTDT,GTS - I'm not talking ideology or abstract theory, but history.
> Vendor promises are worthless when push comes to shove.
>
>  2. In the incidents I was referring to we *did* get the keys in advance;
> they didn't work and the vendor failed to respond within the
> contractually
> guarantied time window. That's why I asked about how you handled
> DR tests.
>
>  3. I'm not concerned with the customer who has delayed renewing, I'm
> concerned with the customer who is fully paid up and doesn't get what
> he paid for.
>
>  4. "To indemnify for or from what exactly?" The cost of the DR facilities
> that could be
> tested because of the bad keys would have been a start.
>
>  5. "what associated risk?  The risk that they will not pay their license
> fee and therefore
>  lose the use of the software?"
>
> More straw dummies. Stop trying to put words in my mouth.
>
>  6. "you are assuming that the Key or the requirement thereof will
> somehow, through the
>  fault of the "key", cause an outage. ".
>
> No, *you* are assuming that I don't have empirical evidence. See item
> 2 above.
>
>  7. "4) What about it?  They paid for the key, it's implemented, and it
> works."
> Were that true I wouldn't have commented. We paid for the keys, it was
> implemented
> and it *didn't* work.
>
>  8. "and not a generation issue or some other purely human factor?"
> From the customer perspective the vendor is a black box; he doesn't
> care whether the outage cased by the vendor was due to hardware,
> software or human error.
>
>  9. "I don't think most vendors try to tell the client what metrics to use
> in
>  evaluation (aside from CA maybe:))"
>
> CA never had the nerve to patronizingly dismiss our concerns. They
> accepted
> them as legitimate and addressed them as best they could.
>
> 10. "6) What danger inherent in the enforcement method? "
> See item 2 above.
>
> 11. "The key works or it doesn't, if it doesn't, either it expired, the
> software has been altered or changed or it never worked in the first
> place. "
> How do you propose that the customer tests whether a DR key works prior
> to going to the DR site and testing?
>
> 12. " I really don't mean to sound flippant, but sending software out
> without keys
> would be similar (maybe only to me) as Ford sending out all of their
> cars without
>  an ignition key or secure button. "
> Only to you; Ford doesn't try to lock its customer out of the car.
>
> Bottom line: keys are bad because historically they have caused problems
> for legitimate users, often problems that the vendor had promised wouldn't
> occur.
>
> --
> 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: Saturday, March 3, 2018 1:22 AM
> To: IBM-MAIN@listserv.ua.edu
> Subject: Re: Product license key program
>
> Hi Shmuel,  this is just a friendly discussion, and I know I tend to have
> a odd sense of humor sometimes, so please don't take any of what I mean as
> levity as something personal.  I really am trying to understand your
> point.  If you can convince me that there is some inherent danger in using
> keys, then I will address the problem and see about coming up with
> something that removes the danger but still provides protection for the
> vendor.  Just because vendors have used keys for years (and years) doesn't
> make it right, nor does it make it wrong, that's why I'm trying to
> understand your side of this.  I  think I'm fairly smart, and if I had to
> come up with a substitute for keys, I could probably do it, but I'm sure
> you understand that I don't want to waste time on something that might be
> unnecessary.
>
> I have heard people complain from time to time about keys, but normally
> it's because of something not related to the keys themselves like it was
> "inconvenient" to get their purchasing department to s

Re: Product license key program

[Seymour J Metz]

 1. BTDT,GTS - I'm not talking ideology or abstract theory, but history. 
Vendor promises are worthless when push comes to shove.

 2. In the incidents I was referring to we *did* get the keys in advance;
they didn't work and the vendor failed to respond within the contractually
guarantied time window. That's why I asked about how you handled
DR tests.

 3. I'm not concerned with the customer who has delayed renewing, I'm
concerned with the customer who is fully paid up and doesn't get what he 
paid for.

 4. "To indemnify for or from what exactly?" The cost of the DR facilities that 
could be
tested because of the bad keys would have been a start.

 5. "what associated risk?  The risk that they will not pay their license fee 
and therefore
 lose the use of the software?"

More straw dummies. Stop trying to put words in my mouth.

 6. "you are assuming that the Key or the requirement thereof will somehow, 
through the
 fault of the "key", cause an outage. ".

No, *you* are assuming that I don't have empirical evidence. See item 2 
above.

 7. "4) What about it?  They paid for the key, it's implemented, and it works."
Were that true I wouldn't have commented. We paid for the keys, it was 
implemented
and it *didn't* work.

 8. "and not a generation issue or some other purely human factor?"
From the customer perspective the vendor is a black box; he doesn't
care whether the outage cased by the vendor was due to hardware,
software or human error.

 9. "I don't think most vendors try to tell the client what metrics to use in
 evaluation (aside from CA maybe:))"

CA never had the nerve to patronizingly dismiss our concerns. They accepted
them as legitimate and addressed them as best they could.

10. "6) What danger inherent in the enforcement method? "
See item 2 above.

11. "The key works or it doesn't, if it doesn't, either it expired, the
software has been altered or changed or it never worked in the first place. 
"
How do you propose that the customer tests whether a DR key works prior 
to going to the DR site and testing?

12. " I really don't mean to sound flippant, but sending software out without 
keys 
would be similar (maybe only to me) as Ford sending out all of their cars 
without
 an ignition key or secure button. "
Only to you; Ford doesn't try to lock its customer out of the car.

Bottom line: keys are bad because historically they have caused problems for 
legitimate users, often problems that the vendor had promised wouldn't occur.

--
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: Saturday, March 3, 2018 1:22 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: Product license key program

Hi Shmuel,  this is just a friendly discussion, and I know I tend to have a odd 
sense of humor sometimes, so please don't take any of what I mean as levity as 
something personal.  I really am trying to understand your point.  If you can 
convince me that there is some inherent danger in using keys, then I will 
address the problem and see about coming up with something that removes the 
danger but still provides protection for the vendor.  Just because vendors have 
used keys for years (and years) doesn't make it right, nor does it make it 
wrong, that's why I'm trying to understand your side of this.  I  think I'm 
fairly smart, and if I had to come up with a substitute for keys, I could 
probably do it, but I'm sure you understand that I don't want to waste time on 
something that might be unnecessary.

I have heard people complain from time to time about keys, but normally it's 
because of something not related to the keys themselves like it was 
"inconvenient" to get their purchasing department to send the check on time.  
That stuff happens, but it's not the fault of the keys, and in fact, sadly it 
tends to make vendors feel better about having the key there in the first place 
because it's the "reminder" to the client to "pay their bills" on time.  I'm 
sure you can understand that vendors deal with that event all the time, and 
it's sad to say, but like your local plumber, we/they have "heard it all 
before".  Sometimes giving the extra 30 days and allowing the client to get a 
temporary 14 day key after that still isn't enough, and we, (as do most other 
vendors) have procedures to extend it even more, but at some point you have to 
be able to "draw the line".

Is that ins some way unreasonable?  If so, why?

Now to the meat of things:

You said "Are you willing to put an indemnification clause in your contracts?". 
 To indemnify for or from what exactl

Re: Product license key program

[Brian Westerman]

o a 
> customer who
>has paid the fee.
>
> 5. No, our difference is that I believe that the customer has no obligation 
> to play
>Russian Roulette.
>
> 6. The issue isn't the rules, it's the danger inherent in the enforcement 
> method.
>
>" If you can do it without losing your temper or being condescending"
>
>PKB. Don't misrepresent my position if you want me to be polite.
>
>"or if you want to be sarcastic "
>
>PKB. If you don't want sarcastic responses, then don't make sarcastic posts.
>
>"and/or virulent "
>
>There's nothing wrong with refusing to buy a product that doesn't suit my 
>needs. You get to set whatever rules you want for the use of your software, 
>provided that you disclose them up front, but you don't get to tell the 
>customer what metrics to use in evaluating his requirements. 
>
>"because I still really do want to try to understand your points."
>
>Then pay attention when I write that keys impose a risk on the customer, and 
>that the customer gets to decide how significant that risk is. Are you willing 
>to put an indemnification clause in your contracts?
>
>
>--
>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, February 28, 2018 1:51 AM
>To: IBM-MAIN@listserv.ua.edu
>Subject: Re: Product license key program
>
>You lost me Shmuel,
>
>I don't think I misrepresented the people who object to keys, at least not on 
>purpose.  I don't understand the straw dummy reference and I honestly don't 
>understand the objection to a vendor using keys for their product(s).
>
>What collateral damage is cause by a vendor's use of keys in their software?  
>The keys are there to "lock" the software to the system it was licensed for.  
>If the software is moved, or used in other creative means without permission 
>from the vendor (who we must remember, owns the software), then it 
>(theoretically) won't work on that "other" platform.  I guess I'm missing the 
>damage part of that.  Do you mean disaster recovery keys?  I think every 
>vendor has that covered by now, but maybe they don't, and again, it's their 
>software, if they don't want to allow that use, and they let you know up 
>front, then whats the damage?
>
>There are many parts (I guess types of keys makes more sense) of vendors keys 
>that I don't agree with, and I don't personally think that software in and of 
>itself should cost more for one processor than another, regardless of 
>processor size, but that's just my personal feeling.  If a vendor wishes to 
>price their software that way, then it's completely their decision.
>
>Possibly our difference of opinion is because I see the vendor's product as 
>belonging to the vendor, not unlike my "locking your car or house" analogy.  
>It's not like the vendor is locking other software, just their own.  At least 
>I hope so.  If the vendor wants to lock their software so that it isn't 
>"misused", (and specifying what "misused" means is 100% the software vendor's 
>decision).  Then, as they "own" the software, it's up to them to say what 
>those rules are.  They need to be up front on the rules, even if they are 
>unreasonable rules, otherwise the contract for the software would be invalid 
>anyway under the "meeting of the minds" concept of contract law.
>
>If a site "purchased" the software instead of licensed (or rented) it, then I 
>believe you are 100% correct that the software vendor loses the right to lock 
>it up.  I don't think many vendors sell their software that way though, it 
>would not be cost effective for either party.
>
>So, I really do want you to educate me on this.  If you can do it without 
>losing your temper or being condescending, then I would like to do it here, 
>publicly, so that others can understand as well.
>
>On the other hand, if you can't discuss it calmly, or if you want to be 
>sarcastic and/or virulent about it, then feel free to send me the discussion 
>points offline, because I still really do want to try to understand your 
>points.
>
>Sincerely,
>
>Brian
>
>
>
>
>On Tue, 27 Feb 2018 21:44:45 +, Seymour J Metz <sme...@gmu.edu> wrote:
>
>>You can, and did, misrepresent the position of those who object to license 
>>keys. The issue isn't protecting the  software; the issue is the means used 
>>to do so and the collateral damage from those means.
>>
>>If you have someone willing to steal y

Re: Product license key program

[Gord Tomlin]

On 2018-03-01 16:40, Seymour J Metz wrote:

What happens when the customer is running at a DR site? What happens when the 
customer needs to do testing with a date beyond the coverage of the license 
key? BTDT,GTS (no, the company was not Action Software International).


In both cases, the appropriate thing for the customer to do would be to 
contact the vendor, preferably in advance, and in both cases the vendor 
should exercise reasonable judgement.


I'm jealous of your t-shirt collection. ;)

--

Regards, Gord Tomlin
Action Software International
(a division of Mazda Computer Corporation)
Tel: (905) 470-7113, Fax: (905) 470-6507
Support: https://actionsoftware.com/support/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Product license key program

[Seymour J Metz]

 1. The people who object to keys do so because of the associated risk.

2.  'You can't over simplify the issue and decide categorically that all vendors
 that want to "protect" their software are bad. ' implies that somebody has 
made
such a claim; that's the straw dummy in question.

 3. The collateral damage is the inability to use the software that they are 
paying for 
and the outage to everything dependent on that software.

 4. The issue is not the licensing terms; the issue is what happens to a 
customer who
has paid the fee.

 5. No, our difference is that I believe that the customer has no obligation to 
play
Russian Roulette.

 6. The issue isn't the rules, it's the danger inherent in the enforcement 
method.

" If you can do it without losing your temper or being condescending"

PKB. Don't misrepresent my position if you want me to be polite.

"or if you want to be sarcastic "

PKB. If you don't want sarcastic responses, then don't make sarcastic posts.

"and/or virulent "

There's nothing wrong with refusing to buy a product that doesn't suit my 
needs. You get to set whatever rules you want for the use of your software, 
provided that you disclose them up front, but you don't get to tell the 
customer what metrics to use in evaluating his requirements. 

"because I still really do want to try to understand your points."

Then pay attention when I write that keys impose a risk on the customer, and 
that the customer gets to decide how significant that risk is. Are you willing 
to put an indemnification clause in your contracts?


--
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, February 28, 2018 1:51 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: Product license key program

You lost me Shmuel,

I don't think I misrepresented the people who object to keys, at least not on 
purpose.  I don't understand the straw dummy reference and I honestly don't 
understand the objection to a vendor using keys for their product(s).

What collateral damage is cause by a vendor's use of keys in their software?  
The keys are there to "lock" the software to the system it was licensed for.  
If the software is moved, or used in other creative means without permission 
from the vendor (who we must remember, owns the software), then it 
(theoretically) won't work on that "other" platform.  I guess I'm missing the 
damage part of that.  Do you mean disaster recovery keys?  I think every vendor 
has that covered by now, but maybe they don't, and again, it's their software, 
if they don't want to allow that use, and they let you know up front, then 
whats the damage?

There are many parts (I guess types of keys makes more sense) of vendors keys 
that I don't agree with, and I don't personally think that software in and of 
itself should cost more for one processor than another, regardless of processor 
size, but that's just my personal feeling.  If a vendor wishes to price their 
software that way, then it's completely their decision.

Possibly our difference of opinion is because I see the vendor's product as 
belonging to the vendor, not unlike my "locking your car or house" analogy.  
It's not like the vendor is locking other software, just their own.  At least I 
hope so.  If the vendor wants to lock their software so that it isn't 
"misused", (and specifying what "misused" means is 100% the software vendor's 
decision).  Then, as they "own" the software, it's up to them to say what those 
rules are.  They need to be up front on the rules, even if they are 
unreasonable rules, otherwise the contract for the software would be invalid 
anyway under the "meeting of the minds" concept of contract law.

If a site "purchased" the software instead of licensed (or rented) it, then I 
believe you are 100% correct that the software vendor loses the right to lock 
it up.  I don't think many vendors sell their software that way though, it 
would not be cost effective for either party.

So, I really do want you to educate me on this.  If you can do it without 
losing your temper or being condescending, then I would like to do it here, 
publicly, so that others can understand as well.

On the other hand, if you can't discuss it calmly, or if you want to be 
sarcastic and/or virulent about it, then feel free to send me the discussion 
points offline, because I still really do want to try to understand your points.

Sincerely,

Brian




On Tue, 27 Feb 2018 21:44:45 +, Seymour J Metz <sme...@gmu.edu> wrote:

>You can, and did, misrepresent the position of those who object to license 
>keys. The issue isn't protecting the  software; the issue is the means used to 
>

Re: Product license key program

[Seymour J Metz]

What happens when the customer is running at a DR site? What happens when the 
customer needs to do testing with a date beyond the coverage of the license 
key? BTDT,GTS (no, the company was not Action Software International).


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List <IBM-MAIN@listserv.ua.edu> on behalf of 
Gord Tomlin <gt.ibm.li...@actionsoftware.com>
Sent: Wednesday, February 28, 2018 9:49 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: Product license key program

On 2018-02-28 01:51, Brian Westerman wrote:
> This is exactly the reason we decided that our software would always be sent 
> with the keys for that particular site embedded into the software, there are 
> no separate steps necessary to install the keys.  It actually provides us 
> with another advantage in that when it's time to update the software (or just 
> the keys) we ship them their new software with the new keys with all current 
> maintenance already applied.  That way we don't end up with trying to support 
> 10 (or 20) years of different versions of the products.  It's more work for 
> us on the one end, but a lot less to maintain overall.

This is exactly what we do. No actions required by the customer.

A couple of key considerations:

1. What action does a product take when the keys "don't fit"? Does it
shut down? Does it issue license violation messages?

2. If a product shuts down when the license expires or the machine
doesn't match the keys, do the effects reach beyond the product in
question? Does a shutdown of the product stop the customer from
performing production functions?

It's worthwhile for customers of any product to know the answers to
these questions.

--

Regards, Gord Tomlin
Action Software International
(a division of Mazda Computer Corporation)
Tel: (905) 470-7113, Fax: (905) 470-6507
Support: 
https://secure-web.cisco.com/1VeNdmScBawVwEWYYFi2RSJ-2pcYx1LvsFemcVawCCMEYjjQGOSFaNtB4s8XPy9ifRYEnel7o9W6_UAWSumqwSjKjCh-qHybO3kJO069wCgDGFPEYj0mPtb1CaOnua3KO4wd0Pya4J_tPvBZYSEG7Sq-j3euJen-_ywpbdiaw32wZlwpr9_NXIhc0QnxgiwcwqY6fmQnAJZpvFkHBnplRtbsuYwAQYG-EDZy6Tbnf5ityhHQFrSFT-dYvxXQtVB8cXjYmCMPb5fmQU1JVLA37FOzRUdYN4b8xfDDA3UK3aT7BsxUP5qOlkny8eaAgkBQMhI9_wfrzzzMuDTjbEjh2_5QeR8VDzV75dR9SZxybDMkkAVWZQvFoX0y8RngFtkDJ/https%3A%2F%2Factionsoftware.com%2Fsupport%2F

--
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

Re: Product license key program

[Tom Brennan]

For Y2K preparation I remember installing a COBOL source scanning 
program for the application folks.  I thought it was interesting for a 
couple of reasons:


1) It was licensed by the number of source code lines you ran through 
it, and would just stop until you bought more "lines".


2) After reading through the licensing doc, I got the impression the 
vendor spent at least as much time designing and coding their protection 
method as they did on the Y2K scanning portion.


Phil Smith wrote:


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Product license key program

[Phil Smith]

Brian Westerman wrote, in part:
>What collateral damage is cause by a vendor's use of keys in their software?  
>The keys are there to "lock" the software to the system it was licensed for.  
>If the software is moved, or used in other creative means without permission 
>from the vendor (who we must remember, owns the software), then it 
>(theoretically) won't work on that "other" platform.  I guess I'm missing the 
>damage part of that.  Do you mean disaster recovery keys?  I think every 
>vendor has that covered by now, but maybe they don't, and again, it's their 
>software, if they don't want to allow that use, and they let you know up 
>front, then whats the damage?

This is (mostly) a good discussion, despite violating Charles' original plea 
not to have it!

Having spent time carrying the beeper back at Sterling, I'd say that the cost 
is downtime when Stuff Happens. Even well-managed sites would have problems 
that caused 3AM calls for an emergency key.

What I think is important is that, if keys are going to be used, the vendor 
understands that:

1) This is a cost to the vendor: they need to be serious about it, with 
folks available 24x7 to deal with problems. Not "That won't happen". Not 
"Customers should plan ahead". Not "Somebody is usually available". Serious, 
24x7x365+, and the staffers should be compensated for that service-even if it's 
$25/day, just something to make them take it seriously. Otherwise it's too easy 
to say "Oh, heck, I'm going for a run, I'll leave the phone here, what are the 
odds?" and miss a call.

2) CPUIDs (as I still call them, lo these 20+ years later) need to be as 
transparent and bulletproof as possible. One vendor I worked for had license 
files that had to have Unix-style linends. So if a customer was sent one via 
email and it passed through a Windows box, it wouldn't work until they did a 
dos2unix on it. Not hard to do, but when you're trying to get the damned 
software to come up and you just got a new key, you don't think of it: you call 
the vendor back. Dumb, and I couldn't get the Unix-heads to understand it. 
Similarly, the license files should be text, not binary, and ideally should be 
self-checking-that is, the license checker can clearly report a difference 
between "This is a valid license, just not for this system" and "This is not a 
valid license" (and of course "Valid but expired").

3) The license checking should be proactive, and warn well in advance of 
failure. This can be tricky for some products that Just Run with no real UI. 
ObAnecdote: many years ago, a friend was in his data center, glanced at the 
console, and saw " WILL EXPIRE IN 14 DAYS!" He pointed at it 
and said something to the operator that probably started with "What the 
..."; the operator glanced at it and said "Oh, it always says that." Um, 
no, just for the last 16 days, moron... You can't save some folks from 
themselves!

4) The license should be as permissive as possible. One of the ones I 
always liked was the SAS C compiler, which, whenever you compiled something, 
said "This compiler is licensed to ". But it would always run (if 
not expired): it didn't actually check CPUID, just date (so there was a license 
key, and it would expire). The theory was that a company might need to use it 
on the wrong system in an emergency, but no real enterprise would accept it 
reporting another company's name. Obviously that will vary with the product 
type, but for a compiler it felt about right. Critical products should allow 
some form of operation even if expired, if possible, and should accept 
temporary, short-term, universal keys, so when that 3AM call happens, a 24-hour 
key can be provided without relying on the staffer's ability to get through 
firewalls, VPNs, etc. to cut a new one.

Bottom line is that CPUIDs are not that hard to break, if someone wants to. So 
the real effort should be on usability, not on getting super-clever and 
complicated. (Another ObAnecdote: we had a "senior" developer who was having a 
problem. This was a VM product, and the CPUID checking would turn off all 
tracing as part of its operation. Said developer was thus stymied from 
debugging it! I pointed out that (a) it was our code, so worst case, a hacked 
version of the CPUID checker could be used, and (b) it took all of 30 seconds 
to break, especially when you could see how it worked...)

>There are many parts (I guess types of keys makes more sense) of vendors keys 
>that I don't agree with, and I don't personally think that software in and of 
>itself should cost more for one processor than another, regardless of 
>processor size, but that's just my personal feeling.  If a vendor wishes to 
>price their software that way, then it's completely their decision.

Not to get into this aspect of the religious war, but that depends on the 
product. For some, I agree; for others, not so much. Usage is, of course, the 
real metric that makes sense: a tiny DB2 (or "Db2", 

Re: Product license key program

[Gord Tomlin]

On 2018-02-28 01:51, Brian Westerman wrote:

This is exactly the reason we decided that our software would always be sent 
with the keys for that particular site embedded into the software, there are no 
separate steps necessary to install the keys.  It actually provides us with 
another advantage in that when it's time to update the software (or just the 
keys) we ship them their new software with the new keys with all current 
maintenance already applied.  That way we don't end up with trying to support 
10 (or 20) years of different versions of the products.  It's more work for us 
on the one end, but a lot less to maintain overall.


This is exactly what we do. No actions required by the customer.

A couple of key considerations:

1. What action does a product take when the keys "don't fit"? Does it 
shut down? Does it issue license violation messages?


2. If a product shuts down when the license expires or the machine 
doesn't match the keys, do the effects reach beyond the product in 
question? Does a shutdown of the product stop the customer from 
performing production functions?


It's worthwhile for customers of any product to know the answers to 
these questions.


--

Regards, Gord Tomlin
Action Software International
(a division of Mazda Computer Corporation)
Tel: (905) 470-7113, Fax: (905) 470-6507
Support: https://actionsoftware.com/support/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Product license key program

[R.S.]

There are two sides of the coin.
One one side customers violate license conditions intentionally and 
unintentionally.


The other side is legal customers sometimes do have problems with the key.
What's more annoying sometimes key code and expiration dates are use as 
part of "negotiation process"or rather (illegal) pressure.


For example company X sold perpetual license with S defined. Cusomer 
paid license fee and pay S every year. Obvioulsy S covers new 
versions of the software. Company X was bought by company Y which claims 
the fee is simply to small. And they invest in the product a lot 
(disputable). However the customer is still using same functionality and 
same features. However now, suddenly new versions have many limitations 
included in the "licensing module", which narrows the use of the product 
seriously.
Customer want to have what he paid for, but other side have different 
view. So far there's a dispute. STOP! There is no fair dispute when one 
side feel the gun at their heads.


There are more examples of such use of keys as a gun.

--
Radoslaw Skorupka
Lodz, Poland




==


   --
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.plsąd Rejonowy dla m. st. Warszawy XII 
Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców 
KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2018 r. kapitał 
zakładowy mBanku S.A. (w całości wpłacony) wynosi 169.248.488 złotych.
   


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Product license key program

[Brian Westerman]

You lost me Shmuel,

I don't think I misrepresented the people who object to keys, at least not on 
purpose.  I don't understand the straw dummy reference and I honestly don't 
understand the objection to a vendor using keys for their product(s).

What collateral damage is cause by a vendor's use of keys in their software?  
The keys are there to "lock" the software to the system it was licensed for.  
If the software is moved, or used in other creative means without permission 
from the vendor (who we must remember, owns the software), then it 
(theoretically) won't work on that "other" platform.  I guess I'm missing the 
damage part of that.  Do you mean disaster recovery keys?  I think every vendor 
has that covered by now, but maybe they don't, and again, it's their software, 
if they don't want to allow that use, and they let you know up front, then 
whats the damage?

There are many parts (I guess types of keys makes more sense) of vendors keys 
that I don't agree with, and I don't personally think that software in and of 
itself should cost more for one processor than another, regardless of processor 
size, but that's just my personal feeling.  If a vendor wishes to price their 
software that way, then it's completely their decision.  

Possibly our difference of opinion is because I see the vendor's product as 
belonging to the vendor, not unlike my "locking your car or house" analogy.  
It's not like the vendor is locking other software, just their own.  At least I 
hope so.  If the vendor wants to lock their software so that it isn't 
"misused", (and specifying what "misused" means is 100% the software vendor's 
decision).  Then, as they "own" the software, it's up to them to say what those 
rules are.  They need to be up front on the rules, even if they are 
unreasonable rules, otherwise the contract for the software would be invalid 
anyway under the "meeting of the minds" concept of contract law. 

If a site "purchased" the software instead of licensed (or rented) it, then I 
believe you are 100% correct that the software vendor loses the right to lock 
it up.  I don't think many vendors sell their software that way though, it 
would not be cost effective for either party.

So, I really do want you to educate me on this.  If you can do it without 
losing your temper or being condescending, then I would like to do it here, 
publicly, so that others can understand as well.  

On the other hand, if you can't discuss it calmly, or if you want to be 
sarcastic and/or virulent about it, then feel free to send me the discussion 
points offline, because I still really do want to try to understand your points.

Sincerely, 

Brian




On Tue, 27 Feb 2018 21:44:45 +, Seymour J Metz <sme...@gmu.edu> wrote:

>You can, and did, misrepresent the position of those who object to license 
>keys. The issue isn't protecting the  software; the issue is the means used to 
>do so and the collateral damage from those means.
>
>If you have someone willing to steal your product, then he will also be 
>willing to patch it to bypass the license check? Illegal, sure, and I hope 
>that you nail anybody who does so, but still inevitable.
>
>As for support of stolen copies, that's a separate issue from preventing the 
>product from running. Use of keys et al in the support process doesn't have 
>the same potential for collateral damage.
>
>Microsoft? They have a vested interest in lying about their reasons; they want 
>to force bundling, and have been very successful at it.
>
>Of course, after inventing straw dummies and openly being facetious  you ar 
>likely to get sarcastic replies; if you didn't want sarcasm then you should 
>have used honest and polite argument.
>
>--
>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: Monday, February 26, 2018 9:27 PM
>To: IBM-MAIN@listserv.ua.edu
>Subject: Re: Product license key program
>
>If someone violates a copyright, there are legal and I think criminal 
>penalties.  But I doubt the FBI will get involved if you decided not to pay CA 
>for using Panvalet.
>
>You can't over simplify the issue and decide categorically that all vendors 
>that want to "protect" their software are bad.  Just like people, there are 
>indeed some bad vendors, whether or not they have product "protection" doesn't 
>enter into the equation.
>
>How would a vendor even know that someone didn't take a "personal" copy of 
>their unprotected code from site A to site B?  Does that happen, it sure does.
>
>Microsoft did a study several years back on how much time they spent

Re: Product license key program

[Brian Westerman]

This is exactly the reason we decided that our software would always be sent 
with the keys for that particular site embedded into the software, there are no 
separate steps necessary to install the keys.  It actually provides us with 
another advantage in that when it's time to update the software (or just the 
keys) we ship them their new software with the new keys with all current 
maintenance already applied.  That way we don't end up with trying to support 
10 (or 20) years of different versions of the products.  It's more work for us 
on the one end, but a lot less to maintain overall. 

Brian

On Tue, 27 Feb 2018 23:40:17 +, Schuffenhauer, Mark <mschu...@tcfbank.com> 
wrote:

>My thought is simply, license keys make it easier (but not always 100%) to 
>protect the intellectual property that belongs to the owner.  It in most cases 
>prevents the expense of having to resort to investigation and litigation of 
>something.  
>
>I think its great Tony takes the time oo properly account in his example. 
>
> Some people are careless, some are less rigorous, and some people are 
> criminal.  License keys and other items that reduce simplicity in product 
> installation and maintenance are a bit to avoid the first two items, and 
> aimed squarely at the criminals.  
>
>From a non-legal standpoint, but from an impaceed person standpoint, I 
>understand where owners of all intellectual/copyrighted property are coming 
>from.  At times it's a pain below my back, but I get it. 
>
>-Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
>Behalf Of Seymour J Metz
>Sent: Tuesday, February 27, 2018 3:24 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: Product license key program
>
>No. 
>
>hhe relevant difference between copying the sheet music and singing it has 
>nothing to do with the equipment used, but with what that equipment is used to 
>do. Making copies not covered by fair use or license is a violation regardless 
>of the hardware used. The Devil is in the details.
>
>Let's take your copier claim. A copier contains a scanner and a printer.  
>Scanning a song is in a very different category from printing the canned song. 
>If I am licensed to play the song and have software that will play it from the 
>scanned image, that performance is legal.
>
>As to eecording the service, that again is not a question of what equipment 
>you use but of what you use it for. The legal issues are the same whether you 
>make a wire recording, a tape recording or a digital recording.
>
>Maybe you should go back to law school and take a refresher course.
>
>--
>Shmuel (Seymour J.) Metz
>http://mason.gmu.edu/~smetz3
>
>
>From: IBM Mainframe Discussion List <IBM-MAIN@listserv.ua.edu> on behalf of 
>Tony Thigpen <t...@vse2pdf.com>
>Sent: Tuesday, February 27, 2018 2:22 PM
>To: IBM-MAIN@listserv.ua.edu
>Subject: Re: Product license key program
>
>Seymour,
>
>You knowledge of music copyright is incorrect. In many cases it *does* matter 
>what equipment.
>
>I am involved with the copyright issues with songs at our church. I have to 
>account separately for:
>
>1) A pre-printed copy of the song, such as a hymnal
>2) A 'copy' of the song printed locally on a printer or copier
>2) The display of the song on a projector during the service
>
>And, if I record the worship services, I have to account for:
>1) Did the audio recording of our people singing the song get recorded>
>2) Did the video of the service actually capture display of the song by the 
>projector on the screen?
>
>And, as for the recordings,
>1) If I plyy back the audio or video to a assembly, then that is another item 
>to be accounted for.
>2) If I make a DVD and send it to someone outside our congergation, then it 
>has to be accounted for.
>
>Tony Thigpen
>
>Seymour J Metz wrote on022/26/2018 12:48 PM:
>> It's fair when the vendor assumes the risk. It's not fair when the customer 
>> has bee left holding the bag. "product keys are just any other license 
>> enforcement" is not even close. If I license, e.g., a copyrighted song for 
>> use in a movie, it doesn't matter what equipment I use to play the song or 
>> to record it in the movie. The enforcement is via legal proceedings that the 
>> vendor does not invoke capriciously, but only when he has good reason to 
>> believe that I am in violation of the license terms.
>>
>> Software keys, OTOH, can and have caused problems for legitimate users. Some 
>> are more reliable than others, but I see nothing wrong with a shop refusing 
>> to use a product because they are not willing to as

Re: Product license key program

[Paul Gilmartin]

On Tue, 27 Feb 2018 23:59:54 +, Seymour J Metz wrote:

>I understand where the vendors are coming from, but that does not mean that 
>I'm willing to assume a risk for their convenience. Given two products of 
>comparable cost and functionality, I'll always opt for the one without keys, 
>except in the unlikely case of a vendor willing to contractually guaranty 
>indemnification when the key software interferes with legitimate use. Tony 
>seems to be unable to see things from the customer's perspective.
> 
And it's unusual for consequential damages to be covered.  Most probably, the 
supplier
will agree only to waive the license fee for the duration of the outage.

At the most recent change of my employer's ownership, the acquiring company
directed that all licensing paraphernalia be removed from our products.

>
>From: Tony Thigpen
>Sent: Tuesday, February 27, 2018 2:22 PM
>
>You knowledge of music copyright is incorrect. In many cases it *does* matter 
>what equipment.
>
>I am involved with the copyright issues with songs at our church.
> 
It's unlikely that a mishap would result in unavailability.  If  your copy of
the license (analogous to "key") were lost or destroyed, or casualty forced
you to relocate the service, would you redact that service, omitting
licensed material until the vendor could issue a new license?

>Seymour J Metz wrote on 02/26/2018 12:48 PM:
>>
>> Software keys, OTOH, can and have caused problems for legitimate users. Some 
>> are more reliable than others, but I see nothing wrong with a shop refusing 
>> to use a product because they are not willing to assume the risk. If you are 
>> really confident that there is no risk, add an indemnification clause to 
>> your contract and I'll take your confidence seriously. If you don't trust it 
>> enough to have such a clause, why should a potential customer trust it?
>> 
Interesting point.  In its early days, Apple offered only a 90-day warranty,
saying,  "Our products rarely break after more than 90 days, so customers
shouldn't be concerned."

>>> 
>>> From: Charles Mills
>>> Sent: Sunday, February 25, 2018 12:47 PM
>>>
>>> Most customers are honest -- beyond honest to the point of
>>> paranoia -- but a few are not. And honest customers sometimes make
>>> honest mistakes.
>>>
Quite so.  We once neglected to read the fine print which restricted not
which processor was running the software but rather in which county
the programmer's chair was.  We negotiated an amendment.

And a while ago I was astonished to learn in this list of a product that was
licensed not according to which processor ran it, but according to the source
of its input data.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Product license key program

[Charles Mills]

Our product originally did not have "keys." We got beat up by a customer for 
THAT! "How the heck are we supposed to know what LPARs we can run it on if it 
doesn't tell us?"

Don't beat me up -- I'm just repeating what the customer said.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Schuffenhauer, Mark
Sent: Tuesday, February 27, 2018 3:40 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Product license key program

My thought is simply, license keys make it easier (but not always 100%) to 
protect the intellectual property that belongs to the owner.  It in most cases 
prevents the expense of having to resort to investigation and litigation of 
something.  

I think its great Tony takes the time to properly account in his example. 

 Some people are careless, some are less rigorous, and some people are 
criminal.  License keys and other items that reduce simplicity in product 
installation and maintenance are a bit to avoid the first two items, and aimed 
squarely at the criminals.  

>From a non-legal standpoint, but from an impacted person standpoint, I 
>understand where owners of all intellectual/copyrighted property are coming 
>from.  At times it's a pain below my back, but I get it. 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Product license key program

[Seymour J Metz]

I understand where the vendors are coming from, but that does not mean that I'm 
willing to assume a risk for their convenience. Given two products of 
comparable cost and functionality, I'll always opt for the one without keys, 
except in the unlikely case of a vendor willing to contractually guaranty 
indemnification when the key software interferes with legitimate use. Tony 
seems to be unable to see things from the customer's perspective.

I will confess that in my callow youth I did write code to protect my 
intellectual property. The first time that it caused problems for an authorized 
user in an unexpected environment, I saw the error of my ways and didn't do it 
again.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List <IBM-MAIN@listserv.ua.edu> on behalf of 
Schuffenhauer, Mark <mschu...@tcfbank.com>
Sent: Tuesday, February 27, 2018 6:40 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: Product license key program

My thought is simply, license keys make it easier (but not always 100%) to 
protect the intellectual property that belongs to the owner.  It in most cases 
prevents the expense of having to resort to investigation and litigation of 
something.

I think its great Tony takes the time to properly account in his example.

 Some people are careless, some are less rigorous, and some people are 
criminal.  License keys and other items that reduce simplicity in product 
installation and maintenance are a bit to avoid the first two items, and aimed 
squarely at the criminals.

>From a non-legal standpoint, but from an impacted person standpoint, I 
>understand where owners of all intellectual/copyrighted property are coming 
>from.  At times it's a pain below my back, but I get it.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Seymour J Metz
Sent: Tuesday, February 27, 2018 3:24 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Product license key program

No.

The relevant difference between copying the sheet music and singing it has 
nothing to do with the equipment used, but with what that equipment is used to 
do. Making copies not covered by fair use or license is a violation regardless 
of the hardware used. The Devil is in the details.

Let's take your copier claim. A copier contains a scanner and a printer.  
Scanning a song is in a very different category from printing the canned song. 
If I am licensed to play the song and have software that will play it from the 
scanned image, that performance is legal.

As to recording the service, that again is not a question of what equipment you 
use but of what you use it for. The legal issues are the same whether you make 
a wire recording, a tape recording or a digital recording.

Maybe you should go back to law school and take a refresher course.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List <IBM-MAIN@listserv.ua.edu> on behalf of 
Tony Thigpen <t...@vse2pdf.com>
Sent: Tuesday, February 27, 2018 2:22 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: Product license key program

Seymour,

You knowledge of music copyright is incorrect. In many cases it *does* matter 
what equipment.

I am involved with the copyright issues with songs at our church. I have to 
account separately for:

1) A pre-printed copy of the song, such as a hymnal
2) A 'copy' of the song printed locally on a printer or copier
2) The display of the song on a projector during the service

And, if I record the worship services, I have to account for:
1) Did the audio recording of our people singing the song get recorded>
2) Did the video of the service actually capture display of the song by the 
projector on the screen?

And, as for the recordings,
1) If I play back the audio or video to a assembly, then that is another item 
to be accounted for.
2) If I make a DVD and send it to someone outside our congergation, then it has 
to be accounted for.

Tony Thigpen

Seymour J Metz wrote on 02/26/2018 12:48 PM:
> It's fair when the vendor assumes the risk. It's not fair when the customer 
> has bee left holding the bag. "product keys are just any other license 
> enforcement" is not even close. If I license, e.g., a copyrighted song for 
> use in a movie, it doesn't matter what equipment I use to play the song or to 
> record it in the movie. The enforcement is via legal proceedings that the 
> vendor does not invoke capriciously, but only when he has good reason to 
> believe that I am in violation of the license terms.
>
> Software keys, OTOH, can and have caused problems for legitimate users. Some 
> are more reliable than others, but I see nothing wrong with a shop refusing 
> to use a product because they are not willing to assume the risk. If you are 
> really confident

Re: Product license key program

[Schuffenhauer, Mark]

My thought is simply, license keys make it easier (but not always 100%) to 
protect the intellectual property that belongs to the owner.  It in most cases 
prevents the expense of having to resort to investigation and litigation of 
something.  

I think its great Tony takes the time to properly account in his example. 

 Some people are careless, some are less rigorous, and some people are 
criminal.  License keys and other items that reduce simplicity in product 
installation and maintenance are a bit to avoid the first two items, and aimed 
squarely at the criminals.  

From a non-legal standpoint, but from an impacted person standpoint, I 
understand where owners of all intellectual/copyrighted property are coming 
from.  At times it's a pain below my back, but I get it. 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Seymour J Metz
Sent: Tuesday, February 27, 2018 3:24 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Product license key program

No. 

The relevant difference between copying the sheet music and singing it has 
nothing to do with the equipment used, but with what that equipment is used to 
do. Making copies not covered by fair use or license is a violation regardless 
of the hardware used. The Devil is in the details.

Let's take your copier claim. A copier contains a scanner and a printer.  
Scanning a song is in a very different category from printing the canned song. 
If I am licensed to play the song and have software that will play it from the 
scanned image, that performance is legal.

As to recording the service, that again is not a question of what equipment you 
use but of what you use it for. The legal issues are the same whether you make 
a wire recording, a tape recording or a digital recording.

Maybe you should go back to law school and take a refresher course.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List <IBM-MAIN@listserv.ua.edu> on behalf of 
Tony Thigpen <t...@vse2pdf.com>
Sent: Tuesday, February 27, 2018 2:22 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: Product license key program

Seymour,

You knowledge of music copyright is incorrect. In many cases it *does* matter 
what equipment.

I am involved with the copyright issues with songs at our church. I have to 
account separately for:

1) A pre-printed copy of the song, such as a hymnal
2) A 'copy' of the song printed locally on a printer or copier
2) The display of the song on a projector during the service

And, if I record the worship services, I have to account for:
1) Did the audio recording of our people singing the song get recorded>
2) Did the video of the service actually capture display of the song by the 
projector on the screen?

And, as for the recordings,
1) If I play back the audio or video to a assembly, then that is another item 
to be accounted for.
2) If I make a DVD and send it to someone outside our congergation, then it has 
to be accounted for.

Tony Thigpen

Seymour J Metz wrote on 02/26/2018 12:48 PM:
> It's fair when the vendor assumes the risk. It's not fair when the customer 
> has bee left holding the bag. "product keys are just any other license 
> enforcement" is not even close. If I license, e.g., a copyrighted song for 
> use in a movie, it doesn't matter what equipment I use to play the song or to 
> record it in the movie. The enforcement is via legal proceedings that the 
> vendor does not invoke capriciously, but only when he has good reason to 
> believe that I am in violation of the license terms.
>
> Software keys, OTOH, can and have caused problems for legitimate users. Some 
> are more reliable than others, but I see nothing wrong with a shop refusing 
> to use a product because they are not willing to assume the risk. If you are 
> really confident that there is no risk, add an indemnification clause to your 
> contract and I'll take your confidence seriously. If you don't trust it 
> enough to have such a clause, why should a potential customer trust it?
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List <IBM-MAIN@listserv.ua.edu> on 
> behalf of ITschak Mugzach <imugz...@gmail.com>
> Sent: Monday, February 26, 2018 12:37 PM
> To: IBM-MAIN@listserv.ua.edu
> Subject: Re: Product license key program
>
> Shmuel,
>
> Vendors are busy in developing products, not in tracing/tracking their 
> clients. product keys are just any other license enforcement (eg.
> electricity, water and any product that you pay per use. Capacity is 
> just another way to limit q measure usage. Sound fair to me.
>
> ITschak
>
> On Mon, Feb 26, 2018 at 7:11 PM, Seymour J Metz <sme...@gmu.edu> wr

Re: Product license key program

[Charles Mills]

And many years ago (~1997?), there was some movement to get multiple vendors 
onto the same page. It fell apart due to anti-trust considerations. If CA and 
BMC and Compuware all got together and licensed their software "the same way" 
it would be a combination in restraint of trade. Anti-trust law sees it as a 
benefit if customers have choices. As we know from many fields -- have you 
re-evaluated how you purchase TV programming recently? -- too many choices is 
often a problem of its own.

Your supposition is amusing but employee mobility is probably a more likely 
explanation. "And then we issue a STCKF in the exit routine" just does not make 
for very romantic pillow talk. IMHO. Your mileage may vary.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson
Sent: Tuesday, February 27, 2018 2:18 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Product license key program

There's the rub. No two vendors manage keys the same way. This creates a 
micro-specialty in every shop for every vendor. Maybe more than one if 
different products are managed differently. 

If you should find the same technology inhabiting two vendor's suites, you can 
be sure that someone's spouse has been diddling someone else's spouse. Pillow 
talk. 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Product license key program

[Jesse 1 Robinson]

There's the rub. No two vendors manage keys the same way. This creates a 
micro-specialty in every shop for every vendor. Maybe more than one if 
different products are managed differently. 

If you should find the same technology inhabiting two vendor's suites, you can 
be sure that someone's spouse has been diddling someone else's spouse. Pillow 
talk. 

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: Tuesday, February 27, 2018 1:03 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Product license key program

> And please, let's not start the whole "to key or not to key" 
> discussion again

I tried. :-(

The OP's question was not "are software keys popular, a good idea, or fair?" 
The OP's question was about technology.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: Sunday, February 25, 2018 9:47 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Product license key program

As the author of such software, let me confirm what others have said: each 
vendor does things its own way -- or perhaps not at all. CA has a central 
"server" program for administering licenses; the software I am responsible for 
has the licensing embedded in the program itself.

The exact technology is proprietary and a trade secret. To say "we do X and Y 
and Z" would be to facilitate its defeat by a dishonest customer.

[And please, let's not start the whole "to key or not to key" discussion again. 
Vendor keys are a fact of life. Yes, they can be a PITA. Most customers are 
honest -- beyond honest to the point of paranoia -- but a few are not. And 
honest customers sometimes make honest mistakes.]

--
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

Re: Product license key program

[Seymour J Metz]

You can, and did, misrepresent the position of those who object to license 
keys. The issue isn't protecting the  software; the issue is the means used to 
do so and the collateral damage from those means.

If you have someone willing to steal your product, then he will also be willing 
to patch it to bypass the license check? Illegal, sure, and I hope that you 
nail anybody who does so, but still inevitable.

As for support of stolen copies, that's a separate issue from preventing the 
product from running. Use of keys et al in the support process doesn't have the 
same potential for collateral damage.

Microsoft? They have a vested interest in lying about their reasons; they want 
to force bundling, and have been very successful at it.

Of course, after inventing straw dummies and openly being facetious  you ar 
likely to get sarcastic replies; if you didn't want sarcasm then you should 
have used honest and polite argument.

--
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: Monday, February 26, 2018 9:27 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: Product license key program

If someone violates a copyright, there are legal and I think criminal 
penalties.  But I doubt the FBI will get involved if you decided not to pay CA 
for using Panvalet.

You can't over simplify the issue and decide categorically that all vendors 
that want to "protect" their software are bad.  Just like people, there are 
indeed some bad vendors, whether or not they have product "protection" doesn't 
enter into the equation.

How would a vendor even know that someone didn't take a "personal" copy of 
their unprotected code from site A to site B?  Does that happen, it sure does.

Microsoft did a study several years back on how much time they spent fixing 
problems and helping people who had pirated copies of their code, and it was 
something on the order of 38%.  That didn't mean that 38% of the people running 
Windows were running pirated copies, just that during their study, 38% of the 
people who called gave pirated copy codes.

They were losing more money on the support of the code for the pirated versions 
than was deemed "acceptable".  The same problem can (and likely is) true for 
other vendors.  Several of our Syzygy products come with parts that are not 
protected by keys or code.  We frequently get calls from people who are not out 
customers to fix (usually the same problem over and over again) problems with 
the unprotected code who are not very happy when we inform them that we can't 
offer them support for the code without them being an actual client, but that 
doesn't stop them from trying.

We had a person, just a few months ago, (who is a member of this list and knows 
who I am talking about), who called with a "problem" for our SyzInfo program 
(it's a small program we send to sites to display their site information, CPU, 
LPAR, SYSPLEX, MEMORY info, etc., a lot of interesting information) because 
they just got a z13 and our code supposedly didn't support it yet.  It worked, 
but didn't give "completely valid" results.  We actually added support for the 
box over 18 months before it came out, so we were fairly perplexed.  When asked 
for his site-ID, he gave it, (it turned out to be one from his old site) and we 
emailed him the new code for his whole product matrix (4 complete products and 
support modules).  Then we received a call from him to tell us that the new 
products would "no longer" operate on his CPU.  When we asked for the CPU type 
and serial, he gave us his old serial from the old shop, so the client support 
people re-verified and sent out a new copy even though there was no real 
changes made.  He told us that it still didn't work so we asked him to execute 
SyzInfo and send a screen print of the results.  Instead of the screen print, 
he "supposedly" cut/pasted the results which showed that the product thought 
exactly what was running was what we shipped.  He escalated the problem (which 
sent it to me), to be resolved, and I asked him to re-execute SyzInfo for the 
screen print and got the same cut/paste thing, but it was different from the 
original one he sent the day before.  The new one had several of the values 
transposed and the CPU was now a EC12 not a z13 as he had originally reported 
having the problem with in the first place.  I called him and got one of his 
co-workers who told me that they were not running our code, and he had no idea 
what I was talking about.  It turned out that they were running a z13 and never 
had a EC12 (they upgraded from a z10 recently).  I explained what had just 
happened and was told that he would talk to his boss and that they would handle 
the "problem".

We never hear

Re: Product license key program

[Seymour J Metz]

No. 

The relevant difference between copying the sheet music and singing it has 
nothing to do with the equipment used, but with what that equipment is used to 
do. Making copies not covered by fair use or license is a violation regardless 
of the hardware used. The Devil is in the details.

Let's take your copier claim. A copier contains a scanner and a printer.  
Scanning a song is in a very different category from printing the canned song. 
If I am licensed to play the song and have software that will play it from the 
scanned image, that performance is legal.

As to recording the service, that again is not a question of what equipment you 
use but of what you use it for. The legal issues are the same whether you make 
a wire recording, a tape recording or a digital recording.

Maybe you should go back to law school and take a refresher course.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List <IBM-MAIN@listserv.ua.edu> on behalf of 
Tony Thigpen <t...@vse2pdf.com>
Sent: Tuesday, February 27, 2018 2:22 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: Product license key program

Seymour,

You knowledge of music copyright is incorrect. In many cases it *does*
matter what equipment.

I am involved with the copyright issues with songs at our church. I have
to account separately for:

1) A pre-printed copy of the song, such as a hymnal
2) A 'copy' of the song printed locally on a printer or copier
2) The display of the song on a projector during the service

And, if I record the worship services, I have to account for:
1) Did the audio recording of our people singing the song get recorded>
2) Did the video of the service actually capture display of the song by
the projector on the screen?

And, as for the recordings,
1) If I play back the audio or video to a assembly, then that is another
item to be accounted for.
2) If I make a DVD and send it to someone outside our congergation, then
it has to be accounted for.

Tony Thigpen

Seymour J Metz wrote on 02/26/2018 12:48 PM:
> It's fair when the vendor assumes the risk. It's not fair when the customer 
> has bee left holding the bag. "product keys are just any other license 
> enforcement" is not even close. If I license, e.g., a copyrighted song for 
> use in a movie, it doesn't matter what equipment I use to play the song or to 
> record it in the movie. The enforcement is via legal proceedings that the 
> vendor does not invoke capriciously, but only when he has good reason to 
> believe that I am in violation of the license terms.
>
> Software keys, OTOH, can and have caused problems for legitimate users. Some 
> are more reliable than others, but I see nothing wrong with a shop refusing 
> to use a product because they are not willing to assume the risk. If you are 
> really confident that there is no risk, add an indemnification clause to your 
> contract and I'll take your confidence seriously. If you don't trust it 
> enough to have such a clause, why should a potential customer trust it?
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List <IBM-MAIN@listserv.ua.edu> on behalf of 
> ITschak Mugzach <imugz...@gmail.com>
> Sent: Monday, February 26, 2018 12:37 PM
> To: IBM-MAIN@listserv.ua.edu
> Subject: Re: Product license key program
>
> Shmuel,
>
> Vendors are busy in developing products, not in tracing/tracking their
> clients. product keys are just any other license enforcement (eg.
> electricity, water and any product that you pay per use. Capacity is just
> another way to limit q measure usage. Sound fair to me.
>
> ITschak
>
> On Mon, Feb 26, 2018 at 7:11 PM, Seymour J Metz <sme...@gmu.edu> wrote:
>
>> And vendors using keys sometimes victimize honest customers. BTDT,GTS.
>>
>> For all of you vendors: it is a fact of life that most vendors have
>> competitors and that some shops will give their money to the vendor that
>> does not treat them like criminals. Of course, if you are willing to sign a
>> contract with big penalty clauses for a malfunctioning key checking routine
>> or key delivery system, that will help to reduce the competitive edge, but
>> I won't hold my breathe.
>>
>>
>> --
>> Shmuel (Seymour J.) Metz
>> http://mason.gmu.edu/~smetz3
>>
>> ________________
>> From: IBM Mainframe Discussion List <IBM-MAIN@listserv.ua.edu> on behalf
>> of Charles Mills <charl...@mcn.org>
>> Sent: Sunday, February 25, 2018 12:47 PM
>> To: IBM-MAIN@listserv.ua.edu
>> Subject: Re: Product license key program
>>
>> As the author of such software, let me 

Re: Product license key program

[Charles Mills]

> And please, let's not start the whole "to key or not to key" discussion again

I tried. :-(

The OP's question was not "are software keys popular, a good idea, or fair?" 
The OP's question was about technology.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: Sunday, February 25, 2018 9:47 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Product license key program

As the author of such software, let me confirm what others have said: each 
vendor does things its own way -- or perhaps not at all. CA has a central 
"server" program for administering licenses; the software I am responsible for 
has the licensing embedded in the program itself.

The exact technology is proprietary and a trade secret. To say "we do X and Y 
and Z" would be to facilitate its defeat by a dishonest customer.

[And please, let's not start the whole "to key or not to key" discussion again. 
Vendor keys are a fact of life. Yes, they can be a PITA. Most customers are 
honest -- beyond honest to the point of paranoia -- but a few are not. And 
honest customers sometimes make honest mistakes.]

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Product license key program

[John McKown]

On Tue, Feb 27, 2018 at 1:22 PM, Tony Thigpen  wrote:

> Seymour,
>
> You knowledge of music copyright is incorrect. In many cases it *does*
> matter what equipment.
>
> I am involved with the copyright issues with songs at our church. I have
> to account separately for:
>
> 1) A pre-printed copy of the song, such as a hymnal
> 2) A 'copy' of the song printed locally on a printer or copier
> 2) The display of the song on a projector during the service
>
> And, if I record the worship services, I have to account for:
> 1) Did the audio recording of our people singing the song get recorded>
> 2) Did the video of the service actually capture display of the song by
> the projector on the screen?
>
> And, as for the recordings,
> 1) If I play back the audio or video to a assembly, then that is another
> item to be accounted for.
> 2) If I make a DVD and send it to someone outside our congergation, then
> it has to be accounted for.
>
> Tony Thigpen
>
>
​You bring up good points. I remember reading in a UK site that a person in
London was charged with copyright infringement for a "unlicensed public
performance" of a song simply by singing it out load as he walked down the
street.


-- 
I have a theory that it's impossible to prove anything, but I can't prove
it.

Maranatha! <><
John McKown

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Product license key program

[Tony Thigpen]

Seymour,

You knowledge of music copyright is incorrect. In many cases it *does* 
matter what equipment.


I am involved with the copyright issues with songs at our church. I have 
to account separately for:


1) A pre-printed copy of the song, such as a hymnal
2) A 'copy' of the song printed locally on a printer or copier
2) The display of the song on a projector during the service

And, if I record the worship services, I have to account for:
1) Did the audio recording of our people singing the song get recorded>
2) Did the video of the service actually capture display of the song by 
the projector on the screen?


And, as for the recordings,
1) If I play back the audio or video to a assembly, then that is another 
item to be accounted for.
2) If I make a DVD and send it to someone outside our congergation, then 
it has to be accounted for.


Tony Thigpen

Seymour J Metz wrote on 02/26/2018 12:48 PM:

It's fair when the vendor assumes the risk. It's not fair when the customer has bee left 
holding the bag. "product keys are just any other license enforcement" is not 
even close. If I license, e.g., a copyrighted song for use in a movie, it doesn't matter 
what equipment I use to play the song or to record it in the movie. The enforcement is 
via legal proceedings that the vendor does not invoke capriciously, but only when he has 
good reason to believe that I am in violation of the license terms.

Software keys, OTOH, can and have caused problems for legitimate users. Some 
are more reliable than others, but I see nothing wrong with a shop refusing to 
use a product because they are not willing to assume the risk. If you are 
really confident that there is no risk, add an indemnification clause to your 
contract and I'll take your confidence seriously. If you don't trust it enough 
to have such a clause, why should a potential customer trust it?


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List <IBM-MAIN@listserv.ua.edu> on behalf of ITschak 
Mugzach <imugz...@gmail.com>
Sent: Monday, February 26, 2018 12:37 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: Product license key program

Shmuel,

Vendors are busy in developing products, not in tracing/tracking their
clients. product keys are just any other license enforcement (eg.
electricity, water and any product that you pay per use. Capacity is just
another way to limit q measure usage. Sound fair to me.

ITschak

On Mon, Feb 26, 2018 at 7:11 PM, Seymour J Metz <sme...@gmu.edu> wrote:


And vendors using keys sometimes victimize honest customers. BTDT,GTS.

For all of you vendors: it is a fact of life that most vendors have
competitors and that some shops will give their money to the vendor that
does not treat them like criminals. Of course, if you are willing to sign a
contract with big penalty clauses for a malfunctioning key checking routine
or key delivery system, that will help to reduce the competitive edge, but
I won't hold my breathe.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List <IBM-MAIN@listserv.ua.edu> on behalf
of Charles Mills <charl...@mcn.org>
Sent: Sunday, February 25, 2018 12:47 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: Product license key program

As the author of such software, let me confirm what others have said: each
vendor does things its own way -- or perhaps not at all. CA has a central
"server" program for administering licenses; the software I am responsible
for has the licensing embedded in the program itself.

The exact technology is proprietary and a trade secret. To say "we do X
and Y and Z" would be to facilitate its defeat by a dishonest customer.

[And please, let's not start the whole "to key or not to key" discussion
again. Vendor keys are a fact of life. Yes, they can be a PITA. Most
customers are honest -- beyond honest to the point of paranoia -- but a few
are not. And honest customers sometimes make honest mistakes.]

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Peter
Sent: Sunday, February 25, 2018 3:55 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Product license key program

Generally which assembler macro or program sets the expiration ?

--
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





--
ITschak Mugzach
*|** IronSphere Platform* *|* *Information Security Contiguous Monitoring
for Legacy **|  *

--

Re: Product license key program

[Brian Westerman]

It was obvious to us, that the "site" was not the one violating things, it was 
Systems Programmer.  We didn't think he had permission from the site to do it, 
and it appeared that they were completely surprised by the event.  Besides, we 
really can't charge them for running code that we give out for free.  The 
SyzInfo code is as much for us as it is for the site.

The real problem was that after client support sent him the whole subset of 
products that his old site had licensed, I believe he was trying to wangle a 
way to get us to provide an alternate key so that they would all work.  Had he 
not been away when I called his office number and his co-worker answered his 
phone, it would have probably worked and we would have wondered what we did 
wrong to make the code not work on his box.  We already had other z13's using 
the code, but we can't go around accusing our clients of making things up just 
because they are the first with a problem.  I'm sure after it was working he 
would have just brushed us off with something like "it's fixed now so don't 
bother me any more".

From a customer support perspective, the client is always right, and we are 
always wrong.  That's just the way it has to be.  I'm sure we would have 
figured it out eventually, but it's hard to deal with a problem when the person 
reporting it is lying.  It's not like I could have called him on it.  

We probably should have billed them for the wasted time, but we were just so 
happy that we didn't have a problem that we were willing to just drop it.  

Looking back on it, we probably should have asked the site to terminate his 
employment, and they might have done that, I don't know.  I like to think that 
there is karma in these sorts of things.

Brian


On Mon, 26 Feb 2018 21:37:27 -0500, zMan  wrote:

>Brian,
>
>Interesting story. I have to ask: given that at that point you had evidence
>that they were running unlicensed code, why not just send them a bill? The
>unspoken "next call will be from our lawyer" might should be convincing, no?
>
>On Mon, Feb 26, 2018 at 9:27 PM, Brian Westerman <
>brian_wester...@syzygyinc.com> wrote:
>
>> If someone violates a copyright, there are legal and I think criminal
>> penalties.  But I doubt the FBI will get involved if you decided not to pay
>> CA for using Panvalet.
>>
>> You can't over simplify the issue and decide categorically that all
>> vendors that want to "protect" their software are bad.  Just like people,
>> there are indeed some bad vendors, whether or not they have product
>> "protection" doesn't enter into the equation.
>>
>> How would a vendor even know that someone didn't take a "personal" copy of
>> their unprotected code from site A to site B?  Does that happen, it sure
>> does.
>>
>> Microsoft did a study several years back on how much time they spent
>> fixing problems and helping people who had pirated copies of their code,
>> and it was something on the order of 38%.  That didn't mean that 38% of the
>> people running Windows were running pirated copies, just that during their
>> study, 38% of the people who called gave pirated copy codes.
>>
>> They were losing more money on the support of the code for the pirated
>> versions than was deemed "acceptable".  The same problem can (and likely
>> is) true for other vendors.  Several of our Syzygy products come with parts
>> that are not protected by keys or code.  We frequently get calls from
>> people who are not out customers to fix (usually the same problem over and
>> over again) problems with the unprotected code who are not very happy when
>> we inform them that we can't offer them support for the code without them
>> being an actual client, but that doesn't stop them from trying.
>>
>> We had a person, just a few months ago, (who is a member of this list and
>> knows who I am talking about), who called with a "problem" for our SyzInfo
>> program (it's a small program we send to sites to display their site
>> information, CPU, LPAR, SYSPLEX, MEMORY info, etc., a lot of interesting
>> information) because they just got a z13 and our code supposedly didn't
>> support it yet.  It worked, but didn't give "completely valid" results.  We
>> actually added support for the box over 18 months before it came out, so we
>> were fairly perplexed.  When asked for his site-ID, he gave it, (it turned
>> out to be one from his old site) and we emailed him the new code for his
>> whole product matrix (4 complete products and support modules).  Then we
>> received a call from him to tell us that the new products would "no longer"
>> operate on his CPU.  When we asked for the CPU type and serial, he gave us
>> his old serial from the old shop, so the client support people re-verified
>> and sent out a new copy even though there was no real changes made.  He
>> told us that it still didn't work so we asked him to execute SyzInfo and
>> send a screen print of the results.  Instead of the screen print, he
>> 

Re: Product license key program

[zMan]

Brian,

Interesting story. I have to ask: given that at that point you had evidence
that they were running unlicensed code, why not just send them a bill? The
unspoken "next call will be from our lawyer" might should be convincing, no?

On Mon, Feb 26, 2018 at 9:27 PM, Brian Westerman <
brian_wester...@syzygyinc.com> wrote:

> If someone violates a copyright, there are legal and I think criminal
> penalties.  But I doubt the FBI will get involved if you decided not to pay
> CA for using Panvalet.
>
> You can't over simplify the issue and decide categorically that all
> vendors that want to "protect" their software are bad.  Just like people,
> there are indeed some bad vendors, whether or not they have product
> "protection" doesn't enter into the equation.
>
> How would a vendor even know that someone didn't take a "personal" copy of
> their unprotected code from site A to site B?  Does that happen, it sure
> does.
>
> Microsoft did a study several years back on how much time they spent
> fixing problems and helping people who had pirated copies of their code,
> and it was something on the order of 38%.  That didn't mean that 38% of the
> people running Windows were running pirated copies, just that during their
> study, 38% of the people who called gave pirated copy codes.
>
> They were losing more money on the support of the code for the pirated
> versions than was deemed "acceptable".  The same problem can (and likely
> is) true for other vendors.  Several of our Syzygy products come with parts
> that are not protected by keys or code.  We frequently get calls from
> people who are not out customers to fix (usually the same problem over and
> over again) problems with the unprotected code who are not very happy when
> we inform them that we can't offer them support for the code without them
> being an actual client, but that doesn't stop them from trying.
>
> We had a person, just a few months ago, (who is a member of this list and
> knows who I am talking about), who called with a "problem" for our SyzInfo
> program (it's a small program we send to sites to display their site
> information, CPU, LPAR, SYSPLEX, MEMORY info, etc., a lot of interesting
> information) because they just got a z13 and our code supposedly didn't
> support it yet.  It worked, but didn't give "completely valid" results.  We
> actually added support for the box over 18 months before it came out, so we
> were fairly perplexed.  When asked for his site-ID, he gave it, (it turned
> out to be one from his old site) and we emailed him the new code for his
> whole product matrix (4 complete products and support modules).  Then we
> received a call from him to tell us that the new products would "no longer"
> operate on his CPU.  When we asked for the CPU type and serial, he gave us
> his old serial from the old shop, so the client support people re-verified
> and sent out a new copy even though there was no real changes made.  He
> told us that it still didn't work so we asked him to execute SyzInfo and
> send a screen print of the results.  Instead of the screen print, he
> "supposedly" cut/pasted the results which showed that the product thought
> exactly what was running was what we shipped.  He escalated the problem
> (which sent it to me), to be resolved, and I asked him to re-execute
> SyzInfo for the screen print and got the same cut/paste thing, but it was
> different from the original one he sent the day before.  The new one had
> several of the values transposed and the CPU was now a EC12 not a z13 as he
> had originally reported having the problem with in the first place.  I
> called him and got one of his co-workers who told me that they were not
> running our code, and he had no idea what I was talking about.  It turned
> out that they were running a z13 and never had a EC12 (they upgraded from a
> z10 recently).  I explained what had just happened and was told that he
> would talk to his boss and that they would handle the "problem".
>
> We never heard back from the person or that site again, but they still
> participate on this site.  When I contacted their old site to ask if things
> were okay, I was told that they were going great and they had no problems
> whatsoever, but that the person I was asking about no longer worked there
> and had not for well over 2 years.
>
> Now, I realize that it's just one occurrence of a bad person, which does
> not make every one bad, but in our case, we expended probably 30 man-hours
> of time on a problem that didn't even exist.  How many of those could a
> small company, or even a large one absorb?
>
> I would like to say this is a one-time occurrence, but I can't.  Similar
> events happen several times a year, but normally it doesn't get to me to
> fix because they discover much sooner that something was amiss.
>
> Our products have built-in protection, actually they all have 3 separate
> protection mechanisms.  We offer free trials that can go up to several
> months when 

Re: Product license key program

[Brian Westerman]

If someone violates a copyright, there are legal and I think criminal 
penalties.  But I doubt the FBI will get involved if you decided not to pay CA 
for using Panvalet.   

You can't over simplify the issue and decide categorically that all vendors 
that want to "protect" their software are bad.  Just like people, there are 
indeed some bad vendors, whether or not they have product "protection" doesn't 
enter into the equation.

How would a vendor even know that someone didn't take a "personal" copy of 
their unprotected code from site A to site B?  Does that happen, it sure does.  

Microsoft did a study several years back on how much time they spent fixing 
problems and helping people who had pirated copies of their code, and it was 
something on the order of 38%.  That didn't mean that 38% of the people running 
Windows were running pirated copies, just that during their study, 38% of the 
people who called gave pirated copy codes.

They were losing more money on the support of the code for the pirated versions 
than was deemed "acceptable".  The same problem can (and likely is) true for 
other vendors.  Several of our Syzygy products come with parts that are not 
protected by keys or code.  We frequently get calls from people who are not out 
customers to fix (usually the same problem over and over again) problems with 
the unprotected code who are not very happy when we inform them that we can't 
offer them support for the code without them being an actual client, but that 
doesn't stop them from trying.

We had a person, just a few months ago, (who is a member of this list and knows 
who I am talking about), who called with a "problem" for our SyzInfo program 
(it's a small program we send to sites to display their site information, CPU, 
LPAR, SYSPLEX, MEMORY info, etc., a lot of interesting information) because 
they just got a z13 and our code supposedly didn't support it yet.  It worked, 
but didn't give "completely valid" results.  We actually added support for the 
box over 18 months before it came out, so we were fairly perplexed.  When asked 
for his site-ID, he gave it, (it turned out to be one from his old site) and we 
emailed him the new code for his whole product matrix (4 complete products and 
support modules).  Then we received a call from him to tell us that the new 
products would "no longer" operate on his CPU.  When we asked for the CPU type 
and serial, he gave us his old serial from the old shop, so the client support 
people re-verified and sent out a new copy even though there was no real 
changes made.  He told us that it still didn't work so we asked him to execute 
SyzInfo and send a screen print of the results.  Instead of the screen print, 
he "supposedly" cut/pasted the results which showed that the product thought 
exactly what was running was what we shipped.  He escalated the problem (which 
sent it to me), to be resolved, and I asked him to re-execute SyzInfo for the 
screen print and got the same cut/paste thing, but it was different from the 
original one he sent the day before.  The new one had several of the values 
transposed and the CPU was now a EC12 not a z13 as he had originally reported 
having the problem with in the first place.  I called him and got one of his 
co-workers who told me that they were not running our code, and he had no idea 
what I was talking about.  It turned out that they were running a z13 and never 
had a EC12 (they upgraded from a z10 recently).  I explained what had just 
happened and was told that he would talk to his boss and that they would handle 
the "problem".

We never heard back from the person or that site again, but they still 
participate on this site.  When I contacted their old site to ask if things 
were okay, I was told that they were going great and they had no problems 
whatsoever, but that the person I was asking about no longer worked there and 
had not for well over 2 years.

Now, I realize that it's just one occurrence of a bad person, which does not 
make every one bad, but in our case, we expended probably 30 man-hours of time 
on a problem that didn't even exist.  How many of those could a small company, 
or even a large one absorb?

I would like to say this is a one-time occurrence, but I can't.  Similar events 
happen several times a year, but normally it doesn't get to me to fix because 
they discover much sooner that something was amiss. 

Our products have built-in protection, actually they all have 3 separate 
protection mechanisms.  We offer free trials that can go up to several months 
when necessary, and every product has a built-in allowance of extra time after 
the expiration date and we warn well in advance of the time left.  Some of the 
products even tell you every time they execute how many days are left, which of 
course can be turned off (except for the last 30 days).  

Most vendors don't have a way to enforce voluntary compliance, but I believe 
that the vast majority of them have some 

Re: Product license key program

[Seymour J Metz]

It's fair when the vendor assumes the risk. It's not fair when the customer has 
bee left holding the bag. "product keys are just any other license enforcement" 
is not even close. If I license, e.g., a copyrighted song for use in a movie, 
it doesn't matter what equipment I use to play the song or to record it in the 
movie. The enforcement is via legal proceedings that the vendor does not invoke 
capriciously, but only when he has good reason to believe that I am in 
violation of the license terms.

Software keys, OTOH, can and have caused problems for legitimate users. Some 
are more reliable than others, but I see nothing wrong with a shop refusing to 
use a product because they are not willing to assume the risk. If you are 
really confident that there is no risk, add an indemnification clause to your 
contract and I'll take your confidence seriously. If you don't trust it enough 
to have such a clause, why should a potential customer trust it?


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List <IBM-MAIN@listserv.ua.edu> on behalf of 
ITschak Mugzach <imugz...@gmail.com>
Sent: Monday, February 26, 2018 12:37 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: Product license key program

Shmuel,

Vendors are busy in developing products, not in tracing/tracking their
clients. product keys are just any other license enforcement (eg.
electricity, water and any product that you pay per use. Capacity is just
another way to limit q measure usage. Sound fair to me.

ITschak

On Mon, Feb 26, 2018 at 7:11 PM, Seymour J Metz <sme...@gmu.edu> wrote:

> And vendors using keys sometimes victimize honest customers. BTDT,GTS.
>
> For all of you vendors: it is a fact of life that most vendors have
> competitors and that some shops will give their money to the vendor that
> does not treat them like criminals. Of course, if you are willing to sign a
> contract with big penalty clauses for a malfunctioning key checking routine
> or key delivery system, that will help to reduce the competitive edge, but
> I won't hold my breathe.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List <IBM-MAIN@listserv.ua.edu> on behalf
> of Charles Mills <charl...@mcn.org>
> Sent: Sunday, February 25, 2018 12:47 PM
> To: IBM-MAIN@listserv.ua.edu
> Subject: Re: Product license key program
>
> As the author of such software, let me confirm what others have said: each
> vendor does things its own way -- or perhaps not at all. CA has a central
> "server" program for administering licenses; the software I am responsible
> for has the licensing embedded in the program itself.
>
> The exact technology is proprietary and a trade secret. To say "we do X
> and Y and Z" would be to facilitate its defeat by a dishonest customer.
>
> [And please, let's not start the whole "to key or not to key" discussion
> again. Vendor keys are a fact of life. Yes, they can be a PITA. Most
> customers are honest -- beyond honest to the point of paranoia -- but a few
> are not. And honest customers sometimes make honest mistakes.]
>
> Charles
>
>
> -Original Message-----
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Peter
> Sent: Sunday, February 25, 2018 3:55 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Product license key program
>
> Generally which assembler macro or program sets the expiration ?
>
> --
> 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
>



--
ITschak Mugzach
*|** IronSphere Platform* *|* *Information Security Contiguous Monitoring
for Legacy **|  *

--
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

Re: Product license key program

[ITschak Mugzach]

Shmuel,

Vendors are busy in developing products, not in tracing/tracking their
clients. product keys are just any other license enforcement (eg.
electricity, water and any product that you pay per use. Capacity is just
another way to limit q measure usage. Sound fair to me.

ITschak

On Mon, Feb 26, 2018 at 7:11 PM, Seymour J Metz <sme...@gmu.edu> wrote:

> And vendors using keys sometimes victimize honest customers. BTDT,GTS.
>
> For all of you vendors: it is a fact of life that most vendors have
> competitors and that some shops will give their money to the vendor that
> does not treat them like criminals. Of course, if you are willing to sign a
> contract with big penalty clauses for a malfunctioning key checking routine
> or key delivery system, that will help to reduce the competitive edge, but
> I won't hold my breathe.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List <IBM-MAIN@listserv.ua.edu> on behalf
> of Charles Mills <charl...@mcn.org>
> Sent: Sunday, February 25, 2018 12:47 PM
> To: IBM-MAIN@listserv.ua.edu
> Subject: Re: Product license key program
>
> As the author of such software, let me confirm what others have said: each
> vendor does things its own way -- or perhaps not at all. CA has a central
> "server" program for administering licenses; the software I am responsible
> for has the licensing embedded in the program itself.
>
> The exact technology is proprietary and a trade secret. To say "we do X
> and Y and Z" would be to facilitate its defeat by a dishonest customer.
>
> [And please, let's not start the whole "to key or not to key" discussion
> again. Vendor keys are a fact of life. Yes, they can be a PITA. Most
> customers are honest -- beyond honest to the point of paranoia -- but a few
> are not. And honest customers sometimes make honest mistakes.]
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Peter
> Sent: Sunday, February 25, 2018 3:55 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Product license key program
>
> Generally which assembler macro or program sets the expiration ?
>
> --
> 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
>



-- 
ITschak Mugzach
*|** IronSphere Platform* *|* *Information Security Contiguous Monitoring
for Legacy **|  *

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Product license key program

[Seymour J Metz]

And vendors using keys sometimes victimize honest customers. BTDT,GTS.

For all of you vendors: it is a fact of life that most vendors have competitors 
and that some shops will give their money to the vendor that does not treat 
them like criminals. Of course, if you are willing to sign a contract with big 
penalty clauses for a malfunctioning key checking routine or key delivery 
system, that will help to reduce the competitive edge, but I won't hold my 
breathe.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List <IBM-MAIN@listserv.ua.edu> on behalf of 
Charles Mills <charl...@mcn.org>
Sent: Sunday, February 25, 2018 12:47 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: Product license key program

As the author of such software, let me confirm what others have said: each 
vendor does things its own way -- or perhaps not at all. CA has a central 
"server" program for administering licenses; the software I am responsible for 
has the licensing embedded in the program itself.

The exact technology is proprietary and a trade secret. To say "we do X and Y 
and Z" would be to facilitate its defeat by a dishonest customer.

[And please, let's not start the whole "to key or not to key" discussion again. 
Vendor keys are a fact of life. Yes, they can be a PITA. Most customers are 
honest -- beyond honest to the point of paranoia -- but a few are not. And 
honest customers sometimes make honest mistakes.]

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Peter
Sent: Sunday, February 25, 2018 3:55 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Product license key program

Generally which assembler macro or program sets the expiration ?

--
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

Re: Product license key program

[Charles Mills]

As the author of such software, let me confirm what others have said: each 
vendor does things its own way -- or perhaps not at all. CA has a central 
"server" program for administering licenses; the software I am responsible for 
has the licensing embedded in the program itself.

The exact technology is proprietary and a trade secret. To say "we do X and Y 
and Z" would be to facilitate its defeat by a dishonest customer.

[And please, let's not start the whole "to key or not to key" discussion again. 
Vendor keys are a fact of life. Yes, they can be a PITA. Most customers are 
honest -- beyond honest to the point of paranoia -- but a few are not. And 
honest customers sometimes make honest mistakes.]

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Peter
Sent: Sunday, February 25, 2018 3:55 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Product license key program

Generally which assembler macro or program sets the expiration ?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Product license key program

[Lizette Koehler]

As far as I know each vendor has their own process for determining when a 
product will no longer function on a given LPAR.  The function could be a key 
with a date/time in it.  They could rely on the customer to renew and then they 
get a new key.  If not, then the product could expire but continue to work.  Or 
the product may just stop working.  Each vendor has their own requirements on 
License keys.  

I do not think you will find one specific way they all do it.  They realize 
there are cleaver people who want to run their software without renewing or 
paying.  So they work very hard to make sure it is very unlikely anyone can 
crack their logic that drives their product authorization process.  They may 
all grab the clock, but how they use that to determine usage, is probably 
proprietary.

Each vendor probably provides a process to see when the product will expire.

There are no easy work arounds when vendors have keys that dictate when the 
product will stop working.


Some vendors grab the clock at start up, then store it into some area of their 
code where you can not see it or alter it.  Then use a key to see where the 
clock is and validate the product is still licensed to run.

For example, SAS, provides me a SAS key.  I can see the expiration date they 
are setting. I cannot change that.  The SAS software is very smart and if I 
change to a new year without the appropriate payment and secret code to go with 
it, it will not work.  The SAS license key is added to something else in the 
SAS software and that is not visible to me.  So if it is 1 day to expiration.  
At day 0 the software stops working.  But they do give you a 60 and 45 day 
warning.


Some vendors will allow you to continue running so long as an IPL does not 
occur. If it does and the product is expired, then it will not be available 
after the IPL.

Some vendors allow for a Disaster Recovery Key.  One that can run during DR 
Testing or actual DR.


Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Peter
> Sent: Sunday, February 25, 2018 3:50 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Product license key program
> 
> Hi
> 
> How does the product license key works. Which program determines  the
> expiration of a product.
> 
> This is a general question.
> 
> Peter
> 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Product license key program

[ITschak Mugzach]

This is a program a vendor develop to protect his ip.  It can be cpu serial
limited, model or time. If your interest is time, just compare machine time
with a value in your program. Stck (or $stck macro) will store the clock
value.

ITschak

בתאריך 25 בפבר׳ 2018 1:54 אחה״צ,‏ "Peter"  כתב:

> Generally which assembler macro or program sets the expiration ?
>
> On 25-Feb-2018 5:07 PM, "Mike Schwab"  wrote:
>
> > Generally, part of the start up of each product.  CA has a common
> > repository that is checked at start up.
> >
> > On Sun, Feb 25, 2018 at 4:50 AM, Peter  wrote:
> > > Hi
> > >
> > > How does the product license key works. Which program determines  the
> > > expiration of a product.
> > >
> > > This is a general question.
> > >
> > > Peter
> > >
> > > --
> > > 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
> >
>
> --
> 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

Re: Product license key program

[Peter]

Generally which assembler macro or program sets the expiration ?

On 25-Feb-2018 5:07 PM, "Mike Schwab"  wrote:

> Generally, part of the start up of each product.  CA has a common
> repository that is checked at start up.
>
> On Sun, Feb 25, 2018 at 4:50 AM, Peter  wrote:
> > Hi
> >
> > How does the product license key works. Which program determines  the
> > expiration of a product.
> >
> > This is a general question.
> >
> > Peter
> >
> > --
> > 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
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Product license key program

[Mike Schwab]

Generally, part of the start up of each product.  CA has a common
repository that is checked at start up.

On Sun, Feb 25, 2018 at 4:50 AM, Peter  wrote:
> Hi
>
> How does the product license key works. Which program determines  the
> expiration of a product.
>
> This is a general question.
>
> Peter
>
> --
> 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