2010/3/15 Gerhard Postpischil <gerh...@valley.net> wrote: >I have mixed feelings about that. When maintaining software, that's great, but >as a stockholder I can't wonder how much money IBM loses due to that policy. I >expect that it sends lawyers after bigger violators, and ignores the really >tiny fish, but how much misuse is there at smaller companies?
>In the nineties I worked as a consultant for a small ISV, to update their key >codes, which then were based on the full CPU id, and their policy was simple - >if a customer called with a problem, a timed key was issued on the spot - good >for any CPU for one month. That was enough time to resolve any other code >issues. And they also had "perpetual" licenses tied to the CPU id, that had no >date dependencies. Again, sometimes an annoyance, but minor compared to some >problems I encountered with other products. Lacking any data to back it up, I'd respectfully suggest that your post is just an anecdotal reflection of the all-too-common vendor paranoia that leads to such codes. Having worked at a variety of mainframe vendors, I'll offer these real data points: - at a vendor without any form of CPUID checking we found, over a decade or so, a handful of inadvertent violators who had added a product to another CPU. These became full-price "bluebirds" for the sales rep and were much appreciated. (They were typically found out when someone would send in a dump or call for support and mention the system name.) - at a vendor WITH CPUID checking -- and good checking, including warnings, grace periods, "emergency mode" operation, and more -- by far the biggest after-hours support load was handing out temporary CPUIDs for DR etc. - at another vendor with less evolved CPUID checking, it was universally hated by customers and support, and never offered any real evidence of doing anything useful (admittedly, lack of evidence is not evidence of lack). My conclusion from all this over several decades: - real companies do not steal software - non-real companies might, but can always hack a CPUID scheme to work if they want (it's just code; unless you're doing something like a dongle, you're fooling yourself that it's "unbeatable"), and either would not have purchased or will get found out eventually - CPUID checking is a waste of everyone's time, resources, and therefore money. BTW, of those who did CPUID checking, one of my favorites was SAS/C, whose CPUID check included a hash of the company name (also in the CPUID file). Whenever you ran it, it would say "This program is licensed to XYZ Corporation", but it would run on any CPU unless expired. The theory was that if someone did steal a copy, eventually someone would ask, "Why does our compiler say we're XYZ Corp when we're really ABC Inc?"s. One more anecdote: back in the 80s, a friend worked at a Large Government Data Center as a sysprog. One day he was in the machine room and noticed an all-caps warning on the operator's console: *** <backup product> WILL EXPIRE IN 10 DAYS!!! PLEASE CONTACT <vendor name> *** He pointed and said something along the lines of "WTF?" to the operator, who replied... "Oh, it always says that." Um, no, just for the last 20 days, son... I think that operator found himself looking for a job shortly thereafter. ...phsiii ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
