Software licensing fundamentals

We do a lot of software licensing transactions. This article addresses two fundamental areas of software licensing legal practice that I think often get missed, but which can be critical to getting the deal right.

A.     Revenue recognition. How revenue is recognized on a software licensing transaction is plainly an accounting issue (as opposed to a legal issue). However, for most software businesses, the manner in which they recognize revenue is a critical component of their licensing program. Investors, partners and customers evaluate a software business’ performance by reference to its revenues. If a company is unable to recognize revenue on a transaction in a manner consistent with its standard revenue recognition policies, then the fees underlying the transaction may not qualify as revenue for the intended period – this can have a detrimental effect on the company’s ability to demonstrate its performance as it would have preferred.

Most software companies’ revenue recognition policies will be established and policed by its accounting team. However, it’s not always practical for the accounting team to be involved in every stage of negotiations around licensing and pricing terms. In these circumstances, it’s helpful to have a basic understanding of the rules affecting revenue recognition, and the specific manner in which the company applies them. Ideally, a lawyer representing a software vendor will have some familiarity with the vendor’s revenue recognition policies.
The primary authority for software revenue recognition in the U.S. is AICPA Statement of Position (SOP) No. 97-2, Software Revenue Recognition. This is a lengthy document; it is, however, surprisingly readable.

At a very high level, revenue will generally be recognized once the following four conditions have been met:
  1. Persuasive evidence of an arrangement exists, e.g., an enforceable contract.
  2. Delivery has occurred.
  3. The vendor’s fee is fixed or determinable.
  4. Collectibility is probable.
There are many intricacies to SOP 97-2 and each vendor’s individual revenue recognition policy, so don’t take the list above as all that’s necessary to understanding the issue.

Because revenue recognition is so critical to measuring a company’s performance, software companies may not have much flexibility when negotiating certain of their licensing and payment terms, especially if deals have been structured so as to enable the company to recognize revenue within a specific period. For example, if a vendor has provided price concessions based upon its recognizing revenue from a transaction by September 30, 2010, but the customer insists that payments will be refundable if the software does not conform to acceptance tests that the customer won’t complete until October, 2010, then both parties will have a problem in closing the deal as they’d hoped. (Acceptance testing with refund rights would be problematic under item 3 above: the fee wouldn’t be fixed or determinable.) Lawyers negotiating the transaction may be called upon to find compromise solutions that conform to the vendor’s revenue recognition policies, but still provide the customer with an appropriate level of comfort regarding the software it’s acquiring.

In summary, persons involved in software licensing transactions will be more valuable to their principals if they understand the interaction between the deal terms and the vendor’s revenue recognition goals and policies.

B.     Copyright. Software programs constitute intellectual property that may be protected by a variety of intellectual property laws, including trade secret, trademark and patent rights. However, software’s fundamental protection lies under the copyright laws.

In very broad terms, the intellectual property laws provide the owner of intellectual property with certain ‘exclusive rights.’ These rights enable the owner to exclude other persons from doing certain things with the intellectual property, except to the extent the owner has specifically granted a person the right to do so (e.g., under a license agreement).

Under the patent laws, an intellectual property owner has the right to control how others ‘make,’ ‘use,’ or ‘sell’ a patented invention. Under the trade secret laws, an intellectual property owner has the right to control how others ‘use’ the protected invention, unless the others develop their invention without access to the protected invention, or unless the protected invention no longer qualifies as secret. Under the trademark laws, a trademark owner has the right to control how products and services are associated with the owner’s trademark (e.g., I can’t associate my software program with the MICROSOFT mark unless I have a license from Microsoft to do so).

Most software lawyers will readily acknowledge that, while the copyright laws don’t provide the most intuitive intellectual property law vehicle to protect software programs, software programs fall under copyright. Because the copyright laws evolved out protecting (in rough order) literary, dramatic and musical works, then audio and audiovisual recordings (such as music recordings, radio broadcasts and movies), the application of copyright law principles to software can look a little odd. This is evident in the exclusive rights under the copyright laws. These exclusive rights are as follows:
  • The right to reproduce a work
  • The right to distribute a work (i.e., to provide a copy to a third party)
  • The right to display a work
  • The right to perform a work
  • The right to create derivative works of a work (i.e., in very general terms, to create modifications)
Surprisingly, many software licenses, especially forms pressed upon reluctant vendors by their customers, don’t address any of the exclusive rights under the copyright laws. They simply provide the licensee with the right to ‘use’ the software. This is all well and good to the extent the licensee needs rights under the software licensor’s trade secret and/or patent rights. But, it doesn’t do much in the way of specifying what rights the licensee has under the copyright law. For example, if I have a license to ‘use’ software, do I have a right to make modifications to the software?

Ideally, a software license will expressly address each of the necessary exclusive rights under the copyright law. For example, a typical license grant might state: ‘Vendor grants Customer the non-exclusive, non-transferable, worldwide right to make up to [####] copies of the Software, and to distribute such copies internally within Customer and install them on up to [####] personal computers owned or under the control of Customer. Vendor grants Customer the further right to create derivative works of those portions of the Software identified as ‘modifiable code’ in the Documentation. Vendor reserves all other rights.’

If the software is also protected by trade secret or patent rights, then the Vendor could also impose restrictions on use of the software, e.g., ‘Customer may use the Software solely for processing data related to the business of its [XYZ] division.’

Different rights may apply depending on different licensing models and technical architecture. For example, if the customer is acquiring rights to a cloud-based application that will make information available to the customer’s customers via web pages, then the customer would need a right to ‘display’ the web pages generated by the software.

In summary, since licenses are governed by the intellectual property laws, it’s important to give some consideration to which intellectual property laws apply, and whether the license correctly addresses each of the rights made available by the intellectual property laws. A simple license to ‘use’ software is a recipe for confusion if a dispute arises over the scope of the usage rights.
blog comments powered by Disqus