Posts Tagged ‘License’

Can you quickly and accurately determine your installed base?

By Michael Costa That seems like a fairly easy and obvious question. Do you know who has which of your licensed software and/or hardware products, where they are located and to what each of your customers is entitled? With many companies responding to market demands for greater license flexibility and customer self-service, maintaining accurate installed base data is becoming a huge problem that must be addressed. Accurate installed base data allows you to maintain and grow your software and/or intelligent hardware business. Revenue from compliance true-ups, maintenance, support, upgrades, up-selling and cross-selling all depend on accurate installed base data. Attempting to audit license compliance based on erroneous installed base data can severely damage your relationships and reputation. Maintenance and support renewal quoting always starts with an accurate installed base view and asking customers to tell you their installed base undermines customer confidence. An otherwise focused up-selling or cross-selling campaign is considered “spam” to targeted customers that do not meet the applicable installed base profile. And, requiring your channel partners to report installed base lifecycle data in an accurate and timely manner is often more than they can achieve. Maintaining accurate installed base data is usually difficult because licenses tend to change during their lifecycle – sometimes frequently. Some of the common lifecycle stages include: initial sale, maintenance renewal, move, rehost, update, upgrade, downgrade, subscription extension, end-of-life and return. In addition, if you have an indirect sales channel, the initial sale can include two or more additional sub-stages. Inadequately integrating these transactions renders the installed base data for applicable licenses obsolete and useless. Workarounds require expensive, custom or manual integration with other transaction systems – and these workarounds are seldom scalable. One of the most common misconceptions I've heard is that the “installed base” module in an ERP system is a viable system-of-record for storing all license lifecycle transactions. The problem is, as Mathieu Baissac pointed out , ERP systems were never architected to support the dynamic nature of today's flexible, self-served license transactions. ERP systems were designed to manage relatively static, physical assets – largely from an accounting perspective. They worked OK for software when license rights (i.e., entitlements) were relatively static – involving only initial sale, fixed period maintenance and end-of-life. But, as entitlements became more dynamic and hardware became field-expandable and networked, ERP systems became less and less viable. Many companies invested heavily to augment their EPR installed base modules to fill the functionality and performance gaps, but that has proven prohibitively expensive, slow and risky. At this point, ERP systems are only the system-of-record for the initial sale stage of the license lifecycle – primarily because they are often used to process orders. SalesForce.com is increasingly the primary or secondary order entry system for many companies because it is a natural, lower-cost environment for that purpose. An Entitlement Management System is increasingly recognized as the “always-accurate” installed base data solution. An entitlement management system converts orders into entitlements consisting of license rights that customers can then consume, transform and manipulate – within the terms of the purchased license rights. Those rights can include all of the license lifecycle stages mentioned above and many others – overdraft, peak usage, draw-downs and term licenses. License rights are not only applicable to software. Many intelligent hardware products are also being developed with flexible use rights metrics like storage capacity, router channels, networking bandwidth, medical diagnostic tests and even surgical procedures. Flexera Software's FlexNet Operations solution is an example of a mainstream entitlement management system that is specifically designed to manage the dynamic nature of current and future software and intelligent hardware lifecycles. It integrates with other on-premises, on-demand and mixed-environments like Oracle, SAP, Saleforce.com and many others using standard, configurable interfaces. Also, its tight integration with electronic software download, in-product license management and in-product messaging functionality to provide commercial, out-of-the-box best practices.

Will the Perpetual Software License Model Ever Go Away? That Depends Upon Who You Ask…

By Cris Wendt The perpetual software license model won't seem to go away, as much as the press and various surveys seem to indicate. The perpetual license model has been the predominant method for selling the software license for most software for the past 30 years. With this approach, software is purchased with the right to use software into perpetuity. Of course, most software only has a useful lifetime of anywhere from 3 – 10 years. The software will eventually become obsolete due to a number of factors including the obsolescence of the underlying hardware, the changing nature of the problem that is being solved, or the availability of better software. To remedy this situation, a maintenance plan is offered whereby a combination of phone support and software updates or “refreshes” are provided. For better or worse, companies know how to sell this software and manage all of the associated business and accounting practices, and, end-customers know how to deploy this license model. The alternative, broadly speaking, is the subscription or time-based license model. With this license model the right to use the software expires after some amount of time, and the license must be purchased again if it is to continue being used. In some cases (the subscription model), the right to install software updates is included. As described in previous blogs, there are different financial reasons why some markets, or some specific customers prefer one license model over another. For the past several years, Flexera Software and IDC have been conducting an annual survey asking a variety of software producers in various markets which license model generates the most revenue, and, how they expect that mix to change. While there is some variance among different markets and in the actual numbers, the general answer seems to remain the same every year – almost like the recurring day in the movie “Groundhog Day” – About 66% of the revenue comes from perpetual licenses, 34% of the revenue come from subscription licenses or some other variant. Furthermore, respondents say that they expect the mix to change about 10% toward offering more subscription licenses and away from the perpetual license. However, the results of this perceived migration toward more revenue being generated by time-based licenses hasn't occurred. Perhaps we've reached an aggregated plateau where the license models have stabilized based upon the various forces and value propositions in different markets. My guess is that this situation won't change, ever………..with one caveat – this will be the case for on-premises software – that is, the case where software runs on machines at the customer environment. In these situations, the hardware and software form a system unit that is more physical than virtual, so a license model that matches to a machine lifecycle makes sense. However, as we enable our customers to take advantage of mobile computing and elastic compute models built upon virtualization and the cloud, then perpetual licenses will be non-existent and pay-per-use or time-based models will be the norm. So is the perpetual software license model going away? Well, that depends upon who you ask.

Software License Management: Process Improvement Using Automatic Renewal

By Flexera Global Consulting Services EMEA I have recently engaged with a software publisher who needed to deliver licenses to customers worldwide. For some countries, customers are allowed to divide payments into multiple chunks over time. The publisher, on the other hand, must ensure the customer performs the payments at the times expected. For this reason, the process of delivering software licenses depends on the ongoing status of their contractual agreement with the publisher: customer receives a new time-limited license with extended validity period every time the publisher receives the payment in advance for that period.

Think Monetization Before Enforcement with Subscription Software Licensing Models

By: Cris Wendt If you are a software vendor, a subscription software license model can be an excellent addition to your product pricing portfolio. The subscription software licensing model can offer a lower cost of entry for your customer, making it a more cash-flow friendly if they need to closely manage cash flow. The subscription license model is often accounted as an operational expense rather than a capital budget item for the buyer, which may also be appealing to your customers who prefer this method of purchasing software (this is popular with engineering software where software license procurement is viewed as a project expense). And for the vendor, the subscription software license model offers the promise of a more predictable annuity revenue stream. This is quite appealing to a CFO who can plan and budget more accurately with known revenue streams. Of course, the subscription software license model isn't always a fit for all software in all markets. However, there are cases where we find that a subscription software license model is a perfect fit for the business, yet the software vendor is reluctant to adopt it. The argument I often hear can be paraphrased as, “Yes, it's the perfect model, but we can't have our software stop running because a license key expired. Our customer's business can't go down.” This is a case of backward thinking – there is an inaccurate technology view of the subscription software license model that affects its adoption. If the subscription software license model is the right monetization and customer-friendly model then it can and should be adopted. Next is the enforcement decision, which can be applied somewhat separately from the software monetization decision. It too, is a business decision, and not a technology decision. If your software is mission critical to your customer's business, and if you trust your customer, then your compliance philosophy should be never to stop the customer from running, but to monetize this over-usage when possible. An enforcement mechanism, such as a license manager, does not actually stop software from running. The license manager simply informs the software that the license has expired, and it is up to the business policy coded into the application that decides on what to do. There is an entire range of possibilities from simply messaging a customer that the software license has expired, all the way to the hard stop of an application. In fact, the business policy coded into the product can be designed to vary by a number of factors (mission criticality of product, product lifecycle, geographic region of sale, size of customer, etc.). If your customer is running your software in a mission critical environment, then simply give them a message that their license has expired. And, be sure that the associated entitlement management systems are providing the business information that a license is about to expire so that a sales conversation can be arranged. Subscription software license models are a great way to grow market share and increase customer satisfaction. If it makes sense, adopt the software license model, and tune the enforcement mechanism to align with your compliance philosophy.

What the Heck is a Token Software License Model?

By: Cris Wendt A flexible software license model that is gaining some traction in the market is a token software license model. This model is very effective for software vendors who have a wide portfolio of software where the usage patterns of individual software are difficult to predict. This situation often occurs in technical markets, where the portfolio of software is used in a design flow, or to conduct a software experiment. Users may not be able to predict how much software to purchase at the beginning of the purchase cycle as the usage of software may be dependent upon the challenges faces in a particular design. For example, in electronic design, a particular design may require more simulation software than previous designs have required. From the perspective of the software vendor, it's also an effective way to fortress a market position against point-tool competitors. The token software license model makes it financially easy for the customer to utilize the entire portfolio of software, and not try to buy the best-of-breed for every part of a design flow. Expiring Concurrent Tokens The simplest form of token software license model is implemented (and easiest described) as a variant of a floating license model . With the typical floating license model, each time a particular software product or title is run it checks-out a license key from a license server for the duration of operation. For example “Software A” will request a particular license key associated with “Software A” from a license server whenever it runs. If the license server has licenses available, the software is granted a license to run. The software will return the license to the server when the software is exited. Similarly, “Software B” will request a particular license key associated with “Software B” from the license server whenever it runs. When deployed as a token license, the software vendor creates a generic license key “token” instead of a license key associated with each product – the idea being that products don't check out product specific licenses, but rather, checkout one or more generic tokens – the amount of which is weighed toward the list price of the product.

The Nuances of Token Software Licensing

By: Cris Wendt The Token Software License Model (as a variant to the floating software license model) is a great way to provide flexibility to your customers. By selling tokens that can be used to invoke multiple products, you provide a great deal of flexibility to users who can't always accurately predict what to purchase. Implementation & Planning Considerations The implementation of tokens as a mechanism to control access to products requires some careful thought and planning. Typically, the Token Software License Model is implemented in conjunction with a license manager technology, such as Flexera Software's FlexNet Publisher software licensing module and operates something like this: before a product operates, it requests to check-out or consume tokens (non-product specific license keys) from the license manager. Based upon the availability of tokens in the pool at the moment of the action (determined by how many tokens were originally sold to the pool less how many tokens were consumed at that moment), the request is either granted or denied. While the implementation of this token license model is easily accomplished in the software when a license manager is present, there are some important policies that need to be established before an implementation begins: How do I determine how many tokens each product requires when it operates? That is, how is a token calibrated to list price? What is the sufficient granularity of value for a token? Is it $500 of list price per token? $1,000 per token? How do I handle list price changes to software? For example, if a product is designed to consume 5 tokens when it runs, what happens when the price of the product changes, especially if the software is already installed in the field? Suppose the new list price warrants that 6 tokens are consumed for each invocation, how do I handle customers that have an installed base of software that checks-out 5 tokens, with software that requires 6 tokens? How do I measure the usage of actual products when tokens are consumed? License managers typically record all license key request activity in a usage log for subsequent software asset management and usage profile analysis. In a non-token software license model, a product will consume a license key that is specific to a particular product. That way when the usage log is inspected, the usage attributed to a particular product can be understood by looking at the time that specifically-named license keys are consumed. When generic tokens are check-out instead, all usage is attributed to a generic token and it is impossible to understand which particular product consumed the token. All of these issues can be easily addressed in a design phase, but they must be carefully considered during the planning and implementation phases. The Temptation of the Token One of the more seductive aspects of a token is the capability to allow customers to access future products that were not available at the time the original sale was made. For example, at the time of the sale, it's easy to tell customers that a new, more desirable product will be available in 6 months, and that it will automatically operate with the token system. While such an assertion is appealing, there is a potentially serious downside—some or all of the revenue associated with the agreement may be deferred until the new technology is available. The topic of revenue recognition was discussed in earlier Subscription Licensing blogs. It is therefore very important to define and bound the parameters of future technology access whenever customers are provided with such a flexible software licensing model and to carefully consider the impact of revenue recognition.

Common Software License Types and Terms

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:

Which free software license allows free distribution/redistribution, but not modification of source code?

that’s pretty much it.

Is it true that the bible is like a software license?

Nobody really bothers to read it, they just scroll to the bottom and click “I agree”

How would violation of software license agreement affect different areas of life?

economy, business, personal, legal

Software license for Training Institute?

I want to start software training institute in India with legal software license, In case if i could not able to afford i want to purchase / contract from some other 3rd party company instead of direct company. Basically i am looking to start SAP software training institute, can any one tell me approximately how much i need to invest for SAP software license to train the people or take license from 3rd party company.

If you buy a software license, you don’t own the software, but do you own the LICENSE per se?

And if you do OWN the license, can a licensing agreement still limit what you can and cannot do with the license (e.g. give it to someone else, resell it, separate it from the terms of the agreement, etc.) Can a vendor say you don’t own something, even if you paid for it?