Still, if a major part of your business is a website or software application (including iPhone and Facebook apps), it’s well worth the time and (minimal) expense to put in place at least a simple contract with your developers. This contract should get signed BEFORE the developer begins any substantial work on the project

What you get with a solid developer contract

Why do you need a properly written contract with your developer?

1. Confidentiality. Ideas have legs — muscular marathon runner’s legs — and you don’t want your developer to walk the idea for your new website or app across the street. It’s difficult to protect still-inchoate ideas and requirements (as opposed to completed designs, specifications or prototypes) under intellectual property law, since bare ideas in the process of formulation are not copyrightable or patentable. Moreover, the allowance rate for business method patents is extremely low (presently under 10%), and the cost of prosecuting patents is typically tens of thousands of dollars, so you should not count on being able to patent your website, program or app even at a more advanced stage of development. What this means is that, besides avoiding disclosures except where strictly necessary, contract protection (i.e., a non-disclosure or “NDA” clause) is your best bet to protect your idea as it is being developed.

2. Intellectual Property Ownership. Even if a bare idea is probably unprotectable, at some point the development of your idea is going to lead to the creation of protectable intellectual property. In the context of web or software development, this could be some or all of the following: (1) code, web design, graphics, images, text and other creative content (all of which can be copyrighted), (2) logos, slogans, catchy domain names and similar branding features (which can be trademarked), (3) look and feel (which is potentially protectable as trade dress), and (4) in rare cases, patentable inventions (if your site, program or app does something new, useful and non-obvious in light of the current state of the art).

It is a widely held but mistaken belief that if you pay a contractor to do something for you, you automatically own all IP rights in the work product because it is a “work made for hire.” (In fact, even attorneys often make this mistake, as I was reminded when I was a reviewing an IP asset purchase agreement drafted by opposing counsel the other day.) “Work made for hire” is a copyright concept only; furthermore, with outside contractors, it applies only to select types of specially commissioned works like atlases, parts of motion pictures or other audiovisual works, tests and instructional texts, which are generally irrelevant to the context we are discussing — and even then, a written agreement stating that the works are “made for hire” is still required!

In plain English, what all this boils down to is: you don’t own it (even if you paid for it) unless there is a contract that says you do. To be legally effective, the contract must also assign all relevant copyrights, patent rights and other IP to your startup. Without such a contract, you only get a license (i.e., a narrow right to use), the developer still owns any copyrights and patents, and it is free to use or commercialize this IP elsewhere. Potential investors and acquirors looking at your startup will want to see that you have IP ownership buttoned down. If you don’t own your product, watch out.

3. Getting What You’re Paying For. In development parlance, this refers to scope and specifications: you are paying X for the developer to build you Y, with Y being fleshed out in as much detail as possible in the contract. The importance of getting this nailed down is best illustrated by a common horror story: Client goes to Developer and asks Developer to build a site with A, B and C features and functionality. Developer says sure, no sweat; it’ll cost you $5,000, half up front and half on completion.

Developer labors for a month before realizing that he seriously underbid the project, which is far more complicated than he had considered. So he stops work and informs Client: sorry, I can’t possibly make a profit on this deal, but because I’m a warm-hearted stand-up guy, I’ll agree to just keep the $2,500 you’ve already paid, even though I’ve done $6,000 of work. For this largesse I welcome any comparisons to Gandhi you care to make. Client, who is out $2,500 and doesn’t have a website, is not inclined to award any Nobel Peace Prizes.

Developers may cry foul at this narrative. The common argument I hear from developers is that clients think developing a website is like rehabbing a bathroom, i.e., the client knows what it wants and parameters of the project are fixed at the outset, so there is no scope creep. In contrast, the argument continues, development clients actually DON’T know what they want. Their requirements are constantly in flux, and they require endless rounds of revisions.

Fair enough. But this doesn’t undermine the case for a contract. Quite the opposite, it means a contract is urgently needed by both parties to manage expectations. The contracting process is an opportunity for both sides to crystallize and refine those expectations before money is spent — what will the basic functionality/features be? what platform will the site run on? how many rounds of revisions are included? what will additional revisions cost? And so on.

The idea is that scope is reduced to writing as much as possible at the discussion stage instead of during the thick of development (and ideally a process is defined to handle any requested changes in scope). If it is impossible or impractical to draft detailed functional specifications at this stage, they can be a deliverable to be approved by the client later. (For complex or expensive sites or programs, the parties may end up splitting the risk by handling functional specification development and actual coding as two separate projects, each covered by its own scope definition and cost parameters, with the client having the option whether or not to proceed to stage 2.)

4. Getting It When You Need It. Launch is everything to startups. If a site or program isn’t ready or isn’t debugged by the time desired, this creates all sorts of risks — risk of the competition getting a jump on you, risk of seed capital running out, cash flow risk if an expected stream of revenue is postponed, reputational risk if you’ve heavily promoted the launch and then have nothing (or nothing respectable) to launch. A well-drafted development contract, therefore, should include key deliverable milestones along with delivery dates, and payments should be tied to successful achievement of these milestones in order to incentivize developer performance. A meaningful portion of the development fee (a third or more) should be payable only after final delivery and successful completion of user acceptance testing.

5. Legal Stuff. This is the part that startups really hate, but it can be critical if a dispute arises (as it frequently does). Say a Philly client hires a developer in California to build a site for $10,000. The parties sign a contract, and the developer takes the client’s up-front payment of $5,000. The developer then absolutely does nothing and greets the client’s increasingly anguished entreaties with an upraised middle finger.

It doesn’t take a tech lawyer like me to tell you the developer breached the contract. But how does the client left in the lurch get a remedy? The contract says nothing about where disputes will be litigated (venue) or which state’s law will apply to the interpretation and enforcement of the contract (choice of law). The answer is that the client hires a California litigator at $500/hr to fight over these issues, as well as over the underlying breach-of-contract issue, and after spending $100,000+ in legal fees (and traveling to California to testify), after three to five years the client may get its $5,000 back or perhaps a court order forcing the developer to finish the site.

Obviously this is a losing economic proposition for any client, and it would be insane to sue, despite the legal merits of the case. On the other hand, let’s say the contract had provided that the law of enforcement would be Pennsylvania’s, that any litigation must take place in Philadelphia, and that the party prevailing in any litigation would be entitled to be reimbursed for its legal fees, in addition to any recoverable damages. The costs and risks of enforcement are now working in the client’s favor; it can now bring the suit in Philly, representing itself pro se if necessary, and force the wrongful party (the developer) to pay both sides’ litigation costs, which is a big stick indeed. Of course, there may still be reasons why litigation is not advisable (for example, the client would still need to get a California court to enforce the Philly court’s judgment, and the developer may not have sufficient assets to pay the client’s legal fees and damages, which defeats the whole purpose). However, the client’s ability to raise at least a credible threat of litigation, together with the possibility of much higher costs for the developer, thoroughly changes the dynamics of the dispute and gives the client greater leverage.

Avoiding the 15-Page Monstrosity

If you think that adequately addressing these considerations requires a 15-page contract which would take months to negotiate and consume thousands of dollars in legal fees, you’d be wrong. All of this can be easily hammered out in relatively simple language taking up a couple of pages. Legal fees should be minimal if you’re dealing with an attorney who knows technology and is used to working with startups (otherwise, you may very well get the 15-page monstrosity).

Your startup doesn’t need a perfect agreement with every conceivable bell and whistle; the perfect should never become the enemy of the good. But the basic issues I have described need to be covered. It’s no exaggeration to say that the costs of not obtaining basic protection, in terms of both money paid out to developers and lost future opportunities for your startup, are likely to vastly exceed the legal fees.

And, developers — this is for your own good too. Think about helping your clients by creating a simple contract template with some moderated version of these basic protections for the client built in, along with protections against scope creep and whatever payment terms you need for your business. Contrary to popular belief, contracts aren’t just (or even primarily) for hypothetical future litigation — if drafted well, they are litigation-preventers and value-enhancers, allowing projects to glide to completion along a pathway of smoothly aligned expectations.

The Copyright Act, 17 U.S.C. Section 109(a), codifies the first-sale doctrine. What this means is that if you own a particular copy of copyrighted material, you have the right to sell or otherwise dispose of that copy, and the buyer then becomes the owner of the copy. Since copyright owners normally have the exclusive right to distribute their works, the first-sale doctrine is what allows the sale of used books, to give just one example. (The buyer of a new book has the right to resell it; otherwise, selling a used book would be copyright infringement, specifically a violation of the author or publisher’s distribution monopoly!).

Another provision of the Copyright Act, 17 U.S.C. Section 117(a)(1), permits the owner of a copy of a computer program to make a copy of the computer program if doing so is an essential step in the utilization of the program. This carve-out from a copyright owner’s exclusive right to reproduce copyrighted material is necessary because when a computer program is run by a machine, it is wholly or partially copied into memory.

In the Vernor case, Autodesk accused Vernor of direct copyright infringement for selling on eBay copies of Autodesk’s “AutoCAD” software (on CDs contained in “jewel cases” which were themselves enclosed in packaging) that he had bought from an architectural firm. He was also accused of contributory copyright infringement for essentially aiding and abetting what was alleged to be unlawful reproduction of the software by his buyer (for if owership of the copies of the AutoCAD software was not transferred to Vernor, then Vernor could not transfer it to his buyer, in which case the buyer could not legally run the software under 17 U.S.C. Section 117(a)(1), which applies only to an “owner” of a copy of a computer program). Still following this?

Vernor sued for a declaratory judgment that his activities were non-infringing, which depended on the court’s finding that the architectural firm had had the right to resell the copies to Vernor under the first-sale doctrine. But for the first-sale doctrine to apply, the transaction between Autodesk and the architectural firm had to involve the transfer of ownership in the software copies (i.e., there had to be a first “sale”), as opposed to a mere license to use the copies. Naturally, the applicable license agreement used license, not ownership, terminology, contained severe restrictions on use and transfer of the software, and stated that title to the software and the copies remained with Autodesk. Autodesk moved for summary judgment dismissing Vernor’s complaint; however, the court denied the motion on the basis of the first-sale doctrine in a decision reported at 555 F.Supp.2d (2008).

Autodesk then moved for summary judgment again after some discovery had been taken. The second time around, the court also denied Autodesk’s motion, finding that the facts had not materially changed, and granted judgment for Vernor, holding as a matter of law that the transfer of the software copies to the architectural firm was a transfer of ownership in the copies, not a mere license. Consequently, the first-sale doctrine applied, Vernor could legally resell the software copies, and his buyers could legally run the programs.

At the heart of the case was the court’s interpretation and characterization of Autodesk’s software license agreement, and its reasoning highlights some critical drafting issues. No one claimed that Autodesk ever transferred ownership of the software itself (i.e., the intellectual property). What was at issue was the rights in the copies. The license agreement stated explicitly that the copies were licensed (and Autodesk retained title to the copies), yet the court overlooked this, noting that how the contract labels a transaction is just one of many factors to be considered in characterizing the whole transaction.

Ultimately, the court was swayed by certain other facts: that the license agreement did not include any right for Autodesk ever to regain possession of the software copies, that there was no unconditional right for Autodesk to force the architectural firm to destroy the copies, and that the fees for the copies were assessed as a single up-front payment rather than being spread out over time. Tying all of this together, the license agreement basically allowed the architectural firm permanent and perpetual possession of the software copies (subject to the restrictions in the agreement) in exchange for a one-time payment at the time of the transaction. To the court, this resembled a sale more than a license:

“In this court’s view, retaining title in a copy is meaningless unless the copyright holder has some means to regain possession of the copy. [United States v. Wise, 550 F.2d 1180 (1977), the Ninth Circuit U.S. Court of Appeals precedent relied upon by the court (involving sales of motion picture reels)] requires the court to look at a transaction holistically, and the court finds no basis for the conclusion that an agreement to permit perpetual possession of property can be construed as reserving ownership.”

There is a clear drafting lesson here for software licensors who want to retain the legal ability to control the transfer of copies of their software: Make sure the license agreement, in addition to reserving ownership or title in the copies, does not allow perpetual possession of the copies, but limits possession to a definite license term, after which the licensee is unconditionally obligated to return or destroy the copies. Making license fees recurring, rather than one-time, also helps.

To be sure, the Vernor case is likely to be appealed to the Ninth Circuit, which may very well reverse or modify the district court’s analysis. The Wise case invoked by the court as controlling precedent was decided in 1977, a time when disco was king and business software was still in its infancy. Later Ninth Circuit cases, such as MAI Sys. Corp. v. Peak Computer, Inc., 991 F.2d 511 (9th Cir. 1993) and Wall Data Inc. v. Los Angeles County Sheriff’s Dep’t, 447 F.3d 669 (9th Cir. 2006), which examined the applicability of the first-sale doctrine to the transfer of software copies, gave far more deference to the characterization of the original transfer in the license agreement. The Vernor court found these decisions to be in irreconcilable conflict with Wise, and, therefore, using the rules of decision in the Ninth Circuit, ignored the later decisions (which it freely admitted would have required a judgment against Vernor, the software reseller) in favor of Wise.

The Ninth Circuit may soon, therefore, have a chance to clarify the legal metaphysics of what exactly distinguishes a sale from a license in a copy of software for purposes of the copyright law. For the time being, however, whether you’re a licensor or a licensee of software, it might be a good idea to take another look at that license agreement. If you need some help with this (or if you just would like to hear an exposition of the Wise ruling with “Disco Inferno” playing in the background), please get in touch with me.

Patenting Business Methods: The Floodgates Open – For a Time

Perhaps you’ve heard of In re Bilski, if not by name. At issue is the viability of business method patents, especially for processes that are implemented by computer or over electronic networks (namely the Internet). Most software and web patents are for business methods. After the U.S. Court of Appeals for the Federal Circuit confirmed in State Street Bank v. Signature Financial Group, 149 F.3d 1368 (1998) (involving a patent for a tax-avoidance method) that methods of doing business could be patent-eligible subject matter if they produced a “useful, concrete and tangible result,” a flood of business method patents were issued during the dot-com boom of the late 1990’s and early 2000’s. This period also saw a commensurate spike in cease-and-desist letters and “offers to license” from holders of business method patents, many of them “patent trolls” who had no interest in commercializing their inventions, but only in extracting license fees and infringement damages from companies with little inkling that apparently routine or ubiquitous methods and processes could be patented.

With incredulity and outrage mounting in the early years of the new century, the courts and the Patent Office began to eyeball business method patents more skeptically and moved to stem the tide. In 2001, the court hearing Amazon.com’s infringement suit against Barnesandnoble.com wound up invalidating Amazon’s “One Click” patent for a single user-action electronic fulfillment method on the ground that it was obvious in light of the prior art. The Patent Office has now instituted a procedure whereby patents for computer-implemented business methods are given an independent second review, resulting in far fewer business method patents being issued and a corresponding decrease in applications. Unlike copyrights and trademarks, a patent is extremely expensive to apply for, maintain and defend against invalidation, requiring tens of thousands of dollars in attorney and filing fees — and if litigation is involved, that amount is usually multiplied tenfold or twentyfold. A good friend of mine who is a patent attorney laments, “A lot of what I do is talk people out of applying for patents.” That may hurt the firm’s bottom line, but it is the right attitude from a client service standpoint, particularly now that the availability of business method patents may be severely curtailed.

Bilski: Patentability Requires a Machine or Transformation of an Article

Which brings us back to Bilski. In that case, the Patent Office refused to grant a patent for a method of hedging risk in commodities trading, not on obviousness grounds (which was the issue in the Amazon case), but rather because the application was not directed to patent-eligible subject matter. To be patentable under the statute (35 U.S.C. §101) an invention must be a “new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof.” Business method patents are “process” patents. The Federal Circuit, hearing the patent applicant’s appeal, agreed with the Patent Office that the application did not describe a patent-eligible “process”. In its en banc (full panel) opinion, reported at 545 F.3d 943 (2008), the court rewrote the legal standard for patentability of business methods, throwing the validity of more than a decade of business method patents into question.

Under the generally controlling legal test (referred to as the machine-or-transformation test), a process is only patentable if (1) it is tied to a particular machine or apparatus, or (2) it transforms a particular article into a different state or thing. (I call this the “generally controlling” test because the court speculated cryptically that some business methods could conceivably be patentable without satisfying the test, but did not care to elaborate.) The rationale for these limitations is that the patent statute was never intended to protect abstract principles, laws or phenomena of nature (even if just discovered) or mental processes, since, as the court put it, these are “the basic tools of scientific and technological work.” In the court’s view, requiring the limitation of process patent claims to a specific machine or the transformation of some specific matter safeguards against a patent owner pre-empting all uses of a fundamental principle that everyone ought to have resort to in the furtherance of progress.

The need to prevent any patent owner from pre-empting all uses of a principle leads to some further caveats. First, if a principle can only be implemented using a particular machine, limiting the patent claims to that machine will not turn the principle into a patent-eligible process. So, far example, in Gottschalk v. Benson, 409 U.S. 63 (1972), discussed extensively in Bilski, the Supreme Court held that a numerical algorithm for converting binary-coded decimal numerals into pure binary numerals was not a patentable process even when limited to a digital computer, since the algorithm will always be implemented on a computer. (This concept obviously has great significance for the validity of many software and Internet business method patents.) Secondly, limiting the patent claims to a single field of use also will not make a patent-eligible process. As the Bilski court noted, if the opposite were true, then one could patent the Pythagorean theorem as used in surveying. Finally, “insignificant” pre- or post-solution activity, such as data gathering or recording a result, which may involve some peripheral use of a machine or a transformation of matter, does render a principle patentable. Of course, what activity is “insignificant” is less than clear and will be the subject of much future patent litigation.

Applying the machine-or-transformation standard with these caveats, the Federal Court affirmed the Patent Office’s denial of the patent claims for the risk hedging method. It also eviscerated (without formally overruling) its ruling in State Street by holding that the “useful, concrete and tangible result” standard is no longer valid. At the same time, it rejected the proposition that business methods are never patent-eligible subject matter. Since the patent statute allows a patent to be issued for a “process,” a business method is patentable subject matter if it is tied to a particular machine or transforms an article into a different state or thing.

If the Supreme Court affirms the Federal Circuit’s reasoning, most business methods implemented through software or Internet will no longer be patentable. As discussed by the Federal Circuit in Bilski, the Supreme Court, in Diamond v. Diehr, 450 U.S. 175 (1981), held that a software algorithm can be used to control the execution of a physical process (curing rubber) which is patentable when considered in its totality, i.e., including the software component. Likewise, the court noted that manipulation of electronic signals or data can form a patent-eligible process (on the basis of a transformation of matter) if the signals or data are not abstract but represent tangible physical objects (e.g., X-ray data that is manipulated to produce images of bodily organs). However, the business method in Bilski involved, at most, the transformation of risks and liabilities, which as intellectual abstractions are not eligible “articles.”

Should I Patent?

What do all of these arcane patent rules mean for technology clients? One the one hand, investors see patents as valuable assets, and so they are – if they are actually issued and the claims are broad enough so that a competitor can’t easily maneuver itself outside their reach. A “patent pending” notice also lends gravitas to one’s website and marketing materials (you can use this notice just by filing a provisional patent application, by the way). However, rejected patents and narrow patents do very little good for anyone, except the lawyers, of course.

Whatever the Supreme Court ruling in the Bilski case (and I expect an affirmation of the Federal Circuit’s approach at least in part), the change in the legal landscape will be largely limited to process patents and to business method patents in particular. Someone looking to obtain a patent in a composition of matter, a machine or a manufacturing process should not stop the patent train to await the Court’s ruling; while some general concepts in Bilski, namely the unpatentability of natural phenomena, mathematical formulas, etc., are applicable to all types of patents, as a practical matter, unless you’re trying to patent some naturally occurring compound, for example, the case doesn’t have much relevance if your invention is not a business method. On the other hand, I would strongly advise clients desiring protection in pure software or Internet processes to file a provisional patent application at most (which is cheap) but hold off any non-provisional patent application for a few more months. (You can file a patent application up to one year after the invention is first publicly sold or used or disclosed in non-confidential fashion.)

Consider Trade Secret Protection for Software and Other Business Methods

Moreover, unavailability of patent protection, or of broad patent protection, does not mean the total absence of intellectual property protection. Clients and counsel evaluating IP protection strategies for a new invention often overlook the need to balance the costs and benefits of patent protection against those of trade secret protection. (Software is also protectible by copyright.)

Patent protection is, by definition, a grant of exclusivity in a limited set of claims for a limited period of time (20 years) in exchange for disclosing a new, useful and non-obvious invention into the public domain. Patent applications become public after 18 months (whether or not a patent is actually issued) unless the applicant disclaims foreign patent protection. If no patent is issued or protection is granted in only a narrow set of claims, the applicant has obtained little or no competitive advantage for its money, and now the secret is out. On the other hand, by instituting procedures to treat a proprietary process or business method as a trade secret, such as internal access restrictions, limitation of external disclosures, use of confidentiality agreements, confidential or proprietary legends on material relating to the process or method, and logging who has contact with it, a company can preserve legal rights against usurpers for a theoretically indefinite period of time. Trade secret protection requires no legal fees and no filing fees. (Copyright protection requires nominal legal and filing fees.) If the Supreme Court embraces the Federal Circuit’s reasoning in Bilski, trade secret (and copyright) protection should supplant patent protection as the optimal strategy for many software and web clients.

As always, stay tuned. Oral arguments before the Supreme Court have been scheduled for November 9. You can expect to find updates on those arguments, as well as an analysis of the Supreme Court’s opinion and what it means for your business, on this blog as events unfold.

Your IT vendors laughing at the contract you signed

Hours of Support

Standard support hours in most IT support contracts are 8:30 am to 5:30 pm Monday through Friday, excluding national holidays. The first question to think about is whether you want to require 24 x 7 x 365 support coverage. Of course, the vendor will tell you it costs more, but consider pushing them on this point. If a critical system malfunction happens at 5:31 pm on Friday, and Monday is Christmas, according to the standard contract language they won’t even take your call, much less task resources to start working on the problem, until 8:30 am on Tuesday. In the meantime, you may be unable to process transactions, and/or key web functionality may be offline.

Even if you decide that the ability to call for support outside of normal business hours is not necessary, make sure that the hours of coverage listed in the contract correspond to the time zone where you are located. If your business is in Philadelphia and the coverage period is given in Pacific time, then you will essentially have three unsupported hours each morning. Also, if a “critical” bug or outage (which should be defined in the contract as one affecting a critical function of the application or equipment or one that results in a substantial inability of the application or equipment to perform the tasks it was designed for) is reported during normal business hours, the vendor should be required to work “continuously,” notwithstanding the regular coverage period, to deliver a correction or suitable workaround as soon as possible. (In other words, they can’t stop work at 5:30 on Friday and pick up again the following week.)

Standard of Diligence and Response Times

Most initial drafts of IT support contracts (i.e., vendor’s standard forms) have wishy-washy language stating that the vendor will “respond” to bug or outage reports and “attempt to fix” the reported problems. Sometimes you may see language assuring that the vendor will use “commercially reasonable efforts” to resolve issues — a favorite lawyer’s trope because no one really knows what this means and, therefore, it’s difficult or impossible to prove in court that the vendor did not use “commercially reasonable efforts.”

If you are purchasing support, you should make sure that bugs or outages are classified by levels of severity and that, at a minimum, the vendor is required to use “continuous best efforts” to correct these problems or provide suitable workarounds, either as soon as possible or within some specific timeframe that is acceptable in view of the impact the problem is likely to have on your business operations. “Continuous best efforts” is another lawyer’s term of art, but is understood to impose a very high standard of responsiveness. To use “continuous best efforts,” a vendor must work tirelessly around the clock and devote the full resources of its business to solving the problem, which, of course, is what you want.

In addition to requiring a high standard of diligence from the vendor, it is also desirable to negotiate specific requirements for initial response to a support request and regular follow-ups. For example, you might require a vendor to respond to an initial notification of a critical bug or outage within two or four hours and provide status updates every four or six hours until the problem is resolved or its severity level can be downgraded. You might also require the vendor to propose a workaround and remediation plan (i.e., a plan for restoring functionality, including projected timeframes) within a certain time after initial notification. The exact time requirements will vary as a function of the operational impact a serious bug or outage is likely to have.

Escalation Procedures

You should consider adding a procedure to the support contract by which, if a certain amount of time passes without a critical problem being fixed, the problem will be escalated up through successive levels of technical support and product engineering all the way to senior management, with a Vice President or Senior Vice President responsible for product engineering or customer service eventually taking charge of the situation. There is no motivator like the threat of the big boss getting involved if the worker bees can’t keep the customer happy.

Remedies

What happens if a critical bug or outage remains unresolved after an unacceptably long period of time? Your business is bleeding, and all too often the contract may not require the vendor to provide any remedy other than continuing to plug away at the problem. This is particularly likely to be true where the warranty period for the application or equipment has expired. Therefore, if possible, try to include a liquidated damages clause or a partial refund of the product and support costs if the product under support cannot be fixed within the time period that your business needs. The vendor’s counsel will often resist this approach because it introduces a contingent liability or a contingency that may prevent the vendor from recognizing revenue. Ultimately, it is a question of risk allocation — who should bear the loss if the product fails outside of the warranty period, but during the period for which the customer has purchased support.

Some Support Traps

When purchasing an important IT system, make sure that the support contract guarantees the availability of support for at least several years after purchase (many support contracts contain tautological language stating that support can be purchased under the contract as long as the vendor has not discontinued support for the applicable line of products, or something like this). Also, where a cap on annual support fee increases has been negotiated, make sure that the contract does not give the vendor the ability to terminate without cause at the end of each support year. (Otherwise, the vendor could use this termination right as leverage to negotiate away the cap on fee increases. Sneaky, but it happens.)

It’s Always Five O’Clock Somewhere

Support contracts often are not as carefully reviewed and negotiated as the IT licenses or product purchase agreements they accompany. However, a strong support contract is a vital component of operational risk mitigation, and if you’re paying for it, you should have some comfort that your vendor will not be at a happy hour at the most vulnerable moment for your business.

CAVEAT: When I’m representing vendors, expect me to push back on a lot of this stuff.

The American Law Institute (ALI) is not a legislative or judiciary body, and its holdings, therefore, do not immediately carry the force of law. “Immediately” is the operative term, however, since the ALI’s publications and draft laws (particularly its magisterial Restatements of major bodies of American law) command great attention and respect among judges, law professors, leading practitioners and other vanguards of legal evolution and are widely regarded as authorities in their respective areas. Hence Microsoft and The Linux Foundation’s grave concern over the ALI’s “Principles of the Law of Software Contracts,” expressed in an open letter to the ALI dated May 14, 2009. (The letter can be downloaded here.)

The primary bone of contention is a provision in the Principles that creates a warranty by “transferors” of commercial software to anyone in the normal chain of distribution that there are no material hidden defects in the software of which the transferor was aware at the time of transfer. This warranty is implied and non-disclaimable, meaning that the licensee’s rights exist even if no warranty appears in the license agreement, and there is no way for the software provider to shirk liability for the warranty, such as by including standard boilerplate in its contract stating that the software is provided “as is, with all defects.” The warranty does not apply to software provided “free-of-charge,” only to software which is transferred for payment, but, as Microsoft and The Linux Foundation point out in their letter, this exclusion is a little ambiguous, since some vendors’ revenue models involve charging for services or support of software rather than for the initial software download or purchase. In their letter they also requested a delay in the adoption of the Principles so that software developers and distributors could have more say, but the ALI turned them down, approving the Principles at its May 19-20 annual meeting.

Having represented both software vendors and software licensees on countless occasions, I agree with Microsoft and The Linux Foundation that a non-disclaimable implied warranty of no hidden defects represents a radical departure from the law of software licensing as it exists today. Courts have generally held that software licenses are governed by Article 2 of the Uniform Commercial Code (UCC), which also provides for implied warranties to protect buyers of goods, but enables vendors to disclaim these warranties by including certain prominent language in their contracts. In other words, Article 2 of the UCC provides default terms which parties to a contract are free to bargain around. It is not clear why software should be treated any differently from, say, the computer on which it runs. Furthermore, high-dollar-value software acquisitions are usually negotiated transactions between sophisticated business entities, who often submit — or should submit — the agreements for review by licensing counsel (that’s where I come in).

Now that the Principles of the Law of Software Contracts have been adopted, software vendors and users and their respective counsels will have to wait to see whether courts and legislatures will follow the ALI’s lead in granting new rights to licensees. Please check this blog for the latest updates.