Suppose you’re a software development computer consultant or consulting firm and your Fortune 500 client asks you to design and code a customized software system. The client’s goal is to achieve business nirvana: the sustainable competitive advantage. The software you develop, the Request for Proposal warns, will be integral to this task.
Your client has hired you, or your firm, because of your information technology expertise and your track record of delivering quality systems on time and on budget.
You get the contract from your client. It’s their standard form. You reach the “Ownership of Deliverables” section. Translating from the original eye-glazing Legalese, it says the following: “We, your valued Client, own EVERYTHING you produce while working for us. You assign to us all right, title and interest to EVERY conceivable intellectual property right in your work product, including its tangible expression and intangible contents, i.e., the IDEAS IN YOUR BRAIN embodied in the work product. So forget about providing a similar work product to anyone else.”
Contract provisions of this type are often so broad as to potentially have at least the following unintended unpleasant effects, from the consultant’s perspective:
- the consultant loses its right to use software development-related ideas and techniques it used before working for the Client if they are embodied in the work product;
- the consultant cannot add to its pool of accumulated knowledge the ideas and techniques it may have learned while working for the Client; and
- the consultant cannot use elsewhere any code it develops while working for the client, such as macros and other efficiency tools, even if such use poses no competitive threat to the client.
The Competing Interests of the Client and the Developer
The client’s objective is to maximize the value of what the consultant provides. The client doesn’t want the consultant to develop a system for the client’s competitors that would afford them a similar competitive advantage. Consequently, the client wants to “own” all rights to the software and related intellectual property. This includes not only the physical code (object and source), but the concepts embodied in that code that the Consultant might otherwise implement elsewhere.
The consultant’s objective is to preserve its own preexisting intellectual property rights in ideas and techniques, as well as code, it knew or developed before working for the client, even if they are incorporated to some extent in the work product for the client. In addition, the consultant wants to be able to use any new techniques and software tools it may develop while working on the client’s project.
Relevant Software Intellectual Property Rights
Development contracts typically speak in terms of the various intellectual property rights of which the software consists: copyrights, patent rights, and trade secrets. Copyrights pertain to the tangible components of the system, the software code and documentation. Most development contracts will grant the client exclusive ownership of all copyrights to the system. The result is that the consultant can’t duplicate the code it created for the client and deliver it, or a modified version of it, to another client.
Copyright ownership doesn’t address the ideas and concepts underlying the software. Patents and trade secrets are relevant here. A patent is a 20 year monopoly on the right to make, use or sell the patented invention. If any aspect of the software delivered to the client is sufficiently novel and unique to be patentable, the client wants to be the exclusive beneficiary of the consultant’s creativity. Accordingly, development contracts typically grant exclusive patent rights to the client.
Trade secrets similarly protect the ideas underlying software, but are of value only to the extent the dissemination of the trade secret idea or concept is strictly limited. Consequently, development contracts will typically prohibit the consultant from disclosing to others any elements of the software which, if used exclusively by the client, might afford the client a competitive advantage.
Apportioning Rights Fairly
It is certainly fair that the client obtain value from its system investment. It is equally reasonable that the consultant be able to build upon its experience and add to it the knowledge gained by developing the client’s system. From a contractual standpoint, this means drafting language that enables the consultant to continue to use the techniques and ideas it knew going into the client’s project, even if they are incorporated into the work product. Conversely, the consultant should grant the client a license to use these techniques and ideas as embodied in the work product, as opposed to owning them.
If the consultant develops a new technique or process reflected in the work product which might be patentable or protectable as a trade secret, the contract should explicitly state the parties’ respective usage rights, perhaps describing the different purposes for which they may be used, and in what contexts. A development contract proposed by the client will typically seek to afford the client exclusive ownership of these rights.
If there are portions of the code that would be useful to the consultant in other situations, and the contract grants copyright ownership to the client, the consultant needs to negotiate the right to re-use that code, perhaps only in situations where the client’s competitive advantage would not be threatened.
The challenge lies in analyzing the intellectual property rights comprising a system and fairly apportioning them between the client and the consultant. The goal should be to enable each to benefit from the development process in ways most relevant to its respective business. Drafting the appropriate contract language to accomplish this is a complicated, but essential task.
Attorney Eric Freibrun specializes in Computer law and Intellectual Property protection, providing legal services to information technology vendors and users. Tel.: 847-562-0099; Fax: 847-562-0033; E-mail: firstname.lastname@example.org.