The contract


This section answers all the who, what, when, where, and why of contracts. We define a contract and its purpose and answer some general contract questions. We also stress why contracts should be used for every project you do for a client.

What is a contract?

A software development contract is an agreement between a consultant and a client. These agreements can be verbal or written. It is the blueprint for handling conflicts that could occur during the development process. It sets up expectations by defining who is responsible for what, what is going to be included and what is not, who owns the code, and licensing restrictions. These are the areas of main concern for most developers and can be covered in one contract document or separate documents. The section ‚“Contract Clauses ‚½ later in this chapter covers the various sections you should consider in a contract.

Contracts don ‚ t have to be huge documents full of legalese. Create a document you would like to use and take it to your attorney. Your attorney should be able to add the clauses you left out. These are usually the ones most normal people wouldn ‚ t think about putting in and are discussed in the ‚“Contract Clauses ‚½ section later.

You want to make sure you cover the issues that concern you the most. For instance, if you are a fanatic about knowing what state ‚ s law governs the contract, make sure you include it so it won ‚ t be left to the legal system to decide. If you don ‚ t normally provide a warranty and you aren ‚ t worried about this issue don ‚ t include one. However, keep in mind that the issues not addressed are left to assumptions. No contract is going to protect you from everything, but it does help establish the expectations and open the lines of communication between you and your client.

Keep in mind that once you have a contract you are happy with you must take it to your client. You may think it is a very equitable contract, but your client may not think so. The client will make their changes and you will go back to your attorney to review those changes. This could take several iterations and cost several hundred if not thousands of dollars.

Why do we need a contract?

There is a very vocal minority of consultants who feel all the formalities of a contract turn off the clients . However, once it is understood exactly why a contract should be used you ‚ ll most likely not want to go without one again. The main reasons we use contracts:

  1. Contracts allow all parties involved in the project to work from the same set of assumptions.

  2. A signed contract is a legally binding record of what has been agreed to.

  3. Contracts provide awareness of some conflict producing situations that may occur when entering into an agreement to develop a software application.

It is important to discuss possible conflict producing situations early in the relationship so if there are disagreements they can be settled and added to the contract. If the conflicts can ‚ t be settled it is best to find this out before being caught in the middle, or even worse , the end of a project. Too much time and money has been invested by this time making it difficult for either party to ‚“give in. ‚½

Going over the contract also allows for discovering the parties have very different philosophies and shouldn ‚ t work together and can amicably part ways. If you are developing in-house applications some of what gets covered in a contract should be incorporated into the company ‚ s policy and procedures manual.

Who should supply the contract?

Well, it ‚ s going to be either the consultant or the client.

The developer

If the developer supplies the contract, the developer may be at a slight advantage. The contract will contain all of the clauses important to the developer. It will also be more complete and include all the items a client would tend not to have. Most clients or their counsels don ‚ t get involved in professional services contracts, especially software development. The developer is more familiar with their own contract so if the client has a question about a specific clause the consultant can provide a satisfactory answer.

Utilizing legal software packages or canned/prewritten contracts is a good way to become familiar with computer contracts. If you are going to use them, be sure not to alter any of the legal wordings. To do so may invalidate important clauses. It ‚ s always good practice to have your attorney review these types of documents also. Always use an attorney who specializes in computer law or intellectual property law and has experience negotiating software development contracts. We recommend using software or prewritten contracts to get started. Decide which paragraphs are most important and/or necessary, and then take it to an attorney for review. Another option is to have an experienced computer law attorney provide a contract based on their experience and expertise.

The client

When presented with a contract that belongs to the client be sure to read carefully; remember it ‚ s not your contract being signed. Sometimes large corporations want to use their standard contract. This isn ‚ t necessarily a bad thing, but read it over very carefully and watch out for the key paragraph describing the work to be done as a ‚“Work for Hire. ‚½ If this clause appears in the contract, be advised that the ownership of any code written for the client is theirs exclusively. This includes all of the developer ‚ s intellectual property used to develop the application.

Developers can protect themselves from losing their rights to their intellectual property by having this clause removed. If the client refuses, the developer should think twice about working for this client. If you choose to sign the contract as is and include previously developed code like a login routine, this login routine now becomes exclusive property of the client and you won ‚ t be able to use it again for your next client. If you do the old client can sue you for copyright infringement.

Another option is to include a paragraph that states you can reuse and maintain exclusive rights to any previously written code incorporated into the client ‚ s application. Therefore, the client does not have exclusive use of this previously written code and this code could be used in the developer ‚ s next project. The client will only have exclusive use of new code.

The employer

Companies own the code and any other copyrightable materials their employees write. If an employee leaves the company, the employee can ‚ t take any developed code (.VCXs, .PRGs, etc.), business and technical design documents, database models, UML designs, e-mail correspondence with employer ‚ s clients, or training manuals to use on future projects for anyone . Any copyrightable material you develop while employed belongs to the employer. If the employee takes any of these kinds of materials, uses them and the employer finds out, the employer can sue.

In a recent conversation with another developer about this issue, he claimed the Copyright Act states that because the employee was the author of the code the employee owns it. Section 101 of the Copyright Act the ‚“Work for Hire ‚½ clause is the exception. The only way the employee could retain copyright ownership is if the employee has a contract with the employer that specifically assigns copyright ownership to the employee.

If you are an employee and you ‚“moonlight ‚½ on the side, you have to carefully document when and where you work on the moonlight projects. If you come up with the million-dollar application, your employer may try to sue you and say they own the code you used to create the million-dollar application, or say you developed the app on their time, dollar, equipment, and tools. Protect yourself by:

  • Keeping a log of when and where you worked on the application

  • Being sure you are developing as a professional and not using your employer ‚ s software, hardware, or tools.

    Note ‚  

    No matter who supplies the contract, have your computer law attorney look it over. Even as an employee it is a good idea to get acquainted with a good computer law attorney.

What could go wrong with a handshake?

Well, honestly, quite a bit. Handshakes are a communications signal between two people, in our case the client and the developer, that an agreement has been reached. But that ‚ s all it is, a gesture. Because this is a gesture between two people, what happens if the client representative gets transferred or worse ‚ fired ? This means no one else at the client site really knows what was agreed to and the client could refuse to pay.

Also, handshakes leave no written record of what was agreed to. Neither party can prove what exactly the deliverables were supposed to be, therefore the client could refuse to pay saying, ‚“That ‚ s not what I wanted or agreed to. ‚½

Last, we have the problem of remembering what was or wasn ‚ t said leading to assumptions. Some of the assumptions often made are the Client assumes copyright and code ownership and lifetime support. Many Clients don ‚ t realize in the absence of a written contract the rights of the developed application default to the developer. The developer can make assumptions like the client is going to supply the test data.




Deploying Visual FoxPro Solutions
Deploying Visual FoxPro Solutions
ISBN: 1930919328
EAN: 2147483647
Year: 2004
Pages: 232

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net