How about reaching an agreement with IBM. When they get a SCRT report that includes your product, they send you a copy. Then when contacting a site, the disclosure agreement to get the trial copy and the final contract indicate that IBM will send you a copy of SCRT results for billing purposes. Base the monthly rate for current utilization plus 5-10%. Then when the review usage vs paid amount comes in, you should be able to give them a credit for the lower usage.
On Mon, Apr 24, 2017 at 8:59 AM, scott Ford <[email protected]> wrote: > Timothy: > > What about theft of software products ? We all know it goes on ... > How do you prevent it ? > > Scott > > On Mon, Apr 24, 2017 at 9:42 AM, Charles Mills <[email protected]> wrote: > >> 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 >> > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
