licensinghandbook.com » limitation of liability http://www.licensinghandbook.com The companion site to the Software Licensing Handbook Mon, 17 May 2010 15:07:13 +0000 en hourly 1 http://wordpress.org/?v=3.3 This Week on The Web 2009-10-04 http://www.licensinghandbook.com/2009/10/04/this-week-on-the-web-2009-10-04/ http://www.licensinghandbook.com/2009/10/04/this-week-on-the-web-2009-10-04/#comments Sun, 04 Oct 2009 14:32:08 +0000 Jeff http://www.licensinghandbook.com/?p=1203 These are the discussions that happened around the web this week – maybe you already read about them, maybe you need to again.  Come join the party on twitter (follow me here and you’ll participate in the conversation live.)

I also realized that many of you might have no idea what you’re seeing below.  Sorry.  These are “tweets”, 140 maximum character messages sent via Twitter.  Within the Twitterverse individual users follow others and have followers (think of it like overlapping Venn diagram circles).  To read a tweet, you have to wade through a bit of jargon used to make the most of the 140 character limitation.  “RT” for example, is shorthand for “Re-tweet” and the @____ is the username of some other individual on Twitter.  Combined together, then, “RT @_____” means that someone else wrote a tweet that I found important and I now want to forward along to my followers.  The URL’s are then also shortened by shortening services like bit.ly to make the most of the character limitation, too.  Lastly, you might see “hash” identifiers “#______” which are ways to tag tweets of a particular flavor for easy searching later and “<” which means that I am commenting on what came before it.

The Licensing Handbook Blog is the companion site to the Software Licensing Handbook. Covering licensing topics on a regular basis, Jeffrey Gordon attempts to offer advice, add humor and sometimes even a bit of wit to a practice that most people find abhorrent – namely, reading a contract from start to finish.  Follow me on Twitter if you want up-to-the-minute information on contracting, licensing, negotiation and the law.

]]> http://www.licensinghandbook.com/2009/10/04/this-week-on-the-web-2009-10-04/feed/ 0 Clear to Sell User Data http://www.licensinghandbook.com/2009/06/29/clear-to-sell-user-data/ http://www.licensinghandbook.com/2009/06/29/clear-to-sell-user-data/#comments Mon, 29 Jun 2009 17:00:33 +0000 Jeff http://www.licensinghandbook.com/?p=1026 When Clear announced their intent to terminate operations, the big question was: “What’s going to happen to each users’ private data (things like, um, fingerprints and background checks)?”

Now we know.  They intend to SELL IT!  This is why I harp on making sure that you have the proper provisions in your contract(s) for confidentiality, indemnification, information security and limitation of liability

To Clear’s credit, they are saying that they’re going to continue to comply with their pre-existing privacy policy – and that the data can only be sold to another TSA-approved traveler program.  But what if that program is run by an organization you wouldn’t want to have your personal details?*

Interestingly enough, however, this violates the terms of that agreement (as it existed when I pulled it from flyclear.com on June 29, 2009) – boldings are mine:

3. ADDITIONAL LIMITATIONS ON APPLICANT AND MEMBER PERSONAL INFORMATION
A. We do not sell or give lists or compilations of the personal information of our members or applicants to any business or non-profit organization. We do not provide member or applicant personal information to any affiliated or non-affiliated organizations for marketing.
B. None of the information that we collect may be used for any purpose outside the operation and maintenance of the Clear Services.
C. We would only disclose personal information about members or applicants if required to do so by law or legal process.

The termination of operation might be considered a “legal process” – but the way the language is written, 3.C. would not be valid as a result of the company’s dissolution.  Thus, they’re limited to 3.A. – which clearly states that they won’t sell the information to “any business.”  I wonder what the chance is now that they’ll only sell it to someone who’s TSA-approved.

*Not that the government doesn’t now already have your information as a result of the background check.  I’m just sayin’.

The Licensing Handbook Blog is the companion site to the Software Licensing Handbook. Covering licensing topics on a regular basis, Jeffrey Gordon attempts to offer advice, add humor and sometimes even a bit of wit to a practice that most people find abhorrent – namely, reading a contract from start to finish.

]]> http://www.licensinghandbook.com/2009/06/29/clear-to-sell-user-data/feed/ 3 Notes from the “I told you so” file http://www.licensinghandbook.com/2009/03/09/notes-from-the-i-told-you-so-file/ http://www.licensinghandbook.com/2009/03/09/notes-from-the-i-told-you-so-file/#comments Mon, 09 Mar 2009 14:32:26 +0000 Jeff http://www.licensinghandbook.com/?p=849 Well, it didn’t take too long.  C-Net reports today that Google inadvertently shared some Google docs files with folks they weren’t supposed to be shared with.

Lifehacker ponders whether this is a “minor privacy blunder”.

Meanwhile, Google is busy blaming it on the user (italics are mine):  “We’ve identified and fixed a bug which may have caused you to share some of your documents without your knowledge.”

Yeah, Lifehacker, this isn’t minor.  It never is.  Especially to those individuals who have data that was shared without knowledge.  Oh, and C-Net, you shouldn’t downplay this either – so while mentioning that lost laptops are a security risk, too, it doesn’t do anything to resolve the issue at hand.

Look folks, any breach of privacy, especially in a SaaS/cloud-computing environment is a HUGE problem.  Shore up your contracts today, please (confidentiality, IP indemnification, and exclusions for breach of confidentiality in your limitation of liability language).  Need help doing it?  Just give me a shout.

The current economic situation is encouraging many organizations to reconsider their current contractual relationships.  Contact me before your opponent does to find out how to make the most of your renegotiations.  The Licensing Handbook Blog is the companion site to the Software Licensing Handbook. Covering licensing topics on a regular basis, Jeffrey Gordon attempts to offer advice, add humor and sometimes even a bit of wit to a practice that most people find abhorrent – namely, reading a contract from start to finish.

]]> http://www.licensinghandbook.com/2009/03/09/notes-from-the-i-told-you-so-file/feed/ 0 Software Licensing Education Series – 300s Track Now Available! http://www.licensinghandbook.com/2008/09/15/sles300strackavailable/ http://www.licensinghandbook.com/2008/09/15/sles300strackavailable/#comments Mon, 15 Sep 2008 13:32:58 +0000 Jeff http://www.licensinghandbook.com/?p=320 Designed for the busy or on-the-go professional, the Software Licensing Education Series (SLES) is video-based training on the complete gamut of software licensing topics. Presented in a college-course level format, with topics increasing in complexity and building upon prior lessons, the SLES allows an audio-visual learner another way to gain knowledge on licensing topics.  Each video is approximately 20-30 minutes in length, so each Track contains about 2 hours of expert instruction in core software licensing topics!

The 300 Track videos include:
SLES 301 – Warranties
SLES 302 – Indemnification
SLES 303 – Limitation of Liability
SLES 304 – Services Issues 1

(400s-500s Tracks are currently in production and will be released shortly!)

Videos are formatted for a computer or portable video player (such as an iPod) and consist of a slide-show format with voice-over instruction, so you can even learn just by listening!

As promised, purchasers of the Second Edition of the Software Licensing Handbook are eligible for a discount on the purchase of a Track from the SLES.  When redeeming your free Software License Risk Matrix, you’ll receive a coupon code for the SLES via e-mail.

The Licensing Handbook Blog is the companion site to the Software Licensing Handbook. Covering licensing topics on a regular basis, Jeffrey Gordon attempts to offer advice, add humor and sometimes even a bit of wit to a practice that most people find abhorrent – namely, reading a contract from start to finish.

]]> http://www.licensinghandbook.com/2008/09/15/sles300strackavailable/feed/ 0 Limitation of Liability http://www.licensinghandbook.com/2008/04/28/limitation-of-liability/ http://www.licensinghandbook.com/2008/04/28/limitation-of-liability/#comments Tue, 29 Apr 2008 02:32:08 +0000 Jeff http://www.licensinghandbook.com/2008/04/28/limitation-of-liability/ A contract is an allocation of risk and liability limits are a huge bone of contention.

Vendors want to limit their liability to very specific types of damages:  1.  They want to only be responsible for direct damages; and, 2. They only want to be liable up to a capped dollar amount.  Generally speaking, this is acceptable (we’ll talk about the dollar amount in a second), as it’s a question of reasonability.

With respects to the types of damages (direct, indirect, consequentials, specials, etc), direct damages (in a very layperson definition) are those that are connected to the cause of the liability.  So, for example, if Person A steals from Person B, the cost of the stolen goods would be direct damages.  But, in the event that the theft led to Person B being unable to complete another business transaction (and thus negatively impacting Person B), that negative impact would be “consequential.”  You can quickly see that damages other than directs can be hard to quantify or calculate – and someone who would be liable for more than directs would not have a good way to understand their total portfolio of liability.

For dollar amounts, most people used to say that you could reasonably ask for 3x the amount “spent” under the terms of the agreement.  But to be fair to both sides, any amount I might recommend here isn’t a fair assessment of damages.  When discussing software deals gone bad, I typically want every penny I’ve paid over the term of the agreement returned to me – this is less an exact science of knowing the amount of future damage and more of an understanding of what it costs to replace software once integrated into an environment.

With respects to both limitations on liability (type and amount), customers should be able to get three exceptions:  A.  Indemnification Obligations (including both IP and general indemnity), B.  Breach of Confidentiality, and C. Gross Negligence or Willful Misconduct.  These three things, in my (supported) opinion, are eligible for ALL forms of liability and without any financial limit, either.  In almost all cases, vendors do not challenge these exclusions from the limits.  They recognize, as does the customer, that indemnification is only valuable when unlimited, that breaches of confidentiality have far reaching implications, and that willful acts shouldn’t be capped, either.

However, even a generous vendor is only going to allow themselves to be “on the hook” for indemnification for software that they licensed in the form in which it was licensed, or for certain types of damages.  Modifications to the software, for example, usually prevent indemnification to the extent that the infringement is a result of those modifications and not based on the unmodified software received from the provider.  However, in many instances, vendors rely heavily on talking the customer through various issues via phone or via e-mail and they provide a variety of bug fixes in numerous ways.  It is advisable to change any language limiting liability as a result of modifications made by licensee to read “modifications made by customer unless authorized by provider.”  This allows for the ability of the customer to make changes to the software at the vendor’s direction but not remove the vendor’s liability for the changes that are made.

In some cases, vendors are concerned that even this language is not enough protection as the customer might not follow the directions/instructions provided by the vendor.  If that is the case, language such as “modifications made by customer unless authorized in writing by vendor and such modifications explicitly conform to the changes contained in the written authorization” can be used.  The net result is that the customer should not be harmed as a result of following the directions of the provider with respect to their software.

Recently, I’ve seen some significant push-back on the limitations section – a desire to avoid the exclusions and reductions in the financial amount, as well.  I’m pushing back and I continue to use one of my favorite bad-cop/jerk phrases when discussing what will happen if the vendor breaches confidentiality (“I want to own your company.”).  What’s happening in your deals?

The Licensing Handbook Blog is the companion site to the Software Licensing Handbook. Covering licensing topics on a regular basis, Jeffrey Gordon attempts to offer advice, add humor and sometimes even a bit of wit to a practice that most people find abhorrent – namely, reading a contract from start to finish.

]]> http://www.licensinghandbook.com/2008/04/28/limitation-of-liability/feed/ 1