Speaking for myself only, I agree 100% with Phil. I HATE with a passion
mainframe vendor software with license keys, codes, all the myriad ways
they use to make my life difficult, adds work to my team, and puts my
company at risk if a vital piece of our infrastructure fails for
licensing problems.
If it was up to me, when we do our software evaluation process, any
product that has these restrictions goes to the bottom of the list of
products that we're going to look at.
Just my $.02
Mark Jacobs
On 03/27/14 10:24, Phil Smith wrote:
Steve Comstock wrote:
Also, what about the shop that tries to locate the
end date and zap it? You may say it doesn't happen
but I have heard tales...
OK, I know this is going to turn into a religious issue, but here's my $0.02.
In 30+ years I've never seen this. I've seen ONE case where a customer was
using licensed software illegitimately (on an extra CPU)-and that was an
oversight: when it was recognized, it was a full-price bluebird for the sales
rep, who was NOT unhappy at all.
I realize there are issues with Certain Countries whose reputation suggests
that such practices might be common, but without hard proof, I'm not inclined
to invest a lot of effort-initial and ongoing-in a CPUID protection scheme; it
just doesn't seem worth it. And if the alternative is that those countries
simply wouldn't buy the software anyway, then it's really not a cost to the
vendor. YMMV.
Of course any sysprog worth his or her salt could hack such a scheme in
minutes; this is the same as having unalarmed windows on your locked house: any
thief who's interested can get in via a broken window. The question is whether
it's also worthwhile to lock the front door and stop the casual intruder (and
yes, I realize that seems to be arguing against my thesis-but locking your
front door is low-cost and low-impact, as opposed to building, maintaining, and
staffing 24x7 a CPUID mechanism).
SAS C used to have a nice, simple scheme: the compiler would say "SAS C LICENSED TO <company>"
whenever it ran. You could run it on the wrong CPU, but it would whine (I forget whether it also said "Hey,
dude, wrong CPU!"). The theory (I assume) was that no serious company would run software that basically yelled
"Look! Stolen!" every time, but in a pinch, you could get critical work done. Seemed elegant to me.
As ever, I'd ask the question: What problem are you trying to solve with a
CPUID scheme? That is, what's the REAL problem THAT YOU ARE HAVING? Or is it a
theoretical problem? If the latter, consider the cost before investing: is your
software so magical that it never needs support? If it does tend to need some
support, then you'll find the cheaters eventually, and have 'em over a barrel
price-wise...
...phsiii
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
Mark Jacobs
Time Customer Service
Tampa, FL
----
The quiet ones are the ones that change the universe...
The loud ones only take the credit.
Londo Mollari - Babylon 5
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
