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