9

Should I guarantee or add a warranty clause to my contract in the event code breaks or an anomaly occurs outside the client's hand or act of God?

If so, what should that language say?

Dan McGrath
  • 11,163
  • 6
  • 55
  • 81
  • 2
    what are the consequences of code failure? software, even major commercial software, is more generally provided "as is" with no warranty - in fact, in pretty much all shrink-wrap software the EULA will disown any responsibility of the softwares use. So, I'd suggest you go that route. Otherwise you leave yourself open to being sued for everything you have and will ever earn because your software threw up an error message preventing grandma from seeing her descendants facebook message, and died of the distress caused at being told something had gone wrong. – TZHX Feb 24 '11 at 21:11
  • 1
    ... you'll need to provide more information on the specific situation before people can provide an informed answer, but usually in a contractor scenario, part of the contract will involve the client "signing off" on the software before paying the final amount. You would usually be expected to perform some amount of validation to demonstrate that they can be confident in the product. – TZHX Feb 24 '11 at 21:14
  • If something fails because of an Act of God (force majeure) why would it be your responsibility to fix it under terms of a warranty? That legal provision exists to exempt people from being held liable for events that occur that are beyond their -- or anyone else's control. – Adam Crossland Feb 24 '11 at 21:17

6 Answers6

13

Unless your client demands some kind of a guarantee or warranty, don't go offering one. Many clients will end up using it to force you into indentured servitude.

Even if they do demand one, consult a lawyer. Otherwise, you are setting yourself up for catastrophe.

Adam Crossland
  • 9,688
  • 2
  • 35
  • 46
  • 3
    This is exactly why nearly all code you find freely on the web has the words "PROVIDED AS-IS AND WITHOUT WARRANTY". – James Love Feb 24 '11 at 21:10
  • @JamesLove: That's partly because nobody's going to provide any sort of warranty without being paid for it. Look at the license agreements for commercial software. The only case I've heard of a software vendor extending and honoring a guarantee was TurboTax. – David Thornley Feb 24 '11 at 22:17
6

Should I guarantee or add a warranty clause to my contract in the event code breaks or an anomaly occurs outside the client's hand or act of God?

No, never

If required don't take the job. This is an impossible situation. There is no end to the list of things that could be changed that would cause your code to break or not work.

Unless you like working for free, then go right ahead.

Josh K
  • 23,019
  • 10
  • 65
  • 100
3

The standard way to respond to this is to add a support or maintenance clause - "the first 10 hours of work included for free, the rest available at the following rate:".

blueberryfields
  • 13,200
  • 8
  • 51
  • 87
3

I upvoted Adam's "don't do it", but offering such a warranty for a commercial software product might get a lot of favorable attention from customers. It would also show you had huge cojones compared to the rest of the industry. :-)

I might consider offering a warranty under the following circumstances:

  • It's my product, as opposed to work-for-hire for somebody else.
  • I had control over the entire software development and release process, including specification, programming, testing, and documentation.
  • I carefully specified in the documentation the circumstances under which the software could be run for which the warranty would apply. For instance, hardware requirements, no running under OS emulators, etc.
  • I limited the period of the warranty.
  • I was really confident of the quality of the software

In that case, I might offer a warranty something like, "For a period of one year from the date of purchase, we guarantee that if the software does not run substantially as documented in the user manual, we will fix it and issue a free update."

That doesn't sound like much of a warranty, but it's far more than most commercial software has, reassures customers that you'll fix bugs, and the word "substantially" leaves enough wiggle room that you won't go broke.

If it's contract programming for somebody else, forget it. I once got into a situation similar to that, porting a Windows program to the Mac, and lost tens of thousands of dollars fixing "bugs" that were actually hidden features in the Windows version that the client conveniently failed to mention before we signed the contract, even though we'd repeatedly asked for specs. That experience was one of the main reasons I quit doing fixed-price contracts.

Bob Murphy
  • 16,028
  • 3
  • 51
  • 77
  • Thanks for the comments and suggestions! As we've never had a client ask for this before, this does help us immensely. First time for everything. –  Feb 24 '11 at 22:13
  • The problem with software warranties is that you're shipping identical versions, so if you make one serious mistake everybody collects on the warranty. They're dangerous. – David Thornley Feb 24 '11 at 22:15
  • Oh, no, you don't **pay** people on a software warranty! It should be like a warranty on a car: you just guarantee to fix the problem. Except in the case of software, you just do a bug fix. I'll update the answer. – Bob Murphy Feb 24 '11 at 23:29
2

It's common to give a warranty that include bug-fixes for a specific period after project end (say 3-6 months). This says to the client that you stand behind your code, and frankly you should have some liability to issues that you deliver with your code.

What we usually do in our projects is offer an SLA (service level agreement) that defines what bugs are and the timetable for fixing them according to their level of severity. For example, critical issues on a live project should be resolved (at least attempted) within 1 hour of receiving the report. Visual issues and minor bugs should be resolved within 48 hours.

It's very important to have a clear definition of what a bug is - since clients will often try to work in new features as bug reports (sometimes unintentionally). Those definitions are always somewhat open to interpretation, so you need to assign an arbitrator (usually an authority in the development language / platform) that can arbitrate disagreements.

Eran Galperin
  • 1,592
  • 10
  • 26
0

The wording of the contract would have to state things similar to the following:

  1. You may not extend this code
  2. You may not reverse engineer this code
  3. You may not integrate this code into your framework (Similar to #1, but different in the sense that it becomes an entire layer of their business)
  4. You may not port this code to other operating systems (IE windows to unix)

Just a few I could think of.

Woot4Moo
  • 914
  • 6
  • 8