The taxation of international SaaS transactions is complicated and not all worked out, but I thought I would summarize a few key points from a recent Grant Thornton article on the subject.

Here are a few key things to think about:

Permanent Establishment – this is accounting speak for do you have enough of a presence in a country for the country’s tax authorities to tax your SaaS offering.

The mains factors are:

• Is there a fixed place of business in the country? [BTW, owning hardware in country = fixed place of business]
• Is there a dependent agent in the country (‘dependent agent’ is not the same as ‘independent agent/contractors’)?

If there is a PE, then

• You will be taxed by the local authorities on the income generated from that location.
• The transfer pricing rules apply (we can figure this one out another day, but here is some info on it from Wikipedia).

Sales and VAT Taxes  – these taxes often apply, even if you don’t have a PE in a country.

Few things.

• SaaS is considered taxable for VAT purposes in the European Union (in the country where your customer is located).
• Your customer should pay this, so make sure in your contract that your clarify that you customer is responsible for any sales, use, VAT and other similar taxes.

If you look at the history, most tax regimes were originally setup to tax tangible goods (i.e. not software or software services) so trying to fit SaaS in does not work that well (at least not right now). Ok this is messy and complex, so don’t be surprised if you are a little confused by all of this. Even though it helps to learn the basics, I highly recommend you talk to your tax accountant or attorney about these issues, as this is beyond my pay grade.

Resources: 

A Link to the Grant Thornton Article

Great Tax Article on SaaS Taxation Issues (even though it is from 2008)

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. 

1) Who is really at fault here: CarrierIQ or the carriers?

• While this is a complex question (and as of today all of the facts are not known) what we do know is Carrier IQ is the software provider and the carriers have licensed their software for use on mobile devices for sale to consumers.
• Two key issues are what type of monitoring the carriers were performing on the phones, and was it disclosed.
• Seems to me, that what was being monitored and if there is an issue of ‘not disclosing’ something, really falls on the carrier’s shoulders. The carriers are the ones that determine what information to collect, transmit, etc., and also are the ones with the obligation to disclose these type of activities to their customers.
• Oh, I am not simply making this up, as Tech Crunch (‘Don’t Blame the CarrierIQ’) and CBS News (‘Carrier IQ wrongly accused of keylogging?’) seem to be taking this view too.

2) What does the indemnity say between CarrierIQ and the carriers?

• Ok I know indemnities are something that makes most people’s eyes glaze over, but this is important, so stay with me. Most software or SaaS providers should only be providing infringement indemnities, and not a typical general indemnity (here is some background on this issue from my blog).
• Why you say?  Well, this CarrierIQ situation should make you think about indemnities, as if CarrierIQ signed an indemnity (which is in essence an insurance policy) in which they indemnified the carrier regarding ‘their use of the software,‘ ‘arising out of CarrierIQ’s performance,‘ etc then CarrierIQ has a huge problem. CarrierIQ could be on the hook for millions of dollars in legal fees and fines/judgments/settlement amounts, when (based on what we know as of now) they may not be the ones that really caused this situation.
• What I am trying to say here, is if you are a tech company think really hard about indemnities, as in situations like this they can really become a big/huge/ bet the company legal issue for you.

You think this is not serious business, well read the top of a recent complaint filed in court on Dec 2nd.

So we will see how this plays out, but at least I am looking out for you and thinking about some good things to learn from this mess.

Resources: 

Carrier IQ Press Release December 1, 2011

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.

This is a pretty fundamental concept in any software negotiation, so this is something you have to master. One of the big guns (William Ury) from the Program on Negotiations at Harvard (which is in my opinion the best negotiation program out there), wrote a book on how to say 'No.' If you did not realize it, 'No' is actually the most used word in the English language (which kinda makes sense) so how to use it in software or SaaS negotiation is worth learning about. 

Here goes,  

1. In saying 'No' to something, in essence means you are saying 'Yes' to something (I know that seems weird at first, but there is always a reason for saying 'No,' which is what you are actually saying 'Yes' to).  
2. Express your 'Yes'  and then deploy your 'No.' 
3. Propose a 'Yes.'

Ok that was probably confusing, so let's go through an example using the three steps (in the software or SaaS negotiations world). 

1. "Your company is not making a real long term commitment to our technology" (that was your internal 'Yes' (ie. the reason you have to say 'No')).
2. "So we cannot give you the discount you asked for" (that was your 'No').
3. "However, if we can work on a long term commitment then I definitely think we can get there on the discount you are looking for. What is more important to your company?" (This is the proposed 'Yes').

Think about using this when you negotiate your next software or SaaS agreement, as Accommodating (saying 'Yes' when you should be saying 'No'), Attacking (saying 'No' in an ineffective way), and Avoiding (not saying anything), are not good ways of dealing with issues. Oh yea, don't forget to actually read the book, as to make the change in your negotiation style, you need to read this book. 

IBM Training Material presentation on this topic (yep, IBM is into how to say 'No' and trains their employees on it). 

Buy 'Power of Positive No' on Amazon for $16.50

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. 

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. 

Ok, let me see if I can explain this issue a little better.

• Can you use third party software (for example, Microsoft's SQL Server) in your partner's demo lab for testing your software?  
• Can you go onsite to a prospect and use/leave SQL Server in a demonstration environment for 3 weeks, so they can test your software?  

While you may not run into this issue every day, this is becoming a much more common licensing issue. The Lady Licensing Blog did a great job of addressing this, so I thought I would give her some recognition for the post and of course, add some of my own thoughts on the subject. 

So here goes. 

1) Check your License Agreement.  While I am sure you had thought of this, I wanted to remind you, as this is where the rubber meets the road. It is ok to look at an FAQ or other online guide, but you should make sure that the actual license agreement specifically allows you to perform the specific demo and test activities (especially offsite). The Lady Licensing Post  addressed this issues in her post (with a useful chart AND the license wording). 

2)  An Internal Use License is Not Enough. The key here is you need the specific right to use the third party software offsite, and specifically for "End User Testing," "End User Demonstration," etc. This specific wording is addressed in her blog, but I thought I would reproduce it here as it is super important. 

3) Follow the Rules and You Should Be In the Clear. 

So using the language/example above, you can use the software for:

(a) Internal Testing and Demonstration. Really not big give by the vendor, but nice to have it clearly described. 

(b) Demonstration Purposes where you Retain "Control and Possession."  This is great, as it means you can take the software offsite, but you have to retain control and possession. 

(c) Trial for End Users.  If these 3 conditions are met (i) 120 day limit, (ii) removal after 120 days, and (iii) have an agreement with the end user. 

So long story short, these are the kinds of things you should think about, when you need to use third party software for demonstration or testing purposes (especially offsite). Read your vendor's agreement and dissect it as outlined above, as the keys to your rights should be in langauge like this. Oh yea, talking to a software attorney is probably a good idea too (but you knew that already).   

Resource:

Lady Licensing Blog Post 

Microsft (Partner) Licensing Benefits FAQ

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. 

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. 

I will definitely not bore you with the long and detailled facts in this case, so let's get to it. 

Key Takeways: 

1) If you want copyright law to protect you, then use copyright wording in your exclusive license grant.  

• Ok that was a mouthful, so let me explain. There are generally 6 exclusive rights a copyright owner has (ie. reproduce, distribute, create derivative works, publicly display and perform, etc.) and these rights need to be used or refered to in the license grant, to seek protection under the copright act. 

2) If too many rights are retained, then you may not receive an exclusive software license. 

• This actually happended in this case, as the court decided that too many rights were retained by the grantor for an exclusive license to be granted. This makes a lot of sense, as if a party says I grant you an exclusive license but then retains rights that are inconsistent with exclusivity, then the exclusive license should not work. 

3) Typically exclusive licenses are granted for certain territories, fields of use, or media. 

• Yes, typically exclusive rights are granted for certain territories (example, US only), fields of use (example, for only the insurance industry), or media (example, print) so think of drafting them this way. 

So next time you are working on an exclusive software license, you may want to review this case, as how the exclusive license grant is drafted really matters. 

Reference: 

Full Case on Google Scholar. 

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. 

You may have already heard of this open source license, but if not, here are a few things every SaaS company needs to know about the Afferro GPL or AGPL (at least from the perspective of an open source attorney).

1) If you use AGPL'd code or modified code in your SaaS offering, you need to make the source code available.

• Yep, this license requires that if provide the AGPL'd code 'over a network,' you must make the source code available (unlike the GPL where if you modify the code but do not provide it externally (i.e. do not distribute it) you do not trigger the source code requirement).

2) What does the GPL say again?

• It is generally considered that SaaS companies that provide their service over the Internet/network (but do not require the user to download the code) are not 'distributing' the code. As a result, using the GPL'd code in a SaaS offering does not necessarily require disclosure of the source code (this is called the ASP exception).

2) Where does it actually say this in the AGPL?

• There is a new Section 13 of the AGPL:

Ok so this is not that hard to remember: if you use code under the AGPL in your SaaS offering, you need to take seriously the source code disclosure requirements, as the rules are very different from the GPL (just a reminder from an open source law firm).

Resources: 

• AGPL V3.0
• Why the Affero GPL
•  List of AGPL Web Applications

As you know, software license agreements contain restrictions (i.e. things you cannot do with the software). Some of them are pretty common (e.g. don't reverse engineer or decompile the software or don't let a third-party use the software) but others are pretty unique. Two very recent big name court cases demonstrate that even the unique restrictions are usually enforceable; let's take a quick look. 

Case #1: In this case Blizzard Entertainment (the folks that make World of Worldcraft) license agreement has a very unique restriction (see below). 

Without taking you through the whole boring details of the case, the court essentially said that this restriction was enforceable and MDY (the company that made a 'bot' that allowed users to advance without actually playing the game) breached the license agreement. Oh yea, MDY also made around $3.5 million from selling the software that performed this task. So not only did MDY make software that violated this restriction, they also profited from it in a pretty big way. Court really don't like this. 

Case #2: NEON Enterprises sued IBM regarding certain restrictions in the IBM license agreement (actually NEON was alleging that these restrictions did not exist). NEON made software that allowed IBM customers to move their workloads around more freely, and was making $ this way. IBM disagreed and said that their customers are restricted from doing this. It seems pretty clear to me that IBM stated in its license agreement that the IBM customer can only use certain workloads on certain processors. It appears that this was enforceable, as at the end of the lawsuit NEON agreed to a permanent injunction withdrawing its software from the market and actually giving the source code to IBM. 

Here is some wording from the court order in the case. 

License Restriction Takeways

• If you are licensing your software and there are unique restrictions you need to protect your software, then think about adding those restrictions to your software license agreement. 
• Be careful with restrictions or capacity limitations in software you license, as courts sure seem to be enforcing them.

Q: Are software license restrictions always enforceable?

A: Actually no, as for example clauses that prohibit customers from publishing benchmark tests may not be enforceable. Here is an article about it. 

RESOURCES: 

Wiki Post on MDY vs Blizzard

Summary of the NEON vs IBM Lawsuit. 

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. 

The Federal Trade Commission (aka FTC) has a rule called the Negative Option Rule, which I really think every SaaS and software company should know about. 

The definition. 

Negative Option means – when someone 'fails to act' (= silence) means they accepted a contract. 

Q: Why Does the FTC Care?

A: Well, some companies use this concept to trick consumers into paying for something, without knowing the financial and cancelation terms (nothing you would do, of course). 

Here are the FTC's 5 Principles: 

1) Disclose the Material Terms of the Offer in an Understandable Manner. 

2) The Appearance of the Disclosure Should be Clear and Conspicuous.

3) Disclose the Material Terms BEFORE the Consumer Pays for or Incurs the Financial Obligation.

4) Obtain the Consumer's AFFIRMATIVE CONSENT to the Offer.

5) Don't Impede the Cancelation Procedure.

Let's Look at Some Examples: 

• bundle one service/product, with another service/product which auto-renews each month with a charge. 

• trial, which converts to a paid service. 

• service that auto-renews, without notice (your SaaS service or support renewal?).

Here is a screenshot from the FTC.

1) This version looks compliant (you have a choice to accept it or not).  

.  

2) This version does not look compliant (where is that specific consent to it, and it is kinda hidden over there on the right side?)

So think about this issue, if you are ever using your customer's silence to accept a renewal or a bundled offer.  Quite frankly, I think this is a good business practice, so you may already be compliant (but re-read those 5 principles above, because they are a great checklist!)

Resources:

1) Here is the FTC's Entire Report on Negative Options.  (72 pages) from January of 2009.  

2) California has a new law on this too (so you California based companies should take a read.) 

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. 

The simple answer is no, don't do it. Ok, let me explain.

Background: Where is this whole idea even coming from in the SaaS law or software law regime? Many customers are counseled or taught (BTW, there are lots of companies teaching your customers how to negotiate and buy from you) to send out long RFPs that ask for the world (lots of detailed questions about your solution . . . more information than they probably need), and then when it comes to the contract stage they too often demand that your whole RFP response should become part of the final contract. Well, I think that is a really bad idea, and here are 3 reasons why.

1) RFP Responses = Marketing Material. These responses were not written or intended to be inserted into contracts. If you really think about it, when you wrote the response you had your marketing hat on; you were telling them how great your product was. But were you thinking you were writing the contract? Probably not. Marketing material has a purpose, and that purpose is not contractual (it is more about education and inspiration).

2) Contracts  = Rights, Duties, Etc. ≠Marketing Material. If you said in your RFP response that "…this software is the best software that does x…" should that become part of the contract? Absolutely not. Have you ever heard of the legal term 'puffery'?  Well it is a legal term that describes those vague and optimistic terms that should not be legally actionable, and should not be relied on (i.e. they are general marketing terms and not contractual terms). So, if these type of words from your RFP response become part of the contract, then I think you are begging for a lawsuit.

3) Good Luck Trying to Book the Revenue. Most of the accounting rules around revenue recognition look for consistency and predictability, and if you start including all these different and varied RFP responses in your contracts, then I think you are probably killing that consistency and predictability. Are you selling a custom solution or a general solution that everyone really gets the same thing? If it is the former then I understand the request to address some of the RFP responses in the contract (re-written in another form), but most SaaS companies (at least most of the ones I have worked with) are providing the latter . . . a general solution in which everyone gets the same thing.

So long story short, try super hard not to include your RFP response into your customer contract, as 1) that was not the purpose you wrote it for, and 2) you are probably looking at some revenue recognition problems if you do (i.e. not a good thing). Think about this folks, as this is coming up more and more, and quite frankly I think it is somewhat of an RFP trick (that I don't want you to fall for). This is SaaS Law you need to be aware of.

Resources

Puffery as a Defense to a Lawsuit.

Another Puffery Article.

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.

A very recent case ruled that the parties conversation on only IM changed the contract, even though there was nothing actually signed to reflect the change (as a software licensing lawyer, I am always looking for cases like this for you). Does this sound like a crazy result? Actually not, so let's run through the actual IM conversation, the legal logic, and what you can learn from this case.

1) Here is the Conversation (that changed the volume commitment under the contract).

That is it. 'Awesome' was interpreted as yes I agree to 'No Limi't on volume.

2) Here is the Legal Logic.

The court essentially said that the parties went through an 'offer and acceptance process' and changed the volume commitment. Where is the signed document you say? Well, there is none, but there is an offer (by typing 'NO LIMIT') and an acceptance (by typing 'awesome').

3) Here is What You Should Remember.

The courts in the US are now starting to get more and more comfortable with contracting via electronic means (email or IM), so don't assume anymore that you have to have a written signed document to change a contract. How do you avoid entering into contract (offer and acceptance) via email or IM?

1. Don't commit to things in a email/IM, and use more non-commital language (i.e. "that is interesting," "let me talk to my boss," "let me think about it," or "not sure … let me get back to you" VS.  "yes I agree," or "we have a deal"), and
2. Clarify in any email/IM trail that you still need a written contract to formalize the deal, and that there is no contract/agreement until then. Intent always matters, so if you do not intend to be bound then say that.

So hopefully you are getting the message that things are a changin, and so be super careful about how you communicate via email/IM regarding commitments.  Courts are starting to look at these electronic communications and have already construed them as a contract (at least if they look like a 'legal offer' and 'legal acceptance.')

Resources.

Offer and Acceptance Basics

The Law School Summary: Offer and Acceptance

The Actual Court Order and Conclusions of Law.

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.

I had a call the other day with Tim Johnson of Sand Hill Finance, and thought you should know about these folks. Their offering is quite unique in the SAAS and software world. Here is an excerpt from our conversation:

Me: "What do you guys do, because I am not sure I get it?"

Tim:  "Sand Hill Finance provides revenue-stage software companies with NON-DILUTIVE growth capital for SAAS, traditional license models or cloud companies."

Me: "What is a typical driver for a SAAS or software company using your services?"

Tim: "Software firms that require capital to meet milestones or increase valuation PRIOR to an equity round."

Me: "What is the profile of a company that could use your service?"

Tim: "A company that has a strong sales pipeline, but insufficient cash to execute. Typically, these companies are 'not quite bank fundable'."

Me: Why did you start this business?

Tim: "As a former turnaround CEO and VC, I saw the need for a NON-DILUTIVE, simple capital solution for growing software firms. Sand Hill Finance provides a unique solution, with funding within 1-2 weeks."

Note to Self: Maybe these folks can finance that 6 figure contract I  just received, where the customer is paying over 3 years for my SAAS solution!

So there you have it. This company has a super unique service, and this is something that you should be aware in the SAAS and software world, as you or your friends in the industry may need it.

Resources:

Site: www.sandhillfinance.com

FAQ: http://www.sandhillfinance.com/faq.htm

Contact: Tim Johnson – email: tim@sandhillfinance.com

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.

As you may have heard, Google settled with the Federal Trade Commission regarding its rollout of Google Buzz and its alleged privacy violations during that rollout. There are a few SAAS privacy or software privacy tips here, so I have tried to outline/simplify them for you.

1) It is All About DEFAULT Privacy Settings. Think about it this way, if you add a new feature to your SAAS service where you connect customers/people/partners, etc. who submitted information subject to your privacy policy, you need to think about whether this feature is by default on or off (open or closed, enabled or disabled . . . you get the idea). I generally think that you should turn these off initially, and then educate your customers why they may want to use that new feature (i.e. it should be their choice). Well, Google got this wrong and opened up Buzz to gmail's contacts by default, and caused all kind of issues.

2) What Google Learned About its Privacy Policy (and you should know). Most privacy policies state that information subject to the policy will not be used for a purpose other than for the purpose for which the information was disclosed (translated into English, if a customer provides a company registration data then the data should only be used for registration purposes, without that customer's consent). Read your policy, because it may say something like this. If it does, make sure you know what it means, before the FTC comes a calling.

Here is the actual text from the Google Privacy Policy.

3) Appoint Someone in Charge.  I bet you this privacy blunder occurred at Google, as the left hand did not know what the right hand was doing (i.e. their in-house privacy attorneys were probably not aware of the details of the Buzz rollout). You really don't have that excuse, as unless you are a super large company this mis-communication should not happen. For a SAAS or software company, even if you don't have an in-house attorney (which of course most don't), you can appoint someone to be in charge of your privacy policy, which can really help to ensure you are complying with it. Maybe someone in the marketing department?

As you can see this is not that hard, but at least learn the basics of what is going on in the privacy regulatory world, as a simple change of default settings (opt in or out)  can cause the Federal Trade Commission to take action against you (not a good thing).

Resources.

FTC Press Release

FTC Complaint

Full Detail of the Settlement with Google from the FTC's Website (only 9 pages, so you can read it in a few mins).

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

There are many different places to go for negotiations training (in general), but where is a great place for learning about the art of software negotiations with customers, partners, etc. I highly recommend the Program on Negotiations at Harvard. I have attended some of their seminars, read some of their books, and have found that there is no better methodology for software customer and partner negotiations (from the perspective of the software vendor for say their software or SAAS contract negotiations). You ask why the PON is great, well let me elaborate.

1) Software Negotiations are Unique. These negotiations are unique as,

• you are selling something that is by definition intangible,
• a general matter software transactions are (i) long-term (i.e. it is not a one shot-deal) and (ii) co-dependent relationship (i.e. you each need each other over time) negotiations, and
• you are generally dealing with super smart people on both sides of the table, who are technically savvy too (i.e. BS will not get you very far).

2) Transparency and Honesty are the Key. I have negotiated in many different industries over my nearly 20 year legal career, and I have not found any other industry that requires more honesty and transparency over the long haul than this industry. Every software vendor wants their customer to understand how their technology works, what their revenue model is, and what problem it is solves (and doesn't); so communication and education are super important. Now selling vaporware is not the way to do it (even though it has been done in past and probably will still be done), and the courts have shown that when this happens you will pay (in a big way).

3) A Collaborative Negotiation Process Works Best. There are hundreds of different negotiation styles, but I think this industry demands a win-win negotiations process. This is where the Program on Negotiation at Harvard comes into play, as this is core to every part of their program.

Take a look at their curriculum of training classes, as I think you will find a few that will resonate with you or address a problem you are having (from 'Difficult Conversations' to 'General Negotiation Training for Senior Managers'). If it is not for you, then consider sending your head of Business Development or Sales, or CFO, as they may need to build their negotiation skills.  In my opinion–for the software and SAAS industry–this is the place to go to get trained on how to negotiate.

Resources:

Advanced Negotiations: Difficult Conversations Training

Negotiation Training for Senior Executives

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

A recent survey of over 358 reported trade secret cases (from 1995-2009) has some great nuggets for every software or SAAS company looking to protect its SAAS trade secrets and software trade secrets (something you should be doing, by the way). Without going into the legal nitty gritty (which I know you want me to skip), here are 3 takeways (after I define 'trade secret').

Q: What is a Trade Secret?

A: Long story short, a trade secret is a business secret that gives you a competitive advantage by remaining secretive.

• The owner must prove that it took 'reasonable measures' to keep it a secret (if you do this then the law (by statute) will give you some great protection and legal remedies). Examples of trade secrets: source code, customer lists, business and strategy plans, and employee lists.

Ok, here is what you can learn from this.

1) WHO are the Most Common Misappropriators (i.e. people that take your trade secrets without your permission)?

1. Employees
2. Business Partners

Together, they add up to 93% of the misappropriators. [see page 68 for more details] Yep, people you know and once trusted!!  Think about that one. A really recent TechCrunch article shows that now the trend is that un-known parties are looking to steal your trade secrets.

2) What do They Usually TAKE?

1. General business information (e.g., customer lists)[litigated 70% of the time], and
2. Technical business information (e.g., software) [litigated 30% of the time].

3) What are the Best Ways to PROTECT your Trade Secrets?

1. Confidentiality Agreements,
2. Computer and Physical Protections (e.g., passwords or restricted access), and
3. Confidentiality Education and Restrictive Markings (marking things as 'confidential information of [your company],'  'internal use,' 'trade secret,' etc.).

Oh yea, I forgot to tell you that the reported litigation is exploding on this front, and the chart is up and to the right (and not the kind of up and to the right you want to see).

So, please think about this, as if you are not taking 'reasonable measures' to protect your trade secrets then good luck trying to stop an ex-employee or business partner from wrongfully taking or using them. Think about this folks, as these may be the keys to your castle!!

Resources:

Here is the law review article with the survey (assuming you have time to read it) Link

Practical Definition of a Trade Secret from the US Dept of Labor Link

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

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.



I finally found a really useful working paper and law review article written by some European open source attorneys and the Free Software Foundation Europe on linking issues and the GPL license. I thought I would share some of the highlights with you as it is really hard to get some good practical guidance on open source legal issues. As a bonus, this perspective tries to marry the legal analysis with the technical analysis. Take a read!

(1) Derivative Work or Compilation (copyleft obligations)

• Static Linking (GPL'd code combined with your code in one executable at build time)
• Macro/Template Expansions (embedding GPL'd code into your code)

(2) Close Call (aka, it depends)

• Plug-ins (to extend functionalities of other programs)
  • depends on external factors (I added a few of my own here):
    • dependency/independency of your code;
    • communication protocols/sharing resources;
    • copying of API host code/no copying of API host code;
    • core functionality not subject to copyright/functionality subject to copyright; and
    • existence of other libraries with the same function.

(3) Independent and Separate Program (no copyleft obligations)

• Dynamic Linking (calling and using library only at run-time; (no GPL code copied, modified, translated or changed . . . I added this part from Larry Rosen's view (see below) on it))
  • remember to look at the above external factors as it could become a derivative work if the facts change
  • oh yea, I moved Dynamic Linking to this section as I think it fits in here more than Close Call
• Interprocess Communications (remote procedure calls)
• System Calls (core operating system resources)
• Interpreted Language 'Scripts' (not compiled, executed by interpreter, no third party code incorporated)

So long story short, this is an evolving issue and I don't think the definitive work has been written, but don't let that stand in your way of learning more about it. As an open source attorney and proprietary software attorney, I thought you should be aware of this, as these folks did a fantastic job with this working paper and law review article (see below).

Resources:

Working Paper on Software Interactions and the GNU Public License (July 2010)

Brian, Malcolm (2010) 'Software Interactions and the GNU Public License,' IFOSS L.Rev, 2(2), pp 165-80

Larry Rosen's view on Dynamic Linking.

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

Have you thought about which parts of your SAAS customer contract commitments should be a short-term, and which parts should be long-term? Well, if you have not thought about it, then how about we do that now.

What Should/Could Be Short Term?

The key with SAAS models is that most* are not perpetual (aka forever) models (like a typical software licensing model where the customer receives a perpetual license to the software), so things are supposed to change along the way. The functionality you provide may change, along with the feature set. Oh yea, this is pretty typical and actually expected for SAAS companies, so don't feel bad about it. So the takeaway here is to think about keeping your commitments as to functionality, features, support  and pricing short in duration (i.e. maybe a year or less and not multiple years). Why you say? Well, things could change, so be careful what you commit to for long periods of time. By the way, if you contractually commit and don't' perform, then that will likely turn into a 'breach of the contract' on your part (aka not a good thing).

• Examples of Long-Term Commitments Requested by Customers: price caps, support commitments, feature and functionality commitments, etc.

What Should/Could be Long Term?

Well in the SAAS model I am not sure there are many really long-term commitments, as the customer is receiving/buying a subscription based offering (something that is time bound). As  I scratch my head to think about what long term commitments you could/should make, I really can't think of any. In fact, maybe that is the answer:  you should not make any really long-term commitments as that is not the model (if you do make any long term commitments, make sure you think it through as things will change). As I said above, the issue of long-term commitments comes up very frequently when licensing software in perpetuity as the customer is paying you for something (and buying something) they could use forever (they are thinking super long term).

So think short-term commitments in your SAAS contracts, and keep the flexibility in your model (to the extent you can). That is what SAAS is all about!

Resources:

Oracle's Long Term Commitment to Support Siebel Products.

Ubuntu Long Term Support Commitment

* Exception: I have seen and worked with some SAAS companies which provide really long-term solutions to their customers, so they will have to address long-term commitment issues, but the key thing is even those are not perpetual models (aka forever).

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

Hey this used to be an easy answer (you owned them and you had possession of them), but these days of LinkedIn, Twitter, Facebook, etc., it is not so simple. Here are some thoughts on this software sales compensation issue.

1) Where are Your Sales Leads Stored (aka who has possession of them)?

Old days = CRM (internal) software and a Rolodex (internal, but portable) (yep business cards are not dead)

Now = CRM (internal), Rolodex (internal, but portable) and LinkedIn, Twitter, Facebook, etc. (external)

2) Solution?

• Create  a Policy To Address It
  • Clarify that sales contacts whether stored internally or externally are the property of the company
  • Clarify that this applies to social media accounts (such as LinkedIn, Twitter and Facebook)
  • Add other clauses to address this issue the way you want to address it (your company may want to deal with this differently)
    • FYI: some companies even prohibit employees from connecting with sales leads and sales contacts (i.e. they cannot accept the invitations) via social media. In other words, the sales reps have to reply that they cannot connect. Sounds tough, but it is true.
• Address it in Your Employment Agreements
  • Same as above
  • Also prohibit sales reps from soliciting the leads after they leave (it may be hard to police though)
  • Non-competes in employment agreements may be more important now, as the worst case scenario is if a sales rep goes to a competitor with all the leads and sales contacts.

At the end of the day, technology and the law don't work so well in this situation. I think the problem now is that getting leads and staying in contact has become an external social process.  This post is not the definitive dissertation on this issue (as this is an evolving issue), but I suggest you think about this in advance, as after the fact you may be dealing with a situation where a sales rep takes or things he/she can take all their leads with them (as they are stored externally).

Resource:

Here is a recent summary of some litigation in this area. Worth a read!

Disclaimer: This is not legal advice, and no attorney client relationship is formed. It is provided for informational or educational purposes only.

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.

1) Retain Ownership of Data. This is covered ground, and nothing new to most people. I think all cloud agreements should address this issue as clearly as possible, so everyone knows who owns what, and how and when data can be returned to the customer.  Oh yea, there is already litigation on this issue, so this is an important issue! Recent Case (see page 4). (Address in Cloud Agreement)

2) Service Level Agreement. This one too is nothing new, as service level agreements have been around forever. I think the SLA should be in the cloud agreement, and not left to a policy statement. (Address in Cloud Agreement)

3) Notification of Changes to the Service. This is a great idea, and cloud vendors really should communicate about (but let's add material or significant) change to their service (i.e. ones that would impact their customer or that they would want/should know about). I think the key here is for the vendor to be as transparent as possible, so there aren't any missed expectations (that is what often leads to disputes and litigation). This too is a communication or policy thing, so it does not need to be in the cloud agreement. (Address via Communication)

4) Understand the Technical Limitations. Gartner is suggesting here that the vendor educate their customer on architecture and technical issues that they should know about. This seems like a no brainer, and is something that every cloud vendor should do as part of selling and supporting their service. (Address via Communication Before and After the Sale)

5) Understand the Legal Requirements of Jurisdictions Where Service Provider Operates. In essence, Gartner is saying that the cloud vendor should tell their customer where their data resides, and handle any legal and privacy issues associated with the transfer of customer data. This seems like a reasonable expectation, and also sounds more like a policy statement (not something that necessarily needs to be in the cloud agreement . . . other than some type of vendor warranty  that "they will comply with all applicable laws regarding their performance under the agreement"). (Address via Communication Before and After the Sale)

6) Know the Security Process the Provider Follows. While this is usually not a contractual issue for a cloud agreement, I think it should be a policy statement wherein vendors communicate what they are doing to secure the customer data. I actually think the cloud company I use for my legal billing does a great job of this in their security statement (here is their statement on security). (Address via Policy Statement)

7) Understand and Adhere to Software License Requirements. The issue here is that software vendors should communicate if they allow their customer's to move their licenses from an on-premise license to the cloud. I find that this is more of a policy statement by a vendor, but it should be documented (if the transfer or use/access is allowed) in an addendum or some type of legal agreement. (Address via Communication and in an Amendment)

All in all, I think this is a great current and short list of many of the important issues to consider when working with a cloud vendor. However, it seems like these lists keep changing and everyone (including me) is still trying to figure out what the most important issues are, and how to address them appropriately.

Resources (lot's of these Bill of Rights things out there!):

CNET Cloud Computing Bill of Rights.

Altimeter's: SAAS Bill of Rights.

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

"Naked Licensing" is in essence a legal defense to a trademark infringement claim, and you absolutely should be aware of it as the consequences of not knowing can be really grave (aka a big deal).

Ok did you get that part about 'abandonment of the trademark.'

Now that I got your attention, here are 3 things to remember to help avoid this.

1) Don't Let Anyone Use Your Trademarks Without a License Agreement. Hopefully I said that clearly enough, but that is the best way to avoid this bad outcome. The trademark license agreement should (at a minimum) expressly state that any use of your trademarks are subject to your trademark guidelines (i.e. supervise their use of your mark), and make sure you take steps to ensure that your trademarks are used in an appropriate manner with the associated goods or services. You can embed this language in any software or SAAS partner agreement.

2) Remember What is At Risk Here! Think about it, you develop your trademark (maybe your company name or logo) and people associate your business with that name or logo. However, if you don't take certain protective measures when allowing third-parties to use your trademarks you could abandon the mark ( = you lose it).

3) Don't Scare Me With This. Does it Really Happen? Absolutely. Here is a case from November 2010. Long story short, the owner of the trademark rights to "Freecycle" (see above) let other affiliated groups (are you seeing a connection to your business?) use their trademark without a written trademark license agreement, without exerting control over the mark and associated services, and simply said in an email " . . . just don't use it for commercial purposes." That was it. The court found that there was no written contractual control over the mark and no actual control, so the result was that the Freecycle mark has been abandoned (because of naked licensing). What that means is they could not stop a Freecycle affiliate from using the mark in any way they wanted. It does not get any more real, relevant and recent than this folks!

So every software or SAAS company out there should sit up and take notice of this issue, as I know you have trademarks (you need to review your processes for allowing partners, resellers, etc. to use your trademarks). You can easily avoid this outcome, if you understand naked licensing and take measures to avoid it (even if it is not as sexy as it sounds)!

Here is a copy of the court opinion (if you want to read the nitty gritty details).

Resources: Example of Really Good Trademark Guidelines.

Microsoft Trademark Guidelines.

Symantec Trademark Guidelines.

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

Background: TomorrowNow was a third-party support company which SAP bought in 2005. TN claimed to provide support for certain Oracle products (for less than 50% of what Oracle charged), and SAP tried to use their business model to lure customers away from the Oracle products and to the SAP products (it was called the 'Safe Passage' program . . . which (funny enough) wasn't safe/legal after all).

3 Takeaways: Here are the 3 things you should not do to your competitor, now that this case has been decided (all based on the last Oracle filed petition in the case).

1) Don't Download More of Their Software Than You Have License Rights To. Oracle alleged with great specificity and detail how SAP downloaded more software through its TN subsidiary than it had license rights to.  This may seem very basic, but you don't want to be in possession of more of your competitor's software than you are validly licensed for.

2) Don't Ignore Their Terms of Use on Their Support Site. Before logging into the Oracle customer support site, the TN employees had to agree to the Oracle 'Terms of Use' (i.e. a contract). This contract prohibited things like downloading more software that you have rights to, and using Oracle software for the benefit of third parties. It appears that TN ignored and disregarded this contract  (i.e. clear warnings/instructions from Oracle).

3) Don't Assume Your Actions are Anonymous. Oracle tracked all the TN downloads, and was able to show that before certain customers moved their support to TN they downloaded lots of software from the Oracle customer support site (much, much more than the Oracle customer was licensed for).  This made it really easy for Oracle to prove that what SAP did was wrong and in violation of their copyrights. 

BTW: The opposite is true too, so to help prevent competitors from taking your stuff:

(a) make sure your license grant and restrictions are super clear (so your competitors know what they can and cannot do with your software);

(b) have 'Terms of Use' on your support site; and

(c) track your customer's downloads of your software under support.

If you do this and you think a competitor is violating your license rights, then you may have a good case to go after them for big $ (like Oracle did).

So long story short, you should not use a person's property without permission (something you probably learned in kindergarten) . . . especially when they are your competitor (something you probably learned once you entered the business world). Also remember that if you do the consequences can be quite grave, as this is the largest software copyright judgment ever.

Here is the 4th Amended Complaint, if you want to read the details.

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

Background: Without going through the long details, 2 top level employees of Starwood who worked on developing the W brand of hotels went to work for Starwood's competitor (Hilton Hotels), and apparently took with them 100,000 documents. Hilton was planning on creating a similar boutique hotel brand to the Starwood W Hotels, and probably thought that hiring these Starwood employees would help them grow into the new market for boutique hotels. Well long story short, Hilton now cannot (by court order) develop–for 2 years–a competitive boutique hotel chain, must have federal monitors supervise their strategic decision marking, and (according to the NY Times) must pay Starwood $75 million (all of this before they even started competing with Starwood). All I can say is WOW. This is unprecedented, and simply started from hiring 2 Starwood employees.

Ok, so what do you need to know about protecting your confidential and trade secret information (at least from the perspective of a company that could lose its key employees to a competitor).

1) 'Identify' and 'Mark' Your Confidential and Trade Secret Information. This case would not have gone as well for Starwood if they had not marked their confidential and proprietary information and restricted access to it. Think about it, once your documents leave your site how does the person in possession of it know that it is your confidential or a trade secret information? In a way–at least for argument's sake–it may seem like documents lose their character once they leave your site if they are not properly marked (in terms of ownership and their confidential nature)!

2) Think About Your Business and Marketing Plans (not only Source Code). What is really unique about this case is Starwood had developed a 'Brand in A Box' (brand handbooks, marketing plans, and immersion plans), and properly marked and protected this material. Lots of software and SAAS companies describe their key business and marketing strategies in this manner, so make sure you mark them and restrict access to them (as Starwood did).

3) Have Exit Interviews With Your Departing Employees. The goal here is to make your departing employees conscious about what the company owns, and that they should return or destroy all company information (i.e. you don't want them to think that because they created it that they own it, or have the right to take a copy with them).

4) Confidentiality Agreements. Use confidentiality agreements where appropriate, as this helps to prove that you took all reasonably steps to protect your important confidential and trade secret information.

Now you can say–and I have heard this argument 100s of times from software executives–that after taking all these steps the Starwood information was still disseminated to a competitor. Well, if Starwood had not identified and marked its information, held exit interviews with its departing employees, and consistently used confidentiality agreements, they would probably not have come out so well in this case.

Think about it this way. Imagine if your significant competitor,

(a) cannot (for 2 years) compete with you in a very important growing market segment,
(b) must have federal monitors on-site reviewing their strategic decision making, and
(c) must pay you $75 million (even before they start to compete with you).

If you could put your competitor in this type of straight jacket by taking the above precautionary measures, then maybe you should consider them for your software or SAAS company! Hopefully you get the message, because departing employees sometimes go wild when they go to a competitor.

Resources: Do departing employees go wild in the tech industry too?

CA vs Quest Software – employees go to Quest Software

SiRF Technologies – employees leave to allegedly start a competitor

Intel vs AMD – employee leaves to go to AMD

Goldman Sachs – departing employee takes source code

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.

If you operate a software based business you are likely using some open source code in your software. There really is nothing wrong with that, as it is really common now (and probably a best practice). But what is your process to review and track this code, and the associated license terms? Well, here are 3 thoughts from a software licensing lawyer that may help.

1) Written Policy. Think through (a) what situations makes sense for your company to use open source code (maybe with functionality that is not core to your offering), and (b) what type of licenses you will allow and won't (maybe try to avoid GPL licenses if you distribute your code to your customers). For example, you may allow licenses which only require notice (i.e. attribution) that the code is distributed with yours. Oh yea, don't forget to write this down in a policy and let all your developers know about it.

See below for an example of attribution.

2) Tracking Process. Tracking where you use the open source code and the associated license terms is critical, and I suggest very easy to do (along the way at least). Your process could be as simple as a spreadsheet with the name of the open source code, listing of which of your products (and versions) it is included with, any requirements of that license, and a copy of the license agreement. This tracking process is super simple if you implement it along the way, and really hard to re-create if you have to do it years later when someone (an acquiror or the CEO) needs to know what open source code is embedded in your product.

3) Annual Review. While many people overlook this, whoever is in charge of your open source process/policy (and I suggest you have one person in charge who owns this policy), should annually review that your developers (including any developers that are actually contract developers) are aware of and follow your policy.

Look I could make this a lot more complicated, but I find that most small software companies need at least these three basics requirements and not the 25 page open source policy.

Great More Detailed Article on Developing an Open Source Policy.

Some Thoughts from a Microsoft Attorney on Creating an Open Source Policy

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.

Background: The book by Gary Noesner came out in September 2010 and is called Stalling for Time: My Life as an FBI Hostage Negotiator. It has all the kinds of things you would expect to find in a book written by the retired head of the FBI's Crisis Negotiations Unit (here is a podcast on the book from NPR): stories about estranged husbands holding their wives hostage, the Branch Davidian shootout in Waco, the DC sniper incident, etc. etc. But what is really interesting, and I think useful, are some pearls of wisdom regarding dealing with irrational people and people under lots of emotional stress. So here are a few things you may be able to use in your next software or SAAS negotiations.

1) Behavioral Change Stairway. I had never heard of this concept before, but it may be useful to you. This is how it works: a) you show interest, b) you respond emphatically (which leads to rapport), and c) only then do you attempt to influence. This makes sense, as during any negotiations with a customer, you need to show interest and listen to them, and then show them you understand their concerns and issues (you don't have to agree to them); only then can you attempt to influence them.

2) Key to Successful Negotiations. Mr. Noesner suggests that it is important to figure out a person's motivation, goals and emotional needs, and then to make use of this strategically. This is relevant too, as having a deep understanding of your customer's (and the person you are working with) motivation, goals and emotional needs can really help to close the deal.

For example, maybe the company has been burned by a previous technology vendor by not appropriately supporting the product. Even if you are the best negotiator, you may not be able to get past this issue as the customer feels burned and abused by that vendor, and they don't want it to happen again. You may have to carry this burden (in some way at least) in the negotiation, and be forced to address the issue.

3) Paradox of Power. Another interesting point is that the harder you push the more resistance you will get. I totally agree with this, and you should definitely remember this in your negotiations. Negotiations are very much about education, and not simply imposing your will on the other party.

4) People Want to Work with People They Like. You probably already knew this, but take this a reminder as the person negotiating the purchase of your technology has a lot more discretion than you probably realize, and if they like you and want to work with you, your deal is much more likely to close.

5) Active Listening. If you don't know what this is, basically it is repeating back to the speaker what they have said or otherwise acknowledging their statement/concerns. Try this, as it takes practice, but really works. Here is a short article that the author wrote on Active Listening.

While software negotiations are not as emotionally charged as a crisis negotiation, it would be worth your effort to try some of these skills if you are dealing with a difficult or irrational person on the other side of the table/phone (even if they are unarmed!). Practice this beforehand though. I plan to try these skills with my kids when they take my TV remote control hostage, as that becomes a crisis negotiation at my house!

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.

• SAP distributed and sublicensed certain AMC Technology software embedded with a SAP product.
• When the software OEM agreement expired, SAP tried to provide 'specific instructions to its customers' on how to use the AMC software with the new version of the SAP product, when the customers actually could not do this (the OEM agreement specifically stated that post termination SAP could only sublicense the AMC software with the 'then current version of the SAP software').
• SAP tried to argue that its customers could use the AMC software with the new version of the SAP software, but the court correctly said no way.

Ok, here is what you can get out of this case.

1) You Can't Grant More Rights Than You Have. This is a fundamental part of property law, and actually dates back hundreds of years to when people tried to grant more rights to buyers of real estate than what they (the seller) had (it is kind of common sense too). This is the first example I have seen where this legal concept was applied in the software OEM agreement world, so it is good to see that it is still true (at least in this context).  So remember, you can't grant more rights than you have, and as the recipient you can't get more rights than the grantor has.

2) Plain English Matters. This agreement was clear as can be, but SAP missed it. . .  thankfully the judge didn't.

SAP tried to argue that the customer had a perpetual license to the software and that this restriction did not apply to them. The court correctly disregarded this argument, and said the agreement is clear on this point… "the then current version of the SAP Software."   Remember, try to be clear on post termination rights in your software OEM agreements, as judges will read the agreement closely to figure out what you meant.

3) Take Ownership of Your Agreements. When you are negotiating a software OEM agreement (no matter which side you are on), dig in and don't simply outsource it to your attorneys. The details really matter, and things like what rights are being granted during term of the agreement and what rights remain after termination should be clearly described in the agreement (just like this one).   Remember to take ownership of the negotiations, as the terms of the agreement will matter . . . especially upon termination.

So next time you are on the receiving end of an software OEM agreement or the granting end, remember this blog post and don't forget to use common sense, as even in the intangible world of software you can't give someone something that you don't have!

Here is the actual court order, for you detailed oriented people.

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.

Most of it I am ok with (see all the yellow highlights), but what I have highlighted in red I don’t (or don’t understand).

(1) Choose Any Implementation Partner. While this sounds good on its face, there may be valid reasons why a software company does not want just anyone implementing their software (you know, training, expertise, know-how, confidentiality, competitive issues, etc.).
(2) Pay for Actual Usage. While this sounds good too, I think software companies should be free to determine their pricing models (plus reporting on actual usage would be really complicated/hard). Remember, that if the license is more restrictive the price for the license should/will be lower.
(3) Licensee Free to Share Modifications. As most software is not provided in source code this is not even an issue, but if it were, I can understand why a software vendor would not want this to happen (e.g. derivative works/extensions to their software could create other software products that the vendor would instead like to capitalize on . . . seems fair to me).
(4) Freely Transfer Software (regardless of site/hardware). Again, this should be up to the vendor to determine as part of their pricing model/strategy. Remember, it is all about price (flexibility that does not add real value may cost more than a customer wants to pay for).
(5) Speak Freely About It. The argument here is often software is treated as the confidential information of the software company, and so why should the customer be free discuss these kinds of things.
(6) Ensure License Equivalency. I am not sure what this is (and nothing came up in a Google search), so I am at a loss on this one.
(7) Unbundling of Support and Maintenance. Nice idea, but I think that should be up to the software company to decide, as they can/should determine their revenue model/strategy. Some companies do unbundle (e.g. Microsoft Windows) and others don’t (most commercial software products).
(8) Third Party Support. Great on first blush, but the practical reality is how can a third-party support someone else code (bug fixes, upgrades, new versions, etc. . . no source code access)? It just does not work (quite frankly I am amazed anyone tried it) . . . but maybe someone can prove me wrong. Ask SAP about it, as a court just ordered them to pay $1.3 Billion in damages for trying to do just that through a company they bought for $10 million.
(9) Define Functionality Replacement. I am not sure I understand this, but yes if the vendor is retiring a product it would be nice/good to tell your customer what key functionality they would need in a replacement (if that is what they mean by this).
(10) Resell Software. This I don’t get, as most commercial software is not transferable, as vendors don’t want to create a secondary market for their products (consumer software vendors usually allow it though). I think they should be free to restrict this.

So why do you need to know about this? I bet these issues will come up at some point during your software negotiations with your customers, so you should figure out your stance/response to these issues. I hope this helps!

Some other people commented on this too.

Deal Architect’s Point of View

Link to the Introduction of the LBOR in 2007

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.

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.