***This article is one part of a ten-part article series by Koley Jessen to help software licensors improve their form software license agreements. Please contact a member of our Commercial and Technology Contracts Practice Group for further assistance.

Key takeaways:

Software license grants should:

• define the recipient(s) of the license grant (usually limiting the license grant to the customer legal entity); 

• address the non-exclusive, non-transferrable, non-sublicensable and term-limited nature of the license grant;

• define rights included in the license grant that are not included in The Copyright Act of 1976; and

• contain express restrictions addressing reverse engineering and creation of derivative works.

The license grant is the core provision of a software license agreement. This article focuses on end user license grants that permit the customer to use the software for its own internal business operations, as opposed to reseller or distributor license grants or license grants that permit the customer to use the software to provide services to its customers. An end user software license grant may read something like this:

“Subject to the terms and conditions of this Agreement, Licensor hereby grants to Customer a non-exclusive, non-transferable, non-sublicensable license during the term of this Agreement to reproduce and internally use the Software in object code form solely for Customer’s internal business purposes.”

We can break the license grant above into its component parts to analyze critical aspects of a license grant. For purposes of this article, the first important part of the license grant is “to Customer”. This license grant is clear that “Customer,” and only “Customer,” is a recipient of the license grant. Importantly, “Customer” should be defined to include only one legal entity. Software licensors should avoid license grants that include numerous different parties as recipients of the grant (ex. “to Customer and its affiliates and authorized users”). This approach creates numerous ambiguities and unintended consequences. For example, is an affiliate of customer at the time of the license grant that later becomes unaffiliated with customer still permitted to use the software as a third-party beneficiary under the software license agreement? This is just one of many examples.

The second important part of the license grant is “non-exclusive”. It is very rare for a software licensor to grant an exclusive license to a customer. Accordingly, the non-exclusive nature of the license grant is rarely negotiated. Nevertheless, every license grant of any kind should address exclusivity, and it is best to be clear that the licensor is permitted to grant the same license to other customers.

Next, we move to “non-transferable, non-sublicensable”. Some software licenses permit the customer to distribute the software and grant other parties licenses to use the software. While such rights to distribute and sublicense are appropriate in certain agreements (ex. software distribution agreements, value added reseller agreements, etc.), this article focuses on software license agreements addressing customer as the ultimate end user. For such licenses, the licensor should ensure that the customer is prohibited from transferring, assigning or sublicensing the software and any rights to use the software. For a more detailed discussion regarding the potential issues created by a customer assigning or transferring a software license, see Part 2 of this article series.

Every license grant should address the duration of the license, which brings us to “during the term of this Agreement”. This provision, along with other provisions in the software license agreement, states that the customer is only permitted to use the software during the term of the software license agreement. When the software license agreement terminates, so does the customer’s license to use the software. This distinction is critical because perpetual software licenses are relatively common in the software licensing industry, although not as common as they once were. So, best practice is to ensure clarity that the customer is not the recipient of a perpetual license (unless that is the intent of the licensor).

The next, and perhaps most important, part of the license grant is “to reproduce and internally use”. These are the verbs of the grant that state what the customer is permitted to do with the software. The most relevant intellectual property right that covers software is copyright, so license grants tend to, and should, reflect the exclusive rights granted by The Copyright Act of 1976: reproduce, distribute, prepare derivative works of, publicly perform and publicly display. The “distribute, prepare derivative works of, publicly perform and publicly display” rights are problematic for a licensor in an end user software license agreement and should not be included in the license grant. The license grant should include the right to reproduce (right to make copies) because every customer will make a copy of the software by installing the software on its computers or other hardware. Consequently, the license grant section should include language that restricts the number of copies the customer is permitted to make to protect against the customer making an unreasonable number of copies of the software.

Many license grants, like the example above, include additional verbs that do not align with the statutory copyright rights. “Use” is the most prominent example. “Use” has become so ubiquitous in the software licensing industry that many customers will expect to see it in license grants. However, courts have interpreted “use” to convey numerous different rights to customers when it is included in a license grant and not expressly defined in the software license agreement. Accordingly, licensors should take care when including “use” and other verbs that don’t align with the copyright statutory rights. Licensors should consider defining “use” and adding modifiers like “internally” in the example above to ensure “use” is interpreted to mean the right to operate the software internally.

We move on to “the Software in object code form”. Perhaps surprisingly, the definition of “Software” is an often overlooked component of the license grant. As always, the goal of the license grant should be precision. The “Software” definition should leave no room for interpretation as to what software the customer is permitted to use. See Part 5 of this article series for a discussion on whether or not upgrades and new versions should be included within the “Software” definition.  In addition, the license grant should state that the customer is permitted to receive and use the Software in its machine readable object code form and not in its human readable source code form. A discussion of the distinctions of object and source code and the considerations a licensor must weigh when granting a source code license are beyond the scope of this article. Suffice it to say, licensors should take care before granting any party a license to access and use its source code and should ensure certain restrictions are included in any such license.

“Solely for Customer’s internal business purposes” is the last component of the example license grant. Many license grants use this language or similar language. Like “use” above, it is best for the licensor to be specific regarding the meaning of this language. Typically, the purpose of this language is to limit customer’s use of the software for customer’s own internal business operations and to prohibit the customer from (i) using the software to provide services to its customers, (ii) permitting its customers to access the functionality of the software, and (iii) processing third-party data using the software.

Finally, every license grant should include a set of restrictions. This language works hand-in-glove with the license grant to provide clarity on the permitted and prohibited uses of the software. An example of standard restriction language is below.

“Customer shall not (i) reverse engineer, decompile, or disassemble the Software by any means whatsoever, (ii) alter, modify, enhance, or create a derivative work of the Software, or (iii) remove, alter, or obscure any product identification, copyright, or other intellectual property notices in the Software.”

_{This content is made available for educational purposes only and to give you general information and a general understanding of the law, not to provide specific legal advice. By using this content, you understand there is no attorney-client relationship between you and the publisher. The content should not be used as a substitute for competent legal advice from a licensed professional attorney in your state.}