Entitlement and Compliance Management

The A, B, C’s of Software License Compliance and Enforcement

By: Cris Wendt

Sometimes the topics of software license compliance and enforcement seem twisted, very much like one of those M.C Escher drawings popular in the 70’s and 80’s that show complex physical objects connected in impossible ways though the optical illusions created by his drawings.

To this end, I thought a few blogs on the subjects of enforcement and compliance would be useful and interesting topics.

Let’s start with some basic definitions: software license compliance is a broad term to describe the behavior - whether or not software is being used within the bounds of a software license as established by the license agreement or the software entitlement the customer purchased. Software license enforcement is the mechanism or the mechanisms that are used to manage software license compliance. An enforcement mechanism will usually result in some experience to the user of the software to let them know if they are using the software outside the bounds of the software license agreement.

An enforcement technology and associated implementation method are designed to balance the needs of the software producer and the software consumer. In general, the software producer uses enforcement to grow revenue in one of two fundamental ways:

1. By making software easier to use so customers use and buy more than anticipated (making this a lower cost way to generating increased sales);

2. Or, by eliminating revenue leakage caused by software piracy and usage of software outside the bounds of the license agreement.

The software consumer doesn’t want unnecessary barriers to adoption of the software, in most cases, but they also don’t want to be out-of-compliance for any extended period of time, because that increases potential liability and risk.

Software license enforcement can be designed to create a continuum of possible outcomes for software that is used outside the bounds of the software license agreement. This continuum can vary from a "do nothing" approach on one extreme of the continuum, all the way to preventing the software from operating at the other end of the continuum. Within this range are a number of possible results such as messaging, enabling overdraft, warning customers that they’re approaching a limit, reduction in quality-of-service, and queuing requests. In fact, the outcome can vary by the specific type of software license compliance condition. For example, you may elect to prevent your software from starting if the customer does not have a valid license, but you may only want to give the customer a message if they are using the wrong version of software.

The software license enforcement methods that software producers employ don’t have to be a one-size-fits-all approach. The enforcement method can be tuned by a handful of key factors:

Market

– Software that is sold primarily to large enterprises and data centers where corporate governance and financial controls are stronger can utilize an enforcement method that is more liberal and tends more toward messaging users or "Nagware." On the other hand, if you are selling games to a consumer markets, piracy and intentional over-usage are probably the problems that you need to address. A stronger enforcement experience may be required.

Geography

– Software sold to the U.S. and Europe, where financial accountability and auditing practices are stronger, can also tend toward a more liberal enforcement policy than software sold to emerging markets with very weak intellectual property laws.

Product Type

– On one extreme, for example, enterprise-level software that is carefully deployed by an IT department and manages data integrity may never shut down due to out-of-compliance usage. On the other hand, desktop design software may be able to sustain a denial of service if the product is out of compliance.

Product Lifecycle

– Products that are early in their lifecycle and provide a lot of value may need stronger enforcement mechanisms to enable secure demos of the new technology, and to protect access to leading edge algorithms (especially with vertical application software such as design and CAD). On the other hand, a company with a wide portfolio of mature products that wants to block competition may want to lessen the enforcement approach as a way to make it easier to use their software and block the use of a competitor’s software.

While the implementation of a software license compliance and enforcement technology has technical implications, it’s very critical that the whole business is involved in defining and articulating a software compliance philosophy that will drive the implementation.

Next Time – Creating a Compliance Philosophy and Enforcement Profile

Through the Looking-Glass at License Models, and What Cris Found There

By: Cris Wendt

When it comes to software license models, I sometimes feel like a singular Tweedledee and Tweedledum, the twin brothers in Lewis Carroll's Through the Looking-Glass, and What Alice Found There. I feel ready to wage a personal battle by promoting opposing perspectives on license models, yet the battle never happens. Like the two brothers with their opposing views, the confrontation never happens because the two views really complement one another and are not contradictory.

The issue is the license metric, the component of a software license model that is used to apply pricing. This is known by such names as "concurrent user", "named user", "Number of CPUs", etc.

At times I feel like Tweedledee by suggesting to companies that the license metric should be a way to create more price points to reach new markets or new customers and increase overall revenue. By understanding different usage profiles, it’s possible to expand a software license that is sold by, for example, named-user, and offer a different type of metric that allows the software to be sold by concurrent users. Such an approach may be used, for example, to take software that is used by a particular individual, and allow it to be affordably used by a wider audience of users as they may not all be using the license concurrently.

At other times, I feel like Tweedledum, by suggesting just the opposite. I sometimes tell companies that they have too many license metrics in their portfolio and that they need fewer of them. For companies that have a large number of software titles that are sold as a larger solution, the complexity of offering many different software license models for the various products can be counter-productive and confusing, especially for customers and channel partners. It’s actually easier for companies with a rich product offering to offer fewer license metrics and not more. This enables a wider portfolio of software to be more easily sold as a collective entity, rather than every product in a solution having a license metric to optimize for its use as a standalone tool.

As it turns out, both recommendations are complementary. When a software producer is small, it’s important to grow market share. By offering the product with more software license models, it’s easier to reach more customers at different price points. When the software producer is large and the solutions naturally reach a broader market, it’s easier to sell more software by making it simpler to buy more software. In these cases, fewer license model options that apply broadly across software titles are more effective.

This perspective reflects a natural lifecycle of software products in a market – over time your license models and product packaging will change to reflect market conditions. As you plan your product roadmap and associate licensing and entitlement management technology, be sure to realize that change will occur, and plan for it. And unlike Tweedledee and Tweedledum, you don’t have to wait for a big black crow to come down from the sky to make you realize these opposing perspectives on software license models aren’t at all at odds.

When it comes to software license models, are you Tweedledee and Tweedledum? Let us know!

In the meantime, check out my V-Smart Radio episode: Virtualizatioin: A Brave New World

 

SaaS / Software + Services – so much that is different, so much is the same

By: John Frame

This past summer, in my conversations with customers, analysts and prospects, a recurring theme was that for all the differences between SaaS and Software + Services models, the number of things that remain the same is remarkable.　Software as a Service, or SaaS, is the latest software delivery model.　 As such, SaaS can be a new way for you to have a relationship with your end-users.  It can address long upgrade cycle times and provide an advantageous cost model.

All indications show that SaaS is likely to follow the same adoption curve as any other new technology -- high growth in the initial phase, but slower growth over time, which makes sense. In fact, many of you are already thinking about and planning for this technology change and are putting in place efforts in two areas.  First, you’re making changes to your product plans, packaging and pricing to enable penetration into adjacent or alternative markets.  Second, you are making changes to ensure that you are fairly compensated for the value that your end-users are getting from the service.

Today access to your services is universally by means of a name and password, or authentication.  Most SaaS / Software + Service providers recognize the problems with authentication and are using session monitoring to try to detect over use or malicious use of the software.  Details on the user sessions are compiled. Reports are generated and based on suspected patterns of abuse; offenders are flagged and targeted for further conversations.  Session monitoring does give software vendors a level of understanding of who is using what. However, it tends to highlight the clear or extreme cases, and does not pick up on cases where the patterns may not be as clear, or if the misuse is more sophisticated. Please remember, unlike traditional software, vendors/manufacturers have a real cost associated with every user of the service regardless of whether the customer paid or not.  Understanding who is using the service and getting fairly compensated by them is a great way to expand profitably.

Licensing services offer some key benefits:　

· Licensing + Authentication provides software vendors and manufacturers granular reporting capabilities allowing them to identify the specific devices where credentials were used during a specific period of time. These reports are far more precise and accurate than what would be generated from simply session monitoring.　

· You can choose to reduce or alter the features available to the user if they are on an "unlicensed" device.　

· Finally, the technology can be used to lock out users from accessing the service if the credentials are being used on unlicensed or too many different devices

By including licensing in your service, all of these benefits are available to you.  You can control all of these different options from the back office and modify the approach based on different users, services, geographies and channels as needed.

I’m going to go out on a limb and say that it’s highly likely you are reading this blog post because you use or offer a service that combines Authentication and Licensing.　

Pop quiz for a $25 Gift Card!

I’ve got a $25 Starbucks card for the first person who can, as a comment to this blog post, name the service with the following characteristics that combine Authentication and Licensing:

· The service launched on April 28, 2003.　

· The service is accessed with a name and password, but that name and password only work on 5 Windows or MAC machines over a two year period.　

· The service does not let you use those credentials on a sixth machine in less than two years; you need to contact the provider of the service.　

What is this service called? (Please provide your answer in the comment box)