Coder to Developer: Tools and Strategies for Delivering Your Software

The first set of issues I want to consider are those that involve software you write for someone else under contract. Although most of us prefer to spend our time developing our own little programs for resale, the need to pay the bills often dictates taking consulting jobs of one sort or another. This means that you’re going to have to actually write a contract (or, perhaps more likely, review a contract that someone else has written). I’m not going to worry about things like insurance and delivery dates here. Instead, I want to focus on one of the key areas that is often neglected: making sure you protect your own intellectual property as you develop software for someone else.

Staking a Claim

When you agree to write a program for a client, you probably think you’re selling them the code that runs on their computers and nothing more. If the customer is running a chain of gas stations, say, you could be writing a database application that tracks hour-by-hour sales to make it easier to predict when to refill the tanks with minimum customer inconvenience. After a few months of work, you hand over a couple of CD-ROMs with the executable code and instructions for their network administrator to install the database. What could be simpler?

But in the absence of any contract, your customer’s point of view is unlikely to be the same as your naive developer’s ideas. Depending on how technically savvy your client is, what they think they can get away with, and how outrageous they feel your fee is, they might demand any or all of these things:

• A copy of the source code

• Exclusive ownership of the source code, so you can’t sell any part of it to any other client

• A royalty for every copy of the application you sell to any other company

• The right to make copies of your application and sell it themselves

• The right to prevent you from marketing the application to their competitors for a limited time (or for an unlimited time, for that matter)

• The right to veto any attempt on your part to sell copies of the application to other companies under any circumstances

• Patents, trademarks, and copyrights on any breakthroughs you made while writing the code

• Ownership of any code you wrote during the entire contract period, whether you were writing it for them or not

Generally, it’s in your interest to give the company as little of this as possible, and it’s in their interest to demand as much as they can get. This is why there are contracts.

Creating the Contract

What can you put in a contract? There’s a simple answer to that one: anything you like—well, anything that doesn’t break the laws of the appropriate jurisdictions or contravene public policy, anyhow. But that still leaves a pretty broad range of potential contract clauses. Of course, your clients will have their own ideas about what belongs in a contract, so you’ll likely need to negotiate somewhat to settle on a document that you can both sign.

Although you may find the entire thought of dealing with lawyers and negotiating contract details to be an annoying distraction from writing code, you must go through the process. Working without a contract is one of the best ways possible to set yourself up for a disaster. Without the contract negotiation, you and the customer may have vastly different ideas of what you’re being paid to do. Worse, it may come down to paying expensive lawyers (which they can probably afford better than you can) to settle whose ideas were right.

Here are some of the intellectual property issues that any well-written software consulting contract should include the following.

• A description of the work product A description of the work product is essential. It should spell out what the deliverables are, both in terms of functionality and in actual physical terms: Are you turning over object code, source code, design documentation, end-user documentation, or some combination of these? If you can’t determine this at the start of the contract because details won’t be clear until you’ve worked on the job for a while, consider a contract that explicitly allows attaching addenda with agreed-upon work products and schedules—and then remember to keep the attachments up to date.

• Confidentiality Make sure that you know what information the client considers confidential, and under what circumstances you are freed from any confidentiality provisions. For example, if they publish their customer list on the Web, are you free from the obligation to keep such information confidential? More important from the standpoint of your own property, make sure that any confidentiality provision is not written so broadly as to encompass your own work, unless you’re getting compensated for this. You might even consider a contract with a two-way confidentiality provision, prohibiting the client from releasing information about your own operations.

  If your work involves proprietary techniques or code that you want kept secret, you should consider having a separate nondisclosure agreement (NDA) that you ask clients to sign before you’ll discuss their projects in depth. That way, your trade secrets are protected even if a particular sales call doesn’t lead to a contract.

• A description of rights purchased A critical issue is what you’re selling the customer. From the consultant’s point of view, it’s often best to sell the client a perpetual, nonexclusive license to use the software rather than selling them the software itself. This will leave you free to sell the same (or very similar) software to other customers. If the client balks at this, you can negotiate what you mutually consider reasonable limitations; perhaps what they really want is exclusive rights for a period of time, or within a particular industry. Also, keep in mind that there are many different software licenses; I’ll discuss a few options in the next section.

• Ownership of utility code Code reuse is a fact of life in the software business, and as a working developer you probably bring a toolbox stocked with utility code to each assignment. Your contract should make it clear that you retain ownership of these common subroutines, even if the overall application is owned by the customer. It’s also worth spelling out how such common subroutines will be identified (one approach is to use comments directly in the source code to assert your ownership).

• Copyrights, trade secrets, and patents Spell out ownership of copyrights, trade secrets, and patents in the contract. This is one area that you need to settle before the question arises. Once again, you might find it simplest to grant a nonexclusive use license to the customer for anything you find patentable, assuming that the customer will agree.

• Limitations on client actions There are also actions you may legitimately wish to prevent the client from taking in the future; for example:

  • Disassembling or reverse-engineering the program

  • Installing the program on more than the agreed-on number of computers

  • Reselling the program to other companies

  • Creating derivative works

  • Making copies for any purpose other than backups

• Means of settling disputes Any contract should include information on how disputes will be settled. If at all possible, specify that disputes related to your contract will be settled by arbitration rather than by going to court. Arbitration is less expensive and more informal, and it’s much easier to argue your side in front of an arbitrator (and get a fair hearing) than a judge if you’re not an attorney.

You may feel awkward raising some of these issues with your customers. You might even worry that you’ll lose the contract by seeming intransigent. But if the customer is reasonable, they’re expecting you to negotiate a contract. And if they’re not reasonable, wouldn’t you rather find out about that before starting the work than when you’re sitting across an arbitrator’s conference table or in a courtroom?