A Take on Kevin Mitnick’s New Book (from a Software Attorney)

Ok, if you have not heard of Kevin Mitnick and you are in the software industry, then he is someone you need to know about. He is probably the most notorious hacker in US history, and he released his new book Ghost in the Wires (A 5 Star Rated Book on Amazon.com) a few months ago. 

So here are some takeaways from the perspective of a software attorney that only represents Software, SaaS and IT services companies. 

1) Read the Book. Ok I get that this is circular logic, but you will learn things that I think you cannot learn other than by reading the book. What I am trying to say here is that the way that he describes how he moved effortlessly in and out of a tech company's systems, steals source code, gains direct access to deverlopers, is nothing short of amazing. Without getting a real gut feel for this by reading the book, the importance of this book will be missed. 

2) The Weakest Link in Your Security.  Kevin Mitnick coined a phrase 'social engineering' and you need to know about it (there is even a wiki page dedicated to it).  Essentially it is all about how a hacker uses trickery and deception to get information to gain access to a computer system. In other words, it is all about the human element. No matter how great your company's technical and physical security is, the human element is the weakest link (at least I think so after reading the book). 

3) Next Steps. I think that if any IT security program is not equally focused on how to prevent social engineering, it is missing the boat. So how do you prevent it? Well there is no guaranty, but I highly recommend some basic training of certain departments within your organization regarding identifying social engineering. I would train these groups, and in this order:

(a) receptionist (definitely first),

(b) tech support, and

(c) and developers.

If you train these groups, you will hopefully see an attack coming, and have a great chance of preventing it. Oh yea, there are some great training materials for this on the web. 

Look I am a software attorney and not an IT security expert, but what is very clear to me is that the most notorious hacker is sharing some of his greatest insights and real world examples (many of them) of how he hacked (deep) into major tech companies. If you have not read this, or don't feel like you know much about this topic, then go read this book!! I think he is really providing a valuable service to all of us by writing this book. As Daniel Tosh of Tosh.O would say, "and for this we thank you." 

Resources: 

Symantec's Social Engineering Fundamentals. 

A Blog from an Expert and Trainer. 

Kevin Mitnick Even Provides Training. 

One Book Review. 

 

2 Reasons Why You Need an API License Agreement

I have been delaying writing a blog post about API licensing, as I could not find a good real world example to go along with the post. Well, Twitter just gave me that real world example, as  they recently changed their API license agreement, which caused quite an uproar in the Twitter community. Take a read below,  as here are 2 great reasons why software and SAAS companies with an API need an API license agreement (instead of going naked with no agreement).

For background purposes, Twitter changed their API licensing terms to further restrict how their API developers use their API (oh yea, there are over 750,000 registered apps). Twitter now wants its API developers to build "tools" . . .  not businesses or applications.

Quote from Twitter email re: their new API Rules of the Road on March 11th:

 

1) Your API Developer Use Case, Could Change. As you know, things change rapidly in the software and SAAS world. You may open up your API and then realize that you opened it up too much, and you want to restrict what your API developers are doing.

• Twitter realized this, as developers were using their API to compete with Twitter or simply duplicate their interface, and causing confusion in the market place (plus trademark issues,  changing the tweets, etc).

As most API license agreements are pretty one sided (as you are giving them something for free and it is your technology) you can change the terms at any time.  However, if you don't have an API license agreement and then change your API program, your API developers may not only  get really upset, but if they lose $ as a result of the change then you may be responding to lots of complaints and maybe a lawsuit or two (= not very fun). So think about putting an API license agreement in place, as it can protect you if things change, as it can expressly give you the right to change your API terms without any liability to you.

2) Communicate the Right Expectations to Your API Developers. As with any agreement, the API license agreement helps to communicate your model (setting expectations of what your developers can and cannot do), and most users actually want to know where the boundaries are (having a great API FAQ is a good idea too). I find that most software or SAAS companies don't know what the terms of their API license agreement should be, so they avoid the issue (remember, no decision is still a decision). Well, maybe you get lucky and you don't need to make significant changes, but I would not recommend relying on luck.

• I bet you if Twitter did not have an API license agreement with (a) limitations of liability, (b) disclaimer of warranties, (c) specific language giving them the right to change the agreement at any time, etc., they would have been sued for this recent change. The API users would have probably argued that they relied on this access without restriction and created a business around it (i.e. spend $), and now Twitter cannot make a change without compensating them for the loss.

Well, a good API license agreement can help avoid this whole argument, as it can help communicate your API development model and set the right expectations with your API developers.

Anyhow, I could go on and on with other reasons, but if you can remember that (1) things can and will change in your API model (i.e. remember that you cannot see the future), and (2) you need to set the right expectations with your API developers, then you get the 2 main reasons why you need an API license agreement.

TechCrunch Post on the Twitter API Change.

ZDNet Post on the Twitter API Change.

Disclaimer: This post is for informational and educational purposes only, and is not legal advice. Hire an attorney if you need legal advice.



Enterprise Software Agreements: How to Design Yours!

This is an issue near and dear to me, as I have spent a large part of my career drafting and negotiating enterprise software agreements. However, what I have found is that many growing software companies are trying to figure out how to design their enterprise software agreement, so some thoughts on it (from a software attorney) would/should be helpful.

1) What is Enterprise Licensing? Essentially, most software companies have a licensing model wherein they provide their software to their customers based on some licensing metric (user, computer, device, division of a company, revenue, etc.). This often works well for small and medium size customers, but not necessarily for large customers (enterprise customers). If you think about it, enterprise customers want something more: flexibility, discount/predictable pricing, and ease of administration if they are going to commit to a large license purchase of your software. So long story short, an enterprise software license can mean many different things to different software companies and enterprise customers, but you need to define what it means to your company and to your large customers. By the way, some customers call an enterprise agreement an agreement under which they can purchase software at a discount company wide for a certain period of time. I am not saying they are wrong (I think that is simply a pricing agreement though), but the key here is to figure out what your enterprise customers need or want.

2) Factors to Consider in Designing Your Enterprise License. The first thing I want you to think about is what does your enterprise customer need/want with your software (compared to your smaller customers). As I mentioned above most enterprise customers want (a) flexibility (the licenses are easy to manage from a password or security perspective), (b) discount and predictable pricing (if they commit to your solution company wide, they don't want you to arbitrarily increase their price), and (c) ease of administration (the agreement is easy to administer), but try to figure out if there are other or different needs/wants of your enterprise customer, as every software product's value proposition is unique. Once you have figured out what your customer is looking for, you need to figure out how to price the enterprise software license. This is not easy, but I suggest you try to ensure that you are being adequately compensated for doing these deals.

3) Example. Let's say you license your software per computer, and customers typically purchase 1-5 licenses at a time. Let's also assume that your licenses are tied to each computer via a unique password, and the licenses cannot be moved around. If a large customer wants to make a purchase and asks for an enterprise software agreement or license, what should you do? I recommend you look at the 3 factors above (flexibility, discount/predictability and ease of admin) and then make sure you are being adequately compensated for the deal.  So maybe an enterprise agreement could look like this: 50 computer licenses with open passwords (to use within their company), higher discount per copy  and fixed price for 5 years for additional copies, annual usage reporting (i.e. if they exceed their 50 licenses), and in 5 years the deal dies and reverts back to fixed computer licenses. This is simply one example, but as you can see there are several levers to pull to ensure that their needs are met but you are not being taken advantage of. I think the key here is that you don't need 5 different types of enterprise agreements, as once you figure out what it should look like you can lead with that model (of course you should consider making changes at the request of an enterprise customer and don't forget to keep improving the model as you learn more about the needs of your enterprise customer).

4) What Not to Do. I have seen some software companies simply provide a site or unlimited license as their enterprise software agreement and call it a day. Now maybe this is the right answer for your company, but I suggest you are not being adequately compensated for this type license. The problem I have with unlimited or site licenses, is how do you define the company or site? What happens when the customer is  acquired or merges with another company? You can get into some really complex drafting  what are called 'change of control clauses' to avoid this issue, but I don't think you want that level of complexity (unless the deal is really large). By the way, most large software vendors rarely license on a site or unlimited basis, and if they do it is often a term license. Here is an example of one.

So remember that when you are designing your enterprise software license agreement, you should think about the needs/wants of the customer and only then you can ensure you are being compensated for it. These enterprise agreements are really not that complex, but they do take some time to design (if you want to get them right). I really can't do this subject justice in such a short blog post, but hopefully you got the main thoughts behind designing your enterprise software agreement.

Legal Disclaimer: This post is not legal advice, and is provided for general informational and educational purposes only.

How to Get Sued Over Your Software EULA/SAAS Contract, and Lose!

Ok as a EULA Attorney I thought that would grab your attention. Well, there is a recent court case you should be aware of where the software company lost big time (over its Software EULA (applies to SAAS Contracts too)), and now owes the customer around $240 million for a software/services deal gone bad (here is the actual response from the jury).

How does this happen? Well, let's take a look as there are some tidbits for every software or SAAS company.

First things first, the case: Dillards (the customer) sued i2 (later acquired by JDA Software) over a failed software and services implementation (even though Dillards still uses the software; figure that one out). Without going through a long detailed overview of the case, Dillards believed the i2 software was not working as promised and took it up with i2. Obviously, the parties could not work it out, and the case went to trial in Dallas, Texas in 2010. Long story short, i2 lost and Dillards won around a $246 million judgment on around a $10 million software and services order (yep, 24 times the amount of the sale). So how does this happen, as there was a contract with a limitation of liability, and i2 had attorneys working on the contract. Let's dig a little deeper and see what you can learn from a case like this.

1) Don't Overcommit and Underperform. You probably knew this already, but if you do it in a big way a court could find that you committed fraud (yes the F word), which is what they found in the Dillards vs. i2 case. What did not help–and I think swayed the jury–was the fact that i2 had agreed to a consent decree with the SEC stating that it had exaggerated the functionality of its products to its customers. But it gets worse! i2 even hired a MIT professor of Management (not quite sure why they had to do this) to perform an assessment of their business practices, as apparently something was not working right. This professor wrote a scathing report stating–in part–that i2 was over-commiting and under-performing…see excerpts below.

2) If You Have a Problem, Solve It Through Negotiation. Look software is not perfect and free of flaws (and customers know this), but if you have a product problem (e.g. the software is not working as it should or your sales team has oversold the technology), then fix it/make it right (free software, credit, extension, refund etc.). Every software company I have come into contact with knows how to solve these type of problems, and doesn't forget the importance of the relationship with the customer. I bet if i2 had given Dillards its money back early on in the process, seen the case for what it is, and handled the disagreement in some fair way, they would not be facing a $240 million dollar judgment. I realize it may seem like I am second guessing i2 with the benefit of hindsight, but come on if you have a consent decree and a report from a MIT professor about your problems, then maybe you should not be going to trial.

So without going on forever on this, my goal is not to scare you, but rather to inspire you make sure you control your sales teams, and make sure people at your company don't think that you can/should commit to things that you cannot do . . . even in the intangible world of software. Oh yea, those limitation of liabilities usually work to protect you, but not necessarily against a finding of fraud as in this case (which you may not realize, is an extremely high burden for the plaintiff to prove). Just a few thoughts from a software attorney, as this is something you should be aware of, even though it is really (actually extremely) rare.

More:

ZDNet Article

Legal Disclaimer:  This is for informational and educational purposes only, and does not constitute legal advice. Contact your attorney for legal advice, which should be provided after review of the facts and applicable law.

6 Tips, If Your Customer Wants You to Use THEIR FORM AGREEMENT

Let me frame this right. When you are selling to an end user, they sometimes say/insist/require that you use their form of agreement as part of the Software agreement negotiations or SAAS agreement negotiations. So what do you do?

1) Negotiate, Negotiate. Don’t forget about this, as this is not the time to simply say yes! and hope that somehow this will make it easier to close the deal (it won’t). Trust me. What to negotiate? See 2-6 below.

2) Price and Terms are Linked. If you think about it, your end user agreement contains your model (what rights the end user receives (and doesn’t get), what restrictions they have, warranties, transfer rights, etc.) and your pricing is based on your model. If your customer wants to significantly change the terms of your offering/model, then this could/should affect the price they receive. Remember this, as price and terms are inextricably linked.

3) Time is of the Essence (hopefully). Is time an issue for them? If time is an issue (i.e. there is an impending event), then make sure you bring this up before you agree to use their form agreement, as I have found that using the customer’s form as a starting place will too often lengthen the sales cycle (not shorten it, even though they may tell you it will). Instead, try to start with your agreement, and make the changes that your customer needs to that agreement (much more efficient).

4) Set the Right Expectations. Make sure the customer understands that there will likely be a lot of changes to their form agreement (every customer form of agreement I have seen looks very little like the vendors model), as you will have to build your model into their agreement and take the terms that affect your pricing/model out. If you don’t bring this up early and get their buy in to help you work through the open issues along the way, the process of using their form will likely be very long/delay the deal unnecessarily. Oh yea, try to get a business owner/decision maker separate from their legal/purchasing department to help you out, as you will need someone to help you make decisions on open issues.

5) It is All About $. It really is all about the money. If the transaction size is too small, then it could be a waste of your time and resources to start with the customer’s form of agreement (suggest that if the transaction was $x, then it would be worth using their form agreement but as it is $x-y, it is not). However, if the transaction is large then read the other tips in this post, as you may be forced to use their form agreement. Where do you draw the line as to $? That is company specific (= your decision).

6) What Are Your Goals? If you land up using the customer’s form of agreement then your goal should be to end up with an agreement that if you sign:

• does not pose any significant risk to your company (i.e. a risk that you normally would not take),
• is administratively efficient (i.e. you don’t have to spend a lot of time maintaining the agreement, tracking it for compliance, looking over your shoulder, etc.), and
• is consistent with your model (i.e. you can still book the revenue as you would other deals).

Keep these goals in mind, or add to/change this list to fit your business model.

Just a few thoughts from an attorney that has negotiated hundreds of deals using the customer’s form of agreement for software and SAAS companies.

Disclaimer: This is provided for educational and informational purposes only, and is not legal advice. Talk to your attorney for legal advice, as they should consider the pertinent facts and applicable law before providing any advice.

Have You Had Your Software EULA/SAAS Contract TUNEUP for 2010?

You know, adjust your contracts to improve their performance…just like your car. Ok, let me explain. Every software or SAAS based business should take a look at their Software EULA or SAAS Contract each year to see if they are 100% consistent with their current model, pricing, go-to-market strategy, etc., as too often this is forgotten or last on the list. Look I know legal issues and contracts are not top-of-the-mind for most executives, but don’t over look it.

My TuneUp ideas are:

1) At least once a year, whenever you make a change to your model, or come out with a new offering etc., think about whether you need to change/tweak your Software EULA or SAAS contract.

2) When do you take a look, think about whether you can simplify, shorten and make your agreement more transparent and clear. That is the trend in contracting for software and SAAS, so don’t forget it.

3) As with cars, there is no one size fits all tuneup (I hope you knew that already), so there is no one size fits all tuneup for your agreements either. Figure out what is new or different, and fix/improve it.

Just a few thoughts from a software attorney.

Disclaimer: This is provided for educational and informational purposes only, and is not legal advice. Hire an attorney for legal advice, as they should consider the pertinent facts and applicable law before providing any advice.

3 Things To Consider In Your Software Referral Agreement

While there are many different issues to include in a software or software services referral agreement (SAAS referral agreement), here are a few practical things to consider:

1) What is In and Out. What types of referrals will  you pay on, and what types won't you? Don't forget excluding transactions that are already in flight or that don't close within x amount of time. What about extensions of the transaction? Be super clear on all these issues, as this is the key part of the agreement (quite frankly most of the disputes I see are related to these issue).

2) Payment/Reporting.  Do you want to pay after each transaction, or on a monthly/quarterly basis under a report? Also, don't forget to address credits and returns, and that you have to be paid first (before you pay them).

3) Simplicity/Plain English. Keep this agreement simple, and short, as you want to make sure (a) your partner understands the agreement, and (b) your internal sales/channel teams understand it too. Any confusion between these two groups on referrals could create a lot of disagreements.

Just a few thoughts from a software attorney.

Disclaimer: This is provided for educational and informational purposes only, and is not legal advice. Talk to your attorney for legal advice, as they should consider the pertinent facts and applicable law before providing any advice.

Installed (not used) or Purchased Licenses. Which One Does a Customer Owe You $ For?

While most customers may say they only want to pay for software eula licenses they use (not all installed), a recent reported case involving the Los Angeles County Sheriff's Office says they need to pay for what is installed (even if they are never used). Without going into a lot of detail, the court ruled that LA County Sheriff's Office must pay the software vendor for the licenses installed (in the amount of $210,000), even if they were not used. Plus, the court awarded the software vendor more than twice the damages award in attorney's fees and costs (nearly $560,000).

Q: So what is the right way to use a case like this?

A: This is a great case to educate your customers about, if they are installing a lot of your software and saying they don't have to pay for those copies as they are not being used. I am not saying hit them over the head with this case or rub their noses in it, but educating them on your perspective is a huge part of software negotiations.

The goal here is not to go to court, but to me if a customer's license ends, then the customer should return or destroy all copies of the software (just as the license agreement states). In addition, well run IT departments should not leave  unlicensed copies of software on computers (even if they are not using them). Any software company should educate itself on these type of issues, and try to avoid going to court  with a customer (if possible, of course).

Some Other Relevant Blog Posts: Showing Respect in Software Negotiations

Legal Disclaimer: This is for informational and educational purposes only, and is not intended to constitute legal advice.

2 Tips to Determine if You are Selling Legal Simplicity or Complexity.

Ok as a software attorney, what I am asking is your end user (EULA or SAAS Contract) or channel  (oem, reseller or distribution agreement) contracting process simple or complex? Have you thought about it? I find that most growing Software, SAAS or IT companies don't really think about these kind of issues (or at least if they do, it is on the bottom of their list). Let me see if I can add this to your to do list, or help move it up the list.

Step 1: End User and Channel Contracts. Your end user and channel contracting process should be super simple. What I mean is, your contract should be vetted internally to make sure it is (a) written in plain english (get the legal jargon out), (b)  only includes the necessary clauses (talk to your attorney about this, as too often there are clauses in there you may not need or want), and (c) as short as possible. If you have not taken this on, then do it. You will find that it is well worth the effort.

Step 2: Negotiating Process. How are your sales teams handling the negotiation of end user and channel contracts? Have they thought through the legal and business issues (are they trained on how to respond to questions from end users and channel partners)? If the answer is yes, then great, you are probably getting your deals closed in a reasonable amount of time and building trust with your end users and partners, but if not then you have some work to do. Have your teams read 'Getting to Yes' (for starters), and then make sure they fully understand the contracts they are asking your end users and partners to sign (i.e. Step 1).

This is really not that hard, but too often these type of issues are not addressed (or addressed too late in the game). If you follow these two simple steps, you can figure out if you are selling legal complexity or simplicity, and make the necessary adjustments to sell simplicity if you aren't. Add this to you to do list, or simply move it up the list!

Some other useful blog posts:

What Does Your SAAS Agreement or EULA Say About Your Company?

How to Inspire your Lawyers to Write Better Contracts?

Two Software Negotiations Books to Read.

Legal Disclaimer: This is for informational and educational purposes only, and is not intended to constitute legal advice.

4 GREAT Reasons to Register Your Software for Copyright Protection!

Most people may not realize that there are 4 GREAT reasons to register your software for copyright protection with the US Copyright Office.  As a software copyright attorney or lawyer, I recommend this for every software based company, whether you are licensing your software or providing it as a service.  So here goes.

1) EASY. It can be done by yourself or with the help of a software copyright attorney. Your call, but any good lawyer will tell you to consult with a software copyright attorney before you file.  In general though, it is not hard to file for copyright protection, so this is not an issue.

2) INEXPENSIVE. The filing fee is low (less than $100) so that is not a barrier either.

3) REIMBURSEMENT OF ATTORNEY'S FEES.  If you file a claim for infringement based on a registered copyright that existed before the infringement, federal copyright law provides that you could be reimbursed for your attorney's fees. If you think about it, this is really a big deal, as it is extremely rare that plaintiffs in a case are reimbursed for their attorneys fees. This can be a double edged sword though, as if you lose you may be paying for the defendant's attorney's fees (i.e. something to definitely discuss with your lawyer before you file the case). To have a shot at being reimbursed for your attorney's fees though, you need to file within 3 months of the work being published (if it is a published work). Talk to a software copyright attorney about it.

4) AWARD OF STATUTORY DAMAGES. What statutory damages provide is a fixed amount of damages awarded to you, without having to go through the difficult (and expensive) task of having to prove your actual damages. This is a big deal too, as proving your business harm of someone infringing your copyrights can be tricky and often difficult, so you have an alternate way of being compensated for the infringement. These damages can be as high as $30,000 per work, and up to $150,000 per work for willful infringement; these are set by a judge, who has some discretion here. To make a claim for statutory damages, you also need to file early (within 3 months for published works), so again talk to a software copyright attorney about the timing issues.

Any software based company should consider filing for copyright protection of their software early, as it can make a real difference to their overall protection of their IP.

Here are some resources:

US Copyright Office: FAQ

Can you Obtain Copyright Protection for your Software's Graphical User Interface (GUI)?

4 Things to Remember About Copyright Law

Contracts vs Copyrights

Legal Disclaimer: This is for informational and educational purposes only, and does not constitute legal advice.

SAAS Agreement vs. Software EULA. Which One Do I need?

As a SAAS lawyer, I sometimes run into the issue of "Do I need a Software as a Service Subscription Services Agreement (SAAS Agreement) or Software EULA?"  In other words, what should I start with (EULA sample or template, or SAAS agreement sample or template). It is pretty easy, as it all depends on the primary item provided. Let me explain.

If a company is trying to define their model in their end user agreement and are unsure of the form agreement to start with, they should figure out if there is any software downloaded by the users, or if they are only providing software-as-a-service through a browser. While many companies have hybrids (some services and some downloaded software) I think it should be viewed as what is the company primarily providing.

• If they are primarily providing software through a browser, but there is some software downloaded (think Go-to-Meeting or Webex), then they would need a Subscription Services Agreement, as they really are in the SAAS business.
• However, if they are primarily providing software which will be downloaded, but there are some services provided (maybe support/maintenance/training/some services through the web), then they would need an EULA, as they are licensing their software.
• Also, some models may be more of a true hybrid, with a SAAS agreement for their online subscription service, and then a EULA for the software that will be downloaded and used with the subscription service..

Every software based company should figure out which form of end user agreement they need, as their customers will be asked about it, and they need to have it right!    A few thoughts, from a SAAS attorney on SAAS agreements and Software EULAs.

5 Most Important Software Agreement and SAAS Agreement Revenue Recognition Issues.

From the perspective of a software copyright attorney, here are the 5 most important revenue recognition issues (based on my experience), for Software Agreements and SAAS Agreements.

Acceptance. Make sure there is express language in the license agreement or order that states that the software is 'accepted' on the order date. I can bore you with all of the reasons why, but I would simply add this one to your end user license agreement or other type of end user software agreement [in general this is more of a software licensing issue for business customers, than a licensing issue to consumers or a SAAS issue].

Warranties with Refund Rights. This is a pretty thorny issue, but in general, other than a standard limited duration performance warranty that the software will perform in material accordance with its documentation and an infringement indemnity warranty/remedy, any additional warranty with refund rights could create a real revenue recognition risk.

Future Deliverables. If you think about it, this should be an easy one. The customer is buying the license for the software (as it currently exists), so there should not be any commitment regarding future enhancements (other than standard maintenance/support) in the contract or outside the contract.

Signed Agreement. While this should be a no-brainer too, having a signed agreement (that means by BOTH parties) is critical to a final deal. While most people focus on getting the deal done, it is really not done until the agreement is signed (more on this topic: When is a Deal Done). By the way, enforceable electronic or click contracts should be fine.

Fee is Clear and Collectable. The license agreement and order should be clear about what the customer will receive and what they will pay for. This seems pretty basic to me, but it should not be overlooked with vague descriptions of what will be provided, or unclear and indefinite payment/fee terms.

When working with my software company clients I try to remind them of these basic rules (at least a software copyright attorney's take on them).

More Details: Here is some reference material on this topic: PWC Material

You Lose Nothing in Software Negotiations by Showing Respect!

Here is something that costs nothing but can really help when selling software or other IT products or services, or otherwise in software negotiations. As a software attorney, I can tell you this can make a difference.

Think about it: when negotiating with a purchasing manager or member of the IT department, you are dealing with a person at the other end of the phone (yes, I have worked with people that forget this basic fact). There are probably a lot of other things going on in their mind or life, besides buying the software, so a little respect can go a long way. By the way, all this means is showing 'regard or consideration for, courtesy or deference.' This is not hard stuff.

This may be as simple as:

1. making sure you address/listen to all their concerns and issues,
2. don't talk down to them (on the phone or in email),
3. under-commit and over-deliver (don't do the opposite),
4. realizing they are not simply a check box in the buying process, and
5. remembering that they will be taking a risk (putting their reputation on the line) if they select you as a vendor.

When I work with software or cloud based clients as an attorney, I try to remind them of this very simple truth.

Have Software Agreements or SAAS Agreements Become Commoditized?

As a software attorney, I actually think about these kind of issues in relation to software agreement templates (EULA templates etc) and SAAS agreements (SAAS contract templates). My short answer is in some ways yes, and other ways no. Let me explain.

There are many websites that provide simple contracts for less than $100, and they could be a great place for a small company to start from. Of course, as an attorney, I would recommend they talk to an attorney before using the contract (to make sure it works for them, is enforceable, etc.). Some would argue that these contracts have been commoditized, and if so, perhaps this is a good thing.

However, I think there is another set of contracts which have not been commoditized and maybe this is a good thing too (complex agreements, agreements which are not self-explanatory or easily understood, and software/IT contracts). While the first few categories are easily understood, I think that software and IT contracts are very unique, and every software and IT company should remember this. In the software and IT world, the contract serves an additional purpose; it further explains what the customer will be receiving (as no tangible item is provided). These contracts play a much more important role (arguably more than any other industry) as they must also communicate, explain and describe what the seller will be providing and what the buyer should expect. For example, I propose that a license agreement for one company should not be used (without a detailed review) by another company as their licensing models may not match (license grant and metrics, warranty terms, support and renewal terms, restrictions, transferability, other unique attributes of their licensing model).

I suggest that in the software and IT world contracts have not become commoditized. I am not saying don't buy one from a site that sells them for $49, but I am saying if you do, have it reviewed by a SAAS attorney who is very familiar with contracts of that type.

Disclaimer: This is for informational and educational purposes only, and is not legal advice. Consult an attorney before making any legal decisions.