The heart of any technology licensing is the contract that defines the terms and conditions associated with its use. This section outlines some of the basic elements associated with technology contracts and some of the terms and conditions commonly found in them.
A valid contract requires three things: an offer, acceptance, and consideration.
Pretty boring, yes? The real action is in the license terms, discussed next.
Before you can understand how license agreements and if the terms can affect your tarchitecture , you have to have an idea of what kinds of terms exist. This section discusses terms commonly found in technology in-license agreements.
A precise, legal description of all important items or terms referenced in the license agreement. Descriptions of technology often go something like this
Pay attention to what is listed, because the definitions will often include specific version numbers , supported operating systems, and so forth. If you need something that isn't defined, you may be unable to obtain support and/or upgrades, or you'll have to create another contract to pay your supplier to provide you with the needed or required technology.
Usage or Grant
The manner in which the in-license technology can be used. This section may be one of the longest in the agreement, as it often contains many of the other terms discussed here.
Duration or Term and Other Key Dates
When the agreement begins and ends. By working together, and by negotiating precise agreements about specific dates, the marketect and tarchitect can create a better overall result for their company. To illustrate , suppose that you agree to license a key technology under an annual license fee. You estimate that it will take you four months to integrate the technology, another month to QA the integration, and another two months to roll it out. From your perspective, the best deal will allow development with the new technology to commence once the contract is signed but will delay payment of the initial annual license fee until the technology is actually delivered to customers, the reason being that until the technology is used by a customer it is only a cost to the licensor. From the perspective of the technology provider, payments should begin when the contract is signed because they are not responsible for how long it takes you to integrate the technology and you're getting the benefits of it from the moment it is delivered. Who's right depends on your role in the negotiating process.
Most in-license agreements specify a variety of other important dates beyond the beginning and end of the agreement. If you don't understand these dates you can be headed for a lot of expensive trouble. At a minimum, keep track of the dates listed in Table 5-1.
Table 5-1. Dates to Keep Track Of
The applicable territory where the in-licensed technology can be used. It is especially important to be careful of geographic restrictions because they can be very hard to honor in our Web-connected world.
Development, quality assurance, technical support, or commercial use of technology as specified by the in-license agreement. It is important to understand what the agreement covers. Note that general terms are sometimes captured in one agreement while specific terms are captured in other, related agreements.
The degree to which the licensee agrees not to license the technology to anyone else. In general, exclusivity is hard to obtain, although there are ways to get it. For example, suppose that you want to license a key technology but only intend to use it in Europe. It might be possible to obtain exclusivity for the European market. It can also be obtained for higher fees. In most circumstances you don't really need exclusivity, so it isn't something you should worry much about.
The degree to which you (the licensee) can license the technology to a third party. Sublicense rights are usually required for embedded technologies. Suppose, for example, that you license in a core technology for use in an information appliance. Chances are very good that you're going to license your solution to your customers, which requires a sublicense right from the technology's vendor. As I will discuss later, sublicense rights often have a substantial impact on your tarchitecture.
The ways in which one party may terminate the contract. All of the contracts I've seen contain at least one termination clause, and most of them contain several. These clauses allow either party to withdraw from the agreement if there is a breach in performance. Performance breaches are usually specifically stated, such as failure to deliver by a specific date or failure of a system to meet defined processing requirements. Enumerating and describing potential breaches and remedies is one of the more time-consuming aspects of contract negotiation. Withdrawing from a contract because of breach is harder than it seems, because there is usually a process for recovery from the breach (the remedy).
Many technology licensing contracts allow either party to withdraw from the agreement provided that they give the other party sufficient advance warning, ranging from as little as 30 days to as much as one year. Always try to negotiate the longest period of time possible. Replacing an in-licensed technology with another one or with technology developed inhouse always takes longer than planned.
The contract can be terminated if either party goes bankrupt or fails to meet defined financial criteria, if one party elects to drop support for the technology, or if there is a substantial change in control (such as when a competitor acquires a technology provider). Although termination sections can get quite lengthy, it pays to read them carefully .
Technology license agreements often contain one or more renewal clauses. These clauses may be automatic, which can actually cause a company to pay too much in fees depending on the evolution of the tarchitecture. Automatic renewal clauses can also create a false sense of security (an automatic renewal does not mean an automic upgrade). In general, I recommend against them as this forces you to evaluate each license agreement to make certain it is still meeting your needs.
Fees or Payment Terms
The foundation of a valid contract is some form of consideration. As discussed in Chapter 4, there are any number of creative licensing and business models, all of which end up in this section of the contract. What is vitally important is that your tarchitecture support the payment terms required. If you are in-licensing a technology based on a transactional business model, your tarchitecture needs to support their business model. A key point of contention is when the business model required in the license is different from the one you use with your customers. Such differences can often be resolved only through careful negotiations, as discussed in the next section.
Some license agreements restrict one or more deployment options associated with the technology. For example, the vendor may require one agreement to use the technology for a customer deployment and a different agreement if the licensed technology is to be used as an ASP. Deployment options are discussed in greater detail in Chapter 7.
Other or General Restrictions
In addition to the terms that define what you can do, license agreements also carefully define what you cannot do. As with the other terms, any of these restrictions can have an impact on your tarchitecture. One example is the very common restriction against any form of reverse engineering or modification of the licensed technology.
The practical effect of this kind of restriction can be fairly surprising. Suppose, for example, that a developer finds a bug in a licensed component. A restriction against reverse engineering may prevent analyzing the technology to identify the bug. Let's say that this restriction doesn't exist, and that you instruct the developer to research the bug. Even if he finds a fix, you may still be out of luck as a restriction against modifications means that you can't apply it. You may only be allowed to supply the fix to the vendor and wait for them to issue a patch or a new release. Since the best thing you can do is influence their development plans, you might be waiting a long time.
Vendors may require that the solution you create not compete with their technology. In other words, you have to create a new offering. This may sound silly, but it prevents people from doing things like licensing a J2EE Web server under the pretense of integrating the technology into a new product without really creating a new product. The net result would be a new solution that competes with the original vendor's solution.
Access to Source Code
Technology agreements often specify that a copy of the source code be placed in escrow and given to the licensee should the licensor breach. In theory, this is great because it makes certain that you can get full and complete access to the technology you need. In practice, however, it is often worthless. Suppose that the vendor does breach and you're given access to the source code. What then? Chances are good that you won't have the necessary skills or staff to manage it.
The agreement may obligate you to issue a press release or allow the licensee or the licensor (or both) the right to use the name or corporate logo of the other on their Web site. Any number of other marketing-related requirements associated with the technology may be laid out, so read these sections carefully. Marketing and branding requirements can mean nasty surprises for your tarchitecture.