The software license is a key document in defining the relationship between the licensor and the licensee, setting forth the parameters of their rights to the software, and allocating risk to one party or the other. Licensors want to protect their rights in the product developed with their time, energy, funds, and effort, while licensees want to know exactly what is being licensed and that the product will meet their needs. Both parties want to define their respective rights carefully and thoroughly, in order to promote mutual understanding and to minimize ambiguities.
Licensing of software may arise in several contexts. The most basic software license involves single-user general-purpose personal or business software purchased from a retailer or distributor, or directly from the developer. More complex software licenses, requiring negotiation between licensor and licensee, arise when software is to be modified or specially developed, used for the benefit of a business other than that of the licensee, or resold, or when it will incorporate or modify pre-existing code or content. In each case, the license must adequately allocate the rights in the software and obligations under the agreement to all the relevant parties. In addition to user agreements, software licensing encompasses sales agreements between the original software developer and an intermediate sales representative or distributor.
Types of Software
‘Off-the-shelf software‘ generally refers to commercially-available software marketed directly by the licensor or through intermediate retailers or distributors to individual personal or business users, although many larger, sophisticated software products are treated by their licensors as off-the-shelf. This type of software is not intended by the licensor to be modified or customized by the licensor, the licensee, or a third party. Although the license may allow users to create interfaces, enable or disable features, or generate personalized reports, it will not allow for modification of the code or creation of derivative works. In fact, generally such software is provided without access to the underlying program code. The license, sometimes in the form of a shrink-wrap or Web-wrap license, is, therefore, a standard form. The publisher is likely to restrict the authorized uses and number of users of the software, make limited representations and warranties, and have little or no obligation to maintain the specific version of the software or to keep the software in production for any specified time. However, as the off-the-shelf software moves along the continuum from simple in scope and price to greater complexity, cost and potential significance to the parties in terms of risk and utility, the likelihood that the end licensee will want to negotiate the terms of the agreement, and the likelihood that the licensor will be willing to negotiate, increases.
‘Customized software‘ is commercially-available software that the licensor has either modified for the licensee or allowed the licensee to modify; the authorization for such customization is subject to negotiation. When the licensor is to modify the software, the licensor should be sure that the licensee's expectations of the modified software are reflected in an agreed-upon set of specifications, that it can deliver the modifications on a timely basis, and that it will be paid promptly. Among the most important issues to be negotiated in such an agreement are the copyright ownership of the modifications and the protection of both parties' trade secrets, which may necessarily be revealed during the process of creating such modifications.
‘Custom software‘ is software that has been specially ordered or commissioned, either by an end user or by a reseller or distributor. For instance, a business might commission a developer to write an Accounts Payable system (or an entire accounting system including modules for Accounts Payable, Accounts Receivable, Royalty Accounting, Financial Accounting and other functions) for the business' own internal use. Similarly, a book publisher might commission a developer to write software for the publisher to distribute with or in connection with its books. In either situation, the developer might have a preexisting code for certain standard functions, such as date calculations or searching, that the developer would reuse rather than reinvent. Such code would be licensed, unless the developer is willing to relinquish all rights in the code and all possibilities of freely using the code in future projects. In the accounting system example, the developer may wish to reuse large sections of code written for an earlier project, or might anticipate reusing sections of the code written for the present project in future projects; unless the commissioning party's accounting system has unique attributes and gives it a competitive advantage in its industry, it will likely not object to such licensing. With software products destined for public distribution rather than internal use for generic functions, however, the situation is more complicated. First, the parties must decide whether the developer is responsible for the software content or only for the software engine. Then they must decide whether the work product should be merely licensed to, or owned outright by, the commissioning party. The greater the originality or novelty of the content and/or the engine provided by the developer, the more likely the commissioning party is to want the agreement to be a work for hire or subject to copyright or patent assignment, rather than a mere license. An agreement for such a product should also contain strong confidentiality and nondisclosure provisions.
Open Source Software
Open source software is software that is made available in source code form, so that it can be read, modified and redistributed by users. The open source approach is the conceptual and practical opposite of the idea of software as a closed, proprietary product, distributed in the form of object code only. Open source software is distributed under specialized licenses that may place obligations on subsequent distributors of the code. Even where there is little or no originality or novelty, a commissioning party might be unwilling to be a mere licensee of the software for two reasons. First, the end product might embody the commissioning party's intellectual property, which it would not want the developer to be able to license. Second, the commissioning party may object to paying the development costs on a time and materials basis without having full ownership of the end product. Development agreements for custom software should address the rights and responsibilities of the parties in connection with the licensing and sublicensing of any component parts of the software content and code. The agreement should also contain or reference detailed specifications, development and delivery milestones (including progress reports and an approval process), and a payment schedule tying payments to the satisfaction of certain key development and delivery milestones. Moreover, the agreement should address post-installation acceptance testing and the subsequent availability of the developer to support the software. Where the commissioning party is a reseller or distributor, as in the publisher example above, additional representations, warranties, and indemnifications might be advisable.
Legal Terms of Software License
A basic tenet of Canadian and United States copyright law is that ownership of a physical copy of a work does not grant any ownership rights in any intellectual property embodied in the copy. For instance, a purchaser of a book or videotape is an owner of a physical copy, but only a licensee of intellectual property. Under Canadian and U.S. copyright law, copyright owners have the exclusive right to distribute copies of the work to the public, subject to the limitation of the “first sale doctrine”. The first sale doctrine allows owners of physical, lawfully-made copies of a work to sell, rent or otherwise dispose of their copies without the authorization of the copyright owner, effectively limiting the copyright owner's exclusive distribution right to the first authorized sale or distribution of the work.
Because the first sale doctrine permitted the rental of a copy of software without the authorization of the copyright owner and because software rental was identified as a key factor in software piracy, the United States in 1990 exempted software rental from the first sale doctrine. The first sale doctrine would, however, still apply to the sale of software, limiting the copyright owner's exclusive distribution right to the first authorized sale. To avoid this result, software agreements usually are a license, not a sale, of both the physical copy and the intellectual property, thereby enabling the copyright owner to restrict the licensee' s ability to transfer the copy of the software to a third party.
A right to sublicense allows the licensee to grant certain rights to third parties. With off-the-shelf software, the licensee generally has no right to sublicense. A licensee of customized or custom software more commonly requires a broader right, so that it may sublicense to its agents or contractors the right to use the licensed software, and thus perform the tasks for which the licensee intended to use the software. Also, for example, without a right to sublicense, a developer may not be able to utilize third-party development tools which imbed run-time modules in new products being created for sale to third parties.
Scope of License
Probably the most important provision of every software license is the one defining the usage rights the licensee acquires from the licensor. Because the license represents the transfer to the licensee of only some of the licensor's rights in the intellectual property “bundle of rights”, the license should delineate precisely which rights are being transferred and to what extent. Generally speaking, if a license is limited in scope and the licensee acts outside the scope, the licensor can bring an action for copyright infringement. The scope of use provision establishes which and how many persons may use the software, the types and numbers of machines on which the software may be run, and at what location(s) the software may be used. When the scope of the license is in dispute, the copyright owner bears the burden of proving that a subsequent software license was unauthorized. The scope may also limit the type of business applications for which the software can be used. The more accurately the licensee anticipates the scope of use it will ultimately make of the software, the less likely it will be that the license will require later amendments and increased fees.
A software license must identify precisely who is authorized to use the software. Off-the-shelf software is typically limited to a single licensee at one time on a single computer, and may be sufficient for an individual or for a small business planning to utilize the software on a single computer. Larger businesses who wish to run off-the-shelf software on a multitude of computers, or on a network server with multiple users accessing the program, may be able to negotiate a company-wide license, known as a site license. A site license may allow the licensee to make multiple copies of the software for installation on multiple computers. More commonly, however, it allows for installation of the software on a local-area network (LAN) or wide-area network (WAN). Depending on the license fee paid, the site license may allow an unlimited number of users to access the software or may limit simultaneous access to a specified number of users. In the latter case, known as a concurrent site license, the license may require the licensee to purchase as many copies of the software as there will be authorized users, although only one copy is installed on the network, or it may allow the licensee to buy only a single copy for installation. A site license may also provide the licensee with licensor support services, timely upgrades, and input into the licensor's product development.
Permitted and Prohibited Uses
A crucial element of a software license is the delineation of the purposes for which the licensee can utilize the software. A licensee may be limited to using the software for its own internal use or only in its primary business activity. Such restrictions aim to prevent the licensee from using the product as a service provider for third parties, such as in a service bureau arrangement. The context of these restrictions is to prevent an expanded use of the software in such a way as to deprive the licensor of license fees from those users for which the licensee may provide service using the software. Licenses may grant only the right to execute the licensed software, or also to copy, modify, maintain, or create derivatives of the software, or to authorize third parties to do so. The rights granted will depend on the particular use to be made of the software. It is also important to note that a software licensee may be liable for actual damages for all unauthorized copies of licensed software, regardless of whether these copies were accessible to or used by the licensee or its customers.
License fee provisions should be detailed and comprehensive. The fees may be based on the number of computers or users for which the software is licensed, and may account for the various locations at which the software will be used. The fee for a multiple-location site license may be a single fee or a sliding scale fee, in which the licensee might pay a full fee for use at the first site, and then a fraction of the full fee for use at additional sites. In connection with complex customized or custom software development, individual fees may be applied to individual modules of the software package. The fee schedule should include all costs that the licensee may incur, including costs of training and installation of the various modules of the software. Payments usually are payable over a period of time and are tied to specific milestones, such as contract execution, delivery, completion of acceptance testing, training of users, and live implementation of the system. The licensee should not be required to pay in full until any custom modifications are installed and tested for conformity to an agreed upon standard.
Off-the-shelf software is granted almost exclusively on a perpetual basis, subject only to termination upon licensee' s breach of the license. Offsetting the benefits of the perpetual term, however, is the fact that off-the-shelf software licenses generally do not obligate the licensor to continue to maintain and support the software, although such a requirement might be negotiable in the context of a large-scale implementation of off-the-shelf software. Some off-the-shelf software, such as shareware or software distributed for evaluation purposes, however, is subject to a temporary license. Moreover, licensees must diligently protect their rights concerning renewal and monitor the deadlines for options so that they are timely exercised. In the event of a lesser breach that still renders the licensor the ability to receive the benefits of the bargain, the licensor is left with option to continue to receive royalty payments while still seeking injunctive relief against the unauthorized.
Representations and Warranties
The licensor's representations and warranties are among the most significant provisions of the software license, development agreement, or sales representative or distributor agreement. They set forth the licensor' s promises and obligations about the software, and therefore form a large part of the bargain from the licensee' s perspective. These representations and warranties generally concern ownership and performance issues.
Ownership of Intellectual Property
Often a licensee will represent and warrant that he has, or if he is a distributor or sales agent, that his principal has, all right, title and interest to the licensed software; that he has not previously assigned, transferred, encumbered or conveyed such right, title or interest; that the intellectual property rights in the software are valid and subsisting; and that the licensed software, and licensee's use thereof as contemplated by the license agreement, does not infringe any intellectual property, proprietary, personal or other rights owned or possessed by any third party.
Licensors may be asked to warrant that the licensed software conforms to the applicable specifications or documentation for the software and that the software performs its functions according to certain specified performance standards. The licensor may also be asked to warrant that the software will be free of defects which substantially effect system performance. Examples of performance warranties follow.
Response Time Warranties
Response time warranties address the acceptable timing for an on-line system to accept a transaction from, and communicate a response to, a licensee. Unacceptably slow response times seriously impede normal business operations and can lead to users viewing the software implementation as a failure. Slow response times may be caused by poor software design or failure of compatibility with the licensee's usage requirements and hardware. They may also result from the licensee' s failure to provide adequate hardware capacity, or to limit the number of applications, including the licensor' s, that run on the hardware.
Capacity or Throughput Warranties
Throughput warranties specify the number of transactions a system is expected to process within a specific time period. Because acquired systems are usually in place for a number of years, the required number of transactions usually forecast the anticipated number of transactions to be processed within the periods of heaviest volume over the subsequent years. Underestimating the volume of transactions can make the system obsolete, even absent a breach of contract by the licensor.
Reliability standards are usually expressed as a percentage of time during which the system will be operational. If the system is to be used primarily during business hours, it may be useful to specify separate percentages for business hours and non-business hours. Reliability warranties usually require the licensee to give written notification to the licensor of defects in the software and to reproduce any alleged defect in order to verify that the defect is a genuine program fault, before requiring the licensor to cure the claimed defect. The licensee's ability to make a reliability warranty claim under the agreement is limited by the functionality specified in the descriptions, proposals, and specifications for the software referenced or included in the agreement. Because descriptions and performance specifications included in the agreement usually qualify as express warranties, the licensee receives greater contract protection if sales literature describing the system, the licensor's proposal, and technical specifications relating to the subject matter of the contract are incorporated by reference, as long as such incorporation by reference does not create contract inconsistencies.
Disclaiming Warranties and Limitations on Liability
Licensors generally disclaim all warranties for any portion of the software modified by the licensee, and all warranties other than those expressly stated, including implied warranties of merchantability and fitness for a particular purpose. In order to comply with the requirement of the Uniform Commercial Code that such a disclaimer be ‘conspicuous,” any such disclaimer should be set in capital letters within the text of the agreement. Moreover, such disclaimers of warranty are usually construed against the licensor, and are not always enforced. A license might also exclude any warranties not found in the license agreement. Such a disclaimer protects the licensor from warranty liability that can arise from implied warranties and express warranties made by overzealous salespeople.