Beyond Software Architecture[c] Creating and Sustaining Winning Solutions

2017-07-07 02:10:07

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.

Contract Basics

A valid contract requires three things: an offer, acceptance, and consideration.

An offer is a statement by the offeror (a person or a corporation) that indicates a willingness to enter into an agreement on the terms stated.

Acceptance occurs when the entity to whom the offer was addressed (the offeree) indicates a willingness to accept the offeror's proposed agreement.

Consideration is anything of value exchanged by the parties. Technology licensing contracts usually specify monetary forms of consideration as payment terms, discussed in greater detail in the next section.

Pretty boring, yes? The real action is in the license terms, discussed next.

License Terms

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.

Definitions

A precise, legal description of all important items or terms referenced in the license agreement. Descriptions of technology often go something like this

Software means the object code software proprietary to { licensor } and listed on the pricing schedule.

or this:

Software means the object code software proprietary to {licensor} and listed in Attachment A of this license agreement.

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

Date	Why Important
Effective	Date the agreement is considered in effect.
Expiration	Date the agreement is ended. May be specified any number of ways, including an absolute or calculated (such as adding a fixed period of time to the effective date).
Payment	Dates when fees are due, usually listed along with payment terms (e.g., Net 30 or payments shall be made the fifteenth and the last day of each month).
Audit periods	Period during which the licensor can audit how the technology is being used.
Termination notice	Amount of time allowed to terminate the contract. It should be long enough to properly replace the terminated technology. (Many agreements do not specify a long enough period of time.)
Other	A wide variety of additional dates depending on license and contract requirements. The license might be required to report usage according to a well-defined schedule. OEM and partnership agreements may specify quarterly, biannual, or annual technology reviews. Timetables associated with new releases may be listed in the contract, along with penalties should these dates be missed.

The Costly Renewal

One product I worked on had licensed a cross-platform database access library. The license agreement clearly specified an end date. When that date arrived, the product development team had a simple choice: renew the agreement or reengineer the product to remove the library. We chose to reengineer the product, primarily because the vendor wanted to raise the price by several thousand dollars. We also felt that we could improve quality and build a higher-performance implementation using a mixture of freely available technology and a new database access layer. Unfortunately, we couldn't finish the reengineering effort by the specified renewal date, so we had to renew the license agreement at a substantial cost to the company.

A variant of this example is the "automatic renewal" associated with many contracts. With an automatic renewal, once the contract has been signed it automatically renews unless you explicitly cancel it. It is vitally important that you remain aware of these renewals. Circumstances change, and you may not want to re-up.

Territory

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.

Specific Use

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.

Exclusivity

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.

Sublicense

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.

Termination

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 .

Renewal

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.

Deployment Restrictions

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.

Noncompete

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.

Marketing Requirements

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.