Oh gee, let me try to respond to the most significant points here. > Charles Mills argues in defense of software product keys for mainframe software.
No, I argue in defense of vendors getting paid (so they can pay their employees, their rent, their SHARE sponsorships, their IBM bills, ...). Keys are just a means to that end. I was asking you how SCRT provided a means to that end. (As I suspected, you only defend it as a way of implementing MSU pricing, not as a way of getting paid at all.) Speaking of things that customers hate -- how about adding MSU pricing to the list, perhaps even ahead of keys? > the scope for software product keys is substantially reduced? Not for vendors that do not MSU price. > you send your customer a bill for the difference up to the full machine capacity Good luck getting paid. > you pursue available remedies. Including court remedies That's a winning customer relations strategy! > even if you still want to stick with them (misguidedly, in my personal view) Misguided only if you neglect my other points. > if you're providing support and maintenance (and I hope you are), machine serial number details are presumably available in dumps, traces, logs, etc. We get very few such problems. VERY few. I cannot tell my management that that is to be our solution. > add machine serial numbers (where the product *might* > run) to their product, up front, and in perpetuity Assuming they run that one box in perpetuity, which does not seem very likely. Without even considering DR. > You put the "emergency" key(s) on a couple secured, cloud-hosted sites (say, at IBM and Google) Agreed. Good solution. Takes a lot of work to get it right however. > Slightly function limit the trial version My management would NEVER agree to "sell" anything but the latest and greatest. Hard to come up with a generalized subset that fully demonstrates to non-technical management that we solve their particular problem/wish list but that is not "good enough" to use for months or years. > open download for everyone Including competitors? Does IBM do this for z/OS LOL? > Give me an idea of what your product does Not "mine," but here you go: https://correlog.com/mainframe-security-solutions/sas-correlog-mainframe/ > Send them a bill per the terms and conditions of your trial agreement with the customer Lots of luck! > forward it to collections And abandon ANY chance of ever actually getting the sale! That's the problem here. Remember, this is a prospect who is saying "we're going to buy your product ... but my boss has been too busy to review your license." Easiest solution is for the sales rep to be able to say "well, I can extend you another ten days but that's absolutely it." Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Timothy Sipples Sent: Sunday, April 23, 2017 6:41 PM To: [email protected] Subject: Re: Vendor Licensing Frustrations 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. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
