• No results found

Demystifying Software Licensing Gary D. Levine

N/A
N/A
Protected

Academic year: 2021

Share "Demystifying Software Licensing Gary D. Levine"

Copied!
10
0
0

Loading.... (view fulltext now)

Full text

(1)

1-01-10 Demystifying Software Licensing

Gary D. Levine

Payoff

The myriad of terms in a software license agreement can pose large hurdles for the

software vendor and the software purchaser, its end users, and technology managers in the IS department. This article takes the mystery out of software licensing by laying out the basics of a software license agreement. The article is to be used as a reference tool to help IS executives interpret the basic legal terms in most standard software license agreements so they can better manage the software sales/purchasing process and minimize the use of outside lawyers.

Introduction

No matter what type of software is being sold or used, whether to large or small

companies, or whether it is a sale under $100 or over $1 million, the software is licensed by the software vendor to the software user. Although many people are involved in creating, selling, and using software systems, to most people in the software industry, the terms of the standard software license agreement remain somewhat of a mystery.

Why is software licensed instead of sold? Why are so many of the terms of the software license so different from the terms under which other items are sold? A basic understanding of these two questions is critical to improving the software sales/purchasing cycle. Without a familiarity with these issues the parties involved in a software sale often run into serious roadblocks early in the business negotiation. Inevitably, one of the two parties defers changes to terms in the agreement to its legal department, which adds weeks to the cycle. This type of response usually signals a lack of understanding, or just a lack of confidence, in the so-called legal terms.

There are, of course, certain terms that should not be modified without the assistance of legal counsel, such as warranties, limitations on liability, and indemnification provisions. For the most part, however, software salespeople and software users seek legal counsel on too many issues that they can resolve themselves if they take the time to become familiar with standard software license terms. This article suggests that an understanding of the license agreement can expedite negotiations and prevent unnecessary breakdowns in communication during the final stages of the sales/purchasing cycle.

Untangling the License Agreement

The purpose of a software license agreement, as with any agreement, is to lay out in written form the understanding between the parties—in this case, the software vendor and the software buyer. In an optimal situation, all software licenses would be-one-page

agreements written in a manner that both an IT executive and a software salesperson would be able to understand with a little effort. Unfortunately, this type of simple licensing has become a relic of the past as the software business has become more competitive and more complicated.

The most obvious example of complex licensing terms relates to the growth of client/server computing and the use of network distributed applications. Licensing was more straightforward when it involved primarily either host-based computing or individual PC workstation applications. Distributed computing has added complexity in the areas of

(2)

the license grant (i.e., who can use the software and on what systems), pricing considerations, and transfer restrictions.

Goals of the Software Customer and the Vendor

In a license agreement, each party is looking to protect its own interests to the

maximum extent, even with respect to relatively minimal risks. A software salesperson is primarily concerned with closing the sale. The software user's goals are to obtain the best software that satisfies the organization's information systems needs and to avoid any unnecessary delays in using the software and maximizing its performance.

The software license agreement sometimes appears to be an obstacle between the goals of the salesperson and the needs of the software user. If it were unnecessary, it might be an avoidable obstacle. However, in the event any questions or conflicts arise concerning the rights and obligations of the software vendor and software purchaser, the software license agreement is the only method available to help to identify and clarify these rights and obligations in a fair and equitable manner. The software license agreement is especially important when the people who negotiated the original arrangement are no longer available to clarify the basis of their understanding.

In fact, often the license agreement can help to avoid misunderstandings further down the road. Most serious problems between software vendors and customers with respect to business terms result from ambiguities in the terms of the agreement.

For example, many software customers presume that they have the right to transfer software that they have purchased to their affiliates in the US, internationally, or even to recently acquired companies. Many software companies do not permit transfers because they consider this to be an opportunity for additional revenue or, in some cases, a higher market price abroad. In other cases, a software customer may presume that it has the right to receive identical discounts on other software products that it may purchase at a later date. Software vendors frequently consider discounts or stipulated prices to be one-time

concessions.

These pricing issues are often intentionally not discussed during the sales process, when the issues related to the needs of the software user and the performance of the software programs are the real priority. Nonetheless, these types of issues are important to both parties after the customer has selected the software that it intends to use. In these cases, the license agreement can help to improve the future relationship between the parties.

A Visual Perspective

The Software License Flowchart and Software License Menu (see Exhibit 1 and Exhibit 2) provide an overview of a standard license agreement and the most important legal terms embedded in the standard licensing terms. The amount of information is intentionally limited to those terms that can be easily understood and used by the parties involved in the sales process so they can expedite the sales/purchasing cycle. A more in-depth

understanding of these terms may be more appropriately left to the contracts/legal department.

(3)

Software License Flowchart

Software License Menu

This menu lists many of the typical choices related to the standard software license agreement terms presented in flowchart form in Exhibit 1. A software company and a software customer must choose among these provisions in order to determine the basic business and legal terms under which the software is licensed for use. the legal terms are discussed in more detail in the text. Business Terms

Terms Choices Considerations ---

--- Form of License Shrinkwrap License For mass-marketed, inexpensive Agreement software

Written (signed) For all other software; greater License Agreement enforceability

-- Type of License Single User License Greater control over licensing; higher pricing per user

Multiple User License Lower production costs; easier administration; typical for mainframe, server and

distributed application software Concurrent User Reduces initial license fees; License permits and increases general use; typical for applications used for limited hours/day Limited User Typical for mainframe/server License software; may reduce license fees; often corporate license or site license

--Term of License Perpetual Term Typical for less expensive software; optional support fees; no income stream for vendor; optimal for the customer because it improves ability to budget for the software

Fixed Term Requires additional license fees at end of term; must negotiate new terms at end of term; at end of term, the license to use the software terminates

Renewable Term May reduce initial license fees; continual license fee stream; failure to pay renewal fees means user loses right to use the software

--License/Mainten- Fixed Fees Guarantee license/renewal/ ance Fees maintenance fees for future purchases and periods; often fixed fees for a limited period Capped Fees Limit the amount of potential license/renewal/maintenance fee increases (over a period) Fees Based on Current Most flexibility to software List Price vendor; based on prices as

charged from time to time

(4)

This visual format is effective for explaining a standard software license agreement because it shows how all the parts—the legal and business perspectives—of a software license agreement fit together. The flowchart format is easy for the reader to recall. The Software License Flowchart and Software License Menu are intended to be used together as reference tools for the software salesperson and the IT executive as they prepare to discuss the terms of the license agreement.

Basic Components of the License Agreement

The IS layperson should be able to discuss certain key legal terms to further negotiate and work out the business arrangement. The basic components of a software license agreement are the business terms and the legal terms. The primary components of each of these terms are:

· Business terms:

· Licensing terms.

· Maintenance/support terms. · Payment/shipment terms. · Transfer restrictions. · Legal terms:

· Grant of license. · Limited warranty. · Limitation of liability. · Proprietary rights indemnity. · Source code escrow.

There are no other basic provisions; there is no great mystery. Each software license only covers these basic issues and the principal subissues related to them. The brief

descriptions in the Software License Menu (Exhibit 2) explain these and other terms. For a more in-depth understanding, it may be helpful to discuss these provisions with an

experienced contracts person or an attorney.

Guide to Basic Legal Terms

Contract provisions are necessary to help define the rights and obligations of the parties. The following explanations are designed to arm the reader with a general understanding of the legal terms, so the reader can then ask relevant additional questions, if necessary, of legal counsel.

(5)

Grant of License

The principal reason that software is licensed for use (as opposed to sold) is that the software user is purchasing less than all of the ownership rights that a buyer receives when purchasing other goods. As an example, when a consumer buys a car, there are typically no limitations that prevent the buyer from selling the purchase to a third party, taking it apart, or using it forever (if it lasts). This is because the buyer owns it. This is not the case with software. Because the rights being sold are so-called intangible rights or intellectual property (which may not exist in the usual physical sense), a unique set of business terms has been developed for the sale of software.

The purchaser does not own the software. The software vendor retains all ownership rights in the software. The purchaser is actually only granted a limited right to use the software, as long as the user does not violate any of the material terms of the license.

The right to use the software comes with certain restrictions: a right to use the software for a limited period (or subject to the payment of additional fees); a prohibition against transfers to third parties; and a prohibition against reverse engineering. Without these types of limitations, the software would most likely be sold for a much greater price. One way to think of a software license is as a software lease in which the user is only paying for a right to use these items and accepts certain appropriate restrictions.

It is critical that the agreement state specifically that the customer is being granted a “license” to use the software. Otherwise, the customer may have a justifiable claim that it has purchased the software and therefore should not be subject to the restrictions that come as part of a software license. Because these restrictions form part of the basis for the pricing of the software, a software vendor should ensure that all software that is “sold” to customers is actually “licensed” under the terms of a license agreement (whether that is a shrinkwrap license or a signed license agreement). A typical license grant provision would read as follows: Grant of License. Licensor hereby grants Licensee a nonassignable, nontransferable, and nonexclusive license to use the Software on a single personal computer or to install the Software on any single computer's hard disk for use on that single computer. If the Software, or any portion thereof, is to be installed on a Local Area Network Server or Network Server hard disk, then the number of personal computers or workstations in the group which have access to the Software on such servers may not exceed the total number of licenses that Licensee has purchased for he Software. Licensee shall use reasonable efforts to inform all users of the Software of the terms and conditions of this License Agreement.

Impact of Distributed Technology.

With the increasing prevalence of client/server computing and distributed applications, it is critical that this section grant the user not only the right to use the software, but also a right to use it in a manner that accurately describes the business environment. Historically, this meant the right to use the software on either a personal computer or a mainframe. A more common use today is for the software to be loaded on a network server. As a result, the issues related to limiting access to properly licensed users become more important. Concurrent user models are requested with increasing frequency for certain applications.

Finally, questions arise as to the permitted location of the software and the location of users as remote access and portable workstations become the norm. In general, the product manager for the software vendor and the end user for the customer must each review the

(6)

terms of the grant of license and agree that they accurately describe the proposed use of the software.

Limited Warranty

Software is sold with warranties that are more limited than those that apply to other commercial goods. Currently, software is considered to be acceptable for sale to customers despite the fact that the software may contain certain limited errors and bugs. Usually, these problems do not have a material impact on the performance of the software and its value to the customer. In some circumstances, however, the software may fail to perform and may require the assistance of the technical support team of the software vendor. These types of problems are accepted in the industry. However, warranty statements in formal legal documents, such as a software license agreement, cause significant concern for users because they are stated so literally. For example, some license agreements go so far as to state that the vendor does not warrant that the software will be free of errors and bugs. The typical warranty states: Warranty. The software will perform in substantial accordance with the user documentation.

Because software may be sold while it contains minor bugs and errors, it is usually sold without the standard commercial warranties that are included with the sale of many other goods. These warranties are implied in most cases by state statute according to the Uniform Commercial Code (UCC), which governs the terms of standard commercial transactions. Because certain commercial warranties are implied into all sales transactions governed by the UCC, the software license agreement must conspicuously state that such warranties are excluded.(Whether software is governed by the UCC remains an open issue in many states). A standard warranty exclusion provision states: Warranty Limitation. The foregoing warranty is in lieu of all other warranties, express or implied, including but not limited to the implied warranties of merchantability and fitness for a particular purpose.

Furthermore, any such warranties must be deleted from any purchase orders supplied to the vendor by the user. This is especially important when the software is being sold under a shrinkwrap license and is being ordered by a purchase order. Often, the terms on the reverse side of the purchase order provide specifically for the UCC standard warranties. If the software vendor does not specifically object to such warranties, they will be provided for with the sale of the software (since they are implied).

Limitation of Liability

Of all the provisions in a standard license agreement, in many ways this provision is the single most important one to the software vendor. This provision states that the amount of potential liability is capped at an amount equal to a return of the total fees paid to the software vendor by the customer. In addition, this section usually states that the software vendor is not liable for any so-called indirect, consequential, or special damages, including damages related to lost profits, loss of data, and interruption of business—in other words, damages that are potentially very large and unforseeable. It is standard industry practice to release the software vendor from these types of damages.

As software becomes more critical to the operations of most major business

enterprises, the amount of the potential damages has increased greatly. This provision may be based to some degree on the history of the software industry, where typically (in the beginning)the software customer's organization was much larger than the software vendor's and consequently the vendor could not bear a large loss.

(7)

This provision is a standard term in virtually all license agreements, and most software vendors insist on this limitation. However, despite its prevalence in the industry, it should be reviewed carefully and understood by a software customer before it is agreed to. It usually is not negotiable, except in certain instances with government entities where such limitations may be unenforceable.

Finally, because most software companies have adopted this limitation, it can be a competitive disadvantage to a vendor to agree to waive this provision. A typical provision is set forth below: Limitation of Liability. In no event shall Licensor or its suppliers be liable for any indirect, special, incidental or consequential damages, including, without limitation, damages resulting from loss of profits, data or use of equipment, arising out of the use of or inability to use the Software, even if Licensor has been advised of the

possibility of such damages. In no event shall Licensor be liable for any monetary damages in excess of the amount(s) paid to Licensor by Licensee, without regard to whether a claim is based in contract or tort, including negligence.

This provision should appear in almost all standard forms of software license agreements, including forms of trial licenses, beta licenses, and end-user licenses. In addition, it usually appears (as modified appropriately) in distribution agreements and value-added-reseller type agreements. A software company should never agree to open itself up to greater liability than absolutely necessary with respect to the potential liability for the use of its software by an end user or a reseller.

Proprietary Rights Indemnification

This provision states that in the event a claim is brought against a software user for violating another party's proprietary rights, the software vendor agrees to indemnify and hold harmless the software user from any claims, losses, costs, or damages. This is an important protection for the software user and comes at a relatively low cost to the software vendor, if proper precautions are taken at the time the software is developed.

A software vendor should be required to provide this indemnity because it is an inappropriate risk to ask the software customer to bear. Only the software vendor has the information with respect to the process by which the software product was developed. The rights that may be violated or infringed include patents, copyrights, trademarks, and trade secrets. A typical provision is as follows: Proprietary Rights Indemnity. Licensor agrees to defend Licensee from and against any claim or action based on any alleged infringement of any US patent, copyright, or trade secret as a result of the use of the Software according to the terms and conditions specified herein and Licensor agrees to indemnify and hold Licensee harmless from any cost and/or damages awarded against Licensee in any such infringement claim or action or settlement thereof; provided Licensor is promptly notified in writing of any such suit or claim against Licensee and further provided that Licensee grants Licensor sole control of the defense and any related settlement negotiations and cooperates with Licensor in the defense of such claim. Notwithstanding the foregoing, Licensor shall have no liability to Licensee if the infringement results from (a) use of the Software in combination with particular software or hardware, where there would

otherwise not be an infringement, (b) modifications to the Software not made by Licensor, if such infringement would have been avoided by the absence of such modifications, or (c) use of other than a current release of the Software, if such infringement would have been avoided by use of a current release. The foregoing states the entire liability of Licensor with respect to infringement of any patents, copyrights, or trade secrets by Software or any part thereof.

(8)

While providing this standard protection to the software user, the software company must, at the same time, protect itself. This is usually done in three ways by the vendor specifying:

· Limitation of scope (territory). · Procedural requirements.

· Exceptions to the indemnification for misuse of the software or possible problems caused by the use of, or combination with, other software products.

The indemnification should be limited to those countries where the software vendor sells its software. The risk to the software company is that in other countries, there may be possible technical violations of which the vendor is unaware because it does not conduct business there. Furthermore, if the software is not permitted to be used in a country, the software vendor should not be required to provide indemnification in that territory.

Most advantageous to the software vendor is an indemnity limited to the US. If required, the software vendor should extend the indemnity to other countries where the vendor licenses its software.

The software user should also be required to follow proper procedures if it is going to request indemnification. First, the user must provide prompt notice to the software company. Second, the software company must have the right to defend any such

claims(including the right to settle the claims). The software company may provide for a remedy if it is unable to defend the claims and is required to request that the user cease using the software. Usually this means the software company has the right to provide a modified version of the software before refunding all or any portion of the purchase price to the software user. Many companies provide for a refund of the purchase price based on a straight-line depreciation of the software cost over a reasonable period of time (i.e., five years).

If the customer's use of the software has violated the license agreement, if the software has been modified by the user (and the modification was the cause of the violation), or if the user was using an outdated version of the software, the software vendor should be relieved of its indemnification obligations, since its software has not directly caused the damages.

Source Code Escrow

Software companies should be willing to escrow the source code to their software products with an independent escrow agent at the request of a software customer. This can be an important issue for customers that rely on the software products and are concerned that the software company may go out of business. However, this is the only appropriate basis for the escrow of the source code, because without the source code and without the assistance of the software vendor, the user may not be able to use, modify, and update the software as required from time to time (i.e., to connect to new platforms and additional software products).

Many software escrow provisions incorrectly provide for a release of the escrowed source code in the event the software vendor fails to provide required maintenance services. If a software company fails to provide required services under a license or maintenance agreement, the software user should be allowed to pursue the software company for breach of contract but should not have the unfair advantage and leverage to invoke its rights under

(9)

the escrow agreement. In most cases, the failure to provide maintenance services satisfactorily is a factual dispute and may be difficult to measure; a failure to provide maintenance should not be an escrow release event.

The source code escrow agreement or arrangement should be carefully structured with the assistance of legal counsel. However, the software company's salespeople should be able to explain in general to their customers the release provisions. Furthermore, the release provisions should not be negotiable with most customers.

A final word of advice: Software users should keep in mind that some software

companies currently charge additional fees to their customers if they want to be included as a beneficiary of the software escrow arrangement (to cover the fees the company may pay to arrange for the service and to add additional customers).

Conclusion

This article advocates that IS executives take the time to understand the basics of the software license agreement so that they can keep the use of outside law firms (and even in-house lawyers) to a minimum. The additional effort to acquire a basic understanding of the most important legal concepts in a standard license agreement can improve the software sales/purchasing cycle significantly because it puts the contracting process back in the hands of software companies and the software customers and their IS executives.

The licensing process must consider the needs of the software user and the requirements of the software vendor. By and large, vendors and customers have little knowledge regarding the other party's concerns about software licensing. This article explains issues from both perspectives so that buyers and sellers of software can begin to talk to each other clearly and correctly should it become necessary to further negotiate the licensing arrangement and reach mutually agreeable solutions.

Author Biographies

Gary D. Levine

Gary D. Levine is General Counsel for Pilot Software, Inc., Cambridge MA. He oversees all general corporate legal matters for Pilot US and its nine foreign subsidiaries. Previously, he was an attorney with Hutchins & Wheeler in Boston where he was involved in financial transactions and general corporate representation. He holds a bachelor of

science degree in psychology from Duke University, a master's degree in management with a concentration in finance from MIT's Sloan School of Management, and a juris doctorate from Boston College Law School. He can be reached at (617) 374-9400.

(10)

References

Related documents

The present study examines the extent to which school resource officers, supervisors of school resource officers, and high school principals in South Carolina high schools,

On 26 th June 2015, we issued a consultation 6 seeking Registration Data Providers’ views on the proposed SIT1 functionality annex.. We consulted for a short period of time on

Moreover, they are attacking and spreading misinformation, intolerance and hatred towards human rights organizations, youth organizations, human rights defenders, activists,

This type of tyre was first developed by Litchfield of Goodyear Tyre having an extra layer of rubber inside the tyre, which acts as an envelope.. These tyres are known as tubeless

Abstract—In this paper, the smoothed finite element method (SFEM) is proposed for 2D elastic problems by incorporation of the cell-wise strain smoothing operation into the

A number of studies have been done on optimal experience or “flow” but few have compared the differences between individual and team sports. The information you provide will

Access annotated data through KMS services on the intranet (SAML, XACML, WS-Policy/ Privacy, XKMS, WSS) Access knowledge partners' annotated data through inter- organizational

Transmitter Connected to Open Tank With Constan Overflow.