Discussion:
Product license key program
(too old to reply)
Peter
2018-02-25 10:48:57 UTC
Permalink
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Mike Schwab
2018-02-25 11:36:15 UTC
Permalink
Generally, part of the start up of each product. CA has a common
repository that is checked at start up.
Post by Peter
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,
--
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Peter
2018-02-25 11:53:18 UTC
Permalink
Generally which assembler macro or program sets the expiration ?
Post by Mike Schwab
Generally, part of the start up of each product. CA has a common
repository that is checked at start up.
Post by Peter
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,
--
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,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
ITschak Mugzach
2018-02-25 11:57:07 UTC
Permalink
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
Post by Peter
Generally which assembler macro or program sets the expiration ?
Post by Mike Schwab
Generally, part of the start up of each product. CA has a common
repository that is checked at start up.
Post by Peter
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,
--
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,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Charles Mills
2018-02-25 17:46:17 UTC
Permalink
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-***@LISTSERV.UA.EDU] On Behalf Of Peter
Sent: Sunday, February 25, 2018 3:55 AM
To: IBM-***@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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Seymour J Metz
2018-02-26 17:10:28 UTC
Permalink
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-***@listserv.ua.edu> on behalf of Charles Mills <***@MCN.ORG>
Sent: Sunday, February 25, 2018 12:47 PM
To: IBM-***@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-***@LISTSERV.UA.EDU] On Behalf Of Peter
Sent: Sunday, February 25, 2018 3:55 AM
To: IBM-***@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 ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Lizette Koehler
2018-02-25 16:49:34 UTC
Permalink
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-----
Behalf Of Peter
Sent: Sunday, February 25, 2018 3:50 AM
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
zMan
2018-02-27 02:36:08 UTC
Permalink
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 <
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 sort of protection built
into their products. And while most people believe that IBM does not keep
track of product use, they would be wrong. Is it possible to get around
the protections? You bet. We believe here, and I'm sure that most other
vendors also believe, that he vast majority if not all of our clients are
extremely trustworthy, and likewise we hope they think we are trustworthy
as well.
Wasn't it Ronald Reagan who said, "trust, but verify". :) Who would I be
to argue with the great communicator? I worked for him for 6 years, he was
no dummy.
So, I also agree that this shouldn't be another long drawn out fight over
"to key or not to key", and I also realize that there are some sites who
might not run our products because they are protected. I don't think it's
too many because we have over 700 clients.
I realize this is going to sound facetious, but when I first read some of
the rants from people complaining about how they are not trusted I can't
help but wonder if they lock their homes and cars. Do they put the WPA2
passwords on their routers? Do they have a pin on their phone? And if so,
is it just that they believe that everyone should trust them, but they need
not trust everyone else?
I don't expect any non sarcastic responses to this, and I probably
wouldn't read them anyway, (yes I will, but I probably won't admit it), but
sometimes I wonder about how people can divide their lives up so simply and
exactly that everyone else who doesn't do something "their way" is
"wrong". Is that a sure sign that I'm getting old that I have a hard time
understanding why there seems to be no such thing as grey any more. If
you're not 100% "good" then you're "bad", or more likely, if you're not
100% "like me" then you're "bad".
What happened to diversity? And why get so virulent about it?
Hopefully this won't start a full rant from anyone, but I'm sure it will,
especially from the guy who I told you about above.
Brian
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
--
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Brian Westerman
2018-02-27 05:43:48 UTC
Permalink
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
Post by 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 <
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 sort of protection built
into their products. And while most people believe that IBM does not keep
track of product use, they would be wrong. Is it possible to get around
the protections? You bet. We believe here, and I'm sure that most other
vendors also believe, that he vast majority if not all of our clients are
extremely trustworthy, and likewise we hope they think we are trustworthy
as well.
Wasn't it Ronald Reagan who said, "trust, but verify". :) Who would I be
to argue with the great communicator? I worked for him for 6 years, he was
no dummy.
So, I also agree that this shouldn't be another long drawn out fight over
"to key or not to key", and I also realize that there are some sites who
might not run our products because they are protected. I don't think it's
too many because we have over 700 clients.
I realize this is going to sound facetious, but when I first read some of
the rants from people complaining about how they are not trusted I can't
help but wonder if they lock their homes and cars. Do they put the WPA2
passwords on their routers? Do they have a pin on their phone? And if so,
is it just that they believe that everyone should trust them, but they need
not trust everyone else?
I don't expect any non sarcastic responses to this, and I probably
wouldn't read them anyway, (yes I will, but I probably won't admit it), but
sometimes I wonder about how people can divide their lives up so simply and
exactly that everyone else who doesn't do something "their way" is
"wrong". Is that a sure sign that I'm getting old that I have a hard time
understanding why there seems to be no such thing as grey any more. If
you're not 100% "good" then you're "bad", or more likely, if you're not
100% "like me" then you're "bad".
What happened to diversity? And why get so virulent about it?
Hopefully this won't start a full rant from anyone, but I'm sure it will,
especially from the guy who I told you about above.
Brian
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
--
zMan -- "I've got a mainframe and I'm not afraid to use it"
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Jesse 1 Robinson
2018-02-27 22:17:42 UTC
Permalink
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
***@sce.com


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Charles Mills
Sent: Tuesday, February 27, 2018 1:03 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: (External):Re: Product license key program
Post by 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-***@LISTSERV.UA.EDU] On Behalf Of Charles Mills
Sent: Sunday, February 25, 2018 9:47 AM
To: IBM-***@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 ***@listserv.ua.edu with the message: INFO IBM-MAIN


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Charles Mills
2018-02-27 23:23:28 UTC
Permalink
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-***@LISTSERV.UA.EDU] On Behalf Of Jesse 1 Robinson
Sent: Tuesday, February 27, 2018 2:18 PM
To: IBM-***@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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Gilmartin
2018-02-28 03:47:19 UTC
Permalink
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?
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."
Post by Seymour J Metz
________________________________________
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Brian Westerman
2018-02-28 06:50:12 UTC
Permalink
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
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-----
Sent: Tuesday, February 27, 2018 3:24 PM
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
________________________________________
Sent: Tuesday, February 27, 2018 2:22 PM
Subject: Re: Product license key program
Seymour,
You knowledge of music copyright is incorrect. In many cases it *does* matter what equipment.
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
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
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
________________________________________
Sent: Monday, February 26, 2018 12:37 PM
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
Post by 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
________________________________________
Sent: Sunday, February 25, 2018 12:47 PM
Subject: Re: Product license key program
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-----
On Behalf Of Peter
Sent: Sunday, February 25, 2018 3:55 AM
Subject: Re: Product license key program
Generally which assembler macro or program sets the expiration ?
---------------------------------------------------------------------
- For IBM-MAIN subscribe / signoff / archive access instructions,
IBM-MAIN
---------------------------------------------------------------------
- For IBM-MAIN subscribe / signoff / archive access instructions,
IBM-MAIN
--
ITschak Mugzach
*|** IronSphere Platform* *|* *Information Security Contiguous
Monitoring for Legacy **| *
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send
----------------------------------------------------------------------
----------------------------------------------------------------------
----------------------------Disclaimer----------------------------
This email may contain privileged and/or confidential information that
is intended solely for the use of the addressee. If you are not the
intended recipient, you are strictly prohibited from disclosing, copying,
distributing or using any of the information contained in the transmission.
If you received this communication in error, please contact the sender
(“Company”) immediately and destroy the material in its entirety,
including all electronic and hard copies.
This communication may contain nonpublic personal information about
consumers which is subject to restrictions under the Gramm-Leach-Bliley
Act and the Sarbanes-Oxley Act. You may not directly or indirectly reuse
or disclose such nonpublic personal information for any purpose other than
to provide the services for which you are receiving the information.
There rre risks associated with the use of electronic transmission. The
sender of this information does not control the method of transmittal or
any service providers and the sender assumes no duty, liability, or
obligation for the security, receipt, or any third party interception of
this transmission.
The Company reserves the right to amend statements made herein in the event
of a mistake. Unless expressly stated herein to the contrary, only agreements
in writing signed by an authorized officer of the Company may be enforced
against it.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Gord Tomlin
2018-02-28 14:47:53 UTC
Permalink
Post by 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.
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Seymour J Metz
2018-03-01 21:39:40 UTC
Permalink
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-***@listserv.ua.edu> on behalf of Gord Tomlin <***@ACTIONSOFTWARE.COM>
Sent: Wednesday, February 28, 2018 9:49 AM
To: IBM-***@listserv.ua.edu
Subject: Re: Product license key program
Post by 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.
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Gord Tomlin
2018-03-02 22:09:13 UTC
Permalink
Post by 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).
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
R.S.
2018-02-28 11:14:27 UTC
Permalink
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&S defined. Cusomer
paid license fee and pay S&S every year. Obvioulsy S&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: ***@mBank.plSąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 0000025237, 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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Phil Smith
2018-02-28 16:42:49 UTC
Permalink
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 "<BackupProductName> 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 <companyname>". 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", as IBM insanely wants us to call it now) database on a huge system will be charged unfairly at the moment, but it's hard to argue that a 50TB DB2 installation used by 1,000 applications should not cost more in license fees than a tiny one used by a single application, no? Utilities often seem easier to justify "one size fits all" pricing.

Another aspect of this whole thing is trial versions of software. For DB2, that's easy: you try it, and if you don't buy it, you uninstall it. For things like, say, a performance tool, it's harder: if you allow trials, you risk customers trialing it, solving their problem, and then not buying. That's an unsustainable business model.
--

...phsiii

Phil Smith III
Senior Architect & Product Manager, Mainframe & Enterprise
Distinguished Technologist
Micro Focus


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Tom Brennan
2018-02-28 17:37:49 UTC
Permalink
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:
<a lot of interesting stuff>

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Wayne Bickerdike
2018-03-04 20:24:13 UTC
Permalink
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.
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
________________________________________
Sent: Saturday, March 3, 2018 1:22 AM
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?
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 either party,
especially the one who wrote it in the first place to enforce it.
1) what associated risk? The risk that they will not pay their license
fee and therefore lose the use of the software? The risk of the Key "not
working"? I'm not trying to be obtuse, I just don't see what the actual
"risk" here is.
2) Okay, I must have misunderstood, sorry for that part.
3) you are assuming that the Key or the requirement thereof will somehow,
through the fault of the "key", cause an outage. I guess that brings me
back to the risk part above, how does the key in and of itself present any
danger. I can understand if the key were to fail (which I have never heard
of any spontaneous key failures anywhere), or if the client were to fail to
complete the license (i.e. not pay) and it expires, but how is that the
fault of the vendor or the key. Obviously there must be some other
criteria that you are using that I have been overlooking. What are the
circumstances that would apply in this case?
4) What about it? They paid for the key, it's implemented, and it works.
Are you saying what happens if it doesn't "work"? That would be the same
as if you have a product that does some specific "thing" and for some
reason it stopped doing that "thing". Do you expect the vendor to fix it,
yes, of course you do. Why would a key be any different? Again, I have
never heard of a key just spontaneously stopping for no reason, so I am
searching for tangible justification here.
5) Again, I don't see the aspect of "chance" in this. Have you EVER
experienced, or ever heard of it happening that was verifiable, of a Key
failure that was caused by the key or the mechanism itself and not a
generation issue or some other purely human factor? Maybe if a new version
of the software was sent that didn't work with the old key, but that's
again grasping on my part, and would fall into the "human error" part. So
it brings me back to ... Have you ever experienced a spontaneous key
failure that was not related to expiration or error from other than the
actual Key or the Key process itself? Again, this is just one of those
things that I have never heard of happening. Keys just don't stop working
without a logical reason. I suppose that the key could get damaged by a
hardware failure or something, but I don't see how that would be the fault
of the vendor of the software. Again, I'm probably missing something
important, so please give me an example that I can use to try to understand
this better.
6) What danger inherent in the enforcement method? I think it's
relatively simple and uncomplicated and not fraught with any real risks.
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. I think
this is another one of those areas where you probably honestly do know what
you are talking about, but I am unable to get your meaning from the one
sentence response.
I am not trying to misrepresent your position, I am trying to understand
it from the vendor side or even from your side, but I can't see your side
if you don't make it clearer for me. I'll admit that sometimes I can be
pretty stupid, just ask my wife she will tell you, but I honestly am trying
to see your point(s), I just haven't got there yet.
I don't think most vendors try to tell the client what metrics to use in
evaluation (aside from CA maybe:)), and I agree with you that ALL VENDORS
need to disclose everything up front. The same should be true of the
client, but sometimes (not very often, but enough times) the client is not
very "up front" with the vendor. That was the point I was making by
telling you of the problem we had with the guy that took our software to
another site and expected us to make it work for him there.
I still would like to know what the risks are that keys impose on the
customer. 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. Again, this is taking
an extreme view again, but when you buy your car, do you ask GM (et.al.)
to sign a indemnification clause because you might lose your keys, or the
key might get bent in the lock, or your dog eats them? There could be lots
of consequential damages from not being able to use your car, related to
the key, but not the fault of GM. (remember this is a far fetched
(entirely a joke) reference), but, based on the information I have gleaned
from your posts so far it's (almost) reasonable to ask.
I'm looking for something tangible that tells me what the "bad" part of
keys are. If it's just you personally don't like them or feel that they
are otherwise inherently bad for no particular reason, then I can live with
that, but I don't want to go off assuming that there is no basis for your
complaint.
I don't know how many vendors, even the company I work for, are willing to
have their technical people spend the time to discuss this with you
personally, but that's why I'm putting this effort in to try to understand
your side of this. Believe me, I have lots of stuff to do, and I'm not
getting paid for this part at all, so it's just me and you and I'm asking
you to try to explain to me why keys are "bad". Again, if it's just that
you just plain don't like them, then that's completely fine, I would just
like to know.
Brian
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
________________________________________
Sent: Wednesday, February 28, 2018 1:51 AM
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
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
________________________________________
Sent: Monday, February 26, 2018 9:27 PM
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 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 sort of protection built
into their products. And while most people believe that IBM does not keep
track of product use, they would be wrong. Is it possible to get around
the protections? You bet. We believe here, and I'm sure that most other
vendors also believe, that he vast majority if not all of our clients are
extremely trustworthy, and likewise we hope they think we are trustworthy
as well.
Wasn't it Ronald Reagan who said, "trust, but verify". :) Who would I
be to argue with the great communicator? I worked for him for 6 years, he
was no dummy.
So, I also agree that this shouldn't be another long drawn out fight
over "to key or not to key", and I also realize that there are some sites
who might not run our products because they are protected. I don't think
it's too many because we have over 700 clients.
I realize this is going to sound facetious, but when I first read some
of the rants from people complaining about how they are not trusted I can't
help but wonder if they lock their homes and cars. Do they put the WPA2
passwords on their routers? Do they have a pin on their phone? And if so,
is it just that they believe that everyone should trust them, but they need
not trust everyone else?
I don't expect any non sarcastic responses to this, and I probably
wouldn't read them anyway, (yes I will, but I probably won't admit it), but
sometimes I wonder about how people can divide their lives up so simply and
exactly that everyone else who doesn't do something "their way" is
"wrong". Is that a sure sign that I'm getting old that I have a hard time
understanding why there seems to be no such thing as grey any more. If
you're not 100% "good" then you're "bad", or more likely, if you're not
100% "like me" then you're "bad".
What happened to diversity? And why get so virulent about it?
Hopefully this won't start a full rant from anyone, but I'm sure it
will, especially from the guy who I told you about above.
Brian
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
--
Wayne V. Bickerdike

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Seymour J Metz
2018-03-04 20:39:27 UTC
Permalink
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-***@listserv.ua.edu> on behalf of Wayne Bickerdike <***@GMAIL.COM>
Sent: Sunday, March 4, 2018 3:25 PM
To: IBM-***@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.
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
________________________________________
Sent: Saturday, March 3, 2018 1:22 AM
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?
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 either party,
especially the one who wrote it in the first place to enforce it.
1) what associated risk? The risk that they will not pay their license
fee and therefore lose the use of the software? The risk of the Key "not
working"? I'm not trying to be obtuse, I just don't see what the actual
"risk" here is.
2) Okay, I must have misunderstood, sorry for that part.
3) you are assuming that the Key or the requirement thereof will somehow,
through the fault of the "key", cause an outage. I guess that brings me
back to the risk part above, how does the key in and of itself present any
danger. I can understand if the key were to fail (which I have never heard
of any spontaneous key failures anywhere), or if the client were to fail to
complete the license (i.e. not pay) and it expires, but how is that the
fault of the vendor or the key. Obviously there must be some other
criteria that you are using that I have been overlooking. What are the
circumstances that would apply in this case?
4) What about it? They paid for the key, it's implemented, and it works.
Are you saying what happens if it doesn't "work"? That would be the same
as if you have a product that does some specific "thing" and for some
reason it stopped doing that "thing". Do you expect the vendor to fix it,
yes, of course you do. Why would a key be any different? Again, I have
never heard of a key just spontaneously stopping for no reason, so I am
searching for tangible justification here.
5) Again, I don't see the aspect of "chance" in this. Have you EVER
experienced, or ever heard of it happening that was verifiable, of a Key
failure that was caused by the key or the mechanism itself and not a
generation issue or some other purely human factor? Maybe if a new version
of the software was sent that didn't work with the old key, but that's
again grasping on my part, and would fall into the "human error" part. So
it brings me back to ... Have you ever experienced a spontaneous key
failure that was not related to expiration or error from other than the
actual Key or the Key process itself? Again, this is just one of those
things that I have never heard of happening. Keys just don't stop working
without a logical reason. I suppose that the key could get damaged by a
hardware failure or something, but I don't see how that would be the fault
of the vendor of the software. Again, I'm probably missing something
important, so please give me an example that I can use to try to understand
this better.
6) What danger inherent in the enforcement method? I think it's
relatively simple and uncomplicated and not fraught with any real risks.
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. I think
this is another one of those areas where you probably honestly do know what
you are talking about, but I am unable to get your meaning from the one
sentence response.
I am not trying to misrepresent your position, I am trying to understand
it from the vendor side or even from your side, but I can't see your side
if you don't make it clearer for me. I'll admit that sometimes I can be
pretty stupid, just ask my wife she will tell you, but I honestly am trying
to see your point(s), I just haven't got there yet.
I don't think most vendors try to tell the client what metrics to use in
evaluation (aside from CA maybe:)), and I agree with you that ALL VENDORS
need to disclose everything up front. The same should be true of the
client, but sometimes (not very often, but enough times) the client is not
very "up front" with the vendor. That was the point I was making by
telling you of the problem we had with the guy that took our software to
another site and expected us to make it work for him there.
I still would like to know what the risks are that keys impose on the
customer. 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. Again, this is taking
an extreme view again, but when you buy your car, do you ask GM (et.al.)
to sign a indemnification clause because you might lose your keys, or the
key might get bent in the lock, or your dog eats them? There could be lots
of consequential damages from not being able to use your car, related to
the key, but not the fault of GM. (remember this is a far fetched
(entirely a joke) reference), but, based on the information I have gleaned
from your posts so far it's (almost) reasonable to ask.
I'm looking for something tangible that tells me what the "bad" part of
keys are. If it's just you personally don't like them or feel that they
are otherwise inherently bad for no particular reason, then I can live with
that, but I don't want to go off assuming that there is no basis for your
complaint.
I don't know how many vendors, even the company I work for, are willing to
have their technical people spend the time to discuss this with you
personally, but that's why I'm putting this effort in to try to understand
your side of this. Believe me, I have lots of stuff to do, and I'm not
getting paid for this part at all, so it's just me and you and I'm asking
you to try to explain to me why keys are "bad". Again, if it's just that
you just plain don't like them, then that's completely fine, I would just
like to know.
Brian
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
________________________________________
Sent: Wednesday, February 28, 2018 1:51 AM
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
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
________________________________________
Sent: Monday, February 26, 2018 9:27 PM
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 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 sort of protection built
into their products. And while most people believe that IBM does not keep
track of product use, they would be wrong. Is it possible to get around
the protections? You bet. We believe here, and I'm sure that most other
vendors also believe, that he vast majority if not all of our clients are
extremely trustworthy, and likewise we hope they think we are trustworthy
as well.
Wasn't it Ronald Reagan who said, "trust, but verify". :) Who would I
be to argue with the great communicator? I worked for him for 6 years, he
was no dummy.
So, I also agree that this shouldn't be another long drawn out fight
over "to key or not to key", and I also realize that there are some sites
who might not run our products because they are protected. I don't think
it's too many because we have over 700 clients.
I realize this is going to sound facetious, but when I first read some
of the rants from people complaining about how they are not trusted I can't
help but wonder if they lock their homes and cars. Do they put the WPA2
passwords on their routers? Do they have a pin on their phone? And if so,
is it just that they believe that everyone should trust them, but they need
not trust everyone else?
I don't expect any non sarcastic responses to this, and I probably
wouldn't read them anyway, (yes I will, but I probably won't admit it), but
sometimes I wonder about how people can divide their lives up so simply and
exactly that everyone else who doesn't do something "their way" is
"wrong". Is that a sure sign that I'm getting old that I have a hard time
understanding why there seems to be no such thing as grey any more. If
you're not 100% "good" then you're "bad", or more likely, if you're not
100% "like me" then you're "bad".
What happened to diversity? And why get so virulent about it?
Hopefully this won't start a full rant from anyone, but I'm sure it
will, especially from the guy who I told you about above.
Brian
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
--
Wayne V. Bickerdike

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

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Lester, Bob
2018-03-05 16:56:03 UTC
Permalink
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-***@LISTSERV.UA.EDU] On Behalf Of Wayne Bickerdike
Sent: Sunday, March 4, 2018 1:25 PM
To: IBM-***@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.
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&d=DwIBaQ&c=huW-Z3760n7oNORvLCN2eJBo4X7nIGCr9Ffht-z0f4k&r=1KMMjoS
vFEwY7ZoooplFIrKcOeeTJVI4X6Bc3o6vdK4&m=1l6hpNNXgTiCCpbDJWg8VLAjcwY3ccs
7JKJn3oF8I2A&s=Ap59KzoG5pNDC3N598NDZ-cKLXf4Aac-cJgMJiZzTDk&e=
________________________________________
Sent: Saturday, March 3, 2018 1:22 AM
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?
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 either
party, especially the one who wrote it in the first place to enforce it.
1) what associated risk? The risk that they will not pay their
license fee and therefore lose the use of the software? The risk of
the Key "not working"? I'm not trying to be obtuse, I just don't see
what the actual "risk" here is.
2) Okay, I must have misunderstood, sorry for that part.
3) you are assuming that the Key or the requirement thereof will
somehow, through the fault of the "key", cause an outage. I guess
that brings me back to the risk part above, how does the key in and of
itself present any danger. I can understand if the key were to fail
(which I have never heard of any spontaneous key failures anywhere),
or if the client were to fail to complete the license (i.e. not pay)
and it expires, but how is that the fault of the vendor or the key.
Obviously there must be some other criteria that you are using that I
have been overlooking. What are the circumstances that would apply in this case?
4) What about it? They paid for the key, it's implemented, and it works.
Are you saying what happens if it doesn't "work"? That would be the
same as if you have a product that does some specific "thing" and for
some reason it stopped doing that "thing". Do you expect the vendor
to fix it, yes, of course you do. Why would a key be any different?
Again, I have never heard of a key just spontaneously stopping for no
reason, so I am searching for tangible justification here.
5) Again, I don't see the aspect of "chance" in this. Have you EVER
experienced, or ever heard of it happening that was verifiable, of a
Key failure that was caused by the key or the mechanism itself and not
a generation issue or some other purely human factor? Maybe if a new
version of the software was sent that didn't work with the old key,
but that's again grasping on my part, and would fall into the "human
error" part. So it brings me back to ... Have you ever experienced a
spontaneous key failure that was not related to expiration or error
from other than the actual Key or the Key process itself? Again, this
is just one of those things that I have never heard of happening.
Keys just don't stop working without a logical reason. I suppose that
the key could get damaged by a hardware failure or something, but I
don't see how that would be the fault of the vendor of the software.
Again, I'm probably missing something important, so please give me an
example that I can use to try to understand this better.
6) What danger inherent in the enforcement method? I think it's
relatively simple and uncomplicated and not fraught with any real risks.
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. I think this is another one of those areas where you probably
honestly do know what you are talking about, but I am unable to get
your meaning from the one sentence response.
I am not trying to misrepresent your position, I am trying to
understand it from the vendor side or even from your side, but I can't
see your side if you don't make it clearer for me. I'll admit that
sometimes I can be pretty stupid, just ask my wife she will tell you,
but I honestly am trying to see your point(s), I just haven't got there yet.
I don't think most vendors try to tell the client what metrics to use
in evaluation (aside from CA maybe:)), and I agree with you that ALL
VENDORS need to disclose everything up front. The same should be true
of the client, but sometimes (not very often, but enough times) the
client is not very "up front" with the vendor. That was the point I
was making by telling you of the problem we had with the guy that took
our software to another site and expected us to make it work for him there.
I still would like to know what the risks are that keys impose on the
customer. 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.
Again, this is taking an extreme view again, but when you buy your
car, do you ask GM (et.al.) to sign a indemnification clause because
you might lose your keys, or the key might get bent in the lock, or
your dog eats them? There could be lots of consequential damages from
not being able to use your car, related to the key, but not the fault
of GM. (remember this is a far fetched (entirely a joke) reference),
but, based on the information I have gleaned from your posts so far it's (almost) reasonable to ask.
I'm looking for something tangible that tells me what the "bad" part
of keys are. If it's just you personally don't like them or feel that
they are otherwise inherently bad for no particular reason, then I can
live with that, but I don't want to go off assuming that there is no
basis for your complaint.
I don't know how many vendors, even the company I work for, are
willing to have their technical people spend the time to discuss this
with you personally, but that's why I'm putting this effort in to try
to understand your side of this. Believe me, I have lots of stuff to
do, and I'm not getting paid for this part at all, so it's just me and
you and I'm asking you to try to explain to me why keys are "bad".
Again, if it's just that you just plain don't like them, then that's
completely fine, I would just like to know.
Brian
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
https://urldefense.proofpoint.com/v2/url?u=http-3A__mason.gmu.edu_-7E
smetz3&d=DwIBaQ&c=huW-Z3760n7oNORvLCN2eJBo4X7nIGCr9Ffht-z0f4k&r=1KMMj
oSvFEwY7ZoooplFIrKcOeeTJVI4X6Bc3o6vdK4&m=1l6hpNNXgTiCCpbDJWg8VLAjcwY3
ccs7JKJn3oF8I2A&s=Ap59KzoG5pNDC3N598NDZ-cKLXf4Aac-cJgMJiZzTDk&e=
________________________________________
Sent: Wednesday, February 28, 2018 1:51 AM
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
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
https://urldefense.proofpoint.com/v2/url?u=http-3A__mason.gmu.edu_-7
Esmetz3&d=DwIBaQ&c=huW-Z3760n7oNORvLCN2eJBo4X7nIGCr9Ffht-z0f4k&r=1KM
MjoSvFEwY7ZoooplFIrKcOeeTJVI4X6Bc3o6vdK4&m=1l6hpNNXgTiCCpbDJWg8VLAjc
wY3ccs7JKJn3oF8I2A&s=Ap59KzoG5pNDC3N598NDZ-cKLXf4Aac-cJgMJiZzTDk&e=
________________________________________
Sent: Monday, February 26, 2018 9:27 PM
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 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 sort of protection
built into their products. And while most people believe that IBM
does not keep track of product use, they would be wrong. Is it
possible to get around the protections? You bet. We believe here,
and I'm sure that most other vendors also believe, that he vast
majority if not all of our clients are extremely trustworthy, and
likewise we hope they think we are trustworthy as well.
Wasn't it Ronald Reagan who said, "trust, but verify". :) Who would I
be to argue with the great communicator? I worked for him for 6
years, he was no dummy.
So, I also agree that this shouldn't be another long drawn out fight
over "to key or not to key", and I also realize that there are some
sites who might not run our products because they are protected. I
don't think it's too many because we have over 700 clients.
I realize this is going to sound facetious, but when I first read some
of the rants from people complaining about how they are not trusted I
can't help but wonder if they lock their homes and cars. Do they put
the WPA2 passwords on their routers? Do they have a pin on their
phone? And if so, is it just that they believe that everyone should
trust them, but they need not trust everyone else?
I don't expect any non sarcastic responses to this, and I probably
wouldn't read them anyway, (yes I will, but I probably won't admit
it), but sometimes I wonder about how people can divide their lives up
so simply and exactly that everyone else who doesn't do something
"their way" is "wrong". Is that a sure sign that I'm getting old that
I have a hard time understanding why there seems to be no such thing
as grey any more. If you're not 100% "good" then you're "bad", or
more likely, if you're not 100% "like me" then you're "bad".
What happened to diversity? And why get so virulent about it?
Hopefully this won't start a full rant from anyone, but I'm sure it
will, especially from the guy who I told you about above.
Brian
--------------------------------------------------------------------
-- For IBM-MAIN subscribe / signoff / archive access instructions,
--------------------------------------------------------------------
-- For IBM-MAIN subscribe / signoff / archive access instructions,
---------------------------------------------------------------------
- For IBM-MAIN subscribe / signoff / archive access instructions,
IBM-MAIN
---------------------------------------------------------------------
- For IBM-MAIN subscribe / signoff / archive access instructions,
IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send
--
Wayne V. Bickerdike

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to ***@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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Wayne Bickerdike
2018-03-06 02:16:49 UTC
Permalink
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.
Post by 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-----
Behalf Of Wayne Bickerdike
Sent: Sunday, March 4, 2018 1:25 PM
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.
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&d=DwIBaQ&c=huW-Z3760n7oNORvLCN2eJBo4X7nIGCr9Ffht-z0f4k&r=1KMMjoS
vFEwY7ZoooplFIrKcOeeTJVI4X6Bc3o6vdK4&m=1l6hpNNXgTiCCpbDJWg8VLAjcwY3ccs
7JKJn3oF8I2A&s=Ap59KzoG5pNDC3N598NDZ-cKLXf4Aac-cJgMJiZzTDk&e=
________________________________________
Sent: Saturday, March 3, 2018 1:22 AM
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?
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 either
party, especially the one who wrote it in the first place to enforce it.
1) what associated risk? The risk that they will not pay their
license fee and therefore lose the use of the software? The risk of
the Key "not working"? I'm not trying to be obtuse, I just don't see
what the actual "risk" here is.
2) Okay, I must have misunderstood, sorry for that part.
3) you are assuming that the Key or the requirement thereof will
somehow, through the fault of the "key", cause an outage. I guess
that brings me back to the risk part above, how does the key in and of
itself present any danger. I can understand if the key were to fail
(which I have never heard of any spontaneous key failures anywhere),
or if the client were to fail to complete the license (i.e. not pay)
and it expires, but how is that the fault of the vendor or the key.
Obviously there must be some other criteria that you are using that I
have been overlooking. What are the circumstances that would apply in
this case?
4) What about it? They paid for the key, it's implemented, and it works.
Are you saying what happens if it doesn't "work"? That would be the
same as if you have a product that does some specific "thing" and for
some reason it stopped doing that "thing". Do you expect the vendor
to fix it, yes, of course you do. Why would a key be any different?
Again, I have never heard of a key just spontaneously stopping for no
reason, so I am searching for tangible justification here.
5) Again, I don't see the aspect of "chance" in this. Have you EVER
experienced, or ever heard of it happening that was verifiable, of a
Key failure that was caused by the key or the mechanism itself and not
a generation issue or some other purely human factor? Maybe if a new
version of the software was sent that didn't work with the old key,
but that's again grasping on my part, and would fall into the "human
error" part. So it brings me back to ... Have you ever experienced a
spontaneous key failure that was not related to expiration or error
from other than the actual Key or the Key process itself? Again, this
is just one of those things that I have never heard of happening.
Keys just don't stop working without a logical reason. I suppose that
the key could get damaged by a hardware failure or something, but I
don't see how that would be the fault of the vendor of the software.
Again, I'm probably missing something important, so please give me an
example that I can use to try to understand this better.
6) What danger inherent in the enforcement method? I think it's
relatively simple and uncomplicated and not fraught with any real risks.
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. I think this is another one of those areas where you probably
honestly do know what you are talking about, but I am unable to get
your meaning from the one sentence response.
I am not trying to misrepresent your position, I am trying to
understand it from the vendor side or even from your side, but I can't
see your side if you don't make it clearer for me. I'll admit that
sometimes I can be pretty stupid, just ask my wife she will tell you,
but I honestly am trying to see your point(s), I just haven't got there
yet.
I don't think most vendors try to tell the client what metrics to use
in evaluation (aside from CA maybe:)), and I agree with you that ALL
VENDORS need to disclose everything up front. The same should be true
of the client, but sometimes (not very often, but enough times) the
client is not very "up front" with the vendor. That was the point I
was making by telling you of the problem we had with the guy that took
our software to another site and expected us to make it work for him
there.
I still would like to know what the risks are that keys impose on the
customer. 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.
Again, this is taking an extreme view again, but when you buy your
car, do you ask GM (et.al.) to sign a indemnification clause because
you might lose your keys, or the key might get bent in the lock, or
your dog eats them? There could be lots of consequential damages from
not being able to use your car, related to the key, but not the fault
of GM. (remember this is a far fetched (entirely a joke) reference),
but, based on the information I have gleaned from your posts so far it's
(almost) reasonable to ask.
I'm looking for something tangible that tells me what the "bad" part
of keys are. If it's just you personally don't like them or feel that
they are otherwise inherently bad for no particular reason, then I can
live with that, but I don't want to go off assuming that there is no
basis for your complaint.
I don't know how many vendors, even the company I work for, are
willing to have their technical people spend the time to discuss this
with you personally, but that's why I'm putting this effort in to try
to understand your side of this. Believe me, I have lots of stuff to
do, and I'm not getting paid for this part at all, so it's just me and
you and I'm asking you to try to explain to me why keys are "bad".
Again, if it's just that you just plain don't like them, then that's
completely fine, I would just like to know.
Brian
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
https://urldefense.proofpoint.com/v2/url?u=http-3A__mason.gmu.edu_-7E
smetz3&d=DwIBaQ&c=huW-Z3760n7oNORvLCN2eJBo4X7nIGCr9Ffht-z0f4k&r=1KMMj
oSvFEwY7ZoooplFIrKcOeeTJVI4X6Bc3o6vdK4&m=1l6hpNNXgTiCCpbDJWg8VLAjcwY3
ccs7JKJn3oF8I2A&s=Ap59KzoG5pNDC3N598NDZ-cKLXf4Aac-cJgMJiZzTDk&e=
________________________________________
Sent: Wednesday, February 28, 2018 1:51 AM
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
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
https://urldefense.proofpoint.com/v2/url?u=http-3A__mason.gmu.edu_-7
Esmetz3&d=DwIBaQ&c=huW-Z3760n7oNORvLCN2eJBo4X7nIGCr9Ffht-z0f4k&r=1KM
MjoSvFEwY7ZoooplFIrKcOeeTJVI4X6Bc3o6vdK4&m=1l6hpNNXgTiCCpbDJWg8VLAjc
wY3ccs7JKJn3oF8I2A&s=Ap59KzoG5pNDC3N598NDZ-cKLXf4Aac-cJgMJiZzTDk&e=
________________________________________
Sent: Monday, February 26, 2018 9:27 PM
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 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 sort of protection
built into their products. And while most people believe that IBM
does not keep track of product use, they would be wrong. Is it
possible to get around the protections? You bet. We believe here,
and I'm sure that most other vendors also believe, that he vast
majority if not all of our clients are extremely trustworthy, and
likewise we hope they think we are trustworthy as well.
Wasn't it Ronald Reagan who said, "trust, but verify". :) Who would I
be to argue with the great communicator? I worked for him for 6
years, he was no dummy.
So, I also agree that this shouldn't be another long drawn out fight
over "to key or not to key", and I also realize that there are some
sites who might not run our products because they are protected. I
don't think it's too many because we have over 700 clients.
I realize this is going to sound facetious, but when I first read some
of the rants from people complaining about how they are not trusted I
can't help but wonder if they lock their homes and cars. Do they put
the WPA2 passwords on their routers? Do they have a pin on their
phone? And if so, is it just that they believe that everyone should
trust them, but they need not trust everyone else?
I don't expect any non sarcastic responses to this, and I probably
wouldn't read them anyway, (yes I will, but I probably won't admit
it), but sometimes I wonder about how people can divide their lives up
so simply and exactly that everyone else who doesn't do something
"their way" is "wrong". Is that a sure sign that I'm getting old that
I have a hard time understanding why there seems to be no such thing
as grey any more. If you're not 100% "good" then you're "bad", or
more likely, if you're not 100% "like me" then you're "bad".
What happened to diversity? And why get so virulent about it?
Hopefully this won't start a full rant from anyone, but I'm sure it
will, especially from the guy who I told you about above.
Brian
--------------------------------------------------------------------
-- For IBM-MAIN subscribe / signoff / archive access instructions,
--------------------------------------------------------------------
-- For IBM-MAIN subscribe / signoff / archive access instructions,
---------------------------------------------------------------------
- For IBM-MAIN subscribe / signoff / archive access instructions,
---------------------------------------------------------------------
- For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send
--
Wayne V. Bickerdike
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email
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,
--
Wayne V. Bickerdike

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Charles Mills
2018-03-04 22:40:12 UTC
Permalink
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-***@LISTSERV.UA.EDU] On
Behalf Of Seymour J Metz
Sent: Sunday, March 4, 2018 11:56 AM
To: IBM-***@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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Gilmartin
2018-03-05 00:28:52 UTC
Permalink
Post by 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.
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
zMan
2018-03-05 00:53:06 UTC
Permalink
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 <
Post by Seymour J Metz
Post by 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.
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,
--
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Gilmartin (π)
2018-03-05 01:35:00 UTC
Permalink
Post by 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!
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
zMan
2018-03-05 03:06:09 UTC
Permalink
I like it. CA should include those.

On Sun, Mar 4, 2018 at 8:36 PM, Paul Gilmartin (π) <
Post by Paul Gilmartin (π)
Post by 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!
That could be solved with a pad of stickers bearing the word "NOT".
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
--
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
David Boyes
2018-03-05 18:21:28 UTC
Permalink
[.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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Lester, Bob
2018-03-05 18:25:35 UTC
Permalink
+1

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of David Boyes
Sent: Monday, March 5, 2018 11:13 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: Product license key program [ EXTERNAL ]
[.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 ***@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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Savor, Thomas , Alpharetta
2018-03-05 21:00:13 UTC
Permalink
" OK, this discussion has reached the level of diminishing returns."

Man, I guess so....this "was" a very interesting discussion about software keys that has dissolved quickly.
Guys, I'm not a systems programmer, never have been....but 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 Seymour....I 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 word....I 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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
J R
2018-03-05 21:19:55 UTC
Permalink
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) <***@FISERV.COM<mailto:***@FISERV.COM>> wrote:

I would love to get your incite on something

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Savor, Thomas , Alpharetta
2018-03-05 21:55:21 UTC
Permalink
Your right...my bad. Spelling is my crutch !!!

Thanks,

Tom Savor

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of J R
Sent: Monday, March 05, 2018 4:21 PM
To: IBM-***@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) <***@FISERV.COM<mailto:***@FISERV.COM>> wrote:

I would love to get your incite on something

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

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Grinsell, Don
2018-03-05 21:21:42 UTC
Permalink
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-----
Savor, Thomas (Alpharetta)
Sent: Monday, March 05, 2018 2:01 PM
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
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Savor, Thomas , Alpharetta
2018-03-05 22:21:28 UTC
Permalink
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 thing....well 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 Bank....so 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 worked....i've seen a zap before to extended a product from now to next year....now 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-***@LISTSERV.UA.EDU] On Behalf Of Grinsell, Don
Sent: Monday, March 05, 2018 4:23 PM
To: IBM-***@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-----
Behalf Of Savor, Thomas (Alpharetta)
Sent: Monday, March 05, 2018 2:01 PM
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
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Jesse 1 Robinson
2018-03-05 22:51:53 UTC
Permalink
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
***@sce.com


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Savor, Thomas (Alpharetta)
Sent: Monday, March 05, 2018 2:23 PM
To: IBM-***@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 thing....well 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 Bank....so 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 worked....i've seen a zap before to extended a product from now to next year....now 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-***@LISTSERV.UA.EDU] On Behalf Of Grinsell, Don
Sent: Monday, March 05, 2018 4:23 PM
To: IBM-***@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-----
Behalf Of Savor, Thomas (Alpharetta)
Sent: Monday, March 05, 2018 2:01 PM
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Savor, Thomas , Alpharetta
2018-03-06 21:01:20 UTC
Permalink
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 help....I will almost certainly need it.

Thanks,

Tom Savor

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Brian Westerman
2018-03-07 05:56:36 UTC
Permalink
The problem with just using a date, is that the software could be moved to any machine and duplicated any number of times and you would never know about it to keep it from being unlawfully duplicated without payment.

This doesn't mean that you don't trust your clients. In effect, while some might argue, it's really just like locking your car or your home or having a bike lock.

Lets say that you generate your software and the people at company "X" pay the license until January of 2020. In the mean time, 40 people who used to work for company "X", decide that it's soooo good that they want to take it to their new site with them. That would be great if you got revenue from that movement, but you can't unless they call you and tell you that they moved the software and their "new" company would like to license it. Also, maybe the people at company "X" decide that they want to defray the cost of the software they licensed from you, so they sell copies on the internet to other sites. It will run until January of 2020, so there is nothing to keep it from happening. I'm not saying that every client is dishonest, but it only takes one person to make it bad for you. Admittedly, this is probably a bit far fetched, but it's late and I'm tired. :)

On the other hand, if you had a check in your module for the CPU Serial number, (and machine type or LPAR name, or any of several limiting factors), the client is in no way harmed or inconvenienced, because it will operate as before with no impediments, save that the software can't be "moved" without your permission.

This should not cause any problems with DR testing or a real disaster because most, (if not all) DR sites run under VM and will simulate the serials and MT for just this purpose. You can also check for running under VM and disallow it (or generate warnings), but that is not normally necessary and gets away from the point I'm making.

Also, your key code needs to take into account that the site might have multiple physical processors (separate mainframes), so you want to make sure that your "key" code supports multiple entries. This will also be useful for those sites that use "friend" arrangements for their DR sites (other companies who share each other's sites as Disaster Recovery sites for each other).

You can/should also add code that temporarily allows the product to function when the key doesn't match, for use as a trial or for when "stuff" happens that the site for some reason needs to use the code on another box "temporarily". You can limit it for a period of time, or number of uses, or whatever you think is reasonable, it's your software, you make the rules, while generating messages that let the site know in no uncertain terms that the the license is not "currently valid".

There are lots of nice features you can add to the key process, and you can do as many vendors have and set up a web page to generate "emergency" keys for, well.... emergencies. The reason is because "stuff happens" and no one is happy if the product can't be used for some reasonable reason and they can't contact the vendor until the next day because no one happens to be on call that night.

If you are going to implement keys, you might as well do it right and make sure you test-test-test the process before you send it out to your client(s). It's a good way to lose them if you mess up something like this. All sites will understand the necessity of you having keys in your software, but no one will understand if it isn't rock solid. It's such a little nit to implement correctly, but all it takes is one error in the key generation program to ruin your day.

Brian
Post by zMan
Brian,
Never thought about Using CPUID and/or machine type as part of a software key.
Generally speaking we try to stay away from tying application to any kind of machine.
Our application is typical Cobol/Asm, Batch/CICS and VSAM/DB2 system.
Cobol 5 was first change in years that required major changes to our application.
Usually a change to the Operating System has no effect on application executing properly.
But having said that, since I didn’t know really what makes up a key and how they work, this is an interesting change in direction and thinking.
Thanks for the ideas.
And thanks for the ofrer of help....I will almost certainly need it.
Thanks,
Tom Savor
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Mike Schwab
2018-03-07 06:25:29 UTC
Permalink
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
Post by 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 soooo good that they want to take it to their new site with them. That would be great if you got revenue from that movement, but you can't unless they call you and tell you that they moved the software and their "new" company would like to license it. Also, maybe the people at company "X" decide that they want to defray the cost of the software they licensed from you, so they sell copies on the internet to other sites. It will run until January of 2020, so there is nothing to keep it from happening. I'm not saying that every client is dishonest, but it only takes one person to make it bad for you. Admittedly, this is probably a bit far fetched, but it's late and I'm tired. :)
On the other hand, if you had a check in your module for the CPU Serial number, (and machine type or LPAR name, or any of several limiting factors), the client is in no way harmed or inconvenienced, because it will operate as before with no impediments, save that the software can't be "moved" without your permission.
This should not cause any problems with DR testing or a real disaster because most, (if not all) DR sites run under VM and will simulate the serials and MT for just this purpose. You can also check for running under VM and disallow it (or generate warnings), but that is not normally necessary and gets away from the point I'm making.
Also, your key code needs to take into account that the site might have multiple physical processors (separate mainframes), so you want to make sure that your "key" code supports multiple entries. This will also be useful for those sites that use "friend" arrangements for their DR sites (other companies who share each other's sites as Disaster Recovery sites for each other).
You can/should also add code that temporarily allows the product to function when the key doesn't match, for use as a trial or for when "stuff" happens that the site for some reason needs to use the code on another box "temporarily". You can limit it for a period of time, or number of uses, or whatever you think is reasonable, it's your software, you make the rules, while generating messages that let the site know in no uncertain terms that the the license is not "currently valid".
There are lots of nice features you can add to the key process, and you can do as many vendors have and set up a web page to generate "emergency" keys for, well.... emergencies. The reason is because "stuff happens" and no one is happy if the product can't be used for some reasonable reason and they can't contact the vendor until the next day because no one happens to be on call that night.
If you are going to implement keys, you might as well do it right and make sure you test-test-test the process before you send it out to your client(s). It's a good way to lose them if you mess up something like this. All sites will understand the necessity of you having keys in your software, but no one will understand if it isn't rock solid. It's such a little nit to implement correctly, but all it takes is one error in the key generation program to ruin your day.
Brian
Post by zMan
Brian,
Never thought about Using CPUID and/or machine type as part of a software key.
Generally speaking we try to stay away from tying application to any kind of machine.
Our application is typical Cobol/Asm, Batch/CICS and VSAM/DB2 system.
Cobol 5 was first change in years that required major changes to our application.
Usually a change to the Operating System has no effect on application executing properly.
But having said that, since I didn’t know really what makes up a key and how they work, this is an interesting change in direction and thinking.
Thanks for the ideas.
And thanks for the ofrer of help....I will almost certainly need it.
Thanks,
Tom Savor
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
--
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Seymour J Metz
2018-03-07 16:15:36 UTC
Permalink
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-***@listserv.ua.edu> on behalf of Brian Westerman <***@SYZYGYINC.COM>
Sent: Wednesday, March 7, 2018 12:57 AM
To: IBM-***@listserv.ua.edu
Subject: Re: Product license key program

The problem with just using a date, is that the software could be moved to any machine and duplicated any number of times and you would never know about it to keep it from being unlawfully duplicated without payment.

This doesn't mean that you don't trust your clients. In effect, while some might argue, it's really just like locking your car or your home or having a bike lock.

Lets say that you generate your software and the people at company "X" pay the license until January of 2020. In the mean time, 40 people who used to work for company "X", decide that it's soooo good that they want to take it to their new site with them. That would be great if you got revenue from that movement, but you can't unless they call you and tell you that they moved the software and their "new" company would like to license it. Also, maybe the people at company "X" decide that they want to defray the cost of the software they licensed from you, so they sell copies on the internet to other sites. It will run until January of 2020, so there is nothing to keep it from happening. I'm not saying that every client is dishonest, but it only takes one person to make it bad for you. Admittedly, this is probably a bit far fetched, but it's late and I'm tired. :)

On the other hand, if you had a check in your module for the CPU Serial number, (and machine type or LPAR name, or any of several limiting factors), the client is in no way harmed or inconvenienced, because it will operate as before with no impediments, save that the software can't be "moved" without your permission.

This should not cause any problems with DR testing or a real disaster because most, (if not all) DR sites run under VM and will simulate the serials and MT for just this purpose. You can also check for running under VM and disallow it (or generate warnings), but that is not normally necessary and gets away from the point I'm making.

Also, your key code needs to take into account that the site might have multiple physical processors (separate mainframes), so you want to make sure that your "key" code supports multiple entries. This will also be useful for those sites that use "friend" arrangements for their DR sites (other companies who share each other's sites as Disaster Recovery sites for each other).

You can/should also add code that temporarily allows the product to function when the key doesn't match, for use as a trial or for when "stuff" happens that the site for some reason needs to use the code on another box "temporarily". You can limit it for a period of time, or number of uses, or whatever you think is reasonable, it's your software, you make the rules, while generating messages that let the site know in no uncertain terms that the the license is not "currently valid".

There are lots of nice features you can add to the key process, and you can do as many vendors have and set up a web page to generate "emergency" keys for, well.... emergencies. The reason is because "stuff happens" and no one is happy if the product can't be used for some reasonable reason and they can't contact the vendor until the next day because no one happens to be on call that night.

If you are going to implement keys, you might as well do it right and make sure you test-test-test the process before you send it out to your client(s). It's a good way to lose them if you mess up something like this. All sites will understand the necessity of you having keys in your software, but no one will understand if it isn't rock solid. It's such a little nit to implement correctly, but all it takes is one error in the key generation program to ruin your day.

Brian
Post by zMan
Brian,
Never thought about Using CPUID and/or machine type as part of a software key.
Generally speaking we try to stay away from tying application to any kind of machine.
Our application is typical Cobol/Asm, Batch/CICS and VSAM/DB2 system.
Cobol 5 was first change in years that required major changes to our application.
Usually a change to the Operating System has no effect on application executing properly.
But having said that, since I didn’t know really what makes up a key and how they work, this is an interesting change in direction and thinking.
Thanks for the ideas.
And thanks for the ofrer of help....I will almost certainly need it.
Thanks,
Tom Savor
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Brian Westerman
2018-03-08 05:20:03 UTC
Permalink
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
Post by 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
________________________________________
Sent: Wednesday, March 7, 2018 12:57 AM
Subject: Re: Product license key program
The problem with just using a date, is that the software could be moved to any machine and duplicated any number of times and you would never know about it to keep it from being unlawfully duplicated without payment.
This doesn't mean that you don't trust your clients. In effect, while some might argue, it's really just like locking your car or your home or having a bike lock.
Lets say that you generate your software and the people at company "X" pay the license until January of 2020. In the mean time, 40 people who used to work for company "X", decide that it's soooo good that they want to take it to their new site with them. That would be great if you got revenue from that movement, but you can't unless they call you and tell you that they moved the software and their "new" company would like to license it. Also, maybe the people at company "X" decide that they want to defray the cost of the software they licensed from you, so they sell copies on the internet to other sites. It will run until January of 2020, so there is nothing to keep it from happening. I'm not saying that every client is dishonest, but it only takes one person to make it bad for you. Admittedly, this is probably a bit far fetched, but it's late and I'm tired. :)
On the other hand, if you had a check in your module for the CPU Serial number, (and machine type or LPAR name, or any of several limiting factors), the client is in no way harmed or inconvenienced, because it will operate as before with no impediments, save that the software can't be "moved" without your permission.
This should not cause any problems with DR testing or a real disaster because most, (if not all) DR sites run under VM and will simulate the serials and MT for just this purpose. You can also check for running under VM and disallow it (or generate warnings), but that is not normally necessary and gets away from the point I'm making.
Also, your key code needs to take into account that the site might have multiple physical processors (separate mainframes), so you want to make sure that your "key" code supports multiple entries. This will also be useful for those sites that use "friend" arrangements for their DR sites (other companies who share each other's sites as Disaster Recovery sites for each other).
You can/should also add code that temporarily allows the product to function when the key doesn't match, for use as a trial or for when "stuff" happens that the site for some reason needs to use the code on another box "temporarily". You can limit it for a period of time, or number of uses, or whatever you think is reasonable, it's your software, you make the rules, while generating messages that let the site know in no uncertain terms that the the license is not "currently valid".
There are lots of nice features you can add to the key process, and you can do as many vendors have and set up a web page to generate "emergency" keys for, well.... emergencies. The reason is because "stuff happens" and no one is happy if the product can't be used for some reasonable reason and they can't contact the vendor until the next day because no one happens to be on call that night.
If you are going to implement keys, you might as well do it right and make sure you test-test-test the process before you send it out to your client(s). It's a good way to lose them if you mess up something like this. All sites will understand the necessity of you having keys in your software, but no one will understand if it isn't rock solid. It's such a little nit to implement correctly, but all it takes is one error in the key generation program to ruin your day.
Brian
Post by zMan
Brian,
Never thought about Using CPUID and/or machine type as part of a software key.
Generally speaking we try to stay away from tying application to any kind of machine.
Our application is typical Cobol/Asm, Batch/CICS and VSAM/DB2 system.
Cobol 5 was first change in years that required major changes to our application.
Usually a change to the Operating System has no effect on application executing properly.
But having said that, since I didn�t know really what makes up a key and how they work, this is an interesting change in direction and thinking.
Thanks for the ideas.
And thanks for the ofrer of help....I will almost certainly need it.
Thanks,
Tom Savor
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Seymour J Metz
2018-03-08 17:52:59 UTC
Permalink
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-***@listserv.ua.edu> on behalf of Brian Westerman <***@SYZYGYINC.COM>
Sent: Thursday, March 8, 2018 12:21 AM
To: IBM-***@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
Post by 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
________________________________________
Sent: Wednesday, March 7, 2018 12:57 AM
Subject: Re: Product license key program
The problem with just using a date, is that the software could be moved to any machine and duplicated any number of times and you would never know about it to keep it from being unlawfully duplicated without payment.
This doesn't mean that you don't trust your clients. In effect, while some might argue, it's really just like locking your car or your home or having a bike lock.
Lets say that you generate your software and the people at company "X" pay the license until January of 2020. In the mean time, 40 people who used to work for company "X", decide that it's soooo good that they want to take it to their new site with them. That would be great if you got revenue from that movement, but you can't unless they call you and tell you that they moved the software and their "new" company would like to license it. Also, maybe the people at company "X" decide that they want to defray the cost of the software they licensed from you, so they sell copies on the internet to other sites. It will run until January of 2020, so there is nothing to keep it from happening. I'm not saying that every client is dishonest, but it only takes one person to make it bad for you. Admittedly, this is probably a bit far fetched, but it's late and I'm tired. :)
On the other hand, if you had a check in your module for the CPU Serial number, (and machine type or LPAR name, or any of several limiting factors), the client is in no way harmed or inconvenienced, because it will operate as before with no impediments, save that the software can't be "moved" without your permission.
This should not cause any problems with DR testing or a real disaster because most, (if not all) DR sites run under VM and will simulate the serials and MT for just this purpose. You can also check for running under VM and disallow it (or generate warnings), but that is not normally necessary and gets away from the point I'm making.
Also, your key code needs to take into account that the site might have multiple physical processors (separate mainframes), so you want to make sure that your "key" code supports multiple entries. This will also be useful for those sites that use "friend" arrangements for their DR sites (other companies who share each other's sites as Disaster Recovery sites for each other).
You can/should also add code that temporarily allows the product to function when the key doesn't match, for use as a trial or for when "stuff" happens that the site for some reason needs to use the code on another box "temporarily". You can limit it for a period of time, or number of uses, or whatever you think is reasonable, it's your software, you make the rules, while generating messages that let the site know in no uncertain terms that the the license is not "currently valid".
There are lots of nice features you can add to the key process, and you can do as many vendors have and set up a web page to generate "emergency" keys for, well.... emergencies. The reason is because "stuff happens" and no one is happy if the product can't be used for some reasonable reason and they can't contact the vendor until the next day because no one happens to be on call that night.
If you are going to implement keys, you might as well do it right and make sure you test-test-test the process before you send it out to your client(s). It's a good way to lose them if you mess up something like this. All sites will understand the necessity of you having keys in your software, but no one will understand if it isn't rock solid. It's such a little nit to implement correctly, but all it takes is one error in the key generation program to ruin your day.
Brian
Post by zMan
Brian,
Never thought about Using CPUID and/or machine type as part of a software key.
Generally speaking we try to stay away from tying application to any kind of machine.
Our application is typical Cobol/Asm, Batch/CICS and VSAM/DB2 system.
Cobol 5 was first change in years that required major changes to our application.
Usually a change to the Operating System has no effect on application executing properly.
But having said that, since I didn�t know really what makes up a key and how they work, this is an interesting change in direction and thinking.
Thanks for the ideas.
And thanks for the ofrer of help....I will almost certainly need it.
Thanks,
Tom Savor
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
zMan
2018-03-09 03:39:05 UTC
Permalink
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.
Post by 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
________________________________________
Sent: Thursday, March 8, 2018 12:21 AM
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
Post by Seymour J Metz
Simulating the CPUID may violate the license agreement. If you're going
to use keys, explicitly address the issue.
Post by Seymour J Metz
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
________________________________________
Sent: Wednesday, March 7, 2018 12:57 AM
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.
Post by Seymour J Metz
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.
Post by Seymour J Metz
Lets say that you generate your software and the people at company "X"
pay the license until January of 2020. In the mean time, 40 people who
used to work for company "X", decide that it's soooo good that they want to
take it to their new site with them. That would be great if you got
revenue from that movement, but you can't unless they call you and tell you
that they moved the software and their "new" company would like to license
it. Also, maybe the people at company "X" decide that they want to defray
the cost of the software they licensed from you, so they sell copies on the
internet to other sites. It will run until January of 2020, so there is
nothing to keep it from happening. I'm not saying that every client is
dishonest, but it only takes one person to make it bad for you.
Admittedly, this is probably a bit far fetched, but it's late and I'm
tired. :)
Post by Seymour J Metz
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.
Post by Seymour J Metz
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.
Post by Seymour J Metz
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).
Post by Seymour J Metz
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".
Post by Seymour J Metz
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.
Post by Seymour J Metz
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.
Post by Seymour J Metz
Brian
On Tue, 6 Mar 2018 21:02:37 +0000, Savor, Thomas (Alpharetta) <
Post by zMan
Brian,
Never thought about Using CPUID and/or machine type as part of a
software key.
Post by Seymour J Metz
Post by zMan
Generally speaking we try to stay away from tying application to any
kind of machine.
Post by Seymour J Metz
Post by zMan
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.
Post by Seymour J Metz
Post by zMan
Usually a change to the Operating System has no effect on application
executing properly.
Post by Seymour J Metz
Post by zMan
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.
Post by Seymour J Metz
Post by zMan
Thanks for the ideas.
And thanks for the ofrer of help....I will almost certainly need it.
Thanks,
Tom Savor
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
--
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Mike Schwab
2018-03-09 07:20:30 UTC
Permalink
https://en.wikipedia.org/wiki/Gopher_wood
The wood used in Noah's Ark. Location believed to be Eastern Turkey
or Northern Iraq
Post by 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.
Post by 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
________________________________________
Sent: Thursday, March 8, 2018 12:21 AM
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
Post by Seymour J Metz
Simulating the CPUID may violate the license agreement. If you're going
to use keys, explicitly address the issue.
Post by Seymour J Metz
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
________________________________________
Sent: Wednesday, March 7, 2018 12:57 AM
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.
Post by Seymour J Metz
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.
Post by Seymour J Metz
Lets say that you generate your software and the people at company "X"
pay the license until January of 2020. In the mean time, 40 people who
used to work for company "X", decide that it's soooo good that they want to
take it to their new site with them. That would be great if you got
revenue from that movement, but you can't unless they call you and tell you
that they moved the software and their "new" company would like to license
it. Also, maybe the people at company "X" decide that they want to defray
the cost of the software they licensed from you, so they sell copies on the
internet to other sites. It will run until January of 2020, so there is
nothing to keep it from happening. I'm not saying that every client is
dishonest, but it only takes one person to make it bad for you.
Admittedly, this is probably a bit far fetched, but it's late and I'm
tired. :)
Post by Seymour J Metz
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.
Post by Seymour J Metz
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.
Post by Seymour J Metz
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).
Post by Seymour J Metz
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".
Post by Seymour J Metz
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.
Post by Seymour J Metz
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.
Post by Seymour J Metz
Brian
On Tue, 6 Mar 2018 21:02:37 +0000, Savor, Thomas (Alpharetta) <
Post by zMan
Brian,
Never thought about Using CPUID and/or machine type as part of a
software key.
Post by Seymour J Metz
Post by zMan
Generally speaking we try to stay away from tying application to any
kind of machine.
Post by Seymour J Metz
Post by zMan
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.
Post by Seymour J Metz
Post by zMan
Usually a change to the Operating System has no effect on application
executing properly.
Post by Seymour J Metz
Post by zMan
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.
Post by Seymour J Metz
Post by zMan
Thanks for the ideas.
And thanks for the ofrer of help....I will almost certainly need it.
Thanks,
Tom Savor
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
--
zMan -- "I've got a mainframe and I'm not afraid to use it"
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
--
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
zMan
2018-03-09 15:54:25 UTC
Permalink
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?
Post by 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
Post by zMan
Where was Gopher Wood? Is that near Norwegian Wood? What kind of market
did
Post by zMan
they have that Noah cornered? Or was Noach someone different?
Inquiring minds want to know.
Post by 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
Post by zMan
Post by Seymour J Metz
CPUID since old man Noach cornered the market in Gopher Wood.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
________________________________________
behalf
Post by zMan
Post by Seymour J Metz
Sent: Thursday, March 8, 2018 12:21 AM
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
Post by zMan
Post by Seymour J Metz
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
Post by zMan
Post by Seymour J Metz
or not to allow it and under what circumstances and for how long.
Brian
Post by Seymour J Metz
Simulating the CPUID may violate the license agreement. If you're going
to use keys, explicitly address the issue.
Post by Seymour J Metz
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
________________________________________
behalf
Post by zMan
Post by Seymour J Metz
Post by Seymour J Metz
Sent: Wednesday, March 7, 2018 12:57 AM
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
Post by zMan
Post by Seymour J Metz
about it to keep it from being unlawfully duplicated without payment.
Post by Seymour J Metz
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.
Post by Seymour J Metz
Lets say that you generate your software and the people at company "X"
pay the license until January of 2020. In the mean time, 40 people who
used to work for company "X", decide that it's soooo good that they
want to
Post by zMan
Post by Seymour J Metz
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
Post by zMan
Post by Seymour J Metz
that they moved the software and their "new" company would like to
license
Post by zMan
Post by Seymour J Metz
it. Also, maybe the people at company "X" decide that they want to
defray
Post by zMan
Post by Seymour J Metz
the cost of the software they licensed from you, so they sell copies on
the
Post by zMan
Post by Seymour J Metz
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. :)
Post by Seymour J Metz
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
Post by zMan
Post by Seymour J Metz
operate as before with no impediments, save that the software can't be
"moved" without your permission.
Post by Seymour J Metz
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
Post by zMan
Post by Seymour J Metz
VM and disallow it (or generate warnings), but that is not normally
necessary and gets away from the point I'm making.
Post by Seymour J Metz
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).
Post by Seymour J Metz
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"
Post by zMan
Post by Seymour J Metz
happens that the site for some reason needs to use the code on another
box
Post by zMan
Post by Seymour J Metz
"temporarily". You can limit it for a period of time, or number of
uses,
Post by zMan
Post by Seymour J Metz
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".
Post by Seymour J Metz
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"
Post by zMan
Post by Seymour J Metz
keys for, well.... emergencies. The reason is because "stuff happens"
and
Post by zMan
Post by Seymour J Metz
no one is happy if the product can't be used for some reasonable reason
and
Post by zMan
Post by Seymour J Metz
they can't contact the vendor until the next day because no one happens
to
Post by zMan
Post by Seymour J Metz
be on call that night.
Post by Seymour J Metz
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
Post by zMan
Post by Seymour J Metz
software, but no one will understand if it isn't rock solid. It's such
a
Post by zMan
Post by Seymour J Metz
little nit to implement correctly, but all it takes is one error in the
key
Post by zMan
Post by Seymour J Metz
generation program to ruin your day.
Post by Seymour J Metz
Brian
On Tue, 6 Mar 2018 21:02:37 +0000, Savor, Thomas (Alpharetta) <
Post by zMan
Brian,
Never thought about Using CPUID and/or machine type as part of a
software key.
Post by Seymour J Metz
Post by zMan
Generally speaking we try to stay away from tying application to any
kind of machine.
Post by Seymour J Metz
Post by zMan
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.
Post by Seymour J Metz
Post by zMan
Usually a change to the Operating System has no effect on application
executing properly.
Post by Seymour J Metz
Post by zMan
But having said that, since I didn�t know really what makes up a key
and
Post by zMan
Post by Seymour J Metz
how they work, this is an interesting change in direction and thinking.
Post by Seymour J Metz
Post by zMan
Thanks for the ideas.
And thanks for the ofrer of help....I will almost certainly need it.
Thanks,
Tom Savor
----------------------------------------------------------
------------
Post by zMan
Post by Seymour J Metz
Post by Seymour J Metz
Post by zMan
For IBM-MAIN subscribe / signoff / archive access instructions,
IBM-MAIN
Post by zMan
Post by Seymour J Metz
Post by Seymour J Metz
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
--
zMan -- "I've got a mainframe and I'm not afraid to use it"
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
--
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,
--
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Brian Westerman
2018-03-09 04:38:58 UTC
Permalink
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
Post by 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
________________________________________
Sent: Thursday, March 8, 2018 12:21 AM
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
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
________________________________________
Sent: Wednesday, March 7, 2018 12:57 AM
Subject: Re: Product license key program
The problem with just using a date, is that the software could be moved to any machine and duplicated any number of times and you would never know about it to keep it from being unlawfully duplicated without payment.
This doesn't mean that you don't trust your clients. In effect, while some might argue, it's really just like locking your car or your home or having a bike lock.
Lets say that you generate your software and the people at company "X" pay the license until January of 2020. In the mean time, 40 people who used to work for company "X", decide that it's soooo good that they want to take it to their new site with them. That would be great if you got revenue from that movement, but you can't unless they call you and tell you that they moved the software and their "new" company would like to license it. Also, maybe the people at company "X" decide that they want to defray the cost of the software they licensed from you, so they sell copies on the internet to other sites. It will run until January of 2020, so there is nothing to keep it from happening. I'm not saying that every client is dishonest, but it only takes one person to make it bad for you. Admittedly, this is probably a bit far fetched, but it's late and I'm tired. :)
On the other hand, if you had a check in your module for the CPU Serial number, (and machine type or LPAR name, or any of several limiting factors), the client is in no way harmed or inconvenienced, because it will operate as before with no impediments, save that the software can't be "moved" without your permission.
This should not cause any problems with DR testing or a real disaster because most, (if not all) DR sites run under VM and will simulate the serials and MT for just this purpose. You can also check for running under VM and disallow it (or generate warnings), but that is not normally necessary and gets away from the point I'm making.
Also, your key code needs to take into account that the site might have multiple physical processors (separate mainframes), so you want to make sure that your "key" code supports multiple entries. This will also be useful for those sites that use "friend" arrangements for their DR sites (other companies who share each other's sites as Disaster Recovery sites for each other).
You can/should also add code that temporarily allows the product to function when the key doesn't match, for use as a trial or for when "stuff" happens that the site for some reason needs to use the code on another box "temporarily". You can limit it for a period of time, or number of uses, or whatever you think is reasonable, it's your software, you make the rules, while generating messages that let the site know in no uncertain terms that the the license is not "currently valid".
There are lots of nice features you can add to the key process, and you can do as many vendors have and set up a web page to generate "emergency" keys for, well.... emergencies. The reason is because "stuff happens" and no one is happy if the product can't be used for some reasonable reason and they can't contact the vendor until the next day because no one happens to be on call that night.
If you are going to implement keys, you might as well do it right and make sure you test-test-test the process before you send it out to your client(s). It's a good way to lose them if you mess up something like this. All sites will understand the necessity of you having keys in your software, but no one will understand if it isn't rock solid. It's such a little nit to implement correctly, but all it takes is one error in the key generation program to ruin your day.
Brian
Post by zMan
Brian,
Never thought about Using CPUID and/or machine type as part of a software key.
Generally speaking we try to stay away from tying application to any kind of machine.
Our application is typical Cobol/Asm, Batch/CICS and VSAM/DB2 system.
Cobol 5 was first change in years that required major changes to our application.
Usually a change to the Operating System has no effect on application executing properly.
But having said that, since I didn�t know really what makes up a key and how they work, this is an interesting change in direction and thinking.
Thanks for the ideas.
And thanks for the ofrer of help....I will almost certainly need it.
Thanks,
Tom Savor
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Loading...