Re: Licensing software

2009-05-12 Thread Joel C Ewing
Assuming, you're talking about a product that runs on the general 
purpose CP engines, mainframe licensing is typically based on either 
total processor capacity (MSU's), or, now becoming more common, 
Sub-Capacity pricing based on monthly max 4-hour-average MSU usage or 
MSU capped capacity of all LPARs running the product.


Licensing per CPU is impractical because within z9 and z10 families 
increasing the MSU capacity can either increase or decrease number of 
CP's depending on the speed setting of the CP's.


Licensing to a specific LPAR would also be undesirable for most 
installations.  New versions of vendor software are not just dropped 
into a production system, but first tested and validated in a test LPAR 
environment.  Any aspect of the software that runs differently in a test 
LPAR environment would mean some branches of the software used in 
production would not get completely tested.  And yes, vendors do tend to 
occasionally ship bugs in their license verification code or ship 
license keys that don't work.

  JC Ewing

ftr0...@gmail.com wrote:

My company sells encoding software to large users across the world.
Recently the question came up as to whether we can license per LPAR vs
CPU.
Can anyone tell me what they feel is a standard, or what normal
practices are?

Thanks,
Fraser


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Licensing software

2009-05-12 Thread Ted MacNEIL
Licensing to a specific LPAR would also be undesirable for most installations.
New versions of vendor software are not just dropped. into a production 
system, but first tested and validated in a test LPAR 
environment.

That's too strong of a statement!
SAS, COBOL, and other compilers sometimes only need to be licensed to a single 
LPAR.

Also, negotiate an arrangement where, when needed, your test requirements are 
'free'.

I've done that with many products.



-
Too busy driving to stop for gas!

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Licensing software

2009-05-12 Thread Timothy Sipples
What sort of encoding does the software do?

Licensing based on capacity (as measured in MSUs) is generally preferred.
Ideally, as JC says, that would be the peak 4 hour rolling average MSUs for
your product itself across all the LPARs where your product is running.
However, depending on what your product does, you can use a product
proxy. For example, if your product performs some sort of encoding
exclusively for DB2, then you could base your licensing on the peak 4HRA
MSUs for DB2 across the DB2 LPARs where your product is also running. Or it
might make sense to use z/OS MSUs as the proxy -- it depends on what your
product does.

You can price software any way you want of course. But peak 4HRA MSU
pricing seems to work pretty well for both vendor and customer.

Many vendors offer a price curve. That is, the first MSU has the highest
price, then each additional MSU has a progressively lower price. There's a
lot of debate about the wisdom of that, but quantity discounts (price
curves) generally (unfortunately?) reflect vendor costs better than flat
pricing. (There are certain fixed costs to doing business with each
individual customer.) For One-Time Charge (OTC) z/OS-based software IBM
does this using something called Value Unit Exhibits -- for example,
VUE007. IBM sets a single price per Value Unit, and MSUs are converted to
Value Units according to the Value Unit Exhibit (a formula). The Value Unit
Exhibit is what applies the curve. IBM's Value Unit Exhibits are public
information, so anybody can price using the same formulas if they wish.
VUE007 is the most common exhibit, as a matter of fact.

As an aside, in my experience customers dislike -- OK, hate -- license
keys. I'm not a fan of them either.

- - - - -
Timothy Sipples
IBM Consulting Enterprise Software Architect
Based in Tokyo, Serving IBM Japan / Asia-Pacific
E-Mail: timothy.sipp...@us.ibm.com
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html