Society for Information Management (Photo credit: Wikipedia)

Best Practices for IT Agreements:  What Lawyers Can Tell Us

Mark is on a panel of experienced IT lawyers discussing “Best Practices for IT Agreements:   What Lawyers Can Tell Us” on Wednesday, May 29th at the monthly chapter meeting of the New York Chapter of the Society for Information Management (SIM).  The event is at the 21 Club at 21 W 52nd St in Manhattan.

Registration is required.  To register and for more information please visit:  http://www.nysim.org/events/next-event-details

The panel will discuss:

• Traps for the unwary in contract negotiations and what to do about them
• Optimizing the role of the IT staff in creating agreements
• Why owning IP you pay for may create the wrong incentives for the vendor
• Coordinating the work of external counsel, internal counsel and the company’s project owner to save time and speed implantation
• How to structure agreements as an “Early Warning System”

I suppose that the misconception arises because — well — it does say “Letter of Intent” and not “Contract” at the top of the page.

Do yourself a favor and press the “I Believe” button on this one when I tell you that LOIs can be binding agreements.  You need to take them seriously and your lawyer needs to write them.

As a person who does other people’s technology, telecom, and outsourcing negotiations, I understand and still get the adrenaline rush of getting close to wrapping the big deal.  Still, these are the moments where you need to take a deep breath and make sure that you get the documentation right.

LOIs go by many names, such as Memorandum of Understanding, Agreement in Principle, and Term Sheet, among other things. Whatever you call them, they can and will bite you if you’re not properly circumspect about the things you sign.

Yes, it’s exciting when your big deal is making big time progress.  I know that when the other side mentions the LOI, it’s a Right Guard moment.  Just understand that once you sign that LOI, you may be blurring the line between engagement and marriage.

If you never close your deal because you never could work out all the details, you may find that LOI under lots of scrutiny. LOIs can and do find their way into courtrooms. The essence of the lawsuit is often plain ol’ “breach of contract.”

It really comes down to non-lawyers are often under the misconception that the title of the document absolutely governs the situation.

If the language in your LOI reads like a binding contract, it’s probably a binding contract. Don’t make the mistake of thinking that just because not every detail of your deal is in the LOI that this necessarily means you would win if sued.

The starting point in drafting an LOI is to remember its purpose. Usually, parties are looking to summarize their deal as a prelude to negotiating the details. Sometime they want to start a project moving before all the details are fully negotiated. Either way, it’s usually intended to be superseded by a more formal and lengthy document.

Further, the parties don’t intend many of the terms to be binding if they never sign a more formal contract that includes all the details.

However, the parties usually have terms they do expect to be binding even if they never close the deal. Some examples would include the part about starting the project, how much that will cost, a confidentiality provision and a provision that says each party is responsible for their own attorneys’ fees and other expenses in connection with the negotiation of the deal.

If your LOI isn’t specific about whether it’s really a contract or a nonbinding summary of the state of your negotiations, you could be creating an unpredictable mess for yourself. If there’s ever a dispute about the LOI, you’re forcing a court to look at the document as a whole, accept testimony with those who participated in the LOI creation process, and then make an educated guess as to the intent of the parties.

In this situation, the fact that it says, “Letter of Intent” at the top is just a single piece of evidence that a court will use to find the parties’ intent. If everything below the title reads like a binding agreement, the court may find that you have a contract and not just the simple outline of terms to be negotiated that you thought you had.

In some ways, if your lawyer does it right, this can be simple. A well-drawn LOI has a provision that specifically states to what extent the parties intend it to be a binding agreement. A typical provision will say that the LOI in fact has provisions that the parties intend to be binding even if they never sign another document. It will then go on to specify those provisions.

Whatever you do, just remember that an LOI is a legal document that you should have your lawyer write. If you think that you are up to the task, let me give you some perspective: As somebody who mentors young lawyers, I’ve yet to find one who fell out of law school with an innate ability to draft legal documents. It takes years of mentoring and training for a young lawyer to master the art of legal writing. I just ask, “Who mentored you?”

Here’s an example of the type of provision that you’ll see in tech agreements:

“The liability of vendor to customer for any reason and upon any cause of action related to the performance of the work under this agreement whether in tort or in contract or otherwise shall be limited to the amount paid by the customer to the vendor pursuant to this agreement.”

Yes it’s heavily slanted in favor of the vendor—it’s the vendor’s form.  I draft them just as one sided when I’m representing a software vendor so that I protect MY client.  As I always say, he who drafts sets the agenda.

Judges Can Read

Now, if you sign off on a clause like that because you figure that your lawyer will find some technicality to overcome it later when a problem develops then I’d say to you, don’t depend on it. As a generalization, the clause means what it says and says what it means.  Judges can read and will probably enforce it as it’s written. Judges are not in the habit of rewriting commercial contracts.

That’s your job when you’re negotiating your deal.

It’s the Norm

When you negotiate your agreement and tell the vendor that the limit of liability has to go, you’re likely to get a blank look. You know, it’s the same look you get from your kids when you remind them that they haven’t given you your change after you sent them off on an ice cream run.

I know that what I say when I represent a vendor and the other side pushes back on the limitation of liability clause being so slanted in the vendor’s favor. I say things like “Limits of liability are the norm.” “Everybody uses them.” “We’ve never done a deal without one.” “We’d have to increase the price dramatically because of the additional risk we’d be assuming.”

Ironically, all of this is true. So, we’re done, right? Wrong. A skilled and experienced negotiator can make all the difference here.

While it is to some extent the norm to see limits of liability in tech, telecom and outsourcing deals, it’s not necessarily true that they’re all as onerous as my example. While getting the vendor to remove it completely may be like climbing Everest, making it fairer isn’t necessarily as hard if you ask for the right things.

The Negotiation

If your vendor won’t eliminate the limit of liability provision, you start by pecking at it. There are many way to do this, some of which I briefly discuss below.

In my example, the vendor’s liability is “limited to the amount paid by the customer to the vendor pursuant to this agreement.”

Let’s say we have a $5,000,000 deal cooking, which calls for 24 equal payments over 24 months as work progresses. Let’s say that after the first month it becomes clear that the work they’re doing is causing more harm than good, so you rightly refuse to make your second payment. Finally, let’s say that they’ve somehow caused damages worth $1,000,000.

You might think that you could successfully seek damages of $2,000,000. However, you are not likely to prevail because you’re limited to the amount you’ve paid — i.e. a refund. So, as written, no matter what they do and no matter ow bad it is, the most you get is the amount you’ve paid to date. They risked nothing!

My first attempt to chink their armor would be to ask them to limit liability to the total value of the contract to them ($5,000,000), not the amount paid to date. Failing that, I might ask for some multiple of the amount paid to date.

However, these two examples above assume that the vendor’s total liability to you will nicely match the total value of the contract to them.  That’s unlikely, so you should also consider asking for a multiple of the total value to them.  You know the scope of what they’re providing to you, so put some thought into all the ways they could potentially harm your company while providing goods and services to you.  How high does that number go?  Ask for it or something even higher and then negotiate downwards as appropriate.

Another approach is “reciprocity.” In fact, I’d say that no single word is more important in moving a one-sided agreement toward the middle than reciprocity. What’s good for them is good for you. Don’t be embarrassed to ask. They certainly weren’t embarrassed to make it one-sided to their advantage..

The idea is that the most that they can ever recover from you is equal to the most you can recover from them. Why should they have a protective limit, but not you? They won’t like that, but it’s hard to argue against the proposal’s inherent fairness. Still, they are likely to ask for an exception from the liability cap for the fees you owe them. In most cases, that’s fair.

Yet another approach is to create exceptions or “carve outs” for the vendor’s liability on several issues.  The most important is often creating an exception for infringing intellectual property. In the example as written, if they “create” software for you and you are sued for millions for infringing some third party’s copyright, you pay unknown millions. Then when you seek indemnity, you find that your indemnification is limited by the limitation of liability provision to a fraction of what you paid to the third-party. That’s fundamentally not fair..

Another common carve out is an exclusion for any third party’s property damage or bodily injury claim. As with the copyright situation, it seems inherently unfair that you should pay unlimited amounts of money to a third party because of something your vendor did, but then your recovery is limited by your contract.

Yet another common carve out is an exclusion from the limitation of liability relating to your vendor’s breach of their (hopefully heavily negotiated) IT security and privacy obligations in the agreement.  If your vendor suffers a data breach and your customer’s personally identifiable information winds up on the Internet, your vendor should be on the hook for the total amount of damages, not some arbitrarily capped amount.  Cleaning up the situation is going to be hard enough. If you’re also out of pocket for something the vendor did (or didn’t do), it only makes things worse.

There are a lot of other common exceptions to pursue during your negotiations.  Vendor’s breach of confidentiality, indemnity obligations beyond intellectual property infringement, gross negligence, recklessness, willful misconduct, intentional breach of the agreement, violation of law, or obligation to provide you with credits under the agreement. However, you won’t get them if you don’t ask for them.

It’s almost a waste of time to put effort into negotiating a contract to have it emasculated by a one-sided limitation of liability clause. Don’t let that happen to you. While it may be true that these types of clauses are “normal,” don’t assume that the one in their proposed agreement has dropped from the heavens as the only way it can be.

Related articles

• Limitation of Liability Clauses in contracts: Indian Perspective (tkamal20.wordpress.com)
• 12 Steps to Contract Negotiations (thethrivingsmallbusiness.com)

What You Need To Know Before You Negotiate Your Intellectual Property and Technology Deals

January 24, 2013

8:30am – 10:30am

Tannenbaum Helpern Syracuse & Hirschtritt LLP

900 Third Avenue,   New York, New York 10022

Speakers

Mark Grossman

Andrew Berger

Donald Prutzman

Intellectual Property (IP) and technology-related transactions raise complex legal and business issues you need to understand, negotiate, and document in your agreements.  From complex software licensing to cloud computing deals to freelance contributor contracts, IP and tech transactions have their own customs, nomenclature, usages, and norms.  In this seminar Mark Grossman, Andrew Berger, and Donald Prutzman will guide you through what you need to know to complete these transactions successfully.  They will explain the norms when doing these deals; the concessions you should expect; and the technicalities you must include.

The discussion will include the nuts and bolts of IP and tech licensing, including warranties, indemnities, limitations of liability, performance standards, acceptance testing procedures and change orders, to name a few.  You will learn how to employ these concepts to your benefit in all types of deals.

2 hours of NY CLE credit pending.

To register please contact Nancy Wu at Wu@thsh.com.

Source Code Escrow

It’s a nightmarish scenario. Let’s say that you’re the head of Information Technology (IT) for a hotel chain. You pay a software development company $500,000 to create new software for your worldwide reservations service. It doesn’t matter whether the software runs locally on your servers, or in the cloud in a SaaS model.  But then your developer goes bankrupt or for whatever reason and refuse to support the software. If you didn’t consider access to the source code in your agreement with the developer, you may find that you’re unemployed.

Essentially, “source code” is computer programming that humans can read. “Object code” is programming that only your computer can read. Typically, as a user, you only have access to the object code.

Software developers consider the source code to be their most valuable trade secret. With the source code, a competitor could create a competing work without incurring all of the development costs of the original developer. Source code is the lifeblood of the software development business.

From your perspective as the head of IT for that hotel chain, you need the source code to continue the evolutionary development of your software or to fix bugs if your original developer disappears on you. If they can’t or won’t help, you’ll need to hire another company to do the work. This other company’s efforts will be severely hampered if they don’t have the original source code.

Back to the Beginning

If we go back to the beginning of this transaction between you and the developer, we see that you had competing interests. You needed software developed to run reservations. You felt that for $500,000, you should own all rights to the final product. The developer wanted to be able to license use of the software to competing hotels and said that “ownership” would cost you far more than $500,000. So, you agreed on a perpetual, non-exclusive license. You could use it forever, but they could license the final product to others. (Presumably for more than $500,000 since you were the guinea pig.)

Typically, when you get a license, you only get the object code. Remember that the source code is the last thing the developer wants to give you. Your lawyer blew it if he didn’t work out a deal concerning access to source code before you paid your $500,000.

 Typical Arrangement

Clearly, you needed a compromise. You had your very real need to access the source code in case the developer went out of business or filed for bankruptcy, or the developer simply breached their support contract with you. Just as legitimately, the developer needed to keep the source code secret — locked up in a vault.

The solution was a source code escrow. Source code escrow is when you deposit the source code and other information with a neutral third party (escrow agent). The “other information” is miscellaneous material that a trained computer programmer would need to work with the source code. This might include things like technical manuals, maintenance tools, proprietary utilities and contact information for key technical employees.

The escrow agent’s job is to keep a copy of the source code secure and safe. You only get the source code if the developer defaults on support, goes out of business, is involved in a merger or acquisition, or any other predetermined “release condition.”

The idea is that if a “release condition” occurs, the escrow agent gives you the proprietary information. This strikes a balance between the parties. The developer can maintain strict control of its company’s greatest assets by not giving away its intellectual property, while continuing to satisfy your needs. At the same time, you can protect your investment in the technology and ensure proper support from the developer or access to the source code in case the developer fails. It’s a fair deal that no developer should refuse. If you fail to get a software escrow, you’re probably fired.

 Setting Up the Escrow

There are many variations in the way you can establish an escrow. My scenario has been $500,000 software. This calls for a major league escrow arrangement.

Still, your development project may only be $25,000, not $500,000. This might call for a minor league arrangement. Somewhere in between is a continuum of increased diligence and cost. You’ll need some expert legal counsel to guide you through all the options in between.

Each escrow will have its own unique twists. First, let’s talk about the simpler “minor league” escrow.

The minor league escrow arrangement is appropriate when the size of your investment is smaller. The problem with what I describe as the “major league” arrangement is that it can cost many thousands of dollars. You may not be able to justify this investment for software that costs you only $25,000.

A typical simple arrangement has the developer depositing the source code and related materials with a bank or attorney who puts the material in a vault. While this arrangement may be better than nothing, the key words are “may be.” There are many problems with this simple arrangement. What’s on the CD-ROM in that vault? Is it what it purports to be? Is it really everything that a trained computer programmer would need to work with the source code? You may find that your banker escrow agent is lost when you need the source code released from escrow. Bankers are in the banking business not the escrow business.

As your investment in software increases in size, you might want to consider an escrow with a professional software escrow company. You never want your lawyer or bank holding your escrow. They are just not equipped to do this right.

A professional escrow company also can offer you technical verification services. This is an essential service. Unfortunately, it’s not always affordable for smaller investments in software. It’s absolutely required if your investment is large.

Typically, an escrow company will offer three levels of verification with varying costs. Typical is something like this:

With Level I Verification, they ensure that the media deposit in your escrow account is readable and complete. They test the deposit to verify that the source code files are identical to the files that the developer warrants are included in the deposit.

With Level II Verification, they confirm that the source code will convert into object code, and that the complete, deposited source code files are the same as their counterparts residing on your hardware.

With Level III, they confirm that the deposited source code, when compiled, will process data exactly as the licensed program does.

How far you go with your escrow will mostly depend on how much you invest in the software. The more you invest in the software, the more you should invest in the escrow.

Software escrow is an essential insurance policy. Still, you must remember that unless you take Level III to the max, you’ll never be sure of what you have in escrow. When your developer goes bankrupt is not the time to find out that the CD-ROM in escrow is blank.

Below you will find his article.  While written for an audience of in-house lawyers, Mark thinks everyone will find the content of the article informative.

Enterprises are increasingly willing to rely on data storage in the cloud and software as a service (“SaaS”).  These are significant changes from the more traditional model that has your data stored locally and your enterprise licensing the software it uses.  This article will discuss the contracting considerations in SaaS deals and how SaaS deals differ from traditional software licenses.

Some Definitions

Before the non-techie readers zone out, this article will turn to the fundamental definitions.  They are neither mysterious nor complex.

It all starts with what is cloud computing and where is the cloud?  You need to understand this as a prerequisite to understanding SaaS.  Cloud computing for the purposes of this article is simply the delivery of computing and storage services over the Internet.  If you have ever stored your music collection with Apple using iTunes or your photos with Flickr, you have personally used the cloud.  Of course, enterprises use the cloud too.

The cloud physically lives in data centers around the world.  Amazon is a well-known example of a cloud services provider since it sells access and use of its data centers to other enterprises for their business needs.  So to visualize the cloud, do not look to the sky.  Instead, you should think more mundanely of racks of computers gorging on the power grid in a cool room with lots of ventilation so that they do not fry.  That is the cloud.

SaaS is the delivery of software from the cloud to your computer.  If you use Gmail or Yahoo mail, you have used a SaaS solution.  Gmail is run by complex email software, but you have do not have the software installed on your computer.  Rather, you access this complex software using your browser.  This is as compared to the traditional licensing model that has complex email software like Outlook installed on your PC’s hard drive.

Negotiating Agreements

Your company’s ability to negotiate an agreement for SaaS and cloud computing services is no different from its ability to negotiate any other type of tech deal.  While service providers may argue that they cannot agree to custom agreements with individual customers because of the shared infrastructure inherent in cloud and SaaS solutions, this writer’s experience says that while the refrain is common, it is simply not true.

What is true is that your company’s ability to negotiate the poorly written form agreements that service providers foist upon you as non-negotiable PDF’s is directly proportional to things like the size of your spend, the length of the agreement and your company’s size.  If this sounds no different from the calculus of your negotiating power in almost any other type of deal, that is because it is not.

SaaS is not a License

The starting point in negotiating any SaaS deal is for you to understand that SaaS is not a software licensing deal.  It is a complete paradigm shift from licensing software to providing it as a service.  Thus, if the service provider sends you a form agreement with licensing language like “Buyer hereby licenses the software installed on Seller’s server,” you have already learned that the service provider’s lawyers are living proof that even the bottom of the law school class can find a job too.

On a more serious note, I will not try to redline a SaaS agreement that feels like a license.  The document is simply a throwaway and I am quick to tell the other side the bad news.  If I can, I will use this as an opportunity to send them my agreement, which has a tilt toward my client.  (He who drafts sets the agenda.)  Sometimes service providers will buy into this because of their hope (as cynically interpreted by this writer) that they can use my agreement as the starting point for the future redo of their form.

Smarter service providers will not let me get away with my form as the starting point for the discussion, but of course, the smarter ones do not send SaaS agreements that read like licenses.  Either way, this conversation about the agreement being completely inappropriate creates some interesting discussion.  If there is any good news here, it is that over time this writer is seeing fewer licenses purporting to be SaaS agreements.

A correctly written SaaS agreement is a service agreement without a license to use anything Sometimes a SaaS solution requires special software and not just any browser to access the software being delivered as a service.  In that case, there may be a license limited to that special software that may be installed on each PC that accesses the services.  The generalization that SaaS is not a licensing arrangement remains true.

By analogy, think of the plain old telephone service (“Pots”) your company buys for landlines from Verizon, AT&T, or whomever.  Your company gets a dial tone that you instinctually know has lots of software behind it.  Nonetheless, your company does not license any software as a part of the Pots deal.  All your company is buying is a service.  What the telephone company does to provide the dial tone is their problem.

With SaaS, it is the same thing.  Your company does not license the software underlying the service.  It simply buys a service that may happen to have software behind the curtains that makes the service work.  Everything about your agreement with your service provider must reflect this reality underlying SaaS.

Some Key Contract Considerations

In all SaaS contracts, you will have the negotiations regarding the usual provisions like limitations of liability and exclusions from the limits, indemnity, and all the other usual suspects.  However, this article will focus on a few examples of considerations and provisions that are unique to SaaS deals.

Service Level Agreements

Probably the most important part of any SaaS deal is the negotiation of the Service Level Agreement (“SLA”).  Since your service provider runs and delivers the service to your enterprise in a SaaS arrangement, it is essential that you have clear and objective provisions regarding things like uptime requirements, speed, responsiveness, and the like.  Typically, an SLA will provide for credits against the next month’s fees if your service provider does not meet the requirements of one of more of the specific services levels.  Also typical are provisions that limit the total of all credits to between 10% and 20% of the fee in any given month.

While it is tempting to write a long SLA with many specific metrics, this writer finds it more effective to push my own client to focus on the metrics that are truly important to it and focus the negotiation to just those.  Otherwise, it is easy to get lost in minutia.

Moreover, do not – I repeat – do not get lost in demanding service levels beyond what your company needs.  Some downtime and occasionally deficient service are often reasonable risks depending on what the service does and the enterprise cost associated with problems.

You may have heard terms bandied about like “five nines” and “four nines” uptime.  In English, this translates to 99.999% uptime and 99.99% uptime respectively.  With a 99.999% (five nines) uptime SLA, the service provider promises that the system will be down no more than about six seconds per week.  With 99.99% (four nines), the promise is downtime not to exceed about one minute per week.  If the system uptime does not meet the standard required by the SLA, the contract would typically award a credit that would be applied to the next month’s bill.

The point of this numbers exercise is to make the point that four and five nines are rigorous standards that come with a cost.  If your enterprise wants and needs five nines, your service provider may have to throw lots of redundancy at the promise and that redundancy comes at a cost to the buyer.  For example, five nines might require using two different data centers that are geographically remote from one another to help accomplish the SLA’s requirements just in case of a power or weather related problem in one particular geographic area.  This type of redundancy is not free.

So, if your operation is tolerant enough to accept 99% uptime (two nines in the lingo) or about 7.2 hours per month of downtime, go for the lower price that probably comes with that lesser SLA.

You may remember all the controversy about cloud and SaaS services that followed storm related outages at companies like Netflix and Salesforce.com in June 2012.  Many of the articles at the time spoke about the reliability issues inherent with cloud and SaaS services.  Ridiculous.

Even if your own IT department ran its own data center, no sane CIO would ever promise 100% uptime.  Even an attempt at five nines uptime would require your CIO to demand increased funding for redundant hardware and a redundant location.  This does not come cheaply.

And this brings you back full-circle to the importance of SLAs.  If you need a certain level of service, your agreement should reflect that.  Careful and thoughtful contracting can help your company accomplish what it needs in the cloud with SaaS.  Moreover, since SaaS fees are usually in the nature of monthly recurring service charges, your company could avoid the large capital expenditures required to run its own data center and local software installations.

Chronic Downtime

An area of legitimate concern with SaaS deals is the mediocre service provider whose failures never quite reach the level of a breach of contract, but rather are more in the nature of every month it misses one or more service level in ways that are annoying and disruptive.  This is a problem your agreement could address using what some commentators refer to as a “chronics provision.”

With this type of provision, you might say something like a failure to meet the SLA required metric on three or more individual items in three consecutive months or four of any consecutive six months would be considered a material breach of the agreement.

The buyer of the service would want a provision that says that the credits provided by the SLA for failures would not be the exclusive remedy for “chronics” and that the buyer could seek all damages permitted by law.  Obviously, the service provider would want “damages” capped by the credits permitted by the SLA.  Many factors would determine how this plays out including the relative negotiating power of the parties and the cost of the service.

Ownership of Data and Risk of Loss

Since your company’s SaaS provider will often store data as a part of a SaaS deal, it is important to have express provisions that appropriately deal with the issues of data ownership and risk of loss if data is lost, damaged, or compromised.

Data ownership is the easier one.  The contract must have an express statement that the customer owns its data and then continue with appropriate authorizations for the service provider to use the data solely for the purposes of providing the services pursuant to the SaaS agreement.  No ambiguity should ever be acceptable in this area.

Lost, damaged, or compromised data is the tougher one to negotiate if for no other reason that it is like any negotiation over risk of loss.  The SaaS provider’s rhetoric includes things like, “We are not charging you enough to bear this risk” and “We are not an insurance company.”

The customer’s pushbacks typically include, “You must bear responsibility for you actions” and “Your reticence to accept responsibility is causing us to wonder about your own confidence in your own abilities.”

Norms are Lacking

People are often in search of the ever-elusive norms in the industry.  Using the example of risk of loss provisions, this writer must conclude from his extensive experience in doing these deals that there are few “norms” and that every deal stands on its own relative merits.

If there is a norm, it is that sophisticated enterprise level SaaS deals are complex exercises in negotiation and contracting and that they usually require many weeks of discussions before the parties can conclude a deal.  The examples of important provisions discussed in this article and basic negotiation tactics like pushing back hard, asking for more than you really need, and not buying into the vendor’s form are the foundational concepts to effectively negotiating a SaaS deal.

Related articles

• Cloud contracts: Watch those gotchas (zdnet.com)
• SaaS is dead, long live SaaS! (actionableinsights.covario.com)
• SaaS Sees Fastest Growth In Cloud Computing (misco.co.uk)
• What is your cloud strategy? (businesstechnologypartner.wordpress.com)
• Six Reasons Why Every SaaS Vendor Needs a Customer Success Management Strategy (customerthink.com)
• Software as a Service (SaaS), Security and Risk Management: Part 1 (websphere.sys-con.com)
• The enterprise Cloud battle will be an integration battle (stage.vambenepe.com)
• Six Reasons to Move to the Cloud, Consider SaaS (wired.com)

First, I’m a panelist on “Law Firms and Legal Outsourcing: Measuring the Return on Investments” at the at the Global LPO Conference and Exhibition in NYC October 11that 10:30 AM.

I’m also a panelist on “Employing the Qualified Personnel for Legal Outsourcing Work – An Insider’s Perspective” at the Global LPO Conference and Exhibition in NYC October 12th at 2:30 PM.  More information on the Global LPO Conference and Exhibition is at www.connect-goal.com/newyork2012.

Third, I am conducting a mock negotiation of a software licensing deal for the Practicing Law Institute’s “Understanding the Intellectual Property License 2012” seminar in NYC October 19th at 3:45 PM.  More information on this event is at  bit.ly/QVciDu.

TechLaw – Avoiding Legal Problems from Screen Scraping and Data Mining

If your company has its pricing data available online, you should assume that your competitors now also have your pricing data.  Of course, the flip side is that your competitor’s prices might also be available to you online.  Is this type of competitive intelligence gathering legal?  How do you reduce the information your competitors can easily get from your site?

It’s certainly easy to use screen scraping programs sometimes referred to as “spiders,” “crawlers,” or “bots” to obtain pricing data from a competitor’s website.  In most cases, it is probably a legal practice although I would caution you that the law is still evolving here.

If you intend to use screen scraping to obtain information from a competitor, you can take some steps to reduce your potential legal liability.  You can also take some defensive steps against your competitors screen scraping your website.

The starting point in the analysis is quantifying the “harm” caused by screen scraping.

Unfortunately, the law provides little guidance.  For example, it is impossible to quantify how many of your visits to a competitor’s website during any 24- period would be too many.  Arguably, you might look at this issue by looking at the harm your activities cause to website performance.

Every visit to a website costs the website’s owner a little server time and network bandwidth in responding to requests.  The cost for an individual site visit is negligible, but over time can add up and be substantial.

One best practice suggestion would be to distribute your load to the target website by scheduling the “pings” over the course of the day rather than flood the website with requests during a smaller period.  Sudden and large amounts of traffic to a website could cause slower response times, increased bandwidth expenses, and run the risk of crashing the server.  Bringing a server back up after such a crash increases costs to the website owner, as well as lost revenue suffered by the website owner while the website is unreachable to customers.  Such damages to their system capacity and customer goodwill could arguably create a liability risk.

One thought would be to monitor the performance of the targeted website to ensure that your scraping is not degrading the target’s performance.

Another thought would be not to get into an escalating technology battle.  So, if the target implements a challenge-response system like “CAPTCHA,”

A CAPTCHA is Not a Perfect Solution

you may not want to invest in technology to beat it.  Legally you may be approaching the line and, beyond that, you are certainly inviting an escalating technology war that could get expensive.

Going on the Offensive

Having said earlier that screen scraping is “probably a legal practice” is not a statement you should interpret as anything close to a sure thing.  Companies have become embroiled in litigation over these issues.

The lawsuits are often based on old-fashioned torts like “trespass to chattels,” “interference with business relations,” “misappropriate,” and “unjust enrichment.”  Some have looked at more recently enacted state and federal statutes like the Computer Fraud and Abuse Act.”

Finally, some of the lawsuits are based on a breach of a website’s Terms of Use.  Any Terms of Use that clearly prohibits the activity you intend should give you pause.  When in doubt, talk to your tech lawyer.

Protecting Your Information

There are things I recommend you do to protect your website information from competitors.  The starting point is including a clear prohibition against screen scraping in your website’s Terms of Use.  And while you’re reading your own Terms of Use, it might be a good time to generally consider a thorough legal review of that document and your Privacy Policy.  It’s an exercise that you should undertake at least every other year since the laws pertaining to the Internet are in a constant state of evolution.

You might consider blocking IP addressed of abusive visitors although this could create an ongoing response / counter-response cold war with your competitors.

You should certainly consider establishing robot exclusion protocols to tell robots not to visit certain portions of your website.  This tactic is likely to be partially effective at best.

Beyond these fundamental suggestions, there are a number of other steps you could consider like a CAPTCHA test, and creating a strong login and limiting the number of logins by each visitor.

Next Steps for You

I suggest that you set up a meeting with key stakeholders like your core business team, IT and your tech lawyer.  While the legal landscape is a murky, you should not take that murkiness as meaning that screen scraping is not something I could recommend in appropriate situations.  My take is that competitive intelligence is invaluable information even if it comes with some legal risks.  And while you’re at it, you should add the defensive steps you should take against your competitors to the agenda.

Related articles

• How to get rid of Screen Scrapers from your Website (theexceptioncatcher.com)
• Bucks Blog: Delta Cracks Down on Mileage Tracking Sites (bucks.blogs.nytimes.com)

Below is an article that I wrote in 1998 about cyber-terrorism.  I would not have to change many words to write it today.

Cyberterrorism

By Mark Grossman

Everyday, more commerce and sensitive information flows over the Internet. People and organizations are becoming dependent on electronic data while paper trails are diminishing. This dependence on electronic information makes for an inviting target for a new breed of terrorists that some are calling “cyberterrorists.”

The website of Air Botswana, defaced by a group calling themselves the "Pakistan Cyber Army (Photo credit: Wikipedia)

Barry Collin, a senior research fellow at the Institute for Security and Intelligence at Stanford University, is quoted by the “Air Force News” as defining “cyberterrorism” as “hacking with a body count.”

In the world according to Tom Clancy, “In the year 2010, computers are the new superpowers. Those who control them, control the world. To enforce the Net Laws, Congress creates the ultimate computer security force agency within the FBI: Net Force.”

In case you think that this is far-fetched, then consider this. On January 22 of this year, the President proposed adding $515 million to the fiscal year 2000 budget to protect the nation’s computer-dependent critical infrastructure, such as power, banking and emergency services. The federal government has already created special offices within the FBI and the Commerce Department to protect critical systems against cyber attack. The President even coined the phrase “Cyber Corps,” which “will encourage federal agencies to train and retrain computer specialists, as well as recruiting gifted young people out of college.”

The Threat is Real

In March 1998, several NASA, Navy, and university websites received “denial of service” attacks (also known as “New Tear” or “Boink” attacks). The attacks targeted computers with Microsoft Windows NT and Windows 95 operating systems. They prevented servers from answering network connections and crashed computers, causing a blue screen and a “fatal error” message to appear (a.k.a. “the blue screen of death”). The systems were restored by rebooting the computers and no permanent damage occurred, but some of the targeted organizations have sought help from the FBI. Microsoft provided a patch for fending off this kind of attack.

In February 1998, over a two-week period, the Defense Department had its worst attack to date. The unclassified networks were penetrated (sources said the classified networks had not been breached), and the hackers accessed personnel and payroll information. Deputy Defense Secretary John Hamre called it a “wake-up call.” Two teenage hackers allegedly perpetrated the attacks, one of whom is a California sophomore in high school who goes by “Makaveli.”

In 1997, a Swedish hacker jammed the 911 emergency telephone system throughout west-central Florida. FBI Director Louis Freeh called the incident “a dress rehearsal for a national disaster.”

English: Photograph of Louis J. Freeh. (Photo credit: Wikipedia)

The Cyberterrorist’s Advantage

Cyberterrorism is an attractive way to mount an attack. It starts with the advantage of anonymity. The simple fact is that it’s difficult to track a cyberterrorist. There are no checkpoints or physical evidence. The terrorist could even be half way around the world.

It can also be a low-budget form of attack. The only real costs may be some computer equipment and programming time. Unlike a real world attack, the terrorist needn’t make or transport a bomb. Customs isn’t an issue. Delivery may be as easy as a PC and a telephone line.

In our computer dependent world, the potential targets are endless. Consider the damage that could be done by attacking Wall Street’s computers, traffic light control computers, prison computers, banks, the Pentagon or AOL. This is not about childish pranks, this is about a form of warfare and no country is more vulnerable than we are.

The legal systems of the world are ill-prepared for this new type of terrorism. Just consider the unique jurisdictional issues raised by an attack launched by a programmer working in Russia, who installs his attack program on a system in Iran, which automatically launches the war months later by satellite link to a computer in Canada that uses the Internet to destroy a computer in New York.

Cyberterrorism is here to stay. We’re vulnerable electronically and it’s just too tempting a way to attack the United States. It can also cause much more damage than a truck bomb. You can expect to hear much more about this in the years to come.

Related articles

• Pentagon cyber chief downplays NSA email snooping; says attack is ‘coming our way’ (rt.com)
• ‘New age’ of cyber threat warning (bigpondnews.com)
• The Role of Cyber Terrorism in the Future (articles.forensicfocus.com)
• ‘Cyber attacks could mean end of world as we know it’ (haaretz.com)
• Pentagon cyber chief downplays NSA email snooping; says attack is ‘coming our way’ (EndtheLie.com)

Is it legal for them to use your data?  What’s the law say about the ownership and use of your data in the cloud?

The short answers are that it may be legal and the law says little about the issue.  As a transactional tech lawyer who does cloud and SaaS deals, I would even go so far as to say that I don’t care what the law says.  This is one of those situations where the “law” (meaning common sense as modified by the courts and legislature) should be irrelevant if you handled this correctly in your contract.

To handle these issues correctly, don’t rely on the law.  Rather, your contract with your SaaS or cloud provider should clearly state who has what rights in your data.  “Law” in this case is something that a litigator looks at when your contract is silent or not helpful.  Get it right in your contract and the “law” won’t matter.

If you get it wrong and your agreement with your SaaS provider says something like you grant them a perpetual license to use your data for their own marketing and other purposes, you might find that this jeopardizes the confidentiality of your data–or worse causes you to be in breach of a confidentiality agreement with your customer.

Preventing the problem is easy.  Read and negotiate your agreements.  This includes online click “I accept” agreements, which can be modified by a separate offline agreement.

Image via CrunchBase

While it’s wholly unrealistic to expect to negotiate the terms of service for Gmail with Google because your enterprise simply does not have the negotiating power, it’s absolutely realistic to assume that in most other contexts you can negotiate almost any provision in any agreement.  If you don’t ask, you won’t know.

New York Technology Council’s CEO Roundtable
New York, NY
May 22, 2012 6-8 PM

On May 22, I will be speaking to the New York Technology Council’s CEO Roundtable on “Preparing Your Tech Business for Sale.”

This seminar will address what you must do now to avoid problems when you want to sell your tech company later.  What will your buyer find when it looks “behind the curtain?”

By running your business professionally now, you can avoid many pitfalls.  In this presentation, I will provide you with tips to ready your business for your exit strategy.  You will come to appreciate what I mean when I say that if you want to play in the major leagues, you have to act like a major leaguer.  And acting like a major leaguer starts on the day you found your company.

I will talk about things like intellectual property due diligence and audits, and how having well-written agreements in place makes your business look like a major league player.  This seminar will touch upon issues like non-disclosure agreements and protecting your intellectual property.  I will also talk about what I learned when I co-founded a software company that Microsoft bought.

If want to attend, please send me an email at mg@eComputerLaw.com with information about you and your company.  I will submit your request for an invitation to the group for approval.  This is an invitation only event.