A software license is a legal document that allows licensee to use or redistribute a software. It typically grants Licensee an end-user permission to exploit one or more copies of the software. The relationship between the licensor and the licensee is often compared to a landlord-tenant relationship. The landlord owns the house & the land while the tenant gets the right to enjoy it following the terms of the rental agreement. In the absence of a Software License, using the software without the permission of the owner constitutes a breach of Copyright or Infringement of Patent.
The licensor is the party that owns the Intellectual Property being licensed and grants limited right to use them to the Licensee.
The licensee could be any the following:
- a user of the software;
- a distributor of the software;
- a publisher of the software;
- a website owner of host;
- a party who modifies, translates or adds codes to the software;
- a party who makes copies of the software for its owner or distributor;
- an original equipment manufacturer;
- a value-added reseller;
- a joint venture partner;
- an independent maintenance company;
- a facilities management company;
- a technology escrow agent;
- an independent training company; or
- an independent sales representative or agent.
A proprietary software program is generally protected by a patent, copyright or trade secret law. The license agreement enables the licensee to exploit the software as specified in the provisions of the license agreement without infringing the licensor’s copyright or patent rights, and/or misappropriating the licensor’s trade secrets. The license agreement will specify provisions as to the use, reproduction, and other important provisions including payments and warranties. Sometimes maintenance and training are also addressed in the license agreement. Whatever transfer of rights it may grant, the license agreement has to be specific as to the rights conveyed and as well as the restrictions imposed to the licensee.
In the absence of a license agreement, the owner runs a big risk of opening doors to piracy or having the technology stolen from him.
IV.A. End User Software License
An End User Software License (EULA) is contract between the user and the licensor/owner where the user agrees to pay for the privileges of using the software. By entering into the agreement, the user is given permission to use and benefit from the software subject to the restrictions stated in the EULA. EULA generally limits the customer’s rights in various ways such as below.
Standard End User Restrictions[1]
Copies of the Software created or transferred pursuant to this Agreement are licensed, not sold, and Customer receives no title to or ownership of any copy of the Software itself. Furthermore, Customer receives no rights to the Software other than those specially granted in this Section . Without limiting the generality of the foregoing, Customer shall not: (a) modify, create derivative works from, distribute, publicly display, publicly perform, or sublicense the Software; (b) use the Software for service bureau or time-sharing purposes or in any other way allow third parties to exploit the Software; or (c) reverse engineer, decompile, disassemble, or otherwise attempt to derive any of the Software’s source code.”
Every EULA should confirm that the customer only receives the rights specifically granted under the agreement and that the licensor retains ownership of the software. If the user is entitled to reproduce the software, the license should specify the specific number of copies. Licensor should also consider stating that individual copies of the software are “licensed,” not “sold.” In other words, the software isn’t like a book you bought, which you can give away or sell.
Every EULA should also list certain rights not granted. The Copyright law grants several exclusive rights to copyright owners. Licensor should make sure the license doesn’t grant any of those rights except those expressly provided.[2] The license should be explicit that the end-user cannot exercise the rights of the copyright holder. It cannot distribute, modify (create derivative works), or publicly display, perform the software or sublicense its rights to anyone else.[3]
Licensor should also stipulate that the user gets no time-sharing or service bureau rights, or any other rights to share the software with third parties. Time-sharing means sharing an application with customers or third-parties. Service Bureau usage involves another type of sharing: the customer keeps the software, but it uses it to process third party data, instead of its own data, including in a cloud service offering. Either could cost the vendor sales.[4]
In an enterprise license, the user may be allowed to make copies as it needs. Licensor should only grant “enterprise license” if it knows the size of the customer’s business and doesn’t mind if it expands, along with the number of copies it may reproduce. Licensor may also consider limiting software use by forbidding subsidiaries, parent companies, and other affiliates from copying or using the software. Some software sits on a on a single server computer and users access and use it from their own client computers, without making any copies. If the license for one of these “client-server” allows 50 “concurrent users,” the customer may allow 50 users at one time. The software could be physically available to hundreds of users and client computers, but it’s restricted to 50 at a time. Such stipulation should be explicit in the license agreement.
IV.B. Distributor License Agreement
In a Standard Distributor Software License Agreement the vendor grants a distributor the right to transfer copyrighted software to third parties. Distribution rights are often restricted to a geographic territory (e.g. state, region, country, and continent). The distributor has no right to distribute outside the area. The territory might also be defined by industry. For instance: “Vendor herby grants Distributor the exclusive right to distribute the Software for use in the Semiconductor Fabrication (as defined in Section __).”[5] If you use an industrial territory, be sure to define the industry or segment clearly. The right to distribute may be exclusive or non-exclusive. If it is exclusive, no one, even the vendor itself has the right to distribute within the territory, or anywhere if the license is worldwide. Some distribution licenses include limited rights to reproduce and use the software. These rights help with marketing and technical support. Technically speaking, the clause should grant those rights. But sometimes it’s fair to assume a distributor has reasonable marketing and support rights, even if they’re not spelled out.
Value-added reseller (VAR) licenses grant limited distribution rights. The distributor can only give the software out as a component of some larger tool – often something the distributor itself produces. Imagine the vendor makes databases and the distributor makes factory-management applications, which use database. A VAR license lets distributor distribute the vendor’s database with the distributor’s application, giving end user customer a complete package. But the distributor cannot distribute the database as a stand-alone product.[6]
Original equipment manufacturer (OEM) licenses grant the same basic rights as VAR licenses. In an OEM license the distributor’s product is always equipment or a hardware. In VAR licenses, it may invoice hardware or software.[7]
Some distribution licenses let the distributor sublicense its rights to its sub-distributors. In such instances, the contract’s payment clause requires royalties or other payments, whether it’s a distributor or sub-distributor that makes the sale. Some clauses also let the distributor sublicense certain rights to customers such giving the distributor the authority to grant its customers the right to reproduce and use the software.
“Provided Distributor complies with the restrictions set forth in Section(Software Restrictions), Vendor hereby grants Distributor a non-exclusive, worldwide license to exploit the Software as follows, solely as an embedded component of Distributor’s Product: (a) to distribute the Software; (b) to reproduce and use the Software for sales and marketing purpose and to the extent necessary to provide technical support to customers of Distributor’s Product; and (c) to sublicense to its customer the right to reproduce and use the Software. Distributor may sublicense to its sub-distributors the rights granted in Subsections ___ (a) through __(c) above.”
Most vendors and distributors assume that sublicensing rights are implied in the right to distribute.
FORM 1 - Software Distribution License Agreement
FORM 2 - VAR/Distribution as Embedded Component; Provider (Vendor) Friendly
IV.C. Developer – Publisher License Agreement.
A developer-publisher licensee agreement is an important type of software license agreement for all categories of software: mainframe, minicomputer, and microcomputer. The license grant may transfer the developer’s copyright interest to the publisher; or the publisher may acquire an exclusive license to distribute the software during the term of the license. Often such agreements cover several programs and it is not unusual for such agreements to cover several machine types or versions of each program, for example a Mac and an IBM version of each program developed.[8]
Sophisticated developers require minimum royalty payments in these agreements plus an advance royalty payment that is returned at a rate of less than 100% of all royalties earned so that the developer receives some incremental revenue from initial copies distributed. They will also limit the geographical scope of the license grant and reserve the right to market some machine types, media types, or foreign language directly or through other publishers. Milestones will be set for the development of each version of each program and insist that royalty advances are divided into payments that are tied to the milestones. Negotiations also occur over advance payments that are not recoverable as advance royalties. [9]
In these agreements’ publishers must be careful to obtain the rights they need to distribute the programs as planned, to obtain warranties on all programs, to address maintenance responsibilities, to address enhancement development, and others. Developers must be careful to retain rights to their libraries or ‘took kits’ of software.
Development projects are seldom completed on schedule, that they often generate dispute and that litigation often arises in relation to failure to deliver on time or failure to match specification. Developer-publisher arrangements are complex transactions that call for a careful thought, attention and negotiations by both parties. It is highly desirable to build dispute resolution mechanism into the software development agreement rather than ignore the potential for problems in developer-publisher relationships. Acquiring outside help in negotiating and drafting the agreement is often prudent and well worth the cost.[10]
FORM 1 - Software Development and Publishing Agreement
IV.D. Shrink – Wrap License
The term “shrink wrap agreement” refers to purchase agreements attached to a shipped product, usually bound by shrink wrap (plastic wrapping) that contains terms and conditions. Generally marketed products using shrink wrap license are products that rarely generate sufficient revenue to support a nationwide field sales force, such products are business applications, educational and entertainment programs. Attempts to have a retail clerk obtain signatures on license agreements were failures. Users shopping in a retail stores usually preferred to acquire the same package in another store where clerks did not insist upon a signed contract as a condition to its acquisition.
Shrink-wrap license agreements attempt to accomplish many of the same things that signed license agreements attempt to accomplish. Payment terms, restrictions on usage, and prohibitions on licensee transfers, loans, rentals, etc., of the licensed copy of software are common to both types of agreements. Prohibitions on reverse engineering, limited warranties, limitations of liability, consequential damages exclusions, and limitations on recoverable damages are also common to both types of agreement. The major difference between a signed license agreement and a shrink-wrap license agreement is that the latter is not signed by the user, hence the validity of the shrink-wrap license is more open to question than the typical signed license agreement.[11] Currently the courts are unclear about shrink-wrap agreements. Courts have been split as to whether consumer consents to the terms in a shrink-wrap agreement since the customer pays for the product and goes so far as to open the package but does not have an actual knowledge of what the terms and until the customer opens the package to read them. The problem with this concept is that one’s action cannot signify contractual acceptance, rather that there is probably no ‘meeting of the minds’ between the licensor the user.
Another criticism about shrink-wrap license agreements is that they are contracts of adhesion. This is when one party has far more superior bargaining position over the other and can enforce the contractual terms over the other by adopting a take-it-or-leave-it approach. However, this does not stop big software companies from pushing the validity of their shrink-wrap licenses. Two cases in 1996, Beta Computers (Europe) Ltd v. Adobe Systems (Europe) LTD and PRO CD Inc. v. Zeidenberg (1996), the court ruled that shrink-wrap license may be valid provided that the customer has the opportunity to read and, if necessary, reject the terms by returning the product within a reasonable period.[12]
FORM 1 - Shrink – Wrap License
IV.E. Click-Wrap License
Click-wrap license agreements are digital variations of the shrink-wrap license agreements and are becoming more common in electronic commerce, cyber-trade and website shopping where no paper precedes or follows the making of a contract by the prover and customer. Click-wraps are often use in End-User License Agreement (EULA), see Form 3 and Form 4, EULA.
For the contract to be valid, users must be presented with the EULA before downloading or installing the app and should use click wrap to get users to agree to the terms and conditions.
In the recent case of iLAN Systems, Inc. v. Netscout Service Level Corporation[13], the courts confirmed that click wrap license agreement enforceable under Massachusetts law would be interpreted under the Uniform Commercial Code. In addressing the case Chief Judge Young said “Has this happened to you? You plunk down a pretty penny for the latest and greatest software, speed back to your computer, tear open the box, shove the CD ROM into the computer, click on ‘install’ and, after scrolling past a license agreement that would take at least fifteen minutes to read, find yourself staring at the following dialog box: ‘I agree.’ Do you click on the box? You probably do not agree in your heart of hearts, but you click anyway, not about to let some pesky legalese delay the moment for which you’ve been waiting.” Is that ‘click-wrap’ license agreement enforceable? Yes, at least in the case of iLAN Systems.[14]
IV.F. Software-as-a-Service (SaaS)
A SaaS license agreement is a hybrid between a software license agreement and a Software as Service agreement. A SaaS software agreement is a service contract that doesn’t require a software license. Intellectual property laws dealing with copyrights give the software’s owner the exclusive rights to reproduce or copy the software, so the customer needs his or her own copyright license to have a copy on his or her own machine(s). Typically, however, most SaaS deals don’t call for installing software on a computer at all. Instead, the vendor keeps the software on its computers or at a third-party data center, and the customer can access it through the internet. Because there is no additional copy being made, copyrights don’t enter the negotiations. Essentially, the customer has access to a service with a SaaS agreement, not the software itself.[15]
SaaS agreements are replacing on-site software licensing in the IT industry. This is primarily because keeping software applications in the cloud can provide operational and cost savings advantage. The problem is that in order to negotiate a great SaaS agreement, the contract drafter needs to understand the legal nuances between the two. Many users prefer SaaS agreements as service agreements because they are accessing the software through rights rather than a license with any IP benefits. Vendor are granting “consent” rather than software license. Like a typical license agreement, the SaaS agreement will cover what rights the customer has to use the software. Vendor must also provide support service and ensure that it complies with the necessary requirements. In a SaaS agreement customer are given subscription rather than the software license. Throughout the duration of the subscription the customer is entitled to receive said service as well as access the system.
Including all the necessary information related to scope of permitted use is extremely important within SaaS agreements, as it should:
- Have the permitted use provision clearly state the aspects of the application the customer is authorized to use.
- Define the number of authorized users.
- Address whether it’s an exclusive or nonexclusive agreement.
- Address the allowed locations and facilities, territories, and technologies authorized to access the service.
- Explain how long the scope of permitted use is good for.
- Describe how transfer and assignments are handled.
- Address the purpose and field of use restrictions.
- Explain if any nonproduction access is allowed, such as the right to use the SaaS free of charge for training, testing, system repair, etc.
Typical software license agreements include maintenance clauses wherein the vendor agrees to resolve any issues with the software, insure it is updated and upgraded. This, however, does not exist in the SaaS setting. Since the customer does not retain her own copy of the software, there is nothing to upgrade or update. When the vendor makes the necessary upgrade, the customer should immediately benefit. Approving a definite time frame in fixing or addressing errors such as speed or latency is another important thing to consider in a SaaS agreement. Another is the issue is data security. Customer sensitive data resides on the vendor’s computer with the software rather than locally on the customer’s machine. This is the reason why most SaaS contracts include a clause on how data privacy is managed.[16]
References:
[1] Tollen, David W., “The Tech Contracts Handbook,” (American Bar Associations, 2015), page 6.
[2] Ibid.
[3] Ibid.
[4] Ibid.
[5] Tollen, “Tech Contracts Academy,” page 10.
[6] Ibid.
[7] Ibid, page 11.
[8] Bond, TJ Robert, “Software Contract Agreements: Drafting and Negotiating Techniques and Precedents,” (Thorogood Publishing Ltd, 2010), 62-63.
[9] Ibid.
[10] Ibid.
[11] Bond, “Software Contract Agreements: Drafting and Negotiating Techniques and Precedents,” page 67.
[12] Ibid.
[13] 183 F.Supp.2d 328
[14] Ibid.
[15] “Upcounsel,” SaaS License Agreement: Everything You Need to Know, https://www.upcounsel.com/saas-license-agreement (Accessed on 5/29/2019).
[16] Ibid.