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.
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Wayne Bickerdike
We always have issues during DR with licence keys.
Worst vendor is Compuware, convoluted process and activation procedure.
We like to expose "novice" users to the DR process, it's a test of documentation and process, not systems skills.
One vendor had the cheek to tell us to give more warning. I told them we are testing you as much as DR.
Don't mind CA, they don't disable just give warnings.
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.