By Richard E. Neff, May 24, 2010: Reprinted and/or reposted with the permission of Daily Journal Corp. (2010).
One of the most fought-over issues in technology development and licensing agreements concerns intellectual property ownership. Superficially, who owns the intellectual property should be easy to resolve. The developer or publisher of a proprietary computer software program virtually always owns the computer program (except for possible open source components). Nobody contests Microsoft’s ownership of Excel, or Autodesk’s ownership of AutoCAD.
At the other end of the spectrum, when a large company commissions a development house or even individual developer to do custom development for it, whether of a Web site or of computer or systems code, and the client pays for such development, generally, the company that commissioned the development owns it. In most cases the developer will sign an agreement stating that the developed code is “work for hire” or “work made for hire” under U.S. copyright law, which means that the recipient of the custom development will be deemed the absolute owner of such development. The developer will have no further rights to use any of it.
The difficulty lies in the enormous gray area between these two easy cases. Generally, the issue surfaces when a talented systems integrator or developer, often renowned in a narrow area of development (e.g., Flash Web development, or data integration development), is asked to do some development for a large company. These contractual relationships sometimes are called professional services relationships or consulting arrangements or even customer services agreements. The company that needs some custom development or systems integration work done is calling upon a developer with great expertise in the area. The expertise has derived from doing similar work for many customers, just as you would want your laser eye surgeon to have performed at least 500 operations before your eyes are touched.
This expertise carries forward from job to job, until the expert developer runs into certain large customers, such as a major studio or telecommunications company or bank, whose in-house lawyers often are trained to insist on ownership of everything, regardless of the merit of such a position. Why? Because they can. They argue that they are paying for the development, and they know that developers or integrators need prestigious studio and other marquee clients. Generally there is no argument over the developer’s ongoing ownership of “preexisting works” that it plans to deploy in the work done for the large client. If the developer lists computer programs or functions that it has developed previously, even studio lawyers generally will concede that the developer owns such works.
Those of us who represent developers and professional services providers often spend a lot of time explaining that the client has hired this developer because of its expertise. If this developer does some systems integration for a large client, the developer will employ methodologies, code, techniques and best practices that the developer personnel have developed and learned on prior jobs. Obviously the client does not want to pay for the developer to learn his or her craft on this specific job. However, if the prestigious client insists on absolute ownership of all such development, technically this might be the last job that the developer can perform in this area. Often, there may not be 10 different ways to skin this particular cat, the scope of the engagement may be narrow, and repetition of prior work by the developer or service provider may be inevitable.
To give the large clients their due, they do not want any restrictions on their ability to sell or transfer the custom work done, whether because they may in the future dispose of a business unit or sell the company. They cannot be in a situation where their desire to transfer their computers and software (including all related development) infringes some developer’s rights. And this freedom of action is a right they should have.
The logical solution is easy in concept: Any development done that is paid for by the client and cannot be reused by the developer because it is so client-specific should be owned by the client. Any development that draws on the developer’s expertise and can be reused by the developer on similar engagements should be owned by the developer, but the client should be given a perpetual right to use, modify and transfer such custom development. In this manner, the client is not at risk of infringing or violating the developer’s intellectual property rights. And the developer can continue to do the sort of custom development that has been at the heart of its business. Alternatively, it is possible to give ownership to the client, with a perpetual license in favor of the developer. The key factor is to ensure that both parties have the right to pursue their business models without violating the other party’s intellectual property rights.
When a marquee client is entirely unreasonable on this issue, which happens not infrequently, the developer has various options. Refuse the assignment and walk away. Identify very broadly and in detail the code elements that are preexisting works, so that the scope of the code or other custom development being produced for the client is as narrow as possible. Sign the onerous agreement, do the development, grant ownership to the client, and do what has to be done in the future. Many service providers and developers do this. While this “no harm no foul” approach may infringe upon the client’s ownership rights, in most cases, the future development that the developer will do for others is undetectable by past clients, and tied up by nondisclosure agreements and confidentiality provisions in any event.
One context deserves special discussion: If a Web developer is developing a Web site for a client, the client needs the assurance that it either owns, or has perpetual license rights, to the Web developer’s creation. Sometimes the Web developer is also the webhost, and in the future, the client may want to use a different webhost. Therefore, regardless of which party owns the developer-created portions of the Web site, the client needs the contractual right to exercise dominion over the entire Web site, including the right to move the Web site to any other webhost, or bring it in-house, and to be assured of the cooperation of the original webhost and/or Web developer.
Another less technology-focused scenario deserves mention also. I have encountered the situation where an advertising agency that created ad copy for a client intentionally failed to assign the copyright to the client, and the agency sued when the client stopped using the ad agency and continued to use the ads, on the basis that it (the agency) still owned the ad content. Therefore, in many contexts relating to creative content, the client must be careful to secure an assignment of copyright along with the ad copy. Unlike obscure software coding, ad copy is very visible to the public, and the creator generally does not have, and probably should not have, the right to own and reuse it with other clients.
Finally, there is a category of computer software code that grew up around the Linux platform, open source code. This code is used in conjunction with many proprietary software programs, and is governed by special license provisions (GNU General Public License, Apache license, etc.). Open source or “free” software is software whose source code is published and made available to the public, enabling anyone to copy, modify and redistribute the source code without paying royalties or fees. Open source code evolves through community collaboration. This code must be excluded from the assertions of ownership by either the developer or the client discussed in this article. In general, clients need not fear open source code, but care must be taken to identify such code so that it can be separated from proprietary code, and follow its license terms.
In negotiating ownership of technology development, so often size matters, and large clients prevail over the more practical needs of developers and integrators. However, reasonable compromises along the lines discussed in this article should break logjams in negotiations and allow each party to achieve its objectives and to maximize its utility.