Chip Camden discusses how he handles the issue of code reuse in his IT consulting work and describes why you need to be smart about how you structure contracts and incorporate open-source solutions.
Do you have the right to reuse code that you create for one IT consulting client in an engagement for another client? Naturally, you learn new techniques as you work on a problem that you can't help but apply to similar projects in the future. But how different does the algorithm have to be in order to be free of your first client's copyright or nondisclosure agreement?
Before I describe how I handle the issue of code reuse in my IT consulting work, I'll share a trip down memory lane; this experience made me sit up and take notice of the issues surrounding code reuse.
A story of massive code reuse
In 1992, I served as an expert witness in a civil case in Chicago. A consulting firm sued one of its clients for nonpayment, and the client filed a counterclaim for nonperformance. In the counterclaim, the client alleged that the consulting firm used "nonstandard programming practices," which made the client overly dependent on its services. I was called in to render an opinion on whether the code complied with "standard" practices because the application was written entirely in Synergy/DE (my specialty), which is a flavor of DIBOL.
As soon as I saw the first module, I said "Yes, this is extremely recognizable. It follows the standard MCBA style, which more than 90% of DIBOL applications have adopted." An examination of the rest of the 12-inch-thick printout of the source code, and a three-hour grilling by the client's attorneys didn't alter my opinion.
To verify what I said, the client's attorneys contacted MCBA, Inc. and showed them the code. MCBA responded, "Yes, that's our code — and we want it back!" Indeed, many of the variables, routines, labels, and logic exactly matched those found in MCBA's source code. This raised the possibility that the client could claim the code provided to them under an unrestricted license might be encumbered with a copyright violation, supporting their claim of nonperformance. The case was never tried in court; the client settled with the consulting firm, and MCBA never pressed its rights, which might have been very difficult to defend.
In the 1970s, MCBA was the first highly successful vendor of accounting applications written in DIBOL for the DEC PDPs. MCBA sold its applications with a license to the source code included, and many of its customers went on to extend those applications and create new ones using very much the same style.
Back then, no one had heard of separating UI from business logic (sometimes the entire app had to run in 16 KB), so the parts that were copied and tweaked from one application to the next comprised what would today be called the presentation framework. The idea that MCBA might be able to claim a right to this code sent shivers down my spine because millions of installations could have been affected by a decision in the company's favor. Fortunately, MCBA now seems to embrace its early generosity to our industry.
Structure contracts wisely
The way IT consultants think about whether they have a right to reuse software has a lot to do with how they structure their contract. For instance, if you grant your client all rights to the software you produce, be extra careful not to replicate recognizable copies of the code for any of your other clients.
I find it useful to have two classifications for software rights in my contract: (1) rights to the "Work product," which is code created specifically for the client, and (2) "Background rights," which are rights to any generalized software that I might bring to the problem. My IT consulting clients get exclusive rights to the former and nonexclusive but unrestricted rights to the latter. My client should feel comfortable that I'm not going to reveal their secret sauce to their competitors and that nothing I put into their application will come back to bite them down the road (well, at least, legally). It also ensures that I can reasonably reuse anything in the "Background" category. (For an alternative approach, read #10 in this post about freelancing on creativebits.)
One of the many benefits to maintaining a site like Chip's Tips is that I am able to prove that a given algorithm was mine before it was a client's — in case there should ever be any question. An algorithm that was shared with the world under an open-source license cannot reasonably be made proprietary later.
Think before incorporating open-source solutions
If you incorporate open-source solutions into client software, you may be invalidating your client's proprietary licenses (if the client has proprietary licenses). The GNU General Public License (GPL) requires that any software licensed under the GPL can only be reused within software having a compatible license.
Even if it's just a technique you learned by studying the code of an open-source application, how different does your implementation have to be in order to avoid license infringement? You might be better off looking for examples licensed under more generous terms, such as those found in the CCD CopyWrite (which I use), BSD, or Creative Commons licenses.
Fess up about code reuse
How often do you reuse software solutions for different clients? Do your IT consulting clients always know about the code reuse? If they know, do they seem to care?Disclaimer: I am not a lawyer, nor have I ever played one on TV. If you're uncertain about how to protect your code, be sure to talk to a lawyer.