We at Cole Software use licensing keys to protect our z/XDC product.
These keys enforce the both the machines and time periods in which
our product runs. There are more good reasons to do this than you might think:
1) Intellectual property protection [duh.]
2) Liability protection. [huh?] Let me explain. z/XDC is a powerful
tool that can be used (security permitting) by a malicious person to
corrupt a system. If a copy is stolen and used to create mischief on
a 3rd party system, then that creates a liability *BOTH* for us *AND*
our customer:
a) It creates a liability problem for us because we don't have a
contract with that 3rd party establishing the limits of liability.
b) It creates a liability for our customer because he's the one that
let the product get stolen in the first place.
c) If a lawsuit should occur, just the simple fact of having
licensing controls is helpful to our defense. (It shows that we
went to extra effort to create protection.)
So execution-CPU controls protect the both of us.
3) We sell z/XDC via a lease (not a permanent license) (maintenance
included). That lease expires periodically. Our license controls are
set to expire after 30 day grace period past the end of the lease.
That way, should a corporation decide that they do not want to renew,
The expiring license limits the ability of a "rogue" employee to
violate corporate's wishes. So the expiration helps the customer (the
corporation) to avoid unwanted liabilities to us.
4) We do have a few customers who tend to be "slow pay". Having a
technologically enforced expiration date is helpful in those
situations (although historically, we're pretty soft-a$$'d about
this. We've been known to give extensions for months!)
User Friendliness:
As for usability concerns, if a product needs to be taken down just
so that licensing controls can be applied, then that product needs to
be rewritten! With out product, licensing controls can be done on the
fly with no interruption of service.
To avoid surprise expirations, our product issues an expiration
warning starting 21 days before expiration. The lead time for that
warning can be change by the customer to whatever time period the
customer chooses.
Also, 30, 60 or 90 days out [depending upon the customer], our own
people will have already been in touch with an expiring customer's
purchasing department to help get the renewal paperwork going, both
so that we get paid our renewal fees on time and so that the
customer's users avoid service interruption.
In the event that a customer's bureaucracy has failed to renew the
lease in time, our web site has a service by which any customer
(expired or otherwise) can obtain temporary license activation codes
on an instant 24x7 basis. (Obviously, our web site incorporates
certain fraud and abuse controls, and it does report to us details
about who has used the service.)
Disaster Recovery:
Since our licensing codes are CPU sensitive, a problem does arise for
DR testing (and real DR). But this problem is resolved by our web
site service. A sysprog at a disaster recovery site can get temporary
licensing codes over the net 24x7, for the recovery machines.
Trust?
As regards the trust model, tried that. Didn't even get a T-shirt. I
started writing license control support back in the mid '80s when I
discovered that one customer, which was licensed to use the product
on two computers, actually was using it on 7! When they installed the
next release, they howled about how they could no longer use XDC on
their "backup" systems. One way or another, though, I guess they made
do. They didn't increase their purchase, but they did stay with us
another decade and a half.
Haven't had much cheating since...
Nevertheless, the trust model can work because customers, especially
large ones, are not monolithic. It's both hard and risky to get word
of licensing cheating down to all of the troops. Sooner or later,
someone is going to contact the vendor to resolve a product problem,
and that's a likely moment when licensing cheating will be
discovered. (I view those moments as sales opportunities. <vbg>)
But why create a situation where the opportunity to cheat is too
easy? Sometimes the "cheating" is entirely inadvertent. Sometimes
small products can get lost in the musical CPUs shuffle unless they
speak out. Licensing codes are a way in which z/XDC speaks out.
The point is, yes licensing codes can be a P.I.T.B., but they do
provide *mutually* beneficial protections. And yes, it is definitely
incumbent upon the vendor both to write their licensing management
software to be as friendly as possible, and to provide as responsive
a customer support service as they can.
Dave Cole REPLY TO: [EMAIL PROTECTED]
Cole Software WEB PAGE: http://www.xdc.com
736 Fox Hollow Road VOICE: 540-456-8536
Afton, VA 22920 FAX: 540-456-6658
At 2/17/2007 08:58 AM, you wrote:
If an ISV doesn't use a key tied to a date and a machine serial
number, what other mechanism is there to insure there are no
pilfered copies of the ISV's product running somewhere, and the ISV
doesn't have a clue?
There is the 'trust' model, which IBM uses.
From a user's perspective, if the ISV is timely in his delivery of
license keys, why is it a big deal?
1. That's a big IF.
2. In a 7/24 multi-time zone environment, getting the capability to
stop all users of a product long enough to apply the keys is problematic.
3. You don't always know until the last minute (usually on a
weekend), and some companies
(PKWARE, for example), only work M-F/9-5.
4. If you're out-sourced, you sometimes have the service provider:
a. Waiting until after they expire to tell you.
b. Slow in applying them.
c. Making mistakes and applying another customer's keys.
The key point is it complicates an already complex environment!
I can see a use for evaluation keys, but once the contract is
signed, give me a permanent key, and use the 'trust' model.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
