Original URL: http://www.theregister.co.uk/2013/05/09/enterprise_software_license_confusion/

Think enterprise software is complex? Check out the licences

It's simple economics - and you're the simpleton

By Alex Woodie

Posted in Cloud, 9th May 2013 08:04 GMT

Analysis Enterprises shouldn't be surprised to discover they're having trouble understanding their enterprise licensing agreements. While Oracle, SAP and other big players publicly tout transparency and fairness in their licensing and pricing policies, customers often disagree when they get to the bargaining table or open the results of an audit.

Oracle and SAP are in unique positions as the two biggest and most respected enterprise software companies in the world. Combined, they account for more than 40 per cent of the worldwide ERP market. No other enterprise software vendors offer software lineups that are as broad and deep as those of Oracle and SAP.

And with billions of dollars invested in R&D every year, customers of these two firms have come to expect a steady stream of technological innovations that give customers real competitive advantages, such as SAP's HANA database and Oracle's Exadata database appliance.

Customers of Oracle and SAP appear, by and large, quite happy with the functionality delivered by the vendors' wares. But there is a darker side to working with the software giants. Depending on which vendor you're dealing with, you may find the licensing agreements to be extremely complex, rife with vague terminology, inflexible to changes in business structure, or subject to capricious levels of enforcement.

SAP licensing: 'Vagueness' and 'irregular enforcement'

SAP's licensing model is, ostensibly, quite simple. The company lays out the basics in a 26-page white paper, "Licensing SAP Software," which is available on its website. The company says the customer is able to pay for only the SAP software that they use. But the reality is usually something different.

At a high level, SAP sells its flagship Business Suite in two main ways: packaged licences and named-user licences. It's all perpetual licensing with SAP, which offers subscriptions only for two solutions: the SMB-targeted SAP Business ByDesign suite, and CRM OnDemand.

An SAP customer will start by licensing the "enterprise foundation" package, which includes the core SAP ERP software (ERP Financials, ERP HCM, and ERP Operations), at a pre-determined price. On top of this, customers select various "enterprise extension" packages (generic business functions like payroll), industry portfolio packages, and line-of-business portfolio packages.

Each of these packages (except for enterprise foundation) is priced based on a "business metric," which could be anything from the customer's revenue, the number of employees, the number of processor cores the software runs on, or the number of invoices sent out daily. Analytics, mobile, and database products are separately priced, and have their own restrictions. SAP HANA is priced on the amount of memory it can use.

Every user that needs access to the SAP package is required to have a named user licence. SAP sells three main types of named user licences: professional, developer, and employee. The differences in the licences depend on the level of access required and the amount of time they're going to spend working in the SAP software.

Chris Hughes is a SAP licensing expert with Flexera Software, a software licence management tool vendor. In his position, Hughes has an in-depth understanding of the different licence types that SAP uses across its products, and helps customers to minimise their SAP licensing expenditures.

"One of the bigger challenges in SAP licensing is that the licence models are very vague and open to interpretation," Hughes says. "For instance, a professional user licence would be defined as somebody who performs operational duty on the SAP system, whereas the limited professional licence - which has substantial cost differences from a professional licence - is really defined as someone with limited operational actions. That definition of 'limited' is very open to different interpretations and different customers will look on that in different ways."

The vagueness is definitely a challenge, Hughes says. "We're starting to see a trend of SAP being more specific in their contracts, but still have a ways to go before the vagueness goes away."

It's your data, but…

The other big challenge facing SAP customers is something called indirect access. SAP defines indirect access as occurring when a user or product accesses data stored in the customer's SAP system through a third-party interface. Examples of this could be an Oracle Hyperion BI application sucking data out of the customer's production SAP database, or serving data through a Microsoft Web portal.

While the data belongs to the customer, it is being "processed" by SAP software, and therefore SAP demands compensation any time it is used outside of the SAP environment. It may surprise customers to find they don't have the freedom to use their data in any way they like without paying SAP for the privilege, but that's likely because they didn't carefully read their licence agreement.

Licensing experts claim SAP used to look the other way when its audits found customers violating the indirect access provisions of their licence agreements, although SAP disputes this.

While customers own their own data, it can be difficult to determine how many licences would be required for all downstream consumers of that data.

But in recent years, according to the licensing experts and users we spoke to, SAP has started to crack down on indirect access, by charging customers for additional licence fees for indirect access. This has angered SAP customers who have been asked to pay millions of dollars to buy additional named user licences as a result of indirect access discovered during audits.

"SAP customers can get some surprises in an audit situation, where they thought they were following the process, they thought they had a very accurate understanding of their licence position, and suddenly they're being charged for thousands of users that run on this other system that is loosely connected to SAP," Hughes says. "This is a clear area of focus for SAP, and for customers going forwards, it's an area of fear and uncertainty."

The fear and uncertainty over SAP's licensing practices was on full display last fall, when the UK & Ireland SAP User Group conducted a survey that found 95 per cent of SAP customers found the company's software licensing policy "over complicated". In response, the head of SAP's UK business pledged at last fall's TechEd 2012 conference that it would clarify and simplify its licensing models.

SAP defends its licensing and pricing schemes as fair, and says it's taking steps to make its licensing policies simpler and more transparent. Broad-strokes generalisations about weaknesses in its licensing scheme are not possible, SAP says, because each customer's situation is unique. Further, SAP questions the comments made by licence optimisation vendors, saying they're trying to "drum up" business for themselves.

In particular, SAP says named user definitions must be broad in scope because they cover user activities that are role-based, and not function-based. As for indirect access, there's just no "there" there. "The idea that indirect usage is somehow 'new' or a change in practice is simply not true," the SAP spokesman says. "Indirect access is not a new topic at SAP, nor is charging for it a new practice. These terms have been in our contracts for many years."

There's also growing pressure for SAP to publish its full price list, as its rival Oracle famously does. While SAP doesn't publish its prices, the company seldom varies from its internal price list when its salespeople close contracts, according to Upper Edge Consulting, a licence optimisation consulting firm that SAP hired to validate its pricing practices. The same cannot be said of Oracle, Upper Edge experts say.

Oracle licensing: A question of trust

Oracle's licensing model is similar to SAP's in several ways. Users of Oracle applications, such as E-Business Suite, must pay a fee based on various business metrics, and also must have the appropriate number of named user licences, what Oracle calls "End User Plus," for most people who work with Oracle software.

Oracle's technology products, such as the database and Fusion middleware, are priced differently. With these products, Oracle mandates processor-based pricing models. Virtualisation further complicates Oracle's processor-based licensing model, especially considering the differences that Oracle recognises between "hard" partitioning and "soft" partitioning. Servers virtualised using Xen-based OracleVM on x86 or Sun's LDOM T-series hypervisor-based OracleVM on SPARC can get the discount of "hard" partitioning.

According to Oracle, every other hypervisor - including other Xen-based hypervisors - can deliver only "soft" partitioning. Here's the catch: "soft" partitioning customers must license the Oracle product for all of the cores on the server, regardless of how many are actually used to run the Oracle application.

Oracle's software licensing model is "one of the most convoluted and complex" models in enterprise software, says Dave Blake, president and CEO of UpperEdge Consulting, which advises clients in enterprise software licensing issues. Some of that complexity stems from the acquisitions that Oracle has made over the years. Those models haven't been shifted to a company-wide standard, he says.

"Where their level of complexity comes in is how they tend to stray from their public list prices and metric pricing," Blake says. "I think Oracle has done a pretty smart thing outwardly facing, as far as declaring that they're fully transparent to the market by posting their list prices for their applications as well as their technology products to their website. Anybody with a web browser and an internet connection can go and download those list prices.

"Where complexity comes in, on the transaction side, is they tend not to present or propose standard template transactions that are based on those list prices," he says. "It's a little bit of a shell game in the sense that they publish their list prices, but 90 per cent of the transactions that we see tend to have custom bundles, custom quotes.

"They develop custom bundles or custom enterprise bundles for their respective pricing which then allows them basically to throw out the price book."

Aggressive business practices on the spot

The business practices of Oracle's sales team raises other concerns for Oracle customers. For example, Oracle is known to price entire custom bundles according to a single business metric, says Jeff Lazarto, an UpperEdge principal. "The challenge for companies is that, as their revenue increases, whether that's related to the value they receive from the Oracle products or not, they're now subjected to additional licence fees as their revenues grows," Lazarto claims. "Not only that, but their maintenance fees increase as well."

By and large, Upper Edge has found customers to be happy with their Oracle products. Products such as Exadata are driving real value into businesses, but what causes fear and uncertainty among Oracle customers are the licensing agreements, Lazarto says.

The inability to modify some of the existing licence agreements - to terminate licences or maintenance for individual products in a bundle - is another thorn in the side of Oracle customers, Lazarto says. "It's an all-or-nothing scenario," Lazarto says. He admits: "They do grant you the licence to terminate, I'd say, three products you didn't deploy out of 20, per their agreement and their policy. But then they have the right then to go back and re-price all of the remaining products, because in essence, you broke up the bundle. So they need to re-price what's left of the bundle, and re-price maintenance as well."

Oracle sales people have also been known to encourage customers to change their licence metric when renewing maintenance, Lazarto claims. For example, the Upper Edge consultant shared the story of a long-time Oracle database customer who licensed the product on a per-user basis (a very favorable licensing method), but said they were convinced to change their licence model to per-core pricing - Oracle's current method of pricing its database - during maintenance renewal negotiations.

"Oracle uses a very heavy-handed negotiation to get people to change their licence models," Lazarto claims. "I'd say one of the common complaints [from customers] is they just feel they're locked into Oracle at times. It's very difficult to break out of it."

That lock-in is a source of enormous revenue for the $37bn software giant. Oracle famously charges new application customers an annual maintenance fee equal to 22 per cent of the initial licence value. These maintenance fees are recorded in the "software license updates and product support" accounting bucket, which brought Oracle $4.2bn in its third quarter of fiscal year 2012, or 47 per cent of its total revenue. Oracle executives have referred to the maintenance revenue as its "birthright," but it's not always cigars and rye for its customers.

Blake recommends that Oracle and SAP customers read their licence agreements closely, make careful note of access rights, and do not be afraid to demand better terms from the vendors. In many cases, getting input from licensing experts, or even using software, may reduce licence expenditures significantly, and reduce the risk of unbudgeted increases and nasty little surprises going forward.

Oracle and SAP have compelling software, but it comes at a cost that may not be apparent at first blush. "If you listen to the press from Oracle and SAP, what they're touting is that they're being more open, they're providing more information to their clients and that the complexity of their models their pricing decreasing and simplifying," Blake says. "What we're seeing in fact is the exact opposite. Their models are getting more complex, and they're getting further complicated by various deployment models."

Oracle could not be reached to comment for this article.®