Software is an intellectual property. Most often, it is licensed by means of a licensing agreement with third-party vendors. With the license (agreement) comes
- rights – such as the right to use the software under certain licensing restrictions, and
- duties – such as license and maintenance costs.
These rights and duties are detailed in the licensing documentation of each specific software product, and vary according to product, edition and version, sometimes also by language, geography, etc. In fact, it can be hard to even identify the correct documentation (challenge #1) in the first place. The licensing documentation contains two crucial topics: the license metrics and their associated restrictions (challenge #2), which can often be difficult to interpret and to abide by.
Challenge #1: Identifying The Correct Licensing Documentation
Customers often have difficulty keeping up with large vendors – Microsoft, IBM, Oracle – which publish thousands of licensing documents online every year.
For instance, from Jan. to Oct. 2012, IBM published over 12,000 licensing documents, of which 8,800 were Program Announcement Letters (PLETs) and 3,500 were Licensing Information (LIs). When it comes to licensing, most non-experts find it almost impossible to remain actively informed, and to find and collect the relevant documentation.
Ultimately, customers must remain in the position of having all licensing documents applicable to their infrastructure, at their disposal. OMTCO’s licensing experts follow the daily evolution of licensing. You can find some tips regarding licensing documentation here:
- Microsoft’s MVLSC – Compliance Audit Preparation for Microsoft Server Products (Windows, SQL, Exchange) (see Chapter III. Microsoft Volume Licensing Service Centre)
Challenge #2: License Metrics And Licensing Restrictions
The license metric defines the formula which is used to calculate the customer’s usage of the software. The ideal license metric should meet four criteria:
- Simple – It should be simple to understand, and simple for vendor employees to explain to customers;
- Scalable – it should fairly represent the value of the software as it is used by customers, and rules set by vendors should reflect customers’ infrastructure and usage;
- Fair – the more value customers draw from the software, the greater the licensing costs should be;
- Measurable – it should have a quantitative approach.
Unfortunately, metrics are often complex, volatile, unfair, and hard to calculate. Metrics are often complex – The Authorized User (one person) metric is rather simple – but then, IBM applied time restrictions to create the Concurrent User metric. Also, combined with the metric per install, they created the Floating User metric. After, they applied another restriction – on sessions opened – to create the FUSSSI (Floating User Single Session Single Install) metric. All in all, increasing complexity. Metrics are often volatile – for instance, in 2012, IBM changed the so-called “IPAA rule 3.5.1″, resulting in a dramatic increase in the reinstatement amount paid in audit settlements for unprepared corporations. Metrics are often unfair – for instance, Oracle does not allow a reduction in the number of processor licenses in the case of virtualization (a few exceptions apply). If an Oracle customer was virtualizing, and allocating exactly the same number of cores to the virtual machines as were available on the physical platform, it does not increase its technical usage, by default. But as Oracle does not allow for the reduction of cores by means of logical partitioning (a few exceptions apply), the license demand is increased. An lastly, metrics are often hard to calculate – some license documents have apparently not passed quality checks before being released and the metrics are not described clearly.
Software vendors are very inventive when it comes to licensing restrictions. Should a customer not comply with these restrictions, it can have dramatic consequences such as a severe audit penalty.
Vendors have no limits when it comes to creating new license metrics or restrictions. You will find advice on these topics in the following publications:
- Oracle processor and NUP metrics – Internal Compliance Audit Of Oracle Database Products (see Chapter I.) Determining the Technical Usage and The License Demand)
- IBM main hardware, user and other metrics – Top 100 IBM SAM Buzzwords – A Glossary Of Selected IBM Terms From A(udit) To Z(series)
- The metrics of different Microsoft Windows Server editions – Compliance Audit Preparation for Microsoft Server Products (Windows, SQL, Exchange) (see Appendix – License Demand Of Windows Server Within Clusters)
Publications
OMTCO has licensing expertise at its disposal, in addition to extensive experience in Software Asset Management, compliance reviews and customer-sided counter-audits. Should you have any questions or comments, please contact your OMTCO representative.
In the meantime, please feel free to read OMTCO’s informative reports and licensing documentation:
- IBM Informix – Product Editions, Metrics And Licensing Restrictions (Released October 2013)
- Top 12 IBM Licensing Metrics And Licensing Restrictions (Released March 2013)
- The Licensing Of Oracle Technology Products – Compliance, Metrics, Licensing Restrictions (Released October 2012, Updated June 2013)
- Top 60 Licensing Pitfalls For Oracle Databases And Oracle Technology Products (Released April 2012, Updated September 2012/March 2013)
IBM Informix – Product Editions, Metrics And Licensing RestrictionsReleased October 2013 | by Tim Sommer This report is aimed at those in licensing and IT leadership with a background or interest in IBM Informix product licensing. The report shows how Informix products are licensed, as well as detailing metrics and product and licensing restrictions. |
Top 12 IBM Licensing Metrics And Licensing RestrictionsReleased March 2013 | by Tim Sommer The report analyses IBM’s twelve most common licensing metrics and their associated licensing restrictions. We give valuable advice and direction to IBM customers on how to deal with the challenges of IBM’s product diversity and complex licensing. |
The Licensing Of Oracle Technology Products – Compliance, Metrics, Licensing RestrictionsReleased October 2012, Updated June 2013 | by Tim Sommer Understanding the metrics used for licensing Oracle product installations is crucial for determining Technical Usage and License Demand. This report is aimed at those in IT leadership and Software Asset Management with a strong background and interest in software licensing. We analyze Oracle licensing, covering their main metrics for Technology Products (including Oracle Databases) and the associated licensing restrictions, using product examples. We give valuable advice and direction to Oracle customers on how to deal with the challenges of such complex licensing. |
Top 60 Licensing Pitfalls For Oracle Databases And Oracle Technology ProductsReleased April 2012, Updated September 2012/March 2013 | by Friedrich Florea Over the course of the Oracle compliance reviews and counter-audits we perform for our customers, we regularly discover recurring compliance issues, as a result of some typical Oracle licensing pitfalls. The following report is an aggregation of the most common licensing mistakes that Oracle customers make relating to, among others, metrics, the counting of users and devices, the determination of processor licenses, virtualization, failover clusters, etc. |