Licensing RisksRewards

Licensing Risks/Rewards

The introduction outlined some of the motivations for licensing technology. While these motivations are quite real, so too are the associated risks. The following list captures both the motivations and the risks that must be considered in every licensing situation.

Motivation/Reward. You can reduce, manage, or otherwise eliminate complexity and risk by licensing technology from a third party. The technology or provider is an expert in a given area that you deem important to success. By licensing their technology you gain the provider's expertise.

Risk. You may be able to shift complexity from your team to the technology provider, but in doing so you increase risk by increasing your reliance on third-party technology. If the technology evolves in a way that fails to match your needs, you could be in serious trouble.

A supplier might change focus, leaving you without an equivalent replacement. You may not even be able to find a plug-compatible supplier. This almost happened to one of my teams when a search engine vendor whose technology we had licensed decided to reposition themselves as a portal vendor. They initially stopped development of their core technology (text indexing and searching). Fortunately, several customers, including us, managed to convince the vendor to maintain its investment in the core technology. Everything worked out, but the situation was very tense for several weeks as we explored several undesirable replacement scenarios.

Finally, make certain that you assess the viability of the technology provider. Given today's volatile corporate market, there is always the risk that a technology provider may go out of business.

Motivation/Reward. In-licensing technology promotes component-based software systems, which can be easily changed (such as replacing one component with another).

Risk. In-licensed technologies can become too intertwined with a solution to make changes to support a different implementation.

For example, suppose you in-license a reporting component. Chances are good that you could only replace it with a different implementation if that implementation supported the same level of functionality. If you expose or rely on any vendor-specific functionality you've probably locked yourself to this vendor. If this was a conscious choice, great. If not, you might be stuck.

Motivation/Reward. In-licensing technology makes your system easier to construct because you can focus on creating your unique technology.

Risk. In-licensed components increase configuration complexity. Incompatible business models may make the use of certain kinds of technologies practically impossible . I'll elaborate on this later in this chapter.

Another potential risk deals with the restrictions that may come with various components. (Consider high-end cryptographic libraries, which are often subject to various forms of export restrictions.) Licensing these technologies means that you're subjecting your software to these restrictions. Keep in mind that this is one of the goals of many open source licenses, most notably GNU GPL.

Motivation/Reward. You can obtain protection by licensing technology protected by a patent.

Risk. Indemnity, legal exemption from the penalties or liabilities incurred for using the component, is hard to secure. Suppose you license a component from company A because it has a patent on a key technology. This license is not likely to protect you from being sued by company B, who may claim that you're infringing on its rights.

Motivation/Reward. You can reduce time-to-market by reusing technology.

Risk. Licensing technology does not always result in faster time to market. At the very least you have to invest time in learning the technology, integrating it into your solution, and verifying that it works correctly for your total solution.

Sometimes it really is faster to build your own technology, from scratch, to meet your needs (consider your choices for creating or licensing a license manager, discussed in Chapter 4).

Motivation/Reward. Vendor-created components are higher quality than those you write on your own.

Risk. Many times this just isn't truein-licensed technology is often lower in quality than what you create from scratch.

Motivation/Reward. Vendor created components are lighter, and consume fewer resources, such as memory or processor cycles (presumably because they have been optimized).

Risk. In-licensed technology may be surprising heavy, consuming more resources or running more slowly than code you write on your own. Moreover, it is nearly impossible to substantially tune the performance of most in-licensed technologies: You're left with the "switches" the vendor gives you and not much else. You can't recompile someone else's library to turn on multithreading or modify the code to perform I/O operations more efficiently .

Motivation/Reward. Licensing a component relieves some of the burden associated with technology currency because the vendor will be continually improving this component.

Risk. Vendors don't always update components as fast as needed. Sometimes they drop support for other components that you must still support, such as an OS.

Motivation/Reward. The component is state of the art, and using it will future-proof your application.

Risk. This sounds like resum driven design, in which developers seek to use a technology because it is cool. If you can't easily justify the use of a given technology based on your real needs, drop it.

Motivation/Reward. Licensing technology is cheaper than building it from scratch.

Risk. The claim that it is cheaper to license a technology is usually based on building an equivalent replacement. You may not need an equivalent replacement, which substantially lowers development costs. License fee structures can ruin the economics associated with a good product.

Motivation/Reward. Licensing components will reduce service and support costs because the bugs associated with these components have been handled.

Risk. Providing support for in-licensed technologies is one of the biggest challenges faced in creating a winning solution. While a mature component may have fewer bugs, in-licensing introduces new possibilities for errors.

Suppose you in-license three technologies: A database management system, a search engine, and a report writing tool. When your customer calls you for support, you're going to have to determine the source of the problem and how it should be fixed.

There are several potential sources of problems. It could be a previously undiscovered bug in your code or in any of the in-licensed components. It could be a bug in how you've integrated the component or in how the components interoperate .

When the situation is tense it can become quite easy for each vendor to blame the other. Your customer doesn't care about this infighting; they just want you to fix the problem. Make certain that you can properly support a component before choosing to in-license it.

Fixing Their Code

In one project we decided to license an essential technology from a new start-up. Unfortunately, its libraries had some real problems: The APIs were poorly documented, the technology didn't scale to our needs, the code was written in C++ and riddled with memory leaks, and the technology lacked functions that would greatly enhance our ability to use it.

We could have dropped the technology, but it was felt by all involved, especially product management, that we simply had to have it. Since the underlying algorithms were protected by some very strong patents, we couldn't simply create our own solution. In fact, even if the underlying technology was not protected we probably would not have created our own version, as the technology was based on extremely sophisticated mathematical algorithms, and it would have taken several months for my team to build the knowledge necessary to create this basic technology. Moreover, we had been given direct access to their source code, and developing a duplicate or replacement version would have put us on very precarious legal grounds (if you're going to try this, you need a wide variety of techniques, including clean-room reverse engineering, to protect yourself as much as possible).

The best choice was to work with the vendor to help them modify their technology to meet our needs. I instructed my team to carefully prepare a document that outlined all of the problems with the technology, including the memory leaks. We also documented what we wanted to see in the APIs, prioritized the additional features we wanted, and provided the vendor with sample code that we had written to test their technology. As you can guess, the vendor was stunned by our apparent generosity. They had never expected that we would work so hard to help them be successful. Of course, we were working for our own benefit because we needed this technology. The vendor adopted our suggestions, and I've maintained a strong, positive relationship with them ever since.