Share your views about how application vendors should license their apps

Posted by Brian Madden on October 17, 2007. send this link to your friendsprint this post
Rating:
Votes: 0 rating(s),  Score: 0/0
  Doc #Id: b802
10
comments
10K views

One of the topics that people have been talking about recently is licensing. Not Citrix or Terminal Server licensing, but application licensing. The problem is that most vendors do not understand the basic concepts of application streaming, VDI, virtualization, etc., and their applications are licensed in ways that don't make sense. Therefore I've decided to write a guide for application vendors that explains this technology and addresses common licensing problems, and gives them a framework for updating their license policies. What do you think I need to include in this guide?

The "classic" example here is that a lot of vendors (Microsoft included) license their applications based on workstation (or device), and not users. The problem is that in today's world, applications are often not physically installed on the workstations where they're used. (Terminal Server, etc.) Therefore the application vendors say, "Okay, then you need to buy one license for every device that could access our application. The problem is that the whole beauty of software streaming, a user who needs an application could walk up to any device in a company and receive that streamed application? Does that mean if you have an application for ten users but you have 1000 desktops, you should buy 1000 licenses for that application, even if your ten users will only ever access the application from their ten workstations? If you follow the license agreement exactly, then yes, that's exactly what this means.

This is just one example. But the more companies I visit, the more I realize that application licensing is a big problem. It's a problem that the business people and the legal people in the company ask the IT people about, and no one really seems to know what's going on. So here's what I'm thinking we should do.

I'm thinking that we should write a document aimed towards explaining all of these application delivery technologies to software vendors. This can explain "our side" of things and hopefully let them understand that we're using these various technologies to make our lives easier--not to screw them out of paying for applications. I think this guide will have several parts:

  • Introduction
  • Overview of the various technologies (SBC, VDI, OS Streaming, App Streaming, etc.)
  • Explanation of why we use the various technologies
  • The challenges of "traditional" app licensing and why they don't fit into this model
  • Our preferred (or virtualization-compatible) licensing methods
The last two points are where I'm interested in your ideas. Have you run into problems and challenges with application licensing in your environment? Please share your stories below. And if you have ideas or suggestions for the vendors, please also share them here.
Reader Comments
Licensing lunacy
Wednesday, October 17, 2007 3:08:30 AM
Hi Brian,

This is a little off topic, but I thought I'd share my recent experiences with SPLA licensing.

For those not familiar with SPLA (service provider's license agreement), this is Microsoft's licensing answer to SaaS or "pay as you go" monthly leasing for software. As a service provider, I can offer software with no upfront costs and fixed monthly subscription fees to my hosted clients (I use CAE 2.0 in VMs).

Well, believe it or not, I actually read through the entire SPUR and SPLA agreement and found a clause with respect to "service devices" that got me steamed. Translated, Microsoft allows a service provider to provide Windows XP and Vista upgrade licenses (SALs) for use on client workstations, BUT they do not allow this licensing to extend to virtual machines!

In other words, as a service provider under SPLA licensing, I can't use VDI solutions to provide clients with XP VMs in my data center! The only alternative is to have my clients provide their own CALs for XP for use in the data center if they want VDI. I wonder how long before Microsoft changes their tune on this one...I'm not holding my breath.
We've needed this for a long time...
Wednesday, October 17, 2007 3:14:02 AM

Guest
The per-accessing device model has been outdated for too many years now. One of the big advantages of deploying TS/Citrix for me is the enablement of my users being able to work from anywhere - now if I follow the licensing agreement to the letter I have to take away access to my apps from web-cafes' and the like. Also, the biggest challenge I'm facing as a reseller is justifying the application licensing costs when there are open-source projects that do the same job for free (a la Open Office).

I'd like to see more choice in the licensing models - perhaps something similar to the MS SQL model where you can license per user/device/processor, and I'm sure for SBC a concurrency-based model would work.
Licensing question...
Wednesday, October 17, 2007 4:57:02 AM
In fact, the problem only occurred for customer facing/used application : 3 models could be seen as good for customer (right sizing is probably not as good for ISV) : Per Named User and Per Concurrent User, Free. I will not talk about the latest one but for the 2 first, the balance will change from company to company... ISV are sometimes afraid with the Per Named User as they have often no control on user directory and this licensing model is more "trust based licensing" than a true licenses enforcement (think about TS Named User CAL). Pay As You Go seems go for me at first sight but I had to stop it as it didn’t feet with my budget planning. It could probably be good for some enterprise (not only SaaS). Question is more : what should be the price difference for NU, CCU and PaYG licenses… ISV could easily offer the 3. At which cost ? Please feel the equation : Base Licence = x(Base Licence)/NU=y(Base Licence)/CCU=z(Base Licence)/PaYG
Loosing our advantage
Wednesday, October 17, 2007 7:49:36 AM
Unlike in many offices where you may have a few users with access to many machines, in manufacturing you may have many users with access to a few machines. In that case are the software producers willing to continue to stand by there 1 license per 1 machine mentality? As we now benefit from many licenses agreements in this case, we need to be careful that if things are changed we don't cause harm in an area where we currently have an advantage.
A named user licensing in this instance would be out of the question. Often cost prohibitive.
A concurrent user model would definitely be a benefit to the many user few machine scenario, the limiting factor being how many machines are available.
Could software developers who are certified to run in Citrix be required to have a way of integrating their licensing within Citrix licensing?
Good premise
Wednesday, October 17, 2007 1:39:14 PM

Guest
The thing that I always find interesting when discussing licensing (especially with that big company in Redmond) is that depending on who you talk to -and- their level of knowledge of your particular contract arrangement with them, they give you a different story as to what you can and can't get away with in regards to licensing. I agree that concurrent licensing (or a pool concept with check-out/check-in) would be a boon to mid-size companies with limited resources and many casual users. It seems that the software virtualization packages support such models even though they are not specifically spelled out by licensing agreements. As for named user licensing, there's no advantage and huge amounts of management overhead. From my perspective (and looking at the overall usage of some of our more expensive apps), the check-out/check-in model combined with concurrent licensing would be perfect. See Autocad server-based licensing for an example.
What should a vendor get?
Wednesday, October 17, 2007 2:25:18 PM
It is reasonable for a vendor to expect more money from you, when you get more value from their product. But that is hard to quantify. All licensing schemes try to make an easy to understand rough hack at making this happen. And as you pointed out, these hacks were developed in a different era. So a new kind of rough hack may be needed, or at least tweaks.

"Per named user" is a resonable hack. Note that this is different than per device. Honestly, I do get more value out of the software if I can run it from more than one place, so paying a small premium (1.2X, not 2X) to run it from different places might be OK also. Maybe a "Per named user single device" pricing, with a "per named user, any device" pricing at a small premium.

"Per concurrent user" can be a resonable scheme also. There is some unfareness when larger companies use timezone shifing to reduce conncurrent license usage, however that may just be part of the discount for getting the big business from them.
Re: What should a vendor get?
Wednesday, October 17, 2007 8:16:46 PM