Oracle Database – usage related compliance issues
Apart from all non-compliance issues related to A) the Hardware Infrastructure on which the Oracle Database software is installed, B) the complete and accurate view on all Oracle Database installations within an organization, and C) the configuration of the different Oracle Database installations – a number of most common issues are related to the actual usage of software.
These arise around the Named User Plus license metric definition . . .
Be Sure to Attend!
Don’t miss our in-depth Oracle Database license management webinar on November 12, starting at 16:00 hours CET. Please register here.
Named User Plus is defined as an individual authorized to use the programs which are installed on a single server or multiple servers, regardless of whether the individual is actively using the programs at any given time. A non-human operated device will be counted as a Named User Plus in addition to all individuals authorized to use the programs, if the device can access the programs. If multiplexing hardware or software (e.g., a TP monitor or a web server product) is used, this number must be measured at the multiplexing front end. Automated batching of data from computer to computer is permitted. You are responsible for ensuring that the Named User Plus per processor minimums are maintained for the programs contained in the User Minimum Table of the licensing rules section. This table provides the minimum number of Named Users Plus required, and all actual users must be licensed.
“Individual” denotes every single human being; not just FTEs or employees. Although your employees may be the major part of your user population don’t forget your contractors and/or agents that may have access to your Oracle Database software. And although three part-time employees may in total sum up to 1 FTE, you still need to license all three single individuals.
“Individual” also does not refer to database usernames or database schemas. It is very important to understand this and to realize that even if there is a larger number of user accounts created, only the actual individuals (distinct human beings) authorized to make use of the software (and not active users) require a license. This consequently requires a regular clean-up of accounts that are no longer active (e.g. accounts of former employees).
“Authorized” refers to the individuals (employees, contractors, agents, etc.) that can access the Oracle Database, no matter if they are actually using the database software. If you created accounts for 1,000 individuals (all your current employees, contractors and agents) but only 50 persons are actually using the software, still all 1,000 individuals need to be licensed. Active management of which individuals should have access and which not, should therefore take place on a regular basis. In practice, such user management does not take place regularly, resulting in a high risk of non-compliance with financial consequences.
Individuals Authorized to Use
“Usage” is not defined in the agreements. This typically causes confusion, since end users are not aware that any individual, who can (directly or indirectly) Create, Read, Update or Delete (CRUD) data in the Oracle database software, is considered to constitute usage and therefore should be licensed.
“Used Programs” means that only features/components that are part of the Oracle program as listed in the Ordering Document and further detailed/specified in Oracle’s Program documentation may be used. Any feature, component or product which is not part of the Oracle Program as listed in the Ordering Document (or any other Ordering Document) is therefore not allowed to be used, even if these features/components/products are related to the licensed Oracle Database Program (e.g. the Database Enterprise Edition Options and/or Database Enterprise Management Packs that come together with the download of the Oracle Database itself).
Installed on a single server or on multiple servers
The Named User (Plus) licensing metric is a so-called “multi-server” or “multi instance” metric. It means that an individual must be counted only once, even if the individual has multiple user accounts on multiple Oracle Database instances on the same server or on multiple servers.
This is yet another issue that adds a lot of complexity especially for larger organizations. Due to the fact that from a technical standpoint only user accounts or database usernames are visible in the database, counting the distinct individuals on multiple servers is even harder and typically requires counting at application level instead of database level!
Consider a company with three database instances; the first one has 50 user accounts, the second 100 accounts and the third 10 accounts. This can lead to confusion, and to the perception that 160 Named User Plus licenses would be required. That is not necessarily the case, since when all individuals of the first and third database have access to the second instances and also 20 individuals have 2 accounts on the second instance they should be counted only once which would result in 80 Named User Plus. De-duplication of user accounts to identify the real number of distinct individuals is therefore necessary. Complex IT infrastructure within an end user organization and lack of active user management make this a hard to execute, time-consuming activity.
Non-human operated devices
Any device (e.g. sensors, scanners) accessing the Oracle Database need to be counted separately and are required to be licensed separately, in addition to all the distinct individuals who are authorized to use the software. Since such devices are not operated by human individuals, these are often overlooked as “users” of the database software, and therefore mistakenly not licensed.
Multiplexing front end
“Multiplexing” is not defined in any of the documents/agreement, but is a commonly known and applied term in the software industry. Multiplexing is when a large number of end users and/or devices access a system via an interface, in such a way that the apparent number of users and/or devices accessing the system is much smaller than the actual number of users and/or devices. If Oracle software is part of an environment in which multiplexing hardware or software is used, then all users and/or devices must be licensed at the multiplexing front end, i.e. the beginning of the automated process.
In the early days, software was being used in two-tier architectures. You would use a client to directly access the data stored in a database on a server. In this type of architecture all the data including the authorization data (user accounts and passwords) were stored on the database. However with the introduction of middleware and application servers (three-tier architectures) and the need of integrating multiple enterprise systems, the authorization of each user on all the integrated databases became redundant and cumbersome. As a result the middleware and applications themselves managed the user population, and users would connect to the databases only through a generic username, channeling all the requests from the different end users.
A final caveat
Measuring the total number of distinct individuals authorized to Create, Read, Update, and Delete (CRUD) data (directly or indirectly) at the multiplexing front end, requires organizations to have a complete and accurate picture of all data streams to and/or from the Oracle Database and to understand which application is making use of which middleware instance and which middleware instance is making use of which database instance. Almost no enterprise today has this level of detail available, resulting in large risks of non-compliance and financial consequences in case such an environment is not licensed by a Processor license metric.
If you are in need of extra expertise and a structured approach, feel free to contact B-lay. We will help you make software compliance an exciting opportunity to improve your business!