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
