There seems to be a common universal belief among many companies that there is a single form agreement circulating among software lawyers with the perfect terms that can just be cut and pasted into their agreements if they can just find the right attorney who can furnish that ‘perfect’ form agreement. I have lost count of the number of times I have been told by clients that they don’t need anything from me other to provide said ‘perfect’ template. A few have even equated my or another attorney’s ability to provide them with the ‘perfect’ form template to the level of expertise of the attorney.
The reality, of course, is that merely cutting and pasting from a form agreement–even a very well-written form agreement–is precisely the wrong way to draft this type of agreement. In fact, I would take this one step further and take the position that it is precisely the wrong way to draft all technology agreements. Furthermore, it is my opinion that an attorney’s willingness to provide any document purported to be a ‘perfect’ software template is likely to be inversely correlated to his or her level of drafting experience in the space. I certainly was far more comfortable with the idea of furnishing a template in response to a client request of that nature as a very junior and inexperienced attorney than I am today, when I know better. I’ve seen all too well how companies may take the ‘perfect’ template provided and rely on it for years and years without understanding that the form required many long hours of attorney customizations and revisions before it was ever put into use for their business.
While there absolutely are standard terms that you will find in all software agreements–whether SaaS or software licenses–which may form the basis of high quality software template for either the software license or SaaS model, a well-drafted contract is more than just an assortment of the “right” terms, it reflects the actual product offering to customers. Thus, the drafter needs to not only know and understand how to draft these contracts but also have a very high level understanding of what the product offering to customers is. Otherwise, the contract will be of a very poor quality, regardless of how good the lawyer was that put the original form agreement together that the contract may be based upon.
For example, in the enterprise license model, a company may purchase a license allowing a set number of user rights. In such a model, a well-drafted license would at least explain what constitutes a user, how users can be added and deleted, what rights the users have to the various license grants made (which should go beyond the simple ‘use of the software’), the cost of purchasing new users, and the cost of purchasing the initial set of users. But the decisions on how to structure each of these terms would be entirely dependent on the business model and product offering made available by the specific software company. Thus, if the terms selected are being cut and pasted from an unrelated form agreement, it is almost certain that the terms chosen will be wrong and make no sense.
The same problem occurs with the cutting and pasting of SaaS agreements. In the enterprise model, again, you may similarly have users with different access rights, which are the SaaS equivalent to a license. Your enterprise customer may want to start with 100 users and anticipate needing to add 100 more in a period of months. Your enterprise customer may also anticipate losing some users and want to get some sort of credit for the users lost. You may have different pricing based on when the timing of the purchase of new users. Given all these different drafting and business model choices that can be made, if the terms selected are simply being cut and pasted from an unrelated form agreement, again, it is almost certain that the resulting agreement simply will make no sense.
The structural choices in how you draft these kinds of agreements do not end with the user rights. For example, there are choices that the drafter has to make based on what type of data is being collected by the product, where the data is being stored, the level of risk to the company if the data is accessed by a third party, and what needs to happen to the data at the end of the relationship. Also, there are choices that need to be made based on whether use of the product depends on importing pre-existing data into the software and effectively reading such data. It is not uncommon for enterprise customers to have much higher requirements with respect to data than a small business client would generally have. Fees, technical support, and training are other common areas of significant variation from product to product.
The bottom line is that a well-crafted software license or SaaS agreement will be structured around the technology, features, functionality, and business model of the applicable product and will not be based merely on a set of “perfect” terms from any template. As a software company, that means that if you retain an attorney to advise you on your contracts, your attorney should absolutely be pushing you to provide significant details about how the technology, features, functionality, and business model of your product work, among other issues. If you are not getting those kinds of questions from your lawyer, then it is highly likely that the terms of any contracts that your attorney reviews or drafts for you will reflect a similarly low level of understanding about those same concepts.
