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.
Archive for the ‘Software Piracy’ Category
SoftwareCEO.com Shares Tips for Software Pricing and Licensing
Bruce Hadley, Founder and Editor of SoftwareCEO.com recently published an article regarding a conversation he had with Steve Schmidt, Vice President for Flexera Software, providers of application usage management solutions for ISVs and intelligent Device Manufacturers. In the article, Steve shared nine (9) software pricing and licensing tips, as well as his thoughts on the hottest trends like cloud computing, SaaS, and subscription licensing. Steve's tips included: Tip #1: If you have only one pricing and licensing model, you don't have enough. Tip #2: Add a pricing and licensing model that's subscription-based. Tip #3: Add a pricing and licensing model that's usage-based. Tip #4: Your pricing needs to flex, but prepare for the hit. Tip #5: Add automated mechanisms to support the new model and provide visibility. Tip #6: Increase scalability within your pricing and licensing model. Tip #7: Implement flexibility in packaging. Tip #8: Make your software portable within the pricing and licensing model. Tip #9: Homegrown solutions aren't likely to survive the long haul. Bruce comments, “Sure, Schmidt and Flexera have something to sell — but we happen to agree that most ISVs should not attempt to create their own systems for application management. Even if you are capable of building such a thing, it will detract from what should be your primary focus: Improving your own software.” For the complete, in-depth interview, read the entire article: Flexera Software VP Offers Tips for Software Pricing and Licensing .
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:
Making a Successful Software Licensing & Entitlement Management Project a Reality
By: Victor Hoisington, PMP, ITIL Deciding to upgrade your software licensing and entitlement system is never an easy task, but it's one that will provide tremendous operational savings and revenue growth.
Ready, fire, aim. Full speed ahead with virtualization.
By: Randy Littleson I've had the opportunity over the last couple of weeks to speak to a lot of press, analysts, customers and prospects.
Why ERPs Aren’t Suited for Entitlement Management
By: Mathieu Bassaic I can't count the number of times CIOs of larger software or OEM companies have told me, “We're doing entitlement management in our ERP system.” My typical response is, “So I bet it hasn't worked so well for you because it's like using your stove as your furnace. It can be done—but it's far from ideal.” There are some basic architectural reasons why ERPs aren't suited to entitlement management. Most entitlement management implementations are done in ERP's install base. You'd be amazed how much SAP and Oracle's install base look alike – so this issue isn't about one vendor vs. another. It's about the fundamentals: Install base is a component of the asset management “modules” of ERPs They were created to track large assets and the impacts on financial books Let's say you're a big printing company, you've got 20-30 printers that cost millions – you want to track those assets as they depreciate, etc. Install base is perfect for you. Install base architecture is based on assumptions like: Few assets (in the 1000s not in the millions) Don't need interdependency between assets (because that doesn't affect depreciation) Any change to those assets has potential financial impact Detailed knowledge of those assets isn't required Ownership of assets is assumed to be the person running the ERP—not a customer or a channel partner So here is what happens when you try to use an ERP install base for managing software entitlements: You can't link asset records together – so when features of a base are upgraded, you have to remember to make changes to multiple records You want to upgrade 100s of thousands of entitlements/assets to a new release because your customers are on maintenance – it takes literally days to run jobs to do this You want to move an asset/entitlement from one organization to another, you have to go through dozens of screens because the ERP thinks that it's moving depreciations around (even if the organization is in the same company) If you want to generate licensing keys or serial #s or… you'll end up doing a lot of coding There is no place to put meta data about licensing structures – more coding Sending emails or files is a foreign concept – more coding Handling concepts like changing fingerprints/machine identifiers doesn't exist – more coding You want to share entitlement (asset) information with customers / channel partners so that you can all agree on a single “source of truth” – more coding please In addition to the fundamental architectural issues with ERPs, there is another flaw with trying to put entitlement management functionality in an ERP: ERPs are core to the business. They are large. They are the vital center to large organizations. They can't /shouldn't change frequently – and usually don't. Typically ERPs are upgraded every 3-5 year years. Entitlement Management reflects licensing/marketing rules. They need to react to new product and program introductions – which happens 2-3 times per year. So confining fast moving, highly responsive requirements into a, by intent, slow moving solution is like putting a jet engine in a truck. At some point, the truck will break the jet engine or the jet engine will force the truck to become aerodynamic – either way – not a pretty sight. Someone will then come up with a hybrid solution: why don't we feed the entitlements from the install base to a CRM. This isn't any easier – I've seen it fail. CRM architecture isn't much better than ERPs and now integrating the two is doubly difficult. Unfortunately System Integrators make a lot of money from doing these changes – so they have no incentive in providing the right solution: Entitlement management should be a build-for-purpose solution which integrates into an ERP and CRM infrastructure With a build-for-purpose entitlement management solution , you get the best of both:
Exploring the Software Licensing Implications of Cloud Bursting
By: Jeanne Morain For many enterprises and software vendors alike there are details that must be solved around people, process, and technology when designing your cloud strategy.
Is Your Current Software Pricing Approach a Barrier to Adopting New Pricing Models?
By: Cris Wendt When pricing software licenses, there is always the classic tradeoff of generating more revenue and market share versus managing the cost of sales and deployment. On one the hand, you can offer multiple price points for the software by grouping different functions into products, or, by offering many new software license models. This gives you the precision to attack different market segments or types of users based upon specific value and need. The downside of this approach is that it may be more complex to figure out exactly what combination of product and software license model fits your customer(s) needs. You will typically see such pricing approaches for large enterprise software that is scalable to address a wide variety of customer needs, such as an ERP or CRM package. On the other hand, there is the approach of offering fewer price points and simpler pricing. With this approach, there is less pricing precision, but it is typically easier for the channel and customers to figure out what to buy. On the surface, this is clearly a less sophisticated approach. This type of software license pricing model is often used in desktop productivity software such as Microsoft Word. Selecting a software pricing approach can be a complex exercise, as many factors need to be considered. However, one of the many factors I like to emphasize is the deployment model behind your product – this means the number of copies of software licenses you sell, and, the corresponding channel model. If you are selling deployment that offers a single instance of your software typically with a direct sales model, then using multiple price points is a good way to drive the revenue model. A direct sales force is more capable of explaining the value, and the pricing model allows revenue scale based upon the organization's size, need, and growth. SAP's ERP software is priced on such a model. At the other extreme, if you are selling tens, hundreds and thousands of copies and use a channel, then it may make sense to make the software products and license models much simpler. This makes it easier for customers to understand what to buy, and, for the channel partners (who often sell products from multiple vendors). In this case, revenue is based upon volume and sales velocity. This is why Microsoft Word doesn't offer too many variants of pricing, such as offering different prices for the spell checker, interfaces to Excel, etc. Such a model probably already makes sense to companies in one or two of the categories. But, it can be a good lesson if you are in the business of offering more sophisticated software with complex pricing models, and then trying to go “down-market” with high volume deployments. The institutional culture behind pricing and selling a more complex model often creates a mindset and a barrier to changing the underlying pricing model to accommodate market needs. Complex models usually include sophisticated sales tools, direct customer interaction, finance and entitlement systems that require a knowledge of the customer configuration in order to perform any expansion sale, and often the presence of a services engineer to install the software. Trying to price software for different market needs becomes difficult because no one thinks that way, and no systems are set to support that type of business model. This can lead to a failure of “down market” initiatives. That's why it's difficult for large enterprise software companies to move into more high volume markets. Clearly, this becomes more than a software license pricing issue…systems and processes are involved, but simply understanding that a new, simpler software licensing and pricing model is required as a first step is paramount to making the transition. Change requires change. Next Time – What does it mean to your entitlement management system when you move to a high volume software business?
2010 Global PC Software Theft Reaches Record $59 Billion
In the global market for personal computers, 2010 was a watershed year. For the first time PC shipments to emerging economies outpaced those mature markets, 174 million to 173 million. This turning point underscores how emerging economies have become the driving force behind PC software piracy, which leapt 14 percent globally in 2010 to $59



Posted in
Tags: