Chapter 12: Legalese

Overview

Who owns the code? How do I license an application? What ‚ s a non-exclusive license? Why do we need to bother with a formal contract? Who supplies the contract? Intellectual property, copyrights, derivative works, oh my! Help! I ‚ m sinking in a pool of legalese. This chapter deals with the deployment issues handled in the contract and defines some of the legal terms developers should become familiar with.

Before getting too deep into this chapter, we must make a disclaimer:

Note ‚  

We are not attorneys nor do we claim to be. This book/chapter is not a substitute for legal advice. Much of what this chapter covers can be left up to interpretation. This is our interpretation. This is for information purposes only and shall not be construed as legal advice. To find out exactly what your rights are, you should seek the advice of an attorney that specializes in Computer and Intellectual Property Law. The information in this chapter is based on the present United States Patent and Copyright Laws. Please contact your attorney for verification of the governing laws where you do business.

We went into software development because we enjoy the technology associated with creating computer software applications. None of us ever dreamed we would need a law degree to develop and deploy computer software applications. Well, software developers really don ‚ t need a law degree, but you do need to be familiar with some basics of contract and computer law and educate yourself in the legal terms most often associated with computer software development. Why? Because developing software often involves contracts and contracts contain legalese you need to understand. The Internet also introduced easy ways to infringe on others development efforts.

This chapter mainly addresses contract issues for independent and small consultancies and corporations developing applications for third parties. We refer to this group as consultants . However, many of these issues cross over into corporate IT departments who mainly develop applications for their own use. For corporations these issues should be addressed in the IT department ‚ s policies and procedures manuals. We refer to this group as employees .

There are many phases to a software development project. Deployment issues must be addressed at each stage of development. The contract signing phase, one of the initial phases of the project, defines the working relationship. By going over the contract paragraph by paragraph, you and your client will uncover areas of contention and find out if you are able to agree on a compromise. You may find you can ‚ t. That ‚ s not necessarily a bad thing. It is much better to cut your losses before beginning the business relationship rather than be half way through the project, and then the client decides they should own the code. Some of the most conflict producing paragraphs of a contract are the ones dealing with who owns the code, software licensing, and non-competition.

The first part of this chapter covers some legal terminology used in software development contracts. It is important to become familiar with these often confusing terms. You will see them frequently. You will also meet clients and other developers who need clarification . You will be better prepared to educate them.

The next section discusses the contract in general. It answers questions like ‚“Why do we need a contract? ‚½, ‚“Who supplies the contract? ‚½, and ‚“What ‚ s wrong with a handshake? ‚½ Software development contracts can be as short as one page or as long as you want them to be. We know some consultants who don ‚ t even use contracts, but we don ‚ t advise that, especially in today ‚ s litigious society. So, how do you go about deciding what goes into a contract and how long to make it?

In the third section of this chapter we provide a list of all the paragraphs that could be in a contract, and highlight the ones that should be there. It is left up to you and your attorney to decide the clauses you need for your specific situation. We ‚ d like to point out that there is no one- size -fits-all contract. A new contract should be created for each client. We look at a typical software development contract.

Not only do software developers need to hone their legal vocabulary, but we need to dramatically improve our communication and relationship building skills. We touch briefly on this.

The last section covers licensing issues. If developers aren ‚ t familiar with the best way to license the application you could unknowingly cheat yourselves out of earned revenue. The client may have offices world wide, so find out how many offices are going to use the application. It costs more to support many offices than it does one. The licensing paragraphs of a contract need to address these issues.

If developers aren ‚ t familiar with the law you could unknowingly break the law. Here ‚ s a familiar scenario: You get a call from a frantic client, ‚“My consultant just quit and I need to get this application finished and deployed. I have all the source code. I got your name from a friend. Can you help me? ‚½ You could use the extra work, so you agree. You contract with this new client to finishes the application. You don ‚ t realize you may have just committed copyright infringement and be sued. Do you know why? You also don ‚ t want to be caught unable to answer a question a client may have. One of our favorites is ‚“What do you mean I don ‚ t own the code? I ‚ m paying you $150,000. ‚½ By the end of this chapter, you will be able to answer these questions.