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
