There is an ancient truism among attorneys that "An oral contract is not worth the paper it wasn't written on." - a truism so old that it was first written in Latin.
And it is absolutely true.
Any lawyer will tell you that, at least in theory, oral agreements are enforceable in court, but in practice they seldom can or will be simply because it is almost impossible to prove the terms of an oral contract.
Like any other oral contract, verbal agreements to develop, modify or maintain software are usually worthless. If you are working under one now, you are relying solely on the good will of your customer to pay you. If he does not, there is probably little you can do except withhold the software -- not much help when it comes to paying the mortgage.
I am always surprised at the number of highly intelligent people who will commit a year of more of their time and expertise to a complex project on the mere hope they will be paid sometime in the future.
A written software development agreement is an admitted nuisance. We usually cannot write it ourselves, so we have to hire that most dread of all individuals, an attorney. This costs money and time. And, frankly, odds are that our customers will pay us and that all will go well with our current projects, so we will never actually need it.
Until we do.
When the customer claims he can cancel the project without notice and does not have to pay us for the four months of work we have already done, we will be very, very unhappy that we did invest the time and money in a written agreement with somewhat different and far more reasonable termination and compensation provisions.
The written agreement is our safety net. We will usually not need a safety net, but when we do we will be very happy to have one.
A properly written software development agreement defines the outer boundaries of correct behavior of the parties toward each other, helps prevent disputes, and if disagreements develop, provides a means of resolving them without getting the courts involved. And if the dispute does end up in court, it defines for the court the legal duties required of us and our customers and clarifies who owes what to whom, making it much easier and quicker for us to get the compensation to which we are justly entitled (with suitable interest, of course).
Now that you are convinced that you need a written agreement, what you need to do it find a lawyer and get him or her to work. So there is no point in reading the rest of this article. Well….
Actually, there are a few good reasons why you should.
First, you will want to know what to look for in a software development contract just to ensure that your attorney has actually covered all the necessary elements. Second, you will need to be prepared to discuss the provisions you want in your agreement -- no two agreements are the same (If they are, they shouldn't be). And third, as an independent businessman or -woman, you just need to know this stuff because this is the legal environment within which you conduct business.
Specifications
Exactly what is the application going to do? This is what the customer most wants to know. Specifications are the "builder's plan" of the project, the blueprint, the outline, the… well, you get it.
It is to everyone's advantage to be as specific as possible. The clearer the specifications, the less likelihood of misunderstanding, customer dissatisfaction and eventual litigation.
Not only is writing clear specifications a necessary part of the agreement, it is almost always our first opportunity to start analyzing and blocking out an application, dividing it into modules and roughing out a progress plan. It is surprising how many developers agree to develop an application with only the vaguest knowledge of what will be required.
Once the clearest possible specifications are drafted, including flow and process charts if warranted, it is time to review them with the customer. Clarify anything that is not understood, fill in any gaps, and make absolutely certain the customer understands what you propose to do before you drop a contract on his desk. That way there are no surprises.
There are probably as many ways of writing specifications as there are developers writing them, but they generally fall into one of three classes:
Statement of Work: This is the most general form of specification. It provides an overview of the work to be accomplished with limited functional grouping and virtually no technical discussion. This is most suitable for very simple projects or initial letters of intent.
Functional Specifications: The most effective in my experience are functional specifications: clear non-technical explanations of what the application will do with no mention of how the application will do it. This format is the easiest for the customer to understand, and does not tie you down to a specific technical means which you might want to change later without having to renegotiate the contract.
Technical Specifications: With technical specifications, you describe not only what you will do, but how you will do it. The technical specification is the most detailed design blueprint. It often follows acceptance by the customer of the functional design specifications and is included in the contract as an addendum to the functional design. When dealing with IS departments, technical specifications are often the only specifications that are acceptable. This level of detail takes a lot of time, and you should be paid for it under a design contract.
Irrespective of what form of specifications you use, the specifications should clearly set out what platform(s) and operating environment(s) the application will be written for and what access and support the customer will provide. If you do not limit the platform and operating environments, you may be presumed to have agreed to develop for all of them (more about this below). If you do not clearly spell out what support and access the customer will provide, you may be stuck with completing the application on time and on budget even if the customer does not provide them.
Once you and the customer agree to the specifications, they are usually attached to the written contract as addenda and referred to in the contract language such as ".. the terms and specifications set out in Appendix A and made part hereof by reference as if fully restated anew herein" or something like that.
Timetable
A small project may be done in one swoop, but a large project requires phasing. You agree to deliver a certain part of the project in working order at a certain time, and the customer agrees to pay you a specified amount at that time.
There are a number of advantages to phasing:
There are also a number of important rules to phasing:
Once the timetable is agreed to, it also should be incorporated in the contract either as an appendix or, since it is usually short, in the text of the agreement itself.
Payment
If the project is phased, the developer usually gets paid at the end of each phase and a final payment at the end of the project.
Contracts specify one of two forms of payment.
The fixed price contract pays the developer a specified amount for the project (and each phase) no matter how much time it takes. This type of contract is usually viewed as most favorable to the customer since he is guaranteed a product at a certain price.
The other form is the cost-plus or time-and-materials contract in which the developer is paid for the time spent and actual costs of the project. The time-and-materials contract is usually seen as most favorable to the developer.
As a practical matter, however, they are about the same. If we have done our specifications and timetable carefully, the project is probably going to take about as long as we initially figured and since even a fixed price contract is based on our best estimate of the hours required, the cost to the customer should be about the same either way.
Given a choice, I almost always go for the fixed-price contract. If you are a fast coder and can beat the "book" time, you will make more money -- maybe almost as much as your auto mechanic. Of course, you take the risk of an unforeseen problem that will require an inordinate amount of time to solve -- but often these situations are so gross that the contract can be renegotiated to cover them.
The payment schedule should always be in the body of the contract.
Just Whose Code Is It Anyway?
Customers are often astounded to find that even though they have paid you a lot of money to develop their application, they do not own the code from which the application was compiled and linked. The source code and the application are two different things - the kind of distinction that lawyers love to make even though they baffle the rest of the world. But just as buying a car does not give you ownership of the factory that made the car, buying an application does not give a customer any rights to the code that made the application.
Nevertheless, you do not want to confuse your customers about ownership of the code. Confused customers are unhappy customers who do not pay. Get the issue of ownership in the agreement and settled up front.
How source code ownership works does not seem to be very well understood in the FoxPro™ developer community. But it is really quite simple.
You do not own just the code. Your ownership would then be limited to those electronic bits in your computer or the scratches on the paper that make up the physical code. You own more than that. The code is an intellectual property subject to copyright. What you own is the code and the
The very instant code is created, it is copyrighted. Contrary to what you may have heard elsewhere, we don't have to actually do anything to copyright code -- the copyright law takes care of it for us. A copyright attaches to original writings immediately upon writing.
Not only is there an instant copyright, there is an instant
We may perfect our copyright, but we don't have to. Perfecting a copyright is no more than a legal formality for
One of the purposes of a written agreement is to determine who will own the source code - that is, who will hold the copyright. There are various degrees of ownership from the developer wholly owns the code, to the customer wholly owns the code, and every possibility in between.
Some customers insist on owning the code, in which case our price for developing the application should be higher. In fact there should be a specific transfer of ownership to the customer in the agreement at a agreed price over and above the price for developing the application.
Other customers don't care to own the code. But even though the law provides that if the agreement says nothing about who owns the code, the developer owns it by default, there should be a provision to the effect that the developer will retain ownership of the code. That way there are no unhappy surprises.
Protecting Your Toolkit
If the customer is to own the copyright on the code, how do you protect your toolkit? You know, the framework, base classes, functions and procedures you developed over many years that you use as the basis of every application you write.
Some or all of this toolkit will end up incorporated in the customer's application. If he owns the code, does he then own your toolkit? Yes, he does. Unless the agreement specifically says he does not. So be careful. If the customer owns your toolkit, you cannot reuse it in another project without the customer's permission. You probably do not want to sell all those years of development experience for the price of one application.
Make certain the agreement specifically excludes your toolkit and any modifications you might make to your toolkit while writing the application, listing in general the classes, functions and procedures included in the toolkit. Also ensure that as you are developing the application, toolkit items included in the application are identified as such and a copyright notice written in the code in a prominent place - for example at the top of each object method and procedure library. Then keep a dated copy of the code just in case the issue arises later.
To permit the customer to use your toolkit in his application, the agreement should specify that the customer receives a non-exclusive license to use the toolkit items. Notice the "non-exclusive". If you give the customer an exclusive license, it’s the same as having sold the toolkit outright.
Platforms and Operating Systems
You write the application. It works perfectly. The customer is happy and everyone is all smiles. Then the customer changes from a Novell server to an NT server. It does not work anymore. The customer wants you to come fix your "bug", for free, of course.
The contract should clearly inventory the customer's platform and operating system and the agreement should state that the application will perform on that platform and operating system only. If the customer "upgrades" to Windows™ 2002 (which will not actually be available until 2004), it should be clear that any modification to the application to accommodate the new operating system is additional work, and will required additional payment.
Which brings us to the subject of …
Warranties
Our customers would like us to guarantee that our applications will work perfectly forever. Giving such a warranty, however, would be prima facie evidence that you are totally out of your mind and thus legally incompetent to enter into a binding contract of any kind. But giving some level of warranty is inevitable.
I have always worked on the basis of reasonableness. If the customer has paid me a lot of money for a complex application, I should expect to warrant it for a year or even longer. If he has negotiated me down to bare bones, I am probably not going to be quite so generous.
Actually the software agreement should provide a number of warranties. The
But there is also the Warranty Of Ownership which states that the customer will get good title to the application. If you have given a interest to your bank in work in progress to secure an operating loan, you may have to get a release from the bank in order to give the customer good title. This is the warranty you got on your house. The seller warranted in the deed that he was giving you good and unencumbered title.
The Warranty of Non-Infringement says that in developing the application you have not violated anyone else's copyright, trade secret or patent. So if you used the framework you appropriated from your old employer, be careful. If the employer sues your customer, you will be paying the customer's cost of litigation as well as any damages the court may award to your old employer and any damages awarded to the customer for your breach of contract. This could get fairly expensive.
These warranties have no term. They are forever and ever "while the sun rises and the grass is green" and perhaps a little longer. Furthermore, even if they are not included in the software development agreement, they may attach to the agreement as a matter of law in your state as implied warranties - in fact, they probably do. So, to make certain the state does not write them for you, ensure your lawyer does.
Other implied warranties should be specifically excluded. These are the
The Warranty of Fitness may be a special problem. It holds that if you knew or could reasonably be expected to know your customer's purpose in contracting for the software, you may be liable if the software does not fulfill his purpose even it fully meets contract specifications and even if the purpose was never included in the contract. Some states do not permit these warranties to be excluded from consumer contracts, but most state laws have no problem with excluding them from commercial contracts between businesses. That's us - commercial contracts between businesses. But if you do not exclude them, they are ordinarily included as a matter of law. So make sure they are out.
Dispute Resolution and Enforcement
One of the principal purposes of a written software development agreement is to head off disputes. But if a dispute arises, the well-written agreement generally provides a means of settling the dispute that does not involve the time and expense of going to court. These are called
Arbitration is the more formal of the two. An arbitrator acts like a judge, taking evidence from both sides (usually in fairly informal process) and giving a decision. Arbitration can be binding or non-binding. If it is binding, the parties agree to abide by an decision of the arbitrator. If it is not binding, then either party may disregard the decision and sue. But there is usually a penalty clause to the effect that if a party sues and loses, he pays the winner's attorney fees and other litigation costs.
Mediation is the process of resolving a dispute through an objective, neutral facilitator who attempts to aid the parties in reaching a settlement. A mediator has no power to make an independent decision on the issues. He merely assists the parties in reaching a fair accommodation. Obviously this works best if the parties are still being reasonable. When they stop being reasonable, someone might as well go ahead and sue.
Whichever you choose, agree on an arbitrator or mediator in advance and identify the person or organization in the contract. Otherwise, the first thing you may disagree about if a dispute arises is who the arbitrator or mediator will be, then you are only one short step from the courtroom.
Avoid the boilerplate arbitration clause where you pick an arbitrator, the other side picks an arbitrator, then the two of them pick a third arbitrator. If you are going to pay for the time of three professional arbitrators, you might as well go to court. It's cheaper.
Most larger communities have formal arbitration/mediation organizations, many sanctioned by the American Arbitration Association. There are also local and regional associations which can provide referrals to arbitrators and mediators who are often retired judges of some distinction. Actually, it is often possible to get a better, more experienced, judge by going to arbitration than by going to court.
The Standard Boilerplate
Everyone makes fun of
Here are the boilerplate clauses that are important and should be in every software development contract.
The Whole (Entire) Agreement Clause: This clause says essentially that the written contract (with attachments, modifications, amendments, etc.) is the "whole agreement" between the parties, and that there are no other documents or oral understandings that are part of the agreement. This prevents the situation where the customer admits that the contract states that he must pay you, but then says that you later told him verbally that he really did not have to. What you may or may not have told him is not admissible because it is not part of the written contract. The written contract alone contains the "whole and entire agreement" of the parties.
The Severability Clause: Your clever lawyer inserted a clause to the effect that in the event of a breach of contract by the customer you get to sacrifice his first born to the Great and Magnificent Oz. Any court is going to find that clause void as against the rather sound public policy prohibiting human sacrifice. But you don't want the rest of the contract to be void with it. Hence the severability clause which says that if one part of the contract is found to be void or unenforceable, it is severed, and the rest of the contract remains valid and enforceable.
Choice of Forum/Choice of Law: You live in Peoria, the customer is an Alaskan business corporation domiciled in Landsend, Alaska. If you go to court, you do not want to go to court in Landsend, you want to go to court in Peoria. Choice of Forum/Law clauses state that in the event of a lawsuit, the suit must be brought in Peoria and the contract interpreted under Illinois law, not whatever law is applicable in Landsend (assuming there is some).
The "No Partnership" Clause: Your customer goes bankrupt and a lot of stiffed creditors are looking around for a deep pocket. They spot you, a wealthy software developer. They sue you, claiming that the software development agreement you entered into with customer created a joint venture and that as a joint venturer with customer you are legally responsible for his debts arising out of the venture. Whoa, Nellie! Bet you never saw that one coming.
To eliminate this possibility, the agreement should contain a clause that unambiguously identifies you as an "independent contractor" and not "a partner, employee, agent or joint venturer" of the customer, and should clearly state that "neither party is responsible for the debts or obligations of the other".
This clause is also helpful if the IRS comes poking around and wants to reclassify you as an employee to void all those nice business deductions you claimed on your Schedule C (even including the ones that were actually true).
Terms and Definitions Clause: Sometimes called the "Interpretation" clause, this is the famous "up shall mean down" clause where every word in the English language seems to have been given another, different and obscure meaning.
Actually the clause is both useful and necessary. Lawyers use terms of art that have the same spelling and pronunciation as the English words but which are not English words. They are legal terms that have a very precise meaning. Terms of art are just shorthand permitting a lawyer to use one word rather than a whole phrase to impart precision to a document. It is often necessary to distinguish between a word used as an English word and the same word used as a legal term of art. This is the clause that does that.
It also defines terms such as "we" when used in a contract. If there are two parties to a contract, which one is "we"? Without the definition contained in this clause, it is often impossible to know.
One word of caution, though. Terms and Definitions Clauses are often the most boilerplate of boilerplate. Many attorneys adopted a favorite terms and definitions clause while still in law school and have not actually looked at it since. Therefore you should. If you find the word "Client" defined but it is the word "Customer" that is used throughout the contract, point it out. Poorly drafted terms and definitions clauses can get you in trouble - the courts will use them as written, so you'd best see they are written to say what you intend.
Written Modifications Clause: This is the clause that provides that the contract may only be modified "in a writing signed by both parties". It means what it says. Oral modifications have no effect. Get any changes in writing signed by the customer. The abuses this protects against are self-evident.
Finding and Hiring a Lawyer
So now you know what goes into a software development contract. Do you know enough to write your own? Probably not. So you need a lawyer. How do you find one?
The kind of lawyer you need is an intellectual property lawyer. These are the guys and gals that specialize in contracts for non-tangible property, copyright registrations and often patent applications. In larger communities they are in the Yellow Pages. In smaller communities you may have to (1) go to a larger community or (2) search the Web.
The most common resource for finding a lawyer is the Martindale-Hubble Directory which can be found on line and in most law libraries. The on-line version is most up to date. Be aware, however, that lawyers pay to get into Martindale-Hubble and their qualifications to do the kind of work advertised are sometimes aspirational and not always thoroughly checked.
After you have found a lawyer, how do you make certain he or she is qualified? And this is important because like any other trade or profession there are good lawyers and poor lawyers, and lawyers that are good at some things and lousy at others. The best way to hire a lawyer is the same way you hire a plumber: interview, ask questions, and check references.
Lawyers, who generally consider themselves a small step above plumbers, are loathe to give references. But if you insist, you will get them. Note carefully: if a lawyer tells you that giving out the names of his clients is an unethical violation of attorney-client privilege, stand up and walk out. He just lied to you, and there is no reason to believe he will not continue to lie to you. But no lawyer will give out a client's name without checking with the client first. So do not expect to get references immediately.
When the contract is done, read it. If you do not understand any part of it, have the attorney explain it until you do. By the way, if the lawyer can explain it in English, he or she can probably write it in English. Insist on it where possible. Unless your customer has his own lawyer, you may end up being the one who explains it to your customer. It's a lot easier to explain English that it is to explain "legalese."
Writing it Yourself
So you are one of those brave and hardy souls who is willing to take big risks - sky diving, para-sailing, formula I racing. Well, you'll probably be as successful at writing the contract as a lawyer would be writing your application. But before you put fingers to keyboard, first try one of the on-line legal document sites. One or two are not bad. The best for this kind of document may be QuickForms which has fairly good standard software development, modification and licensing agreements for about $20.00 each. Their response is quick, about one minute after your credit card is accepted. These boys do not dither around.
Even if you are bound and determined to write a software development agreement yourself, at least start with the QuickForm document, then modify it to your heart's content. It does not, by that way, meet all the criteria set out above. But it is much, much better than no agreement at all.
Oh, and good luck.
Copyright © 1993-1999 Jurix Data Corporation. All rights reserved.
