By: Jill Powell

I was recently asked by a customer to provide some standard definitions of common software licensing terms and thought it might be helpful to others. So here it is…

Common License Types

Appliance: A license covering use of a specific piece of hardware, such as a hub, router, or PBX. Terms and conditions vary between vendors.

User: A license that provides access to the software to a specific number of users. All installations of the software will be counted but installations across multiple devices for the same user will be counted as one license consumption.

Concurrent User: A license which provides wider access to the software but limits the number of simultaneous users using the software. It may or may not include compliance enforcement capabilities. Typically, a concurrent license is “checked out” from the license server when the software is run, assuming a license is available. If no license is available, the requester experiences a denial of service.

Named User: A license that allows access to the software by a specific number of named users. In some cases, these licenses can be transferred from one user to another. When you create the license, you should allocate the license to specific users. Only installations associated with allocated users are counted. For example, if the license is allocated to users Sam and Jan, the maximum installation count is two. Any other installations of the licensed application are treated as unassigned installations. For example, if May has also installed the licensed application but has not been allocated to the license, her installation will not be shown against installations of this license.

Enterprise: A license to install software an unlimited number of times within the enterprise. An Enterprise Agreement, such as the Microsoft EA, is defined separately to this in FlexNet Manager Suite (FNMS ). An Enterprise Agreement is structured as ‘all you can eat’ but the organization must be licensed for a specific quantity of licenses so this is not strictly an ‘Enterprise License’ model in its pure form.

Evaluation: A license that allows one or more users to install and use software for trial purposes. Evaluation licenses may be time limited, may offer limited functionality, or may restrict or mark output (for example, some PDF writing software includes the name of the software on every PDF document produced from a trial version). After evaluation, a user may purchase a full license, uninstall the software, or (for time-limited trials) the software will simply no longer work.

Node Locked: A license that allows access to the software on a specific number of named computers. These licenses are usually for server applications such as database or VMware products. In some cases, these licenses can be transferred from one computer to another, usually by requesting a new license key.

OEM: A license for software that is delivered with the hardware and is only for use on that piece of hardware. These licenses are tied to the lifecycle of the hardware and typically cannot be transferred to other hardware.

Processor (per Processor/CPU): A license based on the number of CPU/Processor sockets on which the software will run, and NOT the logical processors aka cores.

Client Server: A server license that is based on a device metric. In many cases this type of license may also have a Client Access License (or CAL) aspect. In a Server/CAL model a license must be purchased for the physical server (or virtual server – there are varying rules around virtualisation) and also additional ‘access’ licenses must be purchased for any users/devices that may access the server for that application.

Run-Time: A license that provides access rights to third party software embedded in an application. The use of the runtime license is limited to the application through which it has been acquired.

Site: A license to install software on an unlimited number of computers at one physical location.

Device (most common metric): A license for a defined number of software installations. The software may be uninstalled on one computer and installed on any other computer within the same enterprise, so long as the total number of installations does not exceed the number of purchased licenses.

Core/Processor points: A license based on points applied as a multiplier to the number of Cores/Processors in the physical server, or in some cases, the virtual machine. Some vendors count Processor sockets and others count logical processors, or cores, but the license model is similar. For example an application installed on a 4 processor server with 100 points per processor would require a purchase of 400 processor points to cover the license liability. These licenses are mainly used for Datacenter software licensing such as IBM.

Common Software Asset Management (SAM) Terms

Installations: The number of raw software installations without Product Use Rights or license metrics applied.

Entitlement: The number of purchased licenses available combined with any Contractual or Product Use Rights.

Consumed: The actual license liability (not to be confused with ‘Installs’), Consumption is the install count applied against the Entitlement

Compliant: If the number of licenses consumed is less than or equal to the number of licenses purchased.

Breach: If the number of licenses consumed is more than the number of licenses purchased.

Delta: The difference between the number of licenses consumed and the number purchased (for example 10 licenses purchased and 14 consumed would mean a delta of 4).

Was this useful?  Do you have other software licensing and Software Asset Management (SAM) terms and definitions you would like to share?

By: Steve Mullins

In first grade, we all learned that 1+1=2. In our family 1+1 = 4. That’s 1 wife plus 1 husband resulting in a family of four. Luckily for us, software doesn’t quite reproduce the same way, though I’m sure we might think so as we start to look at software install counts versus what we were expecting, in say a virtual environment. Take, for example, two installs of a piece of software that consume 4 licenses because the software is installed on systems with two processors, and the license for the software counts license consumption based on the number of processors. In that case 1+1=4. The process of counting installations, determining the correct number of licenses required and comparing to software purchases is often called software license reconciliation, and that’s a subject for a separate blog.

In another example, what about an IT asset management inventory that says there’s one copy of Adobe Acrobat on Steve’s Laptop under the Program Files Directory, and evidence of another copy of Adobe Acrobat in a different location, but there really is only one copy of the software with evidence being counted twice. You might know that Steve only has one copy of the software, but the software inventory says there are two copies. So, in this case 1 + 1 = 1 as long as you can reconcile the two pieces of inventory evidence correctly.

So just how is software counted, and how can the count sometimes be more than we expect (1+1=4), and sometimes less (1+1=1), and how can we resolve these issues to come up with an authoritative count we can use?

What are we counting and how are we counting it

The problem is not always the addition or reconciliation; problems can often occur in the counting well before any addition takes place. In addition, just what does it take to determine that an instance of Adobe Acrobat is actually installed, not to mention verifying the version and edition? It’s really a question of just what are we counting and how are we counting it.

So how do we assure we are counting correctly? For illustration, let’s take the example of the age old promotion retail stores do— placing a huge number of items, like marbles, in a jar and asking passersby to count them. Counting the marbles while in the jar is almost an impossibility, even if you use complex mathematical formulas (you can equate that to counting software on systems not connected to any network for example— you might as well just make a wild-eyed guess); there are just too many unknowns and variables like how large is the bowl, are the marbles all the same size, did the retailer put any fillers in the bowl. But even if you take all of those marbles out of the jar, then ask different people to count them you still might get different answers. Each person might use different methods to count and verify such a large number, and since the task is very monotonous, they will probably develop some scheme to make their job easier. So each starts using different methods to count, and no matter how accurate they are, chances are, they still could get a different number.

But then ask them not only how many total marbles there are but how many of each type there are. Chances are the variance will be huge when you start to compare the different counts for the different types. That’s because different people will have different ideas on what types of marbles there are, and as a result, one person might say they counted 285 cat’s eyes, while someone else might give you a number of 492 cat’s eyes. How, you may ask will two different people give such widely diverse answers? Well it comes down to what each person thinks a cat’s eye is.

Well, believe it or not, the same thing applies to counting software installations in your environment. Ask someone from IT how many copies of Microsoft Project are in your environment, and they will give you one number. Then ask someone from your help desk how many copies of Microsoft Project are out there, and you will probably get a completely different answer. Chance are these two employees are using two different sources to determine their answer, and each source will have its own idea of just what constitutes a copy of Microsoft Project being associated with a user or machine.

Then you need to consider that these two employees probably have a different understanding of just what you mean when you ask to count Microsoft Project. Is it the full install of Microsoft Project; the latest version of Project; and should we count editions of Microsoft Project separate from Microsoft Project Server components; or does the count include the free version of the Microsoft Project viewer as well. So your first problem is trying to come up with the definition of just what you mean by Project. Even if you were specific enough to say “How many copies of MS Project 2009 Professional do we have” you still might get two different answers because these two employees probably use two different resources to find the answer to the same question. One might use a raw inventory count, while the other might be using a reconciled count provided by some centralized help desk system or CMDB. Again, too many variables when trying to answer one simple question.

And don’t even get me started about asking Accounting how many copies of Microsoft Project they think you have in your company. Let’s just keep focused on counting how many copies of a particular software application you may have in your environment.
So the key here is to understand what you are asking for, and to make sure the people tasked with providing an answer also understand the same question. In this blog, we are trying to address the issues around counting the software installed in an IT environment. This includes the scrubbing of the raw inventory data using an application recognition library and also takes into consideration hardware characteristics.

Keep things simple

So what can we do about the task of counting what software is installed in the organization? Instead of using something like MS Project, let’s start with something easier like the operating system, and let’s just use one source for our question, in this case IT. When we ask IT how many copies of Windows XP operating system we have (our standard for all end-user systems), they might look at their inventory report and answer simply 4,982. So should we believe them? Is this the number we should provide to Microsoft when they come in for their annual true-up? How do I know if this number is even close and how can I verify it. Especially if you remember that just last week, you asked IT how many end-user computers they managed, and they gave you an answer of 5,250. So in this case 1 + 1 doesn’t always equal 2. 5,250 computers with one OS each should equal 5,250 copies of Windows XP, but it doesn’t. So where does the discrepancy lie. Well the first thing to realize is there’s not one answer to the question of why your numbers often times don’t match.

If IT tells us we have 5,250 computers they manage (we are going to ignore servers to keep this easy), then logic tells us we must have 5,250 copies of the standard OS we manage as well. If Windows XP is the standard for our world, then we must have 5,250 copies of Windows XP. So we go to our inventory and the latest inventory report tells us we have 6,384 computers and only 4,982 copies of Windows XP.

So you need to verify the count before talking to Microsoft. Once you start digging a little further, you may find several different items that can change this simple logic such as:

Oh, we forgot about the 800 systems we just ordered that we included in our count of computers, but that haven’t been inventoried yet.
Also, we have about 500 or so older computers that we never upgraded to Windows XP because they were fine with Windows 95, and we didn’t want to risk crashing the systems with an upgrade.
And then there’s a bunch of systems in the closet that have never been inventoried by our new inventory tool.
Oh, and then there are the 400 systems that development uses for testing that they loaded Linux on
And the list of variances continues on and on the deeper you dig.

Solution part 1: A central Hardware and Software Asset Management Repository

So how can we solve this problem that seems to get worse and worse the more you dig into it? To start, you should put in place consistent measures of software that utilize proven methods of reconciling all of the variances and discrepancies that arise in counting software. It’s also important to note that no matter what method of counting you use, you are always dependent on the source of the original count, which in most cases is an inventory tool or multiple tools of some type, so it’s always a good practice from time to time to run comparisons on the inventory counts from different systems. For example, how many computers does the helpdesk monitor, vs. how many computers is the inventory system reporting, and how many computers does accounting tell you that are currently on the books. Also, you should put into practice the process of comparing the electronic inventory with a regular physical inventory to help clean up systems that simply are no longer found in your environment.

In addition to putting in place standards for counting and measuring your systems and software, you should also implement a central Hardware and Software Asset Management repository. It should have built-in reconciliation algorithms, including application recognition based on known libraries of software and have the ability to reconcile varying sources of inventory data into a single count. The system should also take into consideration the hardware portion of the equation— which systems are active, which systems should no longer be counted, and which systems are double counting themselves for some reason and hence should be discarded.

Well, since I’m about to get off the airplane, we’ll continue with Solution Part 2 next time. Meanwhile, happy counting, and please don’t tell my 1st grade teacher that 1+1 doesn’t always equal 2. It would break her heart.

By Alan Swahn
Contracts in general have many stakeholders across multiple departments. Getting upfront reviews and approvals isn’t trivial. Once a contract is executed and in the file cabinet or document management system, tracking time-sensitive terms and compliance to terms is even more challenging. Contract management products and standard processes can help resolve many of the problems associated with a contract lifecycle, if the flashpoints that cause delays within the system are designed out.

One to watch is the workflow management component that can be a go or no go, for efficient contract management. Workflow management is the process enforcer that facilitates transparency, making deadlines, and compliance (contract, regulatory, tax…). Workflow should be tightly coupled to the lifecycle of a contract for:

Request
Sourcing
Approvals
Fulfillment
Auditing
Renewals/Cancellations

A number of key workflows have an associated people matrix. For an approval workflow it may be the approvers and their roles associated with contract amount signoff, contract type, and originating location. If changes are performed manually to approvers’ roles or the approvers themselves, this may be a flashpoint waiting to happen. Updates become reactive to process delays or break down. An example would be a workflow process that is waiting on approvers that are never going to answer the bell. Perhaps because they are on vacation, traveling, on sabbatical, have left the company, or are just off the grid. It doesn’t mean the workflow process will fail. Workflow systems can handle aging, escalation, warnings, failover, cancellation, and updates for workflows in process. In this example the workflow should trigger an escalation phase and backup approver as required. But escalation delays make the process less efficient.

On the flip side, if the workflow system is connected to a dynamic source, a change in personnel could be accounted for and the workflow automatically corrected. The dynamic source doesn’t need to be complex, just accurate and kept up-to-date. In the foregoing example, a company directory that includes name, email address, title, department, and location is sufficient. Of course there should be an accompanying database source that associates a person’s title, department, and location to approval scope—department, business unit, subsidiary, company wide; type of contracts; and dollar amount. The approval scope database changes very infrequently, once setup. On the other hand, a source like the company directory can change almost every day in a large global organization with employees taking on new roles within a company, new hires, and people leaving. The workflow management system should “see” the changes in the company directory, and update its matrix of approver logic, based on their scope. It should then update any workflows in progress to account for the approver change. This potential flashpoint is then removed by a combination of robust workflow and a dynamic data source.

Another flashpoint is the inability to kickoff a workflow, or at least an alert, based on a contract term. Once a contract is signed off and in the firebox, the real work begins. With 1000s or 10000s of contracts, how do you know if the terms are being followed, tiered discounts are being taken, there is compliance to escrow deposits, time sensitive options are executed, or termination provisions proactively selected? An auditable closed loop process is really required. Key terms in a contract should be easily associated with a workflow, before the contract is put in the box. The associated workflow can then be the compliance watchdog to ensure the maximum benefit is achieved from each contract. This flashpoint is therefore addressed by picking a solution that doesn’t view contract management as document management alone, but rather understands the contact management lifecycle and supports the creation of closed loop auditable processes.

By: Vincent Brasseur

IBM announced on April 12, 2011, a change for selected products whereby they are moving from the Processor Value Unit (PVU) software license metric to the new Resource Value Unit (RVU) metric. This impacts several product families such as Tivoli Monitoring, Tivoli Provisioning and Service Delivery Manager. PVU and RVU metrics are radically different:

With the PVU metric, the capacity of the server where the application is installed is measured. If this application is moved to another server or the hardware properties (processors) of the server hosting it are changed, the license may be impacted. This can easily happen in virtual server environments. So, there is a risk of being out of license compliance.

With the RVU metric, the number of units of a specific resource used or managed by the application are counted. The application can be freely moved across servers and the hardware properties (processors) of the server hosting it can be modified with no impact on the license.

This makes perfect sense: the capacity of the server does not always correspond to the usage of the software installed on it. In the past, with the PVU metric, many IBM customers had to choose between price and performance when selecting hardware on which to install the software. With the RVU license metric, IBM customers will be able to configure and adjust the hardware capacity of the server hosting the application to meet their business performance requirements: there will be no impact on license compliance or license cost.

What is a Resource Value Unit? The purpose of the RVU license metric is to tie the number of licenses required, measured in RVUs, to the utilization of the software or the resources the software manages. RVUs may use– the number of Gigabytes, premium income, pages per month, number of messages, etc., as units of measure. The price of the license is based on the number of RVUs required. The RVU calculation is quite complex and usually uses a factor that is applied per quantity tier. In the case related to this IBM announcement, the number of activated processor cores for physical or virtual servers managed must be counted for RVU licensing. The factor table is as follow:

For Servers (active cores):

Quantity Factor
0 to 2,500 1.00
2,501 to 10,000 0.80
10,001 to 50,000 0.60
50,001 to 150,000 0.50
Over 150,001 0.20

Example: if a customer has 45,000 Activated Processor Cores across its managed servers, it will need 29,500 RVUs.

(2,500*1.00 + 7,500*0.80 + 35,000*0.60) = 29,500 RVUs

If the resource considered is a client device, the metric is just the number of client devices but a different factor table is applied. For managed servers, it is not that simple to get the right number of license entitlements needed, as it relies on a number of cores. It gets even more complex if the servers considered are deployed in virtual environments: the RVU license metric in this case supports sub-capacity licensing. In these environments, the measurement of Activated Processor Cores is based on the number of processor cores available for use. Rules and definitions are clearly defined by IBM but are specific to each virtual environment (virtual machines or hardware partitions).

Overall, customers will benefit from the IBM announcement and the use of the RVU software license metric: they will purchase a license from IBM that will be calculated based on what they use. However, moving managed servers across hosts in virtual environments or modifying their hardware characteristics can impact the license position in cases where the RVU is based on active cores available in those managed servers. Staying in license compliance is not going to be easier.

By: John Emmitt

A recent Gartner Research report—Contain Virtualization Licensing Costs With Software Asset Management Best Practices—identifies a number of license management challenges when dealing with both server and desktop virtualization. It also provides several software asset management best practices that organizations should adopt to help meet these challenges. But, organizations can and should do more with the help of next generation software asset management technologies that understand and apply license entitlements, including virtual use rights. Its ‘virtually’ impossible to maintain license compliance and control software costs in these complex environments without the aid of technologies that can automate significant parts of the process. Best practice software asset management processes and procedures are always important, but especially in virtual environments, license management technology is also an imperative.

In virtual server environments, the challenges include the ability to move virtual machines from one physical host to another, using technologies such as VMware’s vMotion. The software license may or may not allow such a move (e.g. Microsoft imposes 90 day move restrictions in some cases), but even if it does, there are additional complexities to consider. For instance, the new machine may have a different processor-core capacity and therefore, the license requirements could change. More cores could mean you need additional core-based licenses.

IBM provides what is called subcapacity licensing for virtual environments that allows customers to license less than the full processing capacity of the server, based on the availability of multiple processors or cores in the machine. The virtual machines running the application can be allocated a subset of the total number of processors in the physical host—say 2 out of 16, for example. This can save you money on the licenses required for your application. Other vendors may require you to license all of the processors on the server, regardless of how many processors are allocated to the virtual machine for the application in question. Oracle typically does this, unless you are using Oracle’s own virtualization technology with hard partitioning.

Symantec also defines virtual environment use rights for their datacenter server products. For example, the operating system edition determines the number of virtual machines allowed per license for Symantec Storage Foundation. The Symantec license tiers correspond to the Windows Server virtualization rights granted by Microsoft. On Windows Server Enterprise edition, the Symantec software may be installed and run on up to 4 virtual machines, whereas for Datacenter edition, the number of virtual machines is unlimited.

On the desktop, the challenges stem from the fact that the application can be streamed from a central server, rather than being installed on the client device. So, install counts don’t help with understanding license compliance in these environments. And now, users can access software running on their virtual desktop, from their mobile device, home computer, or airport kiosk, in some cases. Microsoft allows these Roaming Use Rights for certain products, such as Office, Project and Visio, under Software Assurance. Software licenses are required for all devices that are used to access virtual images of these applications.

These examples illustrate the complexity of the license management problem in both virtualized server and desktop environments. The software asset management tools must understand not only the license models in use—e.g. IBM Processor Value Unit (PVU), but also the license entitlements related to virtualization for that software title, that vendor and the type of license purchase agreement in effect. Customers are ultimately responsible for maintaining license compliance, and need to leverage best practices and technology to meet the challenges of virtualization.

By John Emmitt

A recent article published by industry analyst R “Ray” Wang of Software Insider and Constellation Research Group shows that software audits have risen dramatically over the past 3 years. But you probably already knew that if you are responsible for license compliance in your organization. In the Q1 2011 Software Licensing and Pricing Trends Survey, 58.9% of respondents had been audited in the past year. This was up from 26.6% in the 2008 survey. The primary reasons that major software vendors gave for audits were- to keep customers in compliance and to drive incremental license sales as well as find opportunities for new deals. So, as might be expected, audits are mostly about generating revenue for ISVs.

The article also alludes to the “pain and agony” of a vendor audit and then provides some sound advice for enterprises to help them be better prepared for a software audit or license review. Software audits are costly not only in terms of potential unbudgeted license true-up fees, but also from the standpoint of the time spent collecting the data for the auditors. One customer of ours, a large financial institution, was able to respond to a Microsoft license review in less than 2 weeks time. Another bank of similar size was audited by the same third party audit firm, and required a full year for a similar exercise. There are a lot of dollars attached to an audit process that takes your IT staff a year to complete. You need better software asset management processes and tools in place to minimize this time and expense.

In fact, deploying software license management tools is one of the recommendations in the Ray Wang article. Having the proper processes and tools in place can help you avoid software audits altogether, since vendors generally go after only those companies that they believe to be out of license compliance. That’s why audit ROI is typically very high—the software vendor is fairly certain that there is a compliance problem before they knock on your door. And by high ROI, I mean in the 1000’s of percent in some cases! They do database analysis to check for licensing anomalies that are indicators of non-compliance. For example, if a company has 5000 employees but only 3500 Office CALs, that might trigger a review. Merger and acquisition activity is another common audit event trigger.

Of course, an optimized license management program pays many more dividends than just those discussed here in relation to software audits. Software spend management and ongoing cost reduction are key benefits of optimized license management. So, even if your organization is in the 41.1% minority, and you’re not facing any software audits, there are still planty of reasons why you should implement a software asset and license management program.

By: John Emmitt

Join us for a Defense Systems sponsored webinar on May 17th, 2011 at 11am EST.

Space is limited. Reserve your Webinar Seat Now at:
http://defensesystems.com/webcasts/2011/04/optimized-license-management-for-the-datacenter.aspx?tc=page0

Please join Flexera Software and Defense Systems for this webinar to learn how your organization can achieve significant IT cost reductions in your datacenter.

Software represents one third of the typical IT budget and datacenter applications are usually the most expensive component of software spend. That’s why datacenter license and maintenance fees offer the greatest potential for cost-savings in the software portfolio. Decreasing ongoing costs of multi-million dollar applications in the datacenter is a fundamental component of overall IT spend reduction.

In this webcast, you will learn how to meet these datacenter license management challenges:

Heterogeneous / Multi-platform environments (Windows Server, UNIX, Linux)
Complex License Models
Virtualization
Complex License Entitlements
And how to reduce datacenter software costs by:
Applying product use rights to minimize license consumption
Reducing ongoing maintenance costs
Reducing the cost and risk of software audits by maintaining license compliance

Speaker: Cyndi Tackett, Sr. Manager of Sales Engineering, Flexera Software

Register Now!