Charles Mills argues in defense of software product keys for mainframe software.
OK, let's pursue these arguments a bit. To start off, assuming IBM provides what the z/OS 2.3 preview announcement describes, isn't it reasonable for even the most "stodgy" vendor to concede that the scope for software product keys is substantially reduced? In particular, if your software product key somehow limits runtime capacity on licensed/authorized machines, why? If your customer has 100 MSUs licensed on machine serial number 12345 and actually uses 110 MSUs, you send your customer a list price bill for the additional 10 MSUs per your contractual agreement. If your customer doesn't send a SCRT report for some month, you send your customer a bill for the difference up to the full machine capacity, per your agreement. (If you don't know the full machine capacity, and if your customer doesn't provide reasonable evidence of the full machine capacity, then send a bill for the difference between the largest available capacity IBM currently sells and the customer's licensed capacity.) If your customer doesn't pay the bill you think your customer is supposed to pay, then you pursue available remedies. Including court remedies if necessary. (Which need not cost anything out-of-pocket since lawyers and bill collectors in many countries operate on contingency, if/as you wish.) I hope we can all agree that adoption of SCRT -- assuming IBM delivers what it plans to deliver -- at least reduces the "problem space." And thus properly ought to reduce the burden, complexity, and scope of product keys, even if you still want to stick with them (misguidedly, in my personal view). Also, customers understandably might ask, "If it's good enough for IBM and other vendors (SCRT, no product keys), why isn't it good enough for you?" Think carefully before you answer. :-) Customers aren't often stupid. They're going to assign penalty marks to products with keys. Keys increase their risks and operational costs, and so keys comparatively devalue your product versus competition. Whether you can still win that competitive battle depends on the circumstances, but they're "not helpful." Moving on.... Charles Mills wrote: >- Is this or some other customer running this product on some CPU that we >have no knowledge about? Maybe. There are a couple answers to that. First, if you're providing support and maintenance (and I hope you are), machine serial number details are presumably available in dumps, traces, logs, etc. -- in the problem determination data your customers voluntarily, knowingly send you to help you support them. So there are occasions when you'll have visibility on such "missing" machines. Second, IF you absolutely must have software product keys, then customers ought to be able to add machine serial numbers (where the product *might* run) to their product, up front, and in perpetuity. For example, you license the product on primary machine serial number 12345 and also allow the customer to add serial number 67890 to the key, on day one, for their DR machine. Whenever they get a new or replacement machine (if they do), they can change either or both serial numbers. Loop, repeat. And you must receive SCRT reports for the primary machine, by contract agreement. Can you handle that sort of arrangement commercially? Of course you can. Meanwhile, customers don't have anything to do when they need to recover their operations on their DR machine. They already have the key, and they've already run a DR rehearsal (hopefully). Yet another way to handle keys (IF you must, and I don't recommend them) is a "break glass in an emergency" way. You put the "emergency" key(s) on a couple secured, cloud-hosted sites (say, at IBM and Google). If the customer grabs the key, you receive a message or notice from the cloud provider(s) that somebody grabbed the key. And that key is only to lift already less onerous restrictions, such as exceeding a 90 day DR machine run. If you're going to have keys (please don't), you really need to think through how customers must run their mission-critical operations. And you need to plant your feet firmly in their shoes, first, and understand what YOU would want if it were your business. And you wouldn't want what some vendors (a minority) currently do. >- This customer has been running a "30-day" trial of our product for nine >months now. How do we get them to move "finalizing a license" to the top of >their task list rather than letting it languish under "we have not had time >to do that yet"? There are a couple possible answers to this: 1. Slightly function limit the trial version in a "sensible," reasonable way -- and, better yet, make the trial a free, open download for everyone, so that you get more potential sales. (Maybe with a registration page to collect customer details up front, but with as few barriers as possible. Make it easier to trial the product, and you sell more.) For example, if you're a vendor of printing software, "watermark" every 5th printout in the trial version. The form of "watermarking" will be product specific and situational, but pick something reasonable in the circumstances. When your customer pays for a license and signs their agreement (including SCRT terms and conditions), send them the non-watermarked code. (Which by then might be a point release or two higher anyway.) Give me an idea of what your product does, and I can probably think of a "reasonable" trial version limitation, or couple limitations, that still gives prospective customers a reasonable, legitimate opportunity to evaluate your product but that doesn't convey enduring production suitability. 2. Send them a bill per the terms and conditions of your trial agreement with the customer. If the customer refuses to pay the bill, forward it to collections -- outsourced, on contingency, if/as you prefer. I am expressing my personal views, as always. -------------------------------------------------------------------------------------------------------- Timothy Sipples IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA E-Mail: [email protected] ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
