Thank you for sharing!

Your article was successfully shared with the contacts you provided.
As companies explore new media and technologies, they are structuring business arrangements never before encountered. Documenting these deals does not fall exclusively to those who bill themselves “Internet” or “new media” legal specialists. New technologies deeply pervade the modern business mainstream. Even those who resist most strongly the winds of change can be asked at any time to craft documents that reflect technologies, and business operations based on those technologies, that were unheard of five minutes ago. When the time comes to document the deal, it may turn out there is no “form contract” that can simply be grabbed and slotted into place, much less a time-tested, “traditional” form. When you cannot find that form contract for a new deal, what do you do? How do you design a high-tech contract from scratch? Fortunately, there are techniques that can be very effective for designing new documents for previously unseen deals. Applying these techniques to a newly designed document will maximize the odds that it will cover the deal properly and comprehensively. This article will discuss one of the most useful techniques for designing new contracts from scratch. MIRROR THE BUSINESS DEAL This technique consists of shaping the form of a contract so that it reflects the form of the business arrangement it is supposed to cover. In order to understand how the form of words on pages can possibly “mirror” the form of a business deal, the following three examples are provided. Example 1: Project Development in a Sequence of Steps. Suppose that two parties plan to work together and develop a new software application, and they need a contract to reflect this working arrangement. Among other things, they plan on the following sequence of activities: one party will prepare a design for the work to be performed; the other party will review that design and either accept, reject, or modify the design; the parties will then mutually agree on a final version of the design before proceeding further. If they agree on a final version of the design, one party will then perform the preliminary work to create the software application under the design, and the other party will do some further work on the application, based on the first party’s work — and so it proceeds, with the parties largely taking turns working on the project. How to arrange and present these parties’ respective activities in a contract document? There are a number of different ways this might be done, all of which are perhaps equally “obvious” in an a priori sense. One way would be first to list all of the actions to be performed by one party, and then to list all of the actions to be performed by the other party. This certainly would make clear the total effort, and the kinds of efforts, expected from each party. Another way would be to arrange the parties’ activities in the contract by conceptual category. For instance, all “development activities” could be grouped together in the contract, regardless of when they occur, or which party performs them. The same could be done for such other activities as “review” activities, “mutual agreement” activities, “materials and resources procurement” activities, etc. This approach will primarily show what kinds of activities are to be performed under the contract. However, both of these approaches could also lead to major problems. Perhaps most important, the ways that each party’s efforts depend on those of the other party would be obscured, and perhaps distorted. Taking the steps in project development out of sequence, in order to group them along different lines for conceptual contract purposes, can lead to the illusion that the steps are far more independent from each other than they really are. In addition, it would be far more difficult for anyone reading the contract to derive an accurate “overview” of the development process. Now, consider a third approach. Instead of grouping the parties’ activities in the contract according to “who is supposed to perform them” or “what kinds of activities are conceptually similar,” try designing the contract to “mirror” the parties’ planned activities. In this scenario, it is easy to mirror the sequence of activities to be performed by the parties. The first step to be performed (preparing a plan for the software effort) is described first in the contract, the second step (reviewing the plan), is described in the next contract provision, and so on. Working in this way, a narrative “story” of the project will be woven into the contractual provisions. It enables anyone who reads the contract, whether or not that person was involved in the original negotiations, to recognize at once the shape of the development project (for which a narrative story is an appropriate form), and how the parties’ efforts depend on each other. This does not mean that other objectives, such as assessing each party’s total set of obligations, are neglected. Each party can see within the narrative not only what his own obligations are (presuming these are clearly enough labeled within the contract provisions and descriptions), but also how those obligations fit into the overall picture of the development project. Example 2: Development of a Complex System via Parallel Development Projects. For a second example of how the “mirroring” technique is applied, consider a scenario where one party agrees to develop and deliver an automated system to the other party in exchange for money. The system is not to be developed and delivered all at once, but in a series of deliveries of different system components. In addition, the customer desires the system to be finished so quickly, that the development projects for the various parts of the system must be worked on in parallel, rather than sequentially. In this case, fashioning the contract to mirror the development project will require that the contract provisions not be arranged in sequential project steps, as was done in the last example. This is because a sequential list of development steps would seriously misrepresent the actual project. Using a sequentially ordered contract as the “blueprint” for a parallel development business arrangement could confuse the parties into wrongly believing that sub-project #2, arranged within the contract to follow sub-project #1, depends upon sub-project #1 (when in fact it does not, and they are supposed to be developed in parallel). Or the parties could become confused as to the order of delivery; it may happen that sub-project #1 will be begun before sub-project #2, yet it will be completed and delivered after sub-project #2. Such confusion could even be utilized by one of the parties to try to “break” the contract, where that party has a change of heart after contract execution, but does not wish to buy itself out of the deal in an honorable fashion (such as might happen in a change of management, or budget reduction). For instance, a customer trying to get out of the contract could claim that a sequentially ordered task list in the contract necessarily implies that all later steps require the prior completion of earlier steps, and that since later-listed tasks are being performed in parallel with earlier-listed tasks, those later-listed tasks are just so much wasted effort, and will need to be entirely redone anyway. The whole project is thus a directionless, increasingly expensive mess, and must be aborted immediately. The developer could try to remind the customer that both parties understood from the beginning that parallel development would occur, and in fact was even adopted in order to meet the customer’s own needs. But when the contract lays out a development blueprint that better supports the customer’s claim than the developer in this case, it’s at best a coin toss whether the developer can salvage the original understanding of the deal. The question is how to avoid these problems when arranging contract provisions, since it is necessary to list the various development and delivery sub-projects in some form, and since it is necessary to present them in some sort of linear sequence in the contract document. One effective approach is to add a conspicuous contract provision, entitled something like “Parallel Development Efforts,” immediately before the provisions that describe the items to be developed and delivered. This provision can state everything necessary regarding the parties’ expectations as to parallel development: the fact that parallel development will be necessary in order to meet the customer’s accelerated delivery time frames; how various development efforts may overlap; inter-project dependencies that may limit how separately the various development projects can proceed; how schedules are to be adjusted if one part or other of the projects experience delays. This provision could also reference an attached project chart that graphically depicts the projected timing and overlapping of projects. A listing of development projects can then follow in the body of the contract in some rational sequence, for example in sequence of expected start dates, or expected delivery dates. If the nature of this sequencing is expressly described at the outset of such a listing, it will once again work to reduce possible confusions later on. By conspicuously centering attention on a properly drafted “parallel development” provision, the form of this contract properly mirrors the development project — not a clean series of progressive steps, but a more complex multiple development effort designed with the expectation of creating the desired system faster than a sequence of steps could achieve. Example 3: License of a Software “Development Tool.” For the third example, look at a situation where a company owns a software “development tool” that can be used by its customers to develop products, such as advanced audiovisual presentations or on-line storefront systems. Some companies are founded on the premise of licensing such development tool systems to others. They usually deploy uniform, standard license agreements with all of their customers, agreements which may have been prepared at significant expense at the start of the licensing company’s life. However, an increasing number of companies that primarily provide services to others will create a development tool for their own use — such as to create a product for one of their clients, or to create a mass commodity product — and then realize that they can license the development tool itself to others, even sometimes their own competitors. As these companies begin to license their own standard products, they find that their own form contracts, designed for provision of services to others, do not work as licenses of standard products. They could then turn to form licenses used by other companies, but their own ways of doing business may differ too much from those of other companies for such forms to be very useful. When a company seeks to license its development tool to its first customers, can it design the license agreement to “mirror” the deal in some fashion? The “sequential” and “parallel” contract design concepts, discussed above, are useless here. We are now dealing with a license of an already-completed development tool to a customer which, in turn, will use that tool to develop other products which it will either use internally, or market to others. A static or crystalline “license” is the central theme of this particular deal between tool owner and tool user, not process-oriented “development services.” One approach for mirroring this sort of license arrangement is to “start at the center, and work outwards.” In the case of a development tool license, the centerpiece is not the tool itself, but the customer’s purpose in licensing the development tool. The customer does not simply wish to possess this tool, but to use it to develop the customer’s own products; without this desire, the deal would not happen. It follows that a contract meant to mirror the deal should begin with a provision describing, generally, how the customer will use the licensed development system to develop customer products, perhaps with a title like “Customer’s Use of Development System.” This provision can address matters such as the sorts of products that the customer wishes to develop; the environments in which those products will be used; and the manner in which the customer plans to utilize the licensor’s development tool. These items may be standard for all customers (and thus might be “standard provisions” for the licensor), or they may vary greatly from customer to customer, depending on the nature of the development tool. Note that the customer’s intended uses of the development tool can be discussed before the development tool itself is even described. The development tool can be treated as a “black box,” at least at this initial juncture in the contract. Note further that we are talking here about a provision in the body of the contract document, and not just “whereas”-style preamble material. This initial description of the customer’s purposes makes clear why the license was sought by the customer in the first place. This provision also lets us use the license to make sure the customer solidly understands the deal. If the customer finds it difficult to prepare or recognize the description of customer purposes, this could reflect a lack of clarity on the customer’s part on why it is getting into the deal. This may seem odd when the customer stands ready to commit significant money to the license, but such lack of clarity is not uncommon. It can arise where the development license is requested by a technology development manager in the customer company, but negotiated by a business operations manager who really does not understand what is at stake; or where influential managers at the customer company have strong disagreements about the customer’s business direction. Working outwards from the center, now a provision would be added that describes the development tool being licensed to the customer. This description could include such matters as the general functionality of the development tool, its components, and how the development tool is generally used to develop products. It is a general description, not a detailed system specification (which is typically attached to the back of the contract). This provision clearly identifies the product being licensed, beyond use of mere product names or model numbers, which can be misleading at times. It also should enable anyone reading the license to see that the development tool being licensed squares with the customer’s purposes in obtaining the development tool, as described in the preceding paragraph. Next, still working outwards from the center, would come a provision describing the license rights being granted to the customer. From the previous provisions, one knows what the customer plans to develop, and the nature of the development tool he wishes to use. Simply from reviewing these, the customer’s needed license rights can now be spelled out with certainty and confidence that nothing important has likely been missed. This license rights provision would not necessarily contain every single term that defines the scope of the license; if the licensor has a highly detailed set of standard license terms, many of these can be moved further back to a “general license terms” area of the contract. The licensor’s general terms are important, and must be honored by the customer, but there is no need to mention them up front in the contract, except to the extent they directly interact with or modify the specific license rights most needed by the customer. Working further outwards, we come to such matters as payment, and the operational relationships between licensor and customer. If there is any preferred order to such provisions, it should arise from the details of the deal. For instance, if setup or use of the development tool requires extensive support from the licensor, or if the licensor wants approval over customer products developed using the licensor’s development tool, then it would make sense to describe these operational matters immediately after the license rights section. On the other hand, if there is no expectation that the parties will interact much after the license is executed, then it would make sense to proceed directly to the payment section. In development tool licenses, there are often several sorts of payments, such as initial license fees, internal use fees, product release fees, and even fees based on a percentage of the customer’s revenues from products that were created using the development tool. If the payment section follows the other sections described above, then the manner in which the various payment mechanisms and triggers fit into the overall license should be clear by the time one gets to this section. After this point, the contract might start moving into the various levels of “boilerplate:” property rights, confidentiality, termination, etc. Contrast this center-outwards approach with the form of development tool standard licenses often used by companies premised on licensing development tools, as mentioned above. Their standard licenses often start with a description of the licensor’s payment schedule, followed by provisions that comprehensively spell out the myriad ways in which the licensor claims ownership of its development tool, a long list of customer responsibilities both major and trivial, and finally a barebones description of the standard rights licensed by the licensor, coupled with a much lengthier section describing the limits on the licensed rights. They usually leave out altogether both a description of the licensee’s purposes (why should the licensor care about the customer’s purpose?), and any useful description of the development tool itself (the customer’s tech guys will figure out what the product is). Any license rights specially needed by the customer, if not included in the standard license rights list, must be spelled out in an attached document separately from the other rights, while “standard granted” rights in which the customer has no interest (and which are arbitrary in their relation to the deal) remain in the body of the licensor’s form contract as if they are an important part of the deal. The form of such licenses does not mirror the real business arrangement, and operate better as traps, than as blueprints or descriptions of the business deal. When the customer is finishing up products developed using the licensor’s development tool, it may find that to meet its true license needs, it will have to negotiate for additional license rights at additional cost, just as it is getting ready to go to market with the new products. The “trap” can go against the licensor, too. This author has personally seen more than one situation where a customer who signed a licensor’s convoluted “standard license” terms was able to develop products that were not well described in the licensor’s standard terms but not forbidden either, and for which the customer was able to qualify under the license to pay minimal license fees, despite the fact that the customer’s activities were analogous to activities for which the licensor normally demanded a large fee under its standard terms. CONCLUSION The examples above show how the principle of mirroring the business arrangement can be applied in various concrete scenarios. But that is only part of the point. More important, by comparing these examples, it becomes clear that no one way of arranging contract provisions applies to all situations. In every case, we need to look at the real business arrangement at hand, determine its form, and then mirror that form in the document. The form of the deal in the real world is always the guide. Contract techniques should be utilized to mirror that real-world form; take care to avoid alternative formal structures that conflict with the real-world form of the deal. Lance Rose, of the Law Office of Lance Rose, is the author of “NetLaw” (McGraw Hill), president of Contract Design Consultants, a contract design service for attorneys, and chairman of the New York New Media Association’s Law Special Interest Group.

This content has been archived. It is available exclusively through our partner LexisNexis®.

To view this content, please continue to Lexis Advance®.

Not a Lexis Advance® Subscriber? Subscribe Now

Why am I seeing this?

LexisNexis® is now the exclusive third party online distributor of the broad collection of current and archived versions of ALM's legal news publications. LexisNexis® customers will be able to access and use ALM's content by subscribing to the LexisNexis® services via Lexis Advance®. This includes content from the National Law Journal®, The American Lawyer®, Law Technology News®, The New York Law Journal® and Corporate Counsel®, as well as ALM's other newspapers, directories, legal treatises, published and unpublished court opinions, and other sources of legal information.

ALM's content plays a significant role in your work and research, and now through this alliance LexisNexis® will bring you access to an even more comprehensive collection of legal content.

For questions call 1-877-256-2472 or contact us at [email protected]


ALM Legal Publication Newsletters

Sign Up Today and Never Miss Another Story.

As part of your digital membership, you can sign up for an unlimited number of a wide range of complimentary newsletters. Visit your My Account page to make your selections. Get the timely legal news and critical analysis you cannot afford to miss. Tailored just for you. In your inbox. Every day.

Copyright © 2020 ALM Media Properties, LLC. All Rights Reserved.