Which Software Licensing Policy Is The Unfairest Of Them All?

Early next year I'm going to ask Sourcing & Vendor Management professionals to vote on which software companies' licensing policies they most resent as Unfair.  Fairness is a subjective quality, but it seems to me that some policies penalize customers for circumstances beyond their control that are unrelated to the value they are getting from the software. Others have serious consequences that may not have been apparent to the buyer when he agreed to the contract. Fair software pricing charges some companies more than others, but in a logical, transparent way that is related to value. Jim Hagemann Snabe (SAP's co-CEO) explained software pricing best practice extremely well in this recent interview with Computerweekly.com's Warwick Ashford:

"Q: What is SAP doing to meet user demand for greater clarity on licensing and pricing?"

Snabe: "The problem is a logical one. On the one side, customers would like a very simple price list with as few items as possible, and on the other side they don't want to pay for stuff they don't use. So we need to find a balance between these two. We are constantly working on simplicity of the price list. Ideally, you have a main price concept which is the number of active users, and not what they use. And then the idea is if I produce more functionality, then maybe more people will use it instead of pricing every piece of functionality on its own. Now there are some functionalities that can't describe their value in number of users. In fact, the goal is that there are very few users, like payroll. You basically need only one user. So there you need to find other ways of describing the value, so that a large company pays for the value associated with solving a large problem, and a small company pays only for the value associated with a small problem. In that case, it is the number of payroll slips [that counts] which is a reasonable simplification of the value creation."

Every software company's VP of pricing strategy should read and follow the above advice. Unfortunately, many publishers, including SAP, depart from JHS's guidelines with indefensible policies. Top of my list right now is the multiple-charging for people who access trading partners' systems to collaborate with them, a.k.a. External Use, which I wrote about last year: Do Your Software Contracts Permit External Use?

For example, suppose I have a user ID for my customer's business system to work with him on a design project, plan production schedules, and/or finalize a joint marketing promotion. Even if I have a valid user license for my own SAP system (or Oracle, Microsoft, etc.), my customer still has to buy another user license to enable me to access his system.  I've recently seen several situations where a publisher is trying to get two, three, . . . , n user license fees for the same individual in a situation where multiple supply chain partners access each other's business systems. That can't be right. And don't say "Oh, in that situation the customer should license by processor."  My answer to that includes the words "cloud," "multi-core," "virtualization," and "off!" No, software publishers should fix this increasingly common problem by simply extending a user licensee's rights to cover trading partners' systems, possibly for a small extra fee.

Here are some candidates for "Unfairest Policy Of 2010":

  1. Prohibiting or charging extra for external use.
  2. Charging maintenance on shelfware (unused products and undeployed license capacity).
  3. Counting a quad-core CPU as two or more processors, when it is clearly one physical CPU (see Per-Processor Licensing — It's All About Core Values).
  4. Making a customer pay full price for software that it accidentally deployed on extra devices, but never used.
  5. Similarly, making it pay for options it accidentally installed when the customer has no way to relate what he is installing with the publisher's SKUs in the price list.
  6. Limiting how frequently a customer may move licenses between physical servers within a virtualized data center.
  7. Charging hosting service providers multiple times for the same software if one server supports multiple clients.
  8. Processor Value Units.
  9. Charging maintenance from the date of the purchase order,  instead of the date of deployment or use.
  10. Increasing maintenance prices each year (e.g., by a CPI %) when the product's list price has stayed the same.

Before I launch my survey, I'd like to get some other suggestions. Please add a comment to describe any software licensing policies that really made you angry? Which do you think we should prioritize, to persuade software publishers to change?  I don't want to name and shame the perpetrators until I've collected the votes, so you don't need to identify the culprit — just describe its unfair (in your opinion) policy.



Unfaire SW Policies

Some other prameters are

Charging unfairly when reducing scope in future years due to business changes is another reason. Oracle is notorious for that so are others but not to the same extend
Setting support fee as percentage of list not purchase price!!

Ambigious product offering lending to additioonal purchase ont he claim that the needed funcitionality is not covered - IBM websphere products are notorious for that

Unfair software policies

Charging for bug fixes or patches. Bug fixes should be free, at least for a year. Maintenance should cover support & upgrades.

Charging 100% or more to reinstate maintenance. I didn't get any support during the lapse period, so reinstatement should be <100% and NEVER more.

Oracle repricing maintenance. There aren't words to describe everything wrong with this. Conversly, there's no words to defend this practic.

Licensing by revenue. Oracle & SAP both do this. How many companies have control over the COGS? If your main ingredient is a natural resource, your revenue can fluctuate wildly (but license fees apparently can never go down.) I work for an oil company. We have no control over $150 / barrel oil any more than we control $40/barrel oil.

Great points, although I'd clarify your last one

Thanks for these suggestions, Mark. While Level1 support is only a fraction of the total maintenance package, I like your idea. It would give buyers some leverage in a maintenance negotiation to be able to take a break and come bacxk without being penalized.

I take your point about revenue-based metrics, but I think they can still work. I wrote about business metrics here in this report "Software Buyers Should Consider Business-Metric-Based Licenses — But Cautiously" [ID 43976]. I like them, provided you get the vendor to normalize your revenue using an agreed commodity index, and adjusting for inflation too. If you could correct for the oil price fluctuation then this would be a fair measure. In contrast, the number of cores you need will rise steadily even if your business contracts.

Auditing When Vendor Records Are Inaccurate

From a recent comment on The ITAM Review forum:


"The ability for us to audit the vendors entitlement records and if they are not accurate then they are banned from auditing that customer ever again.

Having had 3 on site / self audits recently from major vendors all who had little / no / bad records of what our entitlement was but had the nerve to come asking questions. Needless to say 2 of the 3 were sent packing and the other looks like going the same way."

Inaccurate entitlement records

This is a great point Martin. I often compare publishers' license compliance teams with traffic cops. This sounds like one who tells you "we don't know how fast you were going, in fact we dont even know what the speed limit is here, but we still think you were speeding". I agree with you - dont let a vendor start collecting usage data until you have agreed your entitlement, amongother things. (see my report "Surviving A Software License Audit ")

Unfair licensing practices

Oracle proposed an employee based license to us for a Peoplesoft product. The definition of an employee was interesting. It included all contractors and all employees of a contracted firm. I read that to mean that if I contracted with a large firm to provide a limited number of people or services to us, we needed to include licensing for all their multitude of employees.

Who counts as an employee?

This is another good example although, to be fair, there is a good policy in there somewhere struggling to get out. The employee-based license can be simple and fair, and it eliminates the disincentive of user-based licenses to encourage everyone to use your key applications as extensively as possible. And of course its far better than a per-proc license. One problem is that the distinction between employees, agents, trading partners and contractors isnt always clear. I've seen many situations in which someone who was legally a self-employed contractor was working in such a way that they were in effect an employee - having an employee record, participating in training and performance reviews, having full access to business systems. Larger scale examples include insurance company sales agents, chain restaurant franchisees, and major employee-transfer IT outsourcing deals.

Bottom line: the publisher has a right to protect itself from customers taking advantage of loopholes in employment law, but not by using vague catch-all definitions that mean what it wants them to mean at the time.