Oracle accused of fudging licence policy

Feature

Oracle accused of fudging licence policy

Chairman of the UK Oracle User Group, Ronan Miles, is seeking a clarification of Oracle's licensing policy after leading US analysts Meta Group told users not to pay additional licensing charges levied by the company.

Meta Group has accused Oracle of unfairly reinterpreting the terms of named user licences to force database customers either to buy more licences or convert to a more expensive processor-based licensing scheme.

The analysts' organisation, which said it had received a "flurry of calls by angry Oracle customers," has suggested users take legal action against the database giant if necessary.

Oracle has firmly rebutted the charges, but for Miles, "The fact that an organisation like Meta Group has issued such a statement should concern the whole Oracle community, users, third parties and the company itself."

There has been considerable tension between Oracle and some of its users over the past year concerning licensing models.

UK Oracle User Group conducts an annual survey of its members and according to Miles, "It shows they want an open, fair and transparent licensing model."

To placate some user concerns and improve pricing transparency, the company recently adopted a processor-based pricing scheme that it claimed would be fairer and simpler for the installed user base to swallow.

The latest controversy centres on how Oracle defines multiplexing. Multiplexing is the use of software such as a Web server or TP monitor that uses a shared pool of connections to the back-end database that masks the actual number of users that are physically connected.

In such cases, customers either licensed the Oracle database through a per-CPU model or paid for all the users at the front-end.

However, Meta says Oracle is trying to expand the definition to include batch feeds from non-Oracle applications into Oracle databases. This change would hit customers who use the database for data warehousing applications that require large servers with few users.

The spat began in January last year, when Oracle began performing random audits that it called "licensing management services".

Even when customers were compliant they found Oracle began clarifying its stance, saying that any batch processor or computer-to-computer connection was now seen as multiplexing, said Mark Shainman, senior research analyst at Meta.

This approach forces organisations to include all its clients at the front-end, a proposition Shainman estimated would increase the cost of converting to a per-processor model fivefold. He added that the original vagueness of the contract, allowed Oracle to reinterpret it unjustly.

"The reality is [Oracle has] seen little to no growth in their licensing revenue, so they need to find revenue somewhere since they're such a quarter by quarter-driven company. This is a way to dig for that extra revenue. When I hear somebody saying a bulk load is multiplexing, I think that's insane. I need to look into my front end for my data warehousing," Shainman said.

For many users, "unless they find themselves in an environment that is 100% Oracle, the only alternative under this model will be to convert to a per-processor model for data warehousing," said Shainman.

Oracle has reacted strongly to the Meta warning. "Oracle pricing and licensing policy, with respect to the treatment of multiplexing and batch processing, has been consistent and in effect for several years," the company said.

Oracle accused Meta of highlighting a few cases where organisations had misunderstood the policy and said concerned users should contact Oracle headquarters to resolve the issue.

Email Alerts

Register now to receive ComputerWeekly.com IT-related news, guides and more, delivered to your inbox.
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

This was first published in March 2002

 

COMMENTS powered by Disqus  //  Commenting policy