1. Been There Done That, Got The Scars
2. Whether the vendors were bad or not is irrelevant; the keys were an
additional risk factor.
3. The issue is risk, not assigning blame.
4. And I asked you to stop putting words in my mouth.
5. " than tell me that my promises are "worthless" solely because I'm a
vendor."
There you go again. If you want me to be civil, then you have to be civil,
and
that includes not attributing things to me that I didn't write.
6. "but you must also take into account what the vendor has to be concerned
with."
No, I don't. If the product doesn't suit my needs then I don't acquire it,
regardless
of why the vendor made the decisions he made.
7. " Also, we still don't know that you didn't get "what you paid for"."
Who is we? Those who read my posts instead of going into denial understood.
Which part of " the vendor failed to respond within the contractually
guarantied time window."
didn't you understand?
8. " If this were a test and you sent them the information and they sent you a
bad key, so what?
Just call them up and get it fixed. "
Why are you pretending to respond to what I wrote when you obviously
weren't paying attention.
I told you; we did call, the contract required them to responded within a
stipulated interval
and they didn't.
9. "If you expected them to be 24x7 and they are not, is that their fault or
yours?"
When the expectation is based on a contractual requirement that they be
24x7,
whose fault do you think it is?
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
________________________________________
From: IBM Mainframe Discussion List <IBM-MAIN@listserv.ua.edu> on behalf of
Brian Westerman <brian_wester...@syzygyinc.com>
Sent: Monday, March 5, 2018 3:02 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: Product license key program
Hi Shmuel,
Sorry to be slow, I don't know what BTDT,GTS means.
Also, this discussion is supposed to be about keys and whether they are
justified or bad or good or "whatever". If you had a bad vendor, then whether
or not they had keys in their software is almost irrelevant. If the vendor
screwed up in some way and it was 100% their fault, then shame on them, but you
should not really blame keys for the rest of your life just because some vendor
screwed up and didn't call you back in time.
If you have an agreement with a vendor to supply you with DR keys, and you did
everything you were supposed to do, (i.e. you called them with the "correct" DR
CPU info, and you notified them as soon as you could that the DR event
started), then I would have to agree with you that it sounds like they screwed
up badly if you were without keys for an extended period of time. By extended
I mean anything over 30 minutes. If, on the other hand, you didn't have a good
DR plan that included contacting your vendors (all of them, whether they have
keys or not), then you plan is already flawed and any delays you experience are
partly if not all your own fault. You might be about to complain that no one
knows of a disaster ahead of time and calling ahead of time for a DR test is
not a "real" test of the plan, but you are wrong. Part of a "good" DR plan is
supposed to be stuff that you do all the time before the Disaster strikes,
which is more than just running FDR every day.
I have been part to literally hundreds of DR tests and thankfully only a
handful of actual disasters. I was at a foreign country site one day when
someone tossed a hand grenade into the command tent where the "datacenter" was
located. Let me tell you, getting vendors to call you back to the Middle East
ain't easy, so you have to be sure you have have your DR plan ready to go.
You should have (somewhere in the DR "bible" book) all of the contact
information for the vendor and someone is "supposed" to make sure it's tested
periodically for validity, (vendors change offices and numbers too). Also, if
your vendor used to be 24x7 and now they aren't, it's your responsibility (as
part of the DR plan) to know that. The vendor might have sent out a email
"blast" to tell you about it 6 months before, but everyone knows that no one
reads the crap from a vendor so missing it is a possibility that should have
been addressed int he DR plan. If it wasn't, then that's also a flawed plan.
I'm not trying to say that your vendor didn't screw up royally. I'm just
saying that it's not logical to blame all vendors that use keys for something
that one vendor did, which may not even be entirely their fault, and if you
"should" have kept this from happening in your DR plan itself, then you need to
accept at least part of the responsibility.
Now back to the numbered stuff:
1) Some vendor promises are indeed worthless, but then so are a lot of other
people's promises (for instance, car salesmen), so why would you expect more or
less from a vendor? All promises are worthless if they cannot be relied upon.
Having keys or not having keys is not going to make them a "better" or "worse"
vendor. I'm a vendor, and I like to think that if I give my word on something,
it's more important than the contract.
Your statement says that my promises are worthless, solely because I'm a
vendor. I'm also a systems programmer with almost certainly MUCH more
experience than you, solely because of my training and the fact that I have
worked in many more environments, and also perform contracts for most of the
bigger vendors (IBM, CA, ASG, Sterling, Candle, and many, many others over the
years) so I know most of their software quiet well. I was trained by the best
people in the world when it comes to IBM operating systems, IBM. My teachers
were some of the internal IBM developers in OS/VS1&2 and MVT and MVS. I have
worked for and with them in IBM development and later, Level2, for JES, IOS,
HSM, SMS and several other areas, as well as having developed a lot of code
that runs in every z/OS system that exists today. I was, and still am, both an
IBM business partner and internals developer. I have met good vendors and bad
vendors, I have met good people and bad people, I have met people with big guns
who would sooner kill me and defecate on my remains and I have met people also
with big guns in uniform (and out) who make sure that the other ones don't get
me, but I would never make statements like you have about someone whom I have
never even met and not feel very bad or very stupid for doing so.
I asked you to be calm and civil and I am asking again, if you can't force
yourself to do that, then just don't reply. If you want to have a civil
conversation about the good and bad of keys then I'm willing to do so. If you
want to rant and rave, then you have the wrong forum for that. I believe
that's what Facebook, Snapchat and Twitter are for. You complained about my
making sweeping generalizations and "straw dummies' than tell me that my
promises are "worthless" solely because I'm a vendor. You don't even know me
so you are not qualified to make that statement. I'm not going to ask you to
"take it back" I'm just asking that you try to remain civil and calm, and try
to think before you say something hurtful and untrue. Deal?
2) So was this is an isolated incident which has riled you up so that you are
against keys in general solely because one vendor screwed up one time? All
vendors or all keys are bad because you had a bad experience one day? Wow,
that would really suck for you were that the actual facts of this. Many
reasons are possible for your DR problem, and I'm only guessing because you
have not offered more information as I have asked. The problem could be
anything from someone had the flu to there was a power outage somewhere,
including your own people could be responsible for passing on incorrect CPU
information. I'm not saying that happened, but as of yet you have not offered
the details I asked for about the event.
Also, I think we must be talking about a time long in the past because most DR
sites simulate the important information which is used by the keys. Although I
suppose some might not, it would be kind of odd nowadays. There are also sites
which make deals with other sites ("friend" sites) to be each other's DR site,
where they allow the site with the disaster to use their box. In a case like
that, while is seems harmless to generate the "alternate" keys, the vendor is
actually taking a big risk that the "other" site won't keep their software.
I'm not saying that they will, just that it's possible and the vendor is
trusting you. They don't have to do that for the client, but most do because
"most' of the vendors are trusting of our clients. Also, I am assuming that
you must have had something in "writing" as to how long the vendor had to
respond to issues from you, did you, if so how long? If so,what time are we
talking that they took vs what they agreed to with you? Did the vendor have
24x7 support and you didn't get it from them? That doesn't make the keys bad,
it makes the vendor bad.
3) What you, as the client are concerned with IS important, but you must also
take into account what the vendor has to be concerned with. Also, we still
don't know that you didn't get "what you paid for". Maybe you didn't pay for
24x7 support, or maybe it diesn't even apply to this "problem". You still have
not said what the cause of the problem was. Although I have a pretty good
sense that the problem was not the keys in this instance but someone falling
down on the job, either on your side or the vendors. Again, I think this
entire thing might be due to a single occurrence where a bad key was generated
and you had some problem(s) getting the vendor to give you a new one in a
reasonable amount of time. If that is so, then while I am sorry for your loss
of time, I can't see the logic in disparaging all vendors that use keys in
their software just because you had a bad experience one day. Most real DR
situations are such that no one wants to be inconvenienced by some stupid
mistake, but they happen. I'm sure, at least I hope so, that the vendor didn't
screw up your keys on purpose. What would be the value in that?
4) Assuming that the bad keys were the vendor's fault and the vendor was unable
or unwilling to generate replacement within a reasonable amount of time, then I
think you would have a point. I have no way of knowing that your people
provided correct information, but I do know that generating keys (for all
vendors that I know of) is a process that takes less than 1 minute. If this
were a test and you sent them the information and they sent you a bad key, so
what? Just call them up and get it fixed. Did you never make a mistake in
your life that affected someone else and you made them wait? If this were a
"test" DR event, and you did not inform your vendor about it in advance to make
sure they had 24x7 coverage for you, then you would be a least partially at
fault for the problem of not being able to reach them (assuming it was
off-hours). If it's a real emergency and they didn't have 24x7 support, then
you are still partly at fault for not contacting them much earlier in your DR
plan. I have been a Systems Programmer for a very long time, and have
undoubtedly worked at more sites and conducted far more disaster recovery plans
and events than any sane person would ever hope to do, and all of them contain
steps at the beginning that make sure to remind whoever is performing the work
(because the main people could also have experienced a personal disaster), to
contact ALL of the vendors to alert them that we are a) performing a test DR in
xx minutes from now, or b) we have a real disaster and we want them to know
that we expect them to be ready for us to call.
It's not just a matter of will the vendors software work, but in a disaster,
you need to have someone who knows how the software works (really works) on tap
because you won't have time to fumble through manuals (that you probably won't
have anyway), to find some esoteric command string to use their product. You
could be dead, so it doesn't matter how well you know how to use CA-1 or Adabas
or SMS. If you don't cover it in your DR plan then YOU messed up. If you
didn't contact the vendors before and at the beginning of your plan, then YOU
messed up. If you did everything you were supposed to, and the vendor fell
down on the job, then that's bad for them, but you still have to deal with it.
Waiting 10 or 20 years to complain about keys as being "bad" that day isn't
going to fix the fact that your DR plan didn't take into account to call the
vendors and make sure you had them on tap. It sure doens't mean all vendors
promises are worthless because you didn't handle the situation correctly.
I don't know that you didn't handle it right, you still have not said exactly
what happened and how it was the fault of the keys. It will be interesting if
you ever get to that part of your story.
If you didn't crate a good and detailed strong plan, then your plan is doomed
to fail, unless you are very lucky.
5) You didn't answer the question posed. You can't just flippantly make
statements (remember you said Russian roulette), and then complain that I am
the one that keeps going off subject. When I add multiple seemingly silly
questions, it's because I'm trying to figure out what you mean by your
response. I could just say "What are you talking about?", but that would be
rude.
6) One event is not evidence of keys being at fault. Actually you have not
fully explained the event anyway. If it was a test and you didn't contact the
vendor at the beginning of the event, then that's a double-dog-shame on you.
If you did contact them and they blew you off, then it's time to find a new
vendor. If you contacted them and it was off hours for them, then that falls
back into your court for being wrong because you failed to plan your test. If
you were trying to simulate a "real" event by not contacting them ahead of
time, and then didn't contact them at your earliest convenience when you got to
the DR site, then it falls back on you. If you didn't call months before to
find out their days and hours of operation, then you screwed up, not them. If
you did contact them, and they didn't blow you off, and they couldn't get you a
key in 30 minutes or less, then that would be a failure that they have to
answer for.
If you expected them to be 24x7 and they are not, is that their fault or yours?
I guess that would depend on whether or not they told you they were 24x7.
We had a disaster once when I was helping Levi Strauss test a about to be
released mainframe, and the day I got there they got flooded, so we "declared a
disaster" and moved to their backup site (which was a "Friend Site", not a
normal DR site) about 25 miles away. Unfortunately, one of their vendors was
also caught in the same flood, and the "friend" DR site had changed CPU's since
their last test so their pre-built and tested keys didn't work and we couldn't
get new ones because the vendor had not yet recovered. What did we do? We
called the vendor and knew of their problem before we even arrived at the DR
site, they worked on getting us a new key and by the time we needed the new
key, they had generated one for us. It "could" have been a very bad
experience, but turned out just fine. Levi Strauss did not have the steps to
call their vendors, but they did have the numbers for them on the back pages of
the DR plan, and I called the vendors myself. The upshot was that they added
that step to their DR plan and they were more chagrined that they forgot
something so simple that they were not mad at the vendor at all.
7) But you still have never said "why" they didn't work. Was it a bad key, or
something about the DR CPU that didn't match the plans, or was it something
else. How much time was lost, 5 minutes, 1 hour, the whole day, it makes a
difference. If it only cost you a short wait, then that's unfortunate, but you
know, sometimes things happen that you just have to roll with. If it was more
than a short wait, then it comes down to "why" was it longer? Was it the
middle of the night and the vendor didn't have 24x7 access? Again, that's part
of a DR plan to make sure you KNOW your vendor's office hours and contact
procedures. It's not the vendor's job to work on your DR plan. If you messed
up the plan, then you can't really blame that on the keys.
8) Not entirely true. If the keys were bad because the site provided the
wrong CPU information, then that is not the vendor's fault. If the key was
never generated until that day (the day of the Disaster), then that is not the
vendor's fault either. I can think of several plausible scenarios where the
vendor is not at fault, and only a couple where it is their fault. I have been
on both sides of this coin and I can tell you that bad keys are generated ALL
THE TIME, it happens to every vendor, but on the other hand, it's not normally
a big deal to get them fixed.
9) I'm just down on CA, but I have nothing against the way they do their keys
either.
10) Still waiting on the details. It's hard to comment here without them.
Your statement : "Bottom line: keys are bad because historically they have
caused problems for legitimate users, often problems that the vendor had
promised wouldn't occur." has no current proof or even anecdotal validity. If
one key caused a problem for one user, that doesn't make them all bad.
Now this next part is trying to point out in a sarcastic way how unfair and (to
me) silly your "bottom line" statement is so don't take this part personally:
I get the newspaper from the Big Island of Hawaii where we own a vacation home.
I just read today that since January 1st, 5 people have died on Hawaii's
roadways, and 4 of those 5 were people that were "walking in the highway", 3 of
them were walking between 2am and 5 am and 1 was at 10p. Hawaii is supposedly
"up in arms" that their highways are so unsafe that people can't walk home any
more in safety. I'm struck by the facts of this article. Doesn't any one
wonder why 4 people were walking in the middle of the road? They were not
"crossing the road" they were walking smack dab in the middle of the highway,
they made it clear that the people were at fault back when each of the deaths
happened. Two of them were a husband and wife who exited their car and were
arguing int he middle of the highway (alcohol was assumed to be a factor, but
not of the driver that hit them), and both of the others were (drugs being a
big factor) just wandering down the middle of the highway, apparently stoned,
but the op-ed editor wants to blame it on the county that the roads are unsafe
to walk on.
I am struck by how similar (with the admittedly little I know of your event)
that vendor keys to protect doftware and the safety of walking down the
Highways of Hawaii are.
Brian
On Sun, 4 Mar 2018 19:55:30 +0000, Seymour J Metz <sme...@gmu.edu> wrote:
> 1. BTDT,GTS - I'm not talking ideology or abstract theory, but history.
> Vendor promises are worthless when push comes to shove.
>
> 2. In the incidents I was referring to we *did* get the keys in advance;
> they didn't work and the vendor failed to respond within the contractually
> guarantied time window. That's why I asked about how you handled
> DR tests.
>
> 3. I'm not concerned with the customer who has delayed renewing, I'm
> concerned with the customer who is fully paid up and doesn't get what he
> paid for.
>
> 4. "To indemnify for or from what exactly?" The cost of the DR facilities
> that could be
> tested because of the bad keys would have been a start.
>
> 5. "what associated risk? The risk that they will not pay their license fee
> and therefore
> lose the use of the software?"
>
> More straw dummies. Stop trying to put words in my mouth.
>
> 6. "you are assuming that the Key or the requirement thereof will somehow,
> through the
> fault of the "key", cause an outage. ".
>
> No, *you* are assuming that I don't have empirical evidence. See item 2
> above.
>
> 7. "4) What about it? They paid for the key, it's implemented, and it works."
> Were that true I wouldn't have commented. We paid for the keys, it was
> implemented
> and it *didn't* work.
>
> 8. "and not a generation issue or some other purely human factor?"
> From the customer perspective the vendor is a black box; he doesn't
> care whether the outage cased by the vendor was due to hardware,
> software or human error.
>
> 9. "I don't think most vendors try to tell the client what metrics to use in
> evaluation (aside from CA maybe:))"
>
> CA never had the nerve to patronizingly dismiss our concerns. They accepted
> them as legitimate and addressed them as best they could.
>
>10. "6) What danger inherent in the enforcement method? "
> See item 2 above.
>
>11. "The key works or it doesn't, if it doesn't, either it expired, the
> software has been altered or changed or it never worked in the first
> place. "
> How do you propose that the customer tests whether a DR key works prior
> to going to the DR site and testing?
>
>12. " I really don't mean to sound flippant, but sending software out without
>keys
> would be similar (maybe only to me) as Ford sending out all of their cars
> without
> an ignition key or secure button. "
> Only to you; Ford doesn't try to lock its customer out of the car.
>
>Bottom line: keys are bad because historically they have caused problems for
>legitimate users, often problems that the vendor had promised wouldn't occur.
>
>--
>Shmuel (Seymour J.) Metz
>http://mason.gmu.edu/~smetz3
>
>________________________________________
>From: IBM Mainframe Discussion List <IBM-MAIN@listserv.ua.edu> on behalf of
>Brian Westerman <brian_wester...@syzygyinc.com>
>Sent: Saturday, March 3, 2018 1:22 AM
>To: IBM-MAIN@listserv.ua.edu
>Subject: Re: Product license key program
>
>Hi Shmuel, this is just a friendly discussion, and I know I tend to have a
>odd sense of humor sometimes, so please don't take any of what I mean as
>levity as something personal. I really am trying to understand your point.
>If you can convince me that there is some inherent danger in using keys, then
>I will address the problem and see about coming up with something that removes
>the danger but still provides protection for the vendor. Just because vendors
>have used keys for years (and years) doesn't make it right, nor does it make
>it wrong, that's why I'm trying to understand your side of this. I think I'm
>fairly smart, and if I had to come up with a substitute for keys, I could
>probably do it, but I'm sure you understand that I don't want to waste time on
>something that might be unnecessary.
>
>I have heard people complain from time to time about keys, but normally it's
>because of something not related to the keys themselves like it was
>"inconvenient" to get their purchasing department to send the check on time.
>That stuff happens, but it's not the fault of the keys, and in fact, sadly it
>tends to make vendors feel better about having the key there in the first
>place because it's the "reminder" to the client to "pay their bills" on time.
>I'm sure you can understand that vendors deal with that event all the time,
>and it's sad to say, but like your local plumber, we/they have "heard it all
>before". Sometimes giving the extra 30 days and allowing the client to get a
>temporary 14 day key after that still isn't enough, and we, (as do most other
>vendors) have procedures to extend it even more, but at some point you have to
>be able to "draw the line".
>
>Is that ins some way unreasonable? If so, why?
>
>Now to the meat of things:
>
>You said "Are you willing to put an indemnification clause in your
>contracts?". To indemnify for or from what exactly?
>
>One point on indemnification,and contracts in general, is if both parties of a
>are not contract equally, or more to the point equitably, or no "special"
>compensation for that inequality is clearly defined (this is simple contract
>law, and yes, unfortunately I do have a law degree and my son is a practicing
>lawyer), then the clause is invalid, thus, if the site wants to be
>indemnified, they would have to likewise indemnify the vendor or provide some
>"special" compensation for that accommodation. The "special" compensation is
>not just the "price of the product", so don't say they are "(over) compensated
>already, so that's the compensation part":). For instance, (and this event
>has happened many times to many vendors), if a site were to allow (through
>their actions or even due to no "action" at all), the vendor's software to be
>used at another site, even an "alternate" site of their own (but that's
>getting off the point), and "anything" is "damaged" or "damages" are incurred,
>including loss of revenue for the vendor (because of the theft of the
>software), then the site would have to accept full responsibility.
>
>I can't think of any site that would ever agree to that. Likewise, expecting
>any vendor to agree to indemnify a site for unforeseen and unspecified
>damage(s), is never going to be able to be enforceable. Any unenforceable
>part of a contract is (by simple definition) not enforceable and therefore
>invalid.
>
>Why place a clause into a contract that has no chance at all of being
>enforceable? it cheapens the contract and the ability of either party,
>especially the one who wrote it in the first place to enforce it.
>
>also, in response to your numbered points:
>
>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
>
>
>
> On Thu, 1 Mar 2018 22:04:06 +0000, Seymour J Metz <sme...@gmu.edu> wrote:
>
>> 1. The people who object to keys do so because of the associated risk.
>>
>>2. 'You can't over simplify the issue and decide categorically that all
>>vendors
>> that want to "protect" their software are bad. ' implies that somebody
>> has made
>> such a claim; that's the straw dummy in question.
>>
>> 3. The collateral damage is the inability to use the software that they are
>> paying for
>> and the outage to everything dependent on that software.
>>
>> 4. The issue is not the licensing terms; the issue is what happens to a
>> customer who
>> has paid the fee.
>>
>> 5. No, our difference is that I believe that the customer has no obligation
>> to play
>> Russian Roulette.
>>
>> 6. The issue isn't the rules, it's the danger inherent in the enforcement
>> method.
>>
>>" If you can do it without losing your temper or being condescending"
>>
>>PKB. Don't misrepresent my position if you want me to be polite.
>>
>>"or if you want to be sarcastic "
>>
>>PKB. If you don't want sarcastic responses, then don't make sarcastic posts.
>>
>>"and/or virulent "
>>
>>There's nothing wrong with refusing to buy a product that doesn't suit my
>>needs. You get to set whatever rules you want for the use of your software,
>>provided that you disclose them up front, but you don't get to tell the
>>customer what metrics to use in evaluating his requirements.
>>
>>"because I still really do want to try to understand your points."
>>
>>Then pay attention when I write that keys impose a risk on the customer, and
>>that the customer gets to decide how significant that risk is. Are you
>>willing to put an indemnification clause in your contracts?
>>
>>
>>--
>>Shmuel (Seymour J.) Metz
>>http://mason.gmu.edu/~smetz3
>>
>>________________________________________
>>From: IBM Mainframe Discussion List <IBM-MAIN@listserv.ua.edu> on behalf of
>>Brian Westerman <brian_wester...@syzygyinc.com>
>>Sent: Wednesday, February 28, 2018 1:51 AM
>>To: IBM-MAIN@listserv.ua.edu
>>Subject: Re: Product license key program
>>
>>You lost me Shmuel,
>>
>>I don't think I misrepresented the people who object to keys, at least not on
>>purpose. I don't understand the straw dummy reference and I honestly don't
>>understand the objection to a vendor using keys for their product(s).
>>
>>What collateral damage is cause by a vendor's use of keys in their software?
>>The keys are there to "lock" the software to the system it was licensed for.
>>If the software is moved, or used in other creative means without permission
>>from the vendor (who we must remember, owns the software), then it
>>(theoretically) won't work on that "other" platform. I guess I'm missing the
>>damage part of that. Do you mean disaster recovery keys? I think every
>>vendor has that covered by now, but maybe they don't, and again, it's their
>>software, if they don't want to allow that use, and they let you know up
>>front, then whats the damage?
>>
>>There are many parts (I guess types of keys makes more sense) of vendors keys
>>that I don't agree with, and I don't personally think that software in and of
>>itself should cost more for one processor than another, regardless of
>>processor size, but that's just my personal feeling. If a vendor wishes to
>>price their software that way, then it's completely their decision.
>>
>>Possibly our difference of opinion is because I see the vendor's product as
>>belonging to the vendor, not unlike my "locking your car or house" analogy.
>>It's not like the vendor is locking other software, just their own. At least
>>I hope so. If the vendor wants to lock their software so that it isn't
>>"misused", (and specifying what "misused" means is 100% the software vendor's
>>decision). Then, as they "own" the software, it's up to them to say what
>>those rules are. They need to be up front on the rules, even if they are
>>unreasonable rules, otherwise the contract for the software would be invalid
>>anyway under the "meeting of the minds" concept of contract law.
>>
>>If a site "purchased" the software instead of licensed (or rented) it, then I
>>believe you are 100% correct that the software vendor loses the right to lock
>>it up. I don't think many vendors sell their software that way though, it
>>would not be cost effective for either party.
>>
>>So, I really do want you to educate me on this. If you can do it without
>>losing your temper or being condescending, then I would like to do it here,
>>publicly, so that others can understand as well.
>>
>>On the other hand, if you can't discuss it calmly, or if you want to be
>>sarcastic and/or virulent about it, then feel free to send me the discussion
>>points offline, because I still really do want to try to understand your
>>points.
>>
>>Sincerely,
>>
>>Brian
>>
>>
>>
>>
>>On Tue, 27 Feb 2018 21:44:45 +0000, Seymour J Metz <sme...@gmu.edu> wrote:
>>
>>>You can, and did, misrepresent the position of those who object to license
>>>keys. The issue isn't protecting the software; the issue is the means used
>>>to do so and the collateral damage from those means.
>>>
>>>If you have someone willing to steal your product, then he will also be
>>>willing to patch it to bypass the license check? Illegal, sure, and I hope
>>>that you nail anybody who does so, but still inevitable.
>>>
>>>As for support of stolen copies, that's a separate issue from preventing the
>>>product from running. Use of keys et al in the support process doesn't have
>>>the same potential for collateral damage.
>>>
>>>Microsoft? They have a vested interest in lying about their reasons; they
>>>want to force bundling, and have been very successful at it.
>>>
>>>Of course, after inventing straw dummies and openly being facetious you ar
>>>likely to get sarcastic replies; if you didn't want sarcasm then you should
>>>have used honest and polite argument.
>>>
>>>--
>>>Shmuel (Seymour J.) Metz
>>>http://mason.gmu.edu/~smetz3
>>>
>>>________________________________________
>>>From: IBM Mainframe Discussion List <IBM-MAIN@listserv.ua.edu> on behalf of
>>>Brian Westerman <brian_wester...@syzygyinc.com>
>>>Sent: Monday, February 26, 2018 9:27 PM
>>>To: IBM-MAIN@listserv.ua.edu
>>>Subject: Re: Product license key program
>>>
>>>If someone violates a copyright, there are legal and I think criminal
>>>penalties. But I doubt the FBI will get involved if you decided not to pay
>>>CA for using Panvalet.
>>>
>>>You can't over simplify the issue and decide categorically that all vendors
>>>that want to "protect" their software are bad. Just like people, there are
>>>indeed some bad vendors, whether or not they have product "protection"
>>>doesn't enter into the equation.
>>>
>>>How would a vendor even know that someone didn't take a "personal" copy of
>>>their unprotected code from site A to site B? Does that happen, it sure
>>>does.
>>>
>>>Microsoft did a study several years back on how much time they spent 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,
>>>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>>
>>>----------------------------------------------------------------------
>>>For IBM-MAIN subscribe / signoff / archive access instructions,
>>>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>
>>----------------------------------------------------------------------
>>For IBM-MAIN subscribe / signoff / archive access instructions,
>>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>
>>----------------------------------------------------------------------
>>For IBM-MAIN subscribe / signoff / archive access instructions,
>>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>----------------------------------------------------------------------
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>----------------------------------------------------------------------
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
