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)
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)