As software increases in scale, the economic and logistic incentives to create resuable components escalate. Advocates have proclaimed software reuse the panacea to the woes of planning and implementing immense software development projects. Others have predicted that software reuse will revolutionize both the development process and the market for software. The demise of high profile, large scale software projects such as the Federal Aviation Administration’s air traffic control software and the Denver airport baggage handling system have fueled the need for a new, more flexible, model for building software.

While the concept of reusable software components has existed for some time, the practice has only recently gained momentum. Recent innovations in supporting technologies, including JavaBeans, CORBA, and DCOM, have contributed to this software resuse renaisaance. Before joining the software reuse rage, however, developers should inform themselves of the legal peculiarities that characterize software component licensing.

Software components jar well-established software licensing paradigms. In particular, assumptions regarding the size, quality, and flexibility of software components differ from those underlying typical licensing scenarios. Those changed assumptions have important effects on the license grant, payment, ownership, liability, warranty and maintenance, and confidentiality terms of software component licenses. Understanding the quirks of software component licensing will enable developers to make informed judgments about the risks and costs they are willing to assume with software components, rather than blindly embracing the latest trend in software development.

A license enables an entity which owns property rights in something (the licensor) to grant to a third party (the licensee) the right to use those property rights. In the case of software components, the licensor owns intellectual property rights in the software component, usually because the licensor developed the software component. Any third party who uses the software component without a license from the owner infringes the intellectual property rights of that owner.

A simple analogy to real property best illustrates the purpose of intellectual property licenses. John owns a thousand acres of forest in Montana. Mark, the owner of a successful timber business, wants to log some of John’s land. If Mark enters John’s land without John’s permission, Mark violates John’s property rights. As owner of the land, John has the exclusive right to prevent others from entering the land and exploiting its resources. John and Mark must enter into a license agreement to enable Mark to enter and clear John’s land. That license agreement will probably include the following general terms: (a) Mark has the right to enter John’s land solely to clear some number of acres of trees (the license grant), (b) Marks owns the trees he clears but John reserves all other rights to the land (ownership), (c) Mark must pay John for the trees he clears (payment), Mark will pay John for any damage that occurs to the land while Mark is logging it (indemnification), and (d) Mark’s liability is limited to damage that directly results from Mark’s use of the land (limitation of liability).

Similarly, a software component licensor owns copyright, trade secret, or patent rights in the software component. Copyright protection pertains to original works fixed in a tangible medium of expression, and gives the copyright owner the exclusive rights to reproduce, prepare derivative works of, distribute, publicly perform, and publicly display the copyrighted work. Trade secret protects any formula, pattern, device, or compilation of information which the owner endeavors to keep secret, and which gives the owner an advantage over competitors. Finally, patents protect novel, non-obvious, and useful inventions, and give patent owners the exclusive rights to make, use, and sell their inventions.

Most software component developers own trade secret or copyright rights, rather than patent rights, in their software. The high price of obtaining a patent prevents most software component developers from obtaining patent protection. In addition, though extremely useful, most software components fail to satisfy the novelty and non-obviousness requirements for patentability. Indeed, the most commercially viable software components are probably those generic components that software developers need and use again and again, rather than those that are particularly novel or non-obvious and hence, patentable.

Consequently, copyright or trade secret property rights pertain to most software components. Owners of software components thus possess the exclusive rights to reproduce, create derivative works of, publicly perform or display, and distribute their code. As in the real property example, any third party who reproduces, modifies, publicly displays or performs, or distributes copyrighted software components without a license transgresses the owner’s intellectual property rights in that software. A license between the software component owner and the licensee should minimally specify (a) the rights the licensor authorizes the licensee to exercise in the software (license grant), (b) payments to the licensor, (c) who owns the licensed component and modifications to the licensed component, (d) the risks and liability each of the parties assumes under the license, (e) support, maintenance, and warranties for the licensed component, and (f) the confidentiality of the licensed component.

The assumptions that underlie software component licensing transactions differ significantly from those that ground typical software licenses. In particular, assumptions regarding purpose, size, quality, and flexibility distinguish software component licenses from traditional software licenses. These assumptions, in turn, profoundly affect the structure and content of software component licenses.

First and most obvious, the purpose of software components differs from the purpose of standard licensed software. Most licensed software consists of stand-alone applications. Software developers generally license their software to distributors, who in turn sell the software to end users, or to companies who use the software to enhance their WWW sites, or to end users directly via shrink-wrap or click-wrap licenses. On the other hand, software components are not intended to, and in most cases do not, function independently as stand-alone applications.

Second, assumptions regarding size distinguish software component licenses. Licensed software components generally consist of many lines of code, and thus constitute a significant part of the finished software product. That follows because short software components are usually not worth licensing, either because (a) it is easier to implement them from scratch that to incur the transactional costs of negotiating a license to them or (b) the developer makes them available as freeware or shareware because they are not large or important enough to generate license revenue for the owner.

Third, strong presumptions regarding quality motivate software component licenses. That presumption arises because licensees reasonably assume that software component licensors have taken advantage of previous software component transactions to debug and test the licensed component thoroughly. Software component licensees consequently covet the reputedly high quality of software components. The quality of software components provides software developers, especially those facing critical time deadlines, to seek the quality of established, tested, and reliable software solutions, rather than attempting to implement them anew.

Finally, software component licensees presume the flexibility and adaptability of software components. Most software licensees purchase software consisting of stand-alone applications, as described above. Software components, however, must possess the flexibility and adaptability to seamlessly mold into myriad contexts and applications. To achieve that flexibility and adaptability, software component licensors must either make extremely detailed and complete application programming interfaces (APIs), or source code, available to licensees.

The shift in assumptions that characterizes software component transactions also shapes the licensing terms that govern those transactions. Assumptions regarding the interoperability, large size, high quality, and adaptability of software components drive the corresponding license terms. As a result, licensees and licensors should regard boilerplate or standard license agreements with great skepticism, and should scrupulously consider the following terms before licensing software components.

A. The License Grant

Assumptions regarding the purpose and flexibility of software components color the license grant. The license grant, the most critical provision in a license agreement, stipulates the rights the licensor grants to the licensee in the intellectual property. Most software licenses grant the licensee the rights to use the software object code, and limited rights to reproduce the software to make one backup or archival copy. Such limited license grants minimally intrude on the property interests of the licensor.

On the other hand, software component licensees require broad license grants to enable them to integrate the software component into their own code, and perhaps even to modify the software component. Rather than simply granting rights to use and make archival copies of software object code, software component licensors face the disturbing prospect of enabling licensees to integrate software components into unknown third party software, and possibly even allowing those licensees to view and modify the source code of that component. Granting licensees rights to integrate software components into other software, and view and modify the source code for the software component, signifies a relinquishment of control over software that software component licensors find (or should find) frightening, if not prohibitive.

Consequently, the license grant must carefully balance the interests of the licensor against those of the licensee. The licensee clearly will not license software components if the license does not enable the licensee to integrate the component into third party software, and modify it if necessary. The licensor will not license software if doing so requires him to surrender to the licensee unrestricted rights to use, integrate, and modify the software component.

The license grant should thus enable the licensee to integrate and modify the software component, but not without restrictions. Rather than granting the licensee the right to integrate the component into any software, for example, the license grant should limit the products the licensee may integrate the component into, perhaps by naming or describing those products. Rather than allowing the licensee to modify the component at will, the license grant should limit the licensee’s rights to modify to narrow segments of the code, or require the licensee to obtain the prior written permission of the licensor before modifying the component.

B. Payment

Assumptions relating to the purpose, size, and quality of software components transform traditional software license payment terms. Typical software licenses stipulate an upfront license fee payment. That upfront fee "fully pays up" the licensee’s obligations, entitling him to exercise fully his rights under the license agreement.

Upfront license fees, however, do not adequately reward the contribution of software component licensors to third party software. Licensees integrate software components into third party software. Those software components may constitute a very significant and critical part of that third party software. Unless extremely generous, an upfront license fee fails to induce licensors to license out software components. On the other hand, huge upfront license fees force licensees to assume enormous risk if the software project in which the software component is integrated fails commercially.

Royalty structures often found in hardware licensing transactions, however, coupled with small upfront license fees, spread the risk of failure and present both licensors and licensees with compelling financial incentives to enter into software component licenses. Rather than paying licensors upfront license fees, royalties enable licensees to defer payment until they actually begin to sell products which integrate the software component. At that point, the licensee pays the licensor a small percentage of revenues from each product (incorporating the software component) that the licensee sells. A commercially successful product enables the licensee to defer license fees during the cash-strapped development phase, and the licensor to enjoy a steady cash stream when the licensee sells products. Royalties also distribute the risk of commercial failure between the parties to the license agreement; the licensee pays minimal upfront fees, and the small upfront fee allows the licensor to recoup some, if not all, of the transactional cost of entering into the license agreement.

Assumptions regarding the function and flexibility of software components alter traditional ownership provisions in software licenses. Standard software licenses pertain to stand-alone software applications. The licensor grants the licensee certain rights to use and perhaps reproduce the software, but retains all other right, title, and interest in and to the licensed software.

On the other hand, ownership provisions in component software licenses must not only address the ownership of the licensed software, but must also contemplate ownership of the third party software that incorporates the licensed software component, as well as ownership of modifications to the licensed component. Ownership of the licensed software component is straightforward; as in standard license agreements, the licensor should retain all right, title, and interest in the component. The licensor needs to retain ownership of the software component to enable him to license the same software component to multiple licensees: the objective of software reuse. Ownership of the third party software which integrates the software component is equally simple; the licensee should own such third party software, and be able to use and dispose of it in all ways consistent with the license grant in the integrated software component. The licensee needs to retain ownership of the third party software that integrates the software component because otherwise, the licensee loses all rights to commercialize and sell that third party software and with that, the incentive to license the software component in the first place.

Nevertheless, structuring a sensible ownership section becomes more difficult if the license grant allows the licensee to modify the software component (i.e., grants the licensee the rights to use and modify the source code of the software component). On the one hand, the licensor should own modifications to the software component because the licensee will not be able to use those modifications once the license grant terminates and the licensee no longer has the right to use the underlying software component. On the other hand, the licensee may modify the software component in highly specialized ways that offer little value to the licensor, and that the licensor has little interest in owning.

Ownership provisions regarding modifications of software component should strive to maximize the combined interests of the licensor and licensee. If the licensee plans to make changes to the software component that could prove very valuable to the licensor, the licensor should retain ownership of those modifications. Alternatively, the licensor may secure his ownership in modifications to the software component by not granting the licensee the right to modify the licensed component but rather, modifying the software component according to licensee’s specifications and licensing the modified software component to licensee. If the licensee plans to make changes to the software component of no foreseeable value to the licensor, though, the licensor should consider allowing the licensee to own those modifications.

Standard indemnification and limitation of liability clauses in software licenses require surprisingly few adjustments to accommodate the software component context. Most software license agreements have both indemnification and limitation of liability provisions. Indemnification provisions normally state that the licensor will defend the licensee if a third party sues the licensee, alleging that the licensee’s use of the licensed software infringes or violates the intellectual property rights of the third party. Limitation of liability provisions limit the liability of each of the parties under the license agreement.

As with other license provisions, the licensor and licensee need to sculpt indemnification and limitation of liability terms that spread the risk of liability between the parties. For example, the licensor should indemnify the licensee for intellectual property infringement by the licensed component, but only to the extent those infringement claims arise from the licensee’s authorized use of the licensed component. Consequently, the licensee should bear the cost of defending infringement claims to the extent those claims arise from the combination of the licensed component with licensee’s own software, or from modifications to the licensed component by the licensee, or from licensee’s misuse of the licensed component.

Standard limitation of liability clauses also apply, with little modification, to the software component context. Under the limitation of liability clause, both of the parties disclaim liability for unforeseeable damages or indirect damages: consequential, incidental, special, indirect, and punitive damages. In addition, however, limitation of liability clauses sometimes place a ceiling (often the aggregate payments the licensor receives from the licensee during the twelve month period preceding the event giving rise to licensor’s liability) on any liability of the licensor that arises under the agreement. Ceilings on the liability of licensor are especially appropriate in the software component context, particularly when licensees integrate the licensed component into high risk software applications (life support systems, for example, or other medical applications) that pose immense liability to the licensor.

All characteristics of software components, including their integration into third party software, as well as their size, quality, and flexibility, compel strong support and warranty obligations in software component license agreements. Standard software license agreements have extremely limited, short-term warranties and few support obligations. Warranty and support provisions, however, are inexorably linked to licensees’ motivation for licensing, rather than developing from the ground up, the software components.

To preserve licensees’ incentive for entering into software component license agreements, then, licensors should offer warranties and support and maintenance to licensees. A developer licenses a software component for inclusion in his software projects because he believes in the high quality and adaptability of the component, and also because licensing the software component is cheaper and more efficient than developing that software component from scratch. As a result, the licensee looks for contractual guarantees regarding the quality and adaptability of software components. The absence of those guarantees weakens licensee’s confidence in the quality and adaptability of software component, and undermines the software component movement by suggesting that software component developers refuse to stand behind their products.

Licensors should thus consider offering software component licensees a strong but short-term warranty, and making technical support available at standard commercial rates to licensees after the warranty expires. Accordingly, a licensor might warrant that the software component will perform according to detailed specifications for the component for a period of one year. During that year, the licensee will presumably integrate the component into his own software, giving the licensor the opportunity to resolve defects or bugs in the software component that rear their ugly head as a result of the combination of the software component with third party software. If the licensee diligently integrates the software component into third party software during the warranty period, any bugs that arise after the warranty period are probably relatively subtle and minor. After the warranty period ends, then, it makes sense for the licensor to continue to eliminate minor bugs from the software component only if the licensee pays support and maintenance fees, which are typically 12% to 15% (per year) of the upfront license fees.

A meaningful but short-term warranty, coupled with extended support obligations in exchange for maintenance and support fees, balances the interests of the licensor and licensee. The warranty motivates the licensee to integrate the software component quickly, and assures the licensee of the quality of the licensed component. At the same time, the warranty period enables the licensor to test and refine the software component. The subsequent maintenance and support period convinces the licensee that he will not have to understand every line and nuance of the software component, which would defeat the purpose of licensing the software component. The maintenance and support period similarly benefits the licensor by allowing him to eliminate subtle bugs and defects that he otherwise would not have the incentive to remove: improving the product for the next licensee of the software component.

Finally, a few minor adjustments to confidentiality provisions in standard license agreements suffice to tailor those provisions to the software component context. In standard license agreements, the confidentiality section states that the parties will protect and not disclose, for a period of time, information that the parties exchange during the agreement that is identified as confidential or proprietary. The interests of the licensor and the licensee conflict regarding confidentiality provisions.

Software component licensors desire strong confidentiality provisions; licensees, weak confidentiality provisions. Software component licensors need to protect their trade secret intellectual property rights in the software component with rigorous confidentiality obligations. Licensees want no restraints on their ability to disclose and disseminate the software component.

Nevertheless, the risk to the licensor of losing trade secret intellectual property rights in the software component probably outweighs the burden on the licensee of taking reasonable precautions to protect the confidentiality of the licensed component. Thus, confidentiality provisions that require the licensee to limit access to the software component and to ensure that employees or agents of the licensee agree in writing to protect the confidentiality of the software component are not unreasonable. The licensor may also consider requiring the licensee to encrypt the component prior to storing or distributing that component.

To fully realize the impressive potential of software components to reform software development, tight license agreements that reflect the intentions of the parties must accompany software component transactions. Indeed, agreements that fail to affirm the flexibility, quality, and interoperability of software components erode the credibility of the software reuse movement. License agreements that certify the quality of the component and the licensor’s ongoing commitment to maintain that component cultivate the reputation of excellence, flexibility, and interoperability that make software components so appealing to licensees. Likewise, license agreements that safeguard the licensor’s ownership of the component, maintain its confidentiality, and offer appropriate financial incentives, lure licensors into software component licenses. Software developers who carefully fashion license agreements that reflect the intent of the parties not only protect their interests, but also affirm the integrity of the software reuse revolution.