While gellyfish is no doubt correct, I'm going to throw one in anyway. I distilled it from various sources, including a company that does mostly contract related work (that my sister works for).. Feel free to pick holes..

<Contract Template>
Date: <current date>
Name/Address: <customer>

Project: <short description>
Details: <long description>
Estimated length: <X days>
Completion by: <date>
Price: <$X>
Requirements: <eg access to source, persons>

Customer <X> hereafter referred to as 'The customer' ..

Standard business conditions:

1. Completed work produced in the project remains the property of the 
+customer, unless otherwise negoiated.
1a. The use of other, freely available software modules is allowed (th
+ese will not be the property of the customer, but remain the property
+ of the community).
1b. Any existing or newly created generic reusable software modules wi
+ll remain the property of the contractor.

2. Estimated time and price include the following:
2a. Creation of software to fulfill the project goals.
2b. Documentation of software, both user and admin manuals, unless sta
+ted otherwise.
2c. Clearly defined milestones (project tasks), and up-to-date informa
+tionabout the progress of each task.
2d. Meeting/Discussion time to clarify project goals. Using Instant Me
+ssaging / EMail methods. Email and IM exchanges will be retained for 
+reference, with 'meeting minutes' summary docments created as appropr
+iate.
2e. Installation and user support for 14 days after completion of proj
+ect.
2f. Project testing in an environment as near to the deployment enviro
+nment as possible. Test results will be available.
2g. Defect fixing after installation. (Subject to defect being confirm
+ed as such by the development team)

3. Estimates do *not* include:
3a. Change requests - wanted features which are outside the scope of t
+he original project specification, after the specification has been a
+greed upon and signed. These will be evaluated and added as appendice
+s to the specification, with new deadline and price estimates.
3b. Cost for changes: See hourly/daily rates.

4. Requirements:
4a. Appropriate access to any existing solution with which the project
+ solution must work.
4b. Access to persons needed to clarify any goals etc.
Delays in this access will result in delays to the completion of the p
+roject.
4c. Project specification detailing exactly which deliverables will re
+sult from the project and what they will do.
4c. Project specification must be agreed and signed by the customer be
+fore development can commence.
4d. Specific details to be set down in the Specification, of the envir
+onment in which the project will be used. (To ease local testing).

#5. We will not be liable for any disruption of work or loss of income
+ due to 
#the use or installation of the completed solution.
#5a. The customer will help in defining tests to prove the solution wo
+rks as
#requested, and will sign off the project upon completion.

5. Tests, work completion document
5a. A set of tests to prove the software works as required will be def
+ined.
5b. The customer will help design and approve the test suite.
5c. When the software has been tested according to the predefined test
+s, and the results are deamed a pass, a document will be signed by th
+e customer to acknowledge that the work is complete and functional.

6. Current specifics:
6a. Specification documentation will be delivered in MS Word format.
6b. User documentation will be delivered as HTML.
6c. Milestone reporting: Depends on project length, at least daily.
6d. Response time to problems with the installed solution: 'Urgent' pr
+oblems occuring within 14 days of installation, 2 hours, daytimes(8:0
+0-22:00 CET timezone).
6e. Problems occuring after 14 days will be treated as change requests
+, see above.
[download]

I should probably also note that it's only seen service once so far.. No doubt others have more experience.

C.