The Devil Is In The Licensing

If you don’t already know that I’m a co-host of a great podcast we do at Gestalt IT, here’s a great way to jump in. This episode was a fun one to record and talk about licensing:

Sometimes I have to play the role of the genial host and I don’t get to express my true opinion on things. After all, a good podcast host is really just there to keep the peace and ensure the guests get to say their words, right?

Double Feature

I once said that every random feature in a certain network operating system somehow came from a million-dollar PO that needed to be closed. It reflects my personal opinion that sometimes the things we see in code don’t always reflect reality. But how do you decide what to build if you’re not listening to customers?

It’s a tough gamble to take. You can guess at what people are going to want to include and hope that you get it right. Other times you’re going to goof and put something your code that no one uses. It’s a delicate balance. One of the biggest traps that a company can fall into is waiting for their customers to tell them what they want to see in the next release. Steve Jobs is famous for having said the following:

Some people say, “Give the customers what they want.” But that’s not my approach. Our job is to figure out what they’re going to want before they do. I think Henry Ford once said, “If I’d asked customers what they wanted, they would have told me, ‘A faster horse!'” People don’t know what they want until you show it to them. That’s why I never rely on market research. Our task is to read things that are not yet on the page.

Granted, it’s a bit different when you’re building a cutting edge consumer device. And if you look at the track record of Apple it’s not spotless. But when you’re trying to figure out what features need to be built into an operating system you should probably know what your customers want.

But no choice about including code or features comes without a cost. Even if you have engineers on staff writing code day and night you’re going to incur a work cost. Development is measure in hours and hours equate to dollars1. If you have a team of hundreds working on a single feature you’re going to rack up some pretty significant costs. And including that feature in the base operating system only makes sense if you’re trying to capture market share or address a huge issue your customers have.

But how can you track adoption? Number of downloads of the OS or the program? Not a great measure if it’s something everyone needs to install. If you were trying to track the number of Apple Mail users based on the number of people running iOS on a device you’d be pretty far off the mark. Just because it’s installed doesn’t mean it’s used. So how can we track that feature and recoup some of the development costs at the same time? That’s right! Licensing!

The Double-Edged Sword

Licensing, in and of itself, it’s evil. You have to agree to a license every time you use software. Even if you’re using something with a license that says you can do whatever you want with it. The inherent evil part of the license is when it’s applied in an unfair way.

A friend once told me that a networking vendor had a great idea on how to recoup the costs of developing their software-defined strategy. Instead of charging more to turn the feature on for the whole switch they wanted to charge per flow that used the feature. The rest of the room was speechless. How in the world can you charge for a feature in a switch by the flow? Even with bundling of the licenses you’d incur a significant amount of costs just to operate whatever that was. Amazingly enough the person that suggested it had come from a consumer productivity software background, which per-use licensing was the norm.

The idea is sound. Charge people for what they use. But the application failed. Could you imagine someone charging you per phone call? It’s happened before. Remember when calling cards were a thing? You could pay a few cents a minute to talk. Today? The idea of mobile phones and unlimited voice plans makes the idea of per-use phones antiquated at best.

Another great example of licensing backfiring is when Cisco decided they wanted to start charging a license fee for each different phone type they sold. After all, it should cost more to connect a video phone than it should to connect a regular desk phone, right? After spending years fighting against Device License Units (DLUs) and watching them get tossed to side in favor of modified user licensing because of the rise of software over voice, I realized that this is a game that really never ends. I was the proud owner of an old unlimited data plan from back in the day when the iPhone first came out and my provider wanted to charge you more for the voice minutes instead of the data. Today the data usage is much more valuable to them. Trends change. Devices change. And that means you have to keep your licensing fair and even.

Would you license a firewall per hundred flows? Per VPN connection? Maybe per concurrent MAC address? These are all things that have been done before. I have installed firewalls that could be “upgraded” to more capable units by removing an artificial limit on the number of concurrent users. It was wrong to me but the company made money. It was an easy “fix” to get a few hundred dollars more plus some recurring support revenue. But did it accurately reflect the way that the users operated the device? Not really. It was more about getting extra funding for some other feature or for keeping your business unit in business.

The dark side of licensing comes from greed. Ensuring proper feature adoption or tracking development costs is fine and dandy. But when you charge more just because you can it becomes wrong. Worse yet, when you charge a fortune to keep all but a select few from using your feature set it’s even worse. You can’t expect to feel good about yourself charging a million dollars to license a feature that you really expect only a couple of customers to use. But that’s happened before too. And we’re not even going to get into the argument from the podcast about licensing being tied to the myth of “shareholder value”. I’d need another 2,500 words for that one.


Tom’s Take

Licensing is a necessary evil. We have to have rules and guidelines to use things properly. We also have to have a way to tie development to use. Most modern software is going to charge you for some feature, whether it’s a model of paying once for every major update or a freemium model that lets you pay a regular fee for regular updates. I can’t predict that market any more than I can predict the end of unlimited data plans and DLUs. But I can say that if licensing stops being about keeping software use sane and keeps running down the path of keeping shareholders deliriously rich, you’re going to find out that licensing was the real villain all along.


  1. Or the currency of your region ↩︎

The Pain of Licensing

Embed from Getty Images

Frequent readers of my blog and Twitter stream may have noticed that I have a special loathing in my heart for licensing.  I’ve been subjected to some of the craziest runarounds because of licensing departments.  I’ve had to yell over the phone to get something taken care of.  I’ve had to produce paperwork so old it was yellowed at the edges.  Why does this have to be so hard?

Licensing is a feature tracking mechanism.  Manufacturers want to know what features you are using.  It comes back to tracking research and development.  A lot of time and effort goes into making the parts and pieces of a product.  Many different departments put work into something before it goes out the door.  Vendors need a way to track how popular a given feature might be to customers.  This allows them to know where to allocate budgets for the development of said features.

Some things are considered essential.  These core pieces are usually allocated to a team that gets the right funding no matter what.  Or the features are so mature that there really isn’t much that can be done to drive additional revenue from them.  When’s the last time someone made a more streamlined version of OSPF?  But there are pieces that can be attached to OSPF that carry more weight.

Rights and Privileges

Here’s an example from Cisco.  In IOS 15, OSPF is considered a part of the core IOS functionality.  You get it no matter what on a router.  You have to pay an extra license on a switch, but that’s not part of this argument.  OSPF is a mature protocol, even in version 3 which enables IPv6 support.  If you have OSPF for IPv4, you have it for IPv6 as well.  One of the best practices for securing OSPF against intrusion is to authenticate your area 0 links.  This is something that should be considered core functionality.  And with IPv4, it is.  The MD5 authentication mechanism is built into the core OS.  But with IPv6, the IPSec license needed to authenticate the links has to be purchased as a separate license upgrade.  That’s because IPSec is part of the security license bundle.

Why the runaround for what is considered a best practice, core function?  It’s because IPv6 uses a different mechanism.  One that has more reach that simple MD5 authentication.  In order to capture the revenue that the IPSec security team is putting in, Cisco won’t just give away that functionality.  Instead, it needs to be tracked by a license.  The R&D work from that team needs to be recovered somehow.  And so you pay extra for something Cisco says you should be doing anyway.  That’s the licensing that upsets me so.

License Unit Report

How do we fix it?  The money problem is always going to be there.  Vendors have to find a way to recapture revenue for R&D while at the same time not making customers pay for things they don’t need, like advanced security or application licenses.  That’s the necessary evil of having affordable software.  But there is a fix for the feature tracking part.

We have the analytics capability with modern software to send anonymized usage statistics to manufacturers and vendors about what feature sets are being used.  Companies can track how popular IPSec is versus MD5 or other such feature comparisons.  The software doesn’t have to say who you are, just what you are using.  That would allow the budgets to be allocated exactly like they should be used, not guessing based on who bought the whole advanced communications license for Quality of Service (QoS) reporting.


 

Tom’s Take

Licensing is like NAT.  It’s a necessary evil of the world we live in.  People won’t pay for functionality they don’t use.  At the same time, they won’t use functions they have to pay extra for if they think it should have been included.  It’s a circular problem that has no clear answer.  And that’s the necessary evil of it all.

But just because it’s necessary doesn’t mean we can’t make it less evil.  We can split the reporting pieces out thanks to modern technology.  We can make sure the costs to develop these features gets driven down in the future because there are accurate statistics about usage.  Every little bit helps make licensing less of a hassle that it currently is.  It may not go away totally, but it can be marginalized to the point where it isn’t painful.