
Not sure if you missed it, but a site was launched called ApplicationPrivacy.org. What is the big deal? Well, this project/site is devoted to educating app developers on application privacy issues (a worthy goal). So as a SaaS Attorney, I thought I would share my thoughts on this site/project, as there are some great takeaways for every company working on app security and privacy.
1) Great Resources. This site looks like a great place to keep track of best practices in developing secure applications, etc., as their resource page is pretty good. Take a look. Resources Page.
2) Useful Privacy Self Assessment Tools. They even provided some online self assessment tools to help see where you are in the privacy maturity model. While the assessment tool is based on a Canadain model, it looks really useful to me. Self Assessment Page. I wish someone in the US would build an assessment tool like this for each privacy regulation
(but you know on second thought, maybe a one size fits all privacy assessment is better, as it could 'theoretically' cover all privacy regs). Here is a link to the actual assessment (print version). Wouldn't it be great if there was one assessment and it said in the assessment that this issue is a HiPPA issue, GLB Issue, General Privacy/Security Issue, etc, etc.
3) Privacy Policy Generators. This is worth a look, as if you can't afford to hire an attorney you may get something useful out of the privacy policy generator. Privacy Policy Generator.
So take a stroll through this site, as there is something there for everyone that is thinking about application privacy. I did, and I learned something.
Disclaimer: This post is for informational and educational purposes only, and is not legal advice. You should hire an attorney if you need legal advice, which should be provided only after review of all relevant facts and applicable law.
First of all, I am not a patent attorney, but I know when to strategically use them (and I stayed at a Holiday Inn last night). A recent news story got my attention, as I think it is a great example of when to buy a patent for any software or SAAS company.
You may have heard of Groupon. If you haven’t, then read about it because it is a very interesting business model. But the angle for you is to learn about how (from my perspective) they are using patents to beat new startups trying to compete with them.
Think of it this way; their business model and site is relatively easy to replicate, as essentially they have a great idea of how to bring coupon buying to local markets. The problem is they are widely successful, and so copycats are coming into their market really fast (maybe faster than Groupon can setup new sites in local markets). So Groupon in essence, has a real ‘execution risk’ to their business model…this is where patents come in.
It looks like Groupon really thought ahead and bought a patent issued in 2001 that covers some of what they do today (i.e. they did not file for the patent, or discover the invention). They are now using it to fight off copycat sites. Pretty smart!
So remember this: if you have a real ‘execution risk’ to your business model, and even if you don’t have a patent or you are not sure you invented anything new, talk to a patent broker as maybe you can buy a patent that covers your technology.
It could really help you ward of competitors, especially if your business model and technology are easy to replicate = execution risk. Where do you find a patent broker? Well there are several of them, but the leader in this space in my view is Ron Epstein.
So long story short, think about patents and talk to a patent attorney or broker about them, as they can really help you differentiate yourself from the pack. Just a few thoughts from a software and SAAS attorney.
Here is a copy of the petition, for you detail oriented folks.
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.
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:
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.
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.
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.
While I know a little bit about SAAS accounting issues, there are people that know a lot more about it. I ran into Jay Howell (from BDO Seidman) at a recent SAAS seminar I presented at (regarding SAAS contracts) in Washington DC (he is the technical guru on SAAS issues at BDO), and I thought I would share some of his presentations and materials (really good stuff for you SAAS accounting/finance types). Any SAAS business should have the right person look at this, especially as these new rules took effect on June 15, 2010.
Before I give you the links, I thought I would share a few points that resonated with me.
1) SAAS Accounting Rules are Different. Yes, these rules are very different (like comparing an apple to an orange) from the typical rules regarding software accounting and revenue recognition (different rules and different interpretations). Don't think of them as similar at all. (see page 6 of his presentation)
2) Less VSOE Proof Requirements. The good news is the SAAS accounting rules are less stringent on the requirements regarding VSOE, so this creates some additional flexibility for the SAAS model. (see page 8 of his presentation) Here is a definition of VSOE if you have not heard of it before. Note to self: figure out how to use this flexibility.
3) More Flexibility in Sharing Your Roadmap with SAAS Customers. Typically if a software licensing company commits or says too much about their roadmap, then the license revenue will be deferred and cannot be recognized upfront. Well, in the SAAS accounting world there is more flexibility here. Note to self: use this as an advantage when competing with a traditional software licensing competitor. (see page 31 of his presentation).
Ok, here are the links.
Long Version: Jay's 45 Page Presentation (pretty technical if you ask me, so give this to your accounting/finance person to review).
Short Version (for the non-accounting/finance types; but willing to read a few pages on this technical issue).
Resources:
Interesting Post by Netsuite CFO
Another One of My SAAS Revenue Recognition Blog Posts.
Disclaimer: This is for informational and educational purposes, and no legal advice is provided. Consult your attorney for legal advice.
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.
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:
Can you Obtain Copyright Protection for your Software's Graphical User Interface (GUI)?
4 Things to Remember About Copyright Law
Legal Disclaimer: This is for informational and educational purposes only, and does not constitute legal advice.
Interesting question. When a software, software as a service or other IT company sends its written software EULA or software as a service agreement to the customer as part of closing a deal, it is really telegraphing a message about the company and its sophistication. As a software copyright attorney, I actually think about this stuff.
The wrong message/impression would be:
1. Is this company for real?
2. This contract seems too complex?
3. I don't understand what they are providing and what we are responsible for?
4. I need to send this to the legal department or to outside counsel?
5. I will read this later; maybe on Friday.
6. It looks like they bought this on the web for $29.
7. I think they wrote it themselves.
8. I am not sure this company knows what they are doing?
9. Is this their first sale?
None of those messages/impressions would be a good thing or help the agreement move through the process.
Here is what your EULA, SAAS contract should be telegraphing about your company.
1. They are serious about this!
2. I understand their pricing/licensing/services model. It is very simple.
3. They seem to be transparent about the way they work and their revenue model.
4. Looks like they know what they are doing.
5. I bet they sell a lot of this stuff.
6. Looks like they have vetted this agreement, and will stand behind it.
7. This looks fair, and I am going to approve/sign it.
8. I don't see any tricks in here.
So, what does your agreement say about your company?
Read your agreement and find out, at least before your customer does.
TAKE THIS QUICK TEST: Read this 2 page IBM NDA agreement and see what it telegraphs about IBM. IBM NDA.
Why aren't your customer facing agreements this simple?
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.
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.
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:
When I work with software or cloud based clients as an attorney, I try to remind them of this very simple truth.
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.
It is not easy to inspire your lawyers to write better EULAs or SAAS agreements, but it is worth a try (I can say this as I am a eula attorney). Watch this short video about simplifying contracts; this speaker (a non-lawyer) did a great job of inspiring his audience (from the 2010 TED conference) and showing them that there is a better way to contract (hint: simplify, simplify, simplify). Did you get that? Hopefully I was clear enough.
As a software licensing attorney, I am always looking for great content for top software companies, and this is one of them. Try to inspire your lawyers to help you contract better, as software and SAAS companies need to find efficient ways to contract.
Disclaimer: This post is for informational and educational purposes only, and is not legal advice. You should hire an attorney if you need legal advice, which should be provided only after review of all relevant facts and applicable law.
While this may seem basic, from the perspective of a software attorney, it is something that I often discuss with clients. If you think about it, end user agreements (whether an EULA or SAAS Agreement) are arguably more important than contracts in other industries. In most industries, the buyer purchases a tangible product they then own, or generally knows what type of services they will receive. However, in the IT world it is not that simple. As the buyer in the IT world does not ‘own‘ the product and often is unsure of exactly the type of service they will receive, I suggest that the contract is more important in this context and can be very helpful to the selling process.
Let me explain further.
1. The contract should explain/support the busines
s model of the seller, and be 100% consistent with that model.
2.The contract should set the right expectations, so that the customer knows what they will and will not receive, and what the seller will and will not provide.
3. The buyer should be able to read and hopefully understand most of the contract without going to their attorney.
4. The contract should of course address what happens if things go wrong, but I suggest that is not the sole purpose of a contract (see 1-3 above for main purpose).
I realize this is a very simple take, but that is really the point. As a software attorney, I suggest that every IT company should take a look at their contracts and figure out their purpose.
Remember, contracts are too important to be left only to the lawyers!
© 2009-12 Jeremy Aber. All Rights Reserved. Represents clients in Austin, Houston, Dallas, San Antonio and nationwide on copyright law.
SAAS Contract
SAAS Reseller Agreement
Austin Software Attorney
Houston Software Attorney
Dallas Software Attorney
Austin Copyright Attorney
Software Negotiations
SaaS Attorney
SaaS Agreement
Developed by Wordpress Experts