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.
The Networking Nerd 
You just said what I’ve been thinking for a couple years now.
Vendors could go one step further and download your actual configuration (with secrets removed) and use this information in depth analysis or even tailored bug notifications. When there’s a bug that affects hardware X, software version Y, with option Z enabled, that’s a pain to identify whether you’re affected. Now the vendor can do the analysis and let you know that you’re *actually* affected by this bug.
That’s a service I think a lot of customers would like and the vendor themself would get useful information from. Of course I’m ignoring all the secrecy and security aspects of this, but you could leave it as an option to turn on/off.
Tom:
This is one of my top annoyances. Licensing the s#!+ out of software, at outrageous margins, is complete nonsense. Especially in the networking space. Licensing for this protocol or that is too granular.
You said:
“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.”
This is the vendors problem, not yours. Let me clarify that. Cisco makes proprietary hardware that can’t be run without their proprietary software. Their proprietary software can not run on non-Cisco gear. It’s insulting to the customer to imply that either the hardware or software has any value apart from the other. Cisco has mind-boggling margins on their hardware. So long as this is true, while their products maintain their proprietary nature, then I’m afraid licensing of IOS features amounts to squeezing blood from a rock. IOS, including all of the various features, is not a product.
You might argue “It’s like pay as you go… I don’t need this feature, so I won’t pay for it.” You are paying for it anyway. I don’t buy into the “different pot of money” shell game that Cisco is playing here. Not with those margins on what is, again, a proprietary system.
Here’s something to ponder. For whatever evil people attribute to Microsoft, they encouraged a security ecosystem with their OS by creating a way for other vendors’ security products to work with their OS. You can choose another vendor’s firewall software, or VPN software.
If Cisco is losing money on security feature development, then maybe they should follow suit here. After years of housing some of the best talent in the network development world, and building network OSes and features, surely they can create standard interfaces to allow 3rd parties to develop these kinds of features. Surely. But they won’t.
This is a symptom of a larger problem in the networking industry. Everything is proprietary. Everything. Nobody wants to be the “IBM PC” of networking. They hover over their intellectual property hanging on for dear life to protect their margins. A lot of folks think whitebox gear will save the day, but in it’s current form we still have the same problem.
To this very day, for any Intel CPU, I can download a complete set of programming and reference guides for free from Intel’s website. Hell, they used to mail these books in print *for free* all over the world! If you want to know about Win32 or Win64 development, all the nitty gritty details are out there in the wild.
When will merchant silicon vendors make their SDKs freely available with solid supporting documentation, like Intel? When will companies that make software for network devices (or, in the case of SDN, software for *networks*) allow anyone in the wild to develop on their OS or framework, like Microsoft?*
When this happens, without expensive licensing fees or restrictions, then we will see real innovation that’s worth paying for.
Derick
Interesting. I never thought about it from the perspective of the company trying to recoup R&D costs. This makes sense in your example, but I was pretty outraged recently when I had to pay a licensing fee to unlock 10Gb ports on an ASA. That was pretty outrageous!