By Mike Gunderloy
When you agree to write a program for a client, you probably think you’re selling the client some code to run on its computers, and that’s it. Suppose you’re consulting for a chain of dry-cleaning stores, and they want a networked program to make it easier for them to search across every garment in every store by color, style, and ticket number. Their goal is to make it simple to find lost garments, and you know that with your knowledge of databases and distributed systems, you can do the job.
A few months later, you hand over a couple of CD-ROMs with the executable code and instructions for the client's network administrator to install the database. What could be simpler?
That’s certainly the typical consultant’s point of view. But it’s not likely to be the customer’s. Depending on how technically savvy the client is, what it thinks it can get away with, and how outrageous it feels your fee is, the client might demand:
- 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.
- The right to prevent you from marketing the application to competitors for a limited time.
- 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 the client or not.
Obviously, it’s in your interest to give the company as little of this as possible, and in the company's interest to demand as much as it can get. This is why we have contracts.
Always have legal look it over
You should always hire a lawyer when you need to write a contract (or when, as may be more likely, you need to review a contract that someone else has written).
What can you put in a contract?
You can put anything in a contract. (Well, anything that doesn’t break the laws of the appropriate jurisdictions or contravene public policy.) Look at your contract as a way to formalize your relationship with the customer, not just on intellectual property issues (though I’ll focus on those here) but on all aspects of your consulting engagement.
Working without a contract is one of the best ways to set yourself up for 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) to settle whose ideas were right.
A description of the work product is essential. This 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 this can’t be known 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-on work products and schedules.
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 the client tells a business reporter who their largest customer is, are you free from your obligation to keep such information confidential? More importantly, from the standpoint of your own property, make sure any confidentiality provision is not written so broadly as to encompass your own work, unless you’re getting compensated for this.
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 the client the software itself. This will leave you free to sell copies to other customers. If the client balks at this, you can negotiate what you consider reasonable limitations; perhaps what the client really wants is exclusive rights for a period of time or within a particular industry.
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).
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. 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
Once again, the contract is the appropriate place to settle these issues. Consultants sometimes feel awkward raising these issues with a customer, fearing they’ll blow the sale by seeming intransigent from the outset. But if the customer is reasonable, you shouldn’t have anything to worry about. And if the customer isn't reasonable, wouldn’t you rather find out about that before starting the work instead of when you’re sitting across an arbitrator’s conference table or in a courtroom?
One more tip: Pay your lawyer to draw up a boilerplate contract that you’re happy with, with a space to fill in the client’s name. If the sales meeting goes well, you can leave a copy with a remark that these are your standard terms. You can always decide to leave it in your briefcase if things don’t go so well, or if the client beats you to the punch by handing you its standard terms instead.
So far, I’ve been assuming that you’re negotiating intellectual property issues in good faith with a potential consulting client. But there’s a second concern to keep in mind: What about those individuals with no good faith who want to flat-out steal your work? While more of a concern for those selling shrink-wrapped mass-market products, reverse-engineering is a concern any time you’re not selling the actual source code. It’s a special concern when you’re working in a modern language that supports reflection, which makes decompilation a trivial affair. Java and .NET both suffer from this potential weakness.
Enter the code obfuscator. Code obfuscators are programs that take your application’s executable code and remove some of the information that the computer doesn’t really need. For example, you might have a method named CheckLicenseKeyNow. The computer doesn’t care if that’s renamed to Plergb, so long as the change is made everywhere in the application. An obfuscator will go through your compiled code, changing all of the identifiers to remove any clues that a human with a decompiler can use to make sense of your code.
Obfuscators can pull many other sneaky tricks as well. If a language supports overloading, and two methods of an object have different signatures, there’s no reason they can’t have the same (nonsensical) name. Loops can be unrolled, logical tests converted to more confusing (but logically equivalent) tests, and strings can be encrypted. The goal is simply to raise the bar. You can’t prevent someone from decompiling Java or .NET code, but you can go a long way to ensure that what they get as a result is a stew of confusing jumps and meaningless names.
There are many obfuscators on the market, from freeware applications to commercial obfuscators that cost hundreds of dollars. If you find yourself selling software in any circumstance where you’re not comfortable including the full source code, consider making use of an obfuscator.
Better safe than sorry
Every once in a while, I run into a developer who simply refuses to consider these issues. “I didn’t get into software development to waste my time with lawyers,” they say. “I treat my customers fairly and they treat me fairly.”
Well, that may be, but I think such people are living on borrowed time. All it takes is one serious misunderstanding with a client in the absence of a contract, and you’ll be spending more time than you ever dreamed of with lawyers. Take the time to conduct your business in a professional manner, make sure everyone is in agreement from the start of the job, and you’re likely to be much happier in the long run.
Mike Gunderloy is the lead developer for Larkware, an independent software development shop in eastern Washington state.