On 12/27/2011 07:55 AM, Mark Zelden wrote:
On Mon, 26 Dec 2011 16:11:02 -0500, zMan<[email protected]> wrote:
OK, I gotta ask -- what's the problem you're trying to solve? You
don't trust your customers? In over a quarter century in the mainframe
software business, I've come across ONE customer running software on
an unlicensed box, and it was an oversight -- and a nice full-price
bluebird for the sales rep. I don't believe "CPUIDs" are worth the
hassle.
Obviously the point of view of someone who doesn't make a living by
selling their software.
I can tell you from personal experience (one of my clients) who I helped
write CPU protection for about 10 years ago that there were many instances
of unauthorized use and in at least one case I know about the abuse was
rampant. I know a lot of the unauthorized use wasn't intentional, but a
lot of it was also or shops just didn't care since there was no checking.
Some of the companies that used this software outsourced their IT, and
ended up using it on different machines than those that were licensed.
Or the outsourcer copied it to other machines / environments / clients.
My client must have lost hundreds of thousands of dollars in
licensing / maintenance fees and fees from related litigation.
In my own personal experience as a sysprog, I know some of the
same things have happened unintentionally. Consolidations, moving
LPARs around, creating / cloning new LPARs can lead to this and
when the software doesn't check it's easy for the "techies" to
make mistakes since they often (usually?) don't know the T's and
C's of all the software contracts.
So even though it can be a pain, I actually prefer that any vendor that
cares, checks the CPU id for authorization. If the software has a "site
license" option, then have a method for a non-cpu specific key to generate
for the client. Provide an easy way to change the key and a grace
period that won't put the shop's business in jeopardy because of a
missing / wrong key after a CPU upgrade or engine add.
Regards,
Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
mailto:[email protected]
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html
Systems Programming expert at http://expertanswercenter.techtarget.com/
Although most of my career was spent with configurations with no more
than two independent mainframe systems, I can appreciate the additional
confusion of trying to track inconsistent vendor license terms in a much
larger environment and how that would raise the probability of
unintended violations.
Thankfully I've never had direct experience with a company that was in
process of outsourcing their mainframe operations, so I hadn't
considered that aspect. Obviously a company with no reservations about
shafting its own IT department for short-term profit would probably have
even less compunction about doing the same to its former software vendors.
--
Joel C. Ewing, Bentonville, AR [email protected]
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
