Not intending to raise a political/social issue, but I think it is apropos the 
subject.  What about the "bad actors" out there in places like Russia and 
certain rogue parts of the Middle East and Asia?  Is software theft by those 
regions not also a licensing loss issue?

I don't have any anecdotes or first-hand knowledge, it just seems to me to be a 
probable issue given that "bad actors" in those regions are not going to be 
bothered to pay for anything they can easily steal.

OTOH if one only concerns oneself with customers and potential customers who 
are at least nominally likely to pay you, I guess I could agree about not 
wasting time and effort (and therefore money) on protecting anything.

Peter

P.S. - Probably not unless I had access to z/XDC or at least Intertest.  My 
dump-reading skills are rusty, and unfortunately for me IPCS isn't on my 
skills-acquired list.

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf 
Of Phil Smith
Sent: Tuesday, April 25, 2017 6:49 PM
To: [email protected]
Subject: Re: Vendor Licensing Frustrations

scott Ford wrote:
>What about theft of software products ? We all know it goes on ...
>How do you prevent it ?

When I see someone assert that "We all know it goes on", I don't see it as a 
meaningful statement. Spontaneous fission also occurs, but not enough for me to 
worry about it. There have been a few war stories shared here of folks who 
found a cheater; I'd submit that the scarcity of such stories (in 
mainframe-land, not talking about PCs!) proves the point: this isn't an issue 
that's big enough to waste cycles on.

As Timothy has suggested, shoplifting happens, but stopping it isn't a store's 
highest priority, at the expense of alienating customers, because it isn't a 
big enough problem (with notable exceptions, like liquor stores in certain 
neighborhoods). Enterprise shops stealing mainframe software happens, but 
stopping it at the expense of alienating customers (and costing a lot to boot) 
doesn't make sense because it isn't a big enough problem.

Now, Charles raises some more substantive issues, like never-ending trials. A 
related problem is with performance software, for which it is really dangerous 
to offer trials, because "clever" customers will use the trial time to solve 
their performance problem, and then say "No thanks". And it also depends on how 
critical the software is: if CorreLog stops working, everyone is irritated, but 
the system probably doesn't go down, production continues, etc. (if perhaps 
slightly degraded, and with the ability to head off problems seriously 
damaged). But it's not necessarily an all-hands-on-deck issue.

If, say, your product was a TCP/IP stack, you'd be in a different situation: if 
it goes down, the world effectively stops. So you might find shops willing to 
skate a bit with CorreLog who would not with our hypothetical stack product.

That doesn't mean CorreLog is less valuable/useful/necessary, but it does 
inform the decisions about risk that Charles' management has to make, and the 
steps they may need to take to mitigate those. I applaud them for not wanting 
to cripple the software for trials, but find myself thinking that in their 
shoes, I'd be far more willing to do so than for that stack product.

But it still wouldn't convince me that keys were needed for production. 
Seriously-I've heard the assertion for over 30 years; show me some evidence. 
One or two anecdotes don't qualify. And I've spent more than 25 of those 30 
years selling mainframe software without keys, so either we left a lot of money 
on the table or we'd've noticed the theft. (Anyone who has always used keys 
doesn't really have a basis for making such an assertion, BTW, now do they?)

...phsiii (NOT trying to start a pissing contest, just honestly baffled by the 
seemingly baseless belief)

P.S. Who here doesn't believe that, given a reason, (s)he couldn't break CPUID 
checking in a few hours anyway?
--

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to