This is the text of a short speech I gave at the Skirball Cultural Center on July 6, 1999, as part of the VIC Presents series. The issue of ownership of the developer's tools continues to come up in drafting and negotiating contracts, small and large:

Thanks for inviting me.

I’m going to address a specific issue in IP rights relating to a project – that of ownership of certain kinds of the developer’s usually more technical creations -- such as a unique search engine or other database driven solution. This is an issue I see regularly in my practice.

The premise to the transaction we are dealing with is simple. The client, usually a corporate entity, sometimes in interactive media, more often not, needs a web presence, and hires an interactive agency to develop and/or execute its plan.

As opposed to the traditional ad agency model, the interactive developer is a content provider and a technology solutions provider. Each of these roles implies its own set of needs and requirements for the developer and the contract drafter.

As a content provider, in the advertising agency model, the job is to take the information provided by the client as to the needs of the client and the type of experience the client wants the target market to have, and create that experience, -- complete that mission. It is natural and traditional that, in all but the unusual cases, the client will expect to own free and clear, the fruits of the developer’s labors.

However, as a technology solutions provider, the “solution” maybe a new high-powered search engine, or some other nifty database solution that might be very attractive to the developer’s next client, and something that the developer could then modify for the next client, and sell at a lower price than it costs to reinvent the wheel, while making some profit on the process. It’s similar to how all good and conscientious transactional attorneys work; if I develop some great language which elegantly solves a particular problem, I will certainly use it again the next time that problem presents itself to me. My clients will get my experience and best work, and I’ll do it faster, and, therefore, for less. Everyone benefits.

Here’s the problem:

Assuming that there is a written agreement, which there should ALWAYS be, in the absence of detailed rights language in a developer contract, the standard “Work Made For Hire” language will provide that the Client owns everything that is created relating to the project, or, even more dramatically, everything that is contributed by Developer to the project. This fails to take into account any nifty solutions that the developer might have created in a previous project and any similarly bitchen solutions the developer might come up with during the project. If you are the developer, do you hand over your latest and greatest invention knowing that doing so will result in the client owning it? Hence the tension between the parties.

How does it get resolved?

As always, it depends on a number of factors. Often a client starts with the attitude that, “We’ve paid for it, we own it. End of story.” That’s often where the conversation starts. First, you ask questions about the nature of the transaction and the nature of the parties.

QUESTIONS

1. WHO’S GOT THE LEVERAGE? . . .Is the client huge? Is the job huge? Is the developer desperate? I think we can see how that one is going to turn out . . . unless someone like me representing the developer can convince the client or its attorney that we’re not as desperate as we actually are.
   
   
2. Who is the client? Simply a company with a need for a web presence, or someone who can be a competitor to the developer?
   
   
3. Does the client need to know that no one else can ever use this proprietary technical solution? Is it a design-oriented feature? Is it going to be a cornerstone solution that is going to create a serious advantage for the client against its competitors?

If the answer to some of these questions is yes, it will be tough, but not impossible, to negotiate retaining these rights for future usage. If none of these factors is present and the developer has someone handling the negotiations who knows what he or she is doing, there is no good reason the developer can’t retain some rights to its creations; there are compromises that can work for all parties.

SOLUTION

Often the solution involves parceling up the various rights, defining the various categories of intellectual property, and give them different rights status. I will use terms I commonly see as the defined terms. These vary from contract to contract.

Work Product –

“Work Product” is the work created by the developer for the project that typically is what the target audience sees. In any scenario, this is almost always owned in its entirety by the client Work for Hire or through a broad grant of rights.

A common definition of Work Product which appears in developer contracts looks like this:

-- Work Product means all programs, systems, data and materials, including but not limited to, images, graphic user interface, source code, object code, and any documentation and notes associated with the Web Site, in whatever form, first produced or created by or for Developer as a result of, or related to, performance of work or services under this Agreement.

Background Technology –

“Background Technology” means creations of the developer prior to date of the agreement which are usually proprietary technical solutions, and often also includes “off the shelf” software licensed by the developer from a third party for use in the final product. That sub-category is sometimes called Developer Tools.

A common definition of Background Technology which appears in developer contracts looks like this:

Background Technology means all programs, systems, data and materials, in whatever form that do not constitute Work Product and are: (1) included in, or necessary to, the Work Product; and (2) owned solely by Developer, licensed to Developer with a right to sub-license, or licensed directly to Client. Background Technology includes, but is not limited to, the following items: Computer code generated by programs proprietary to Client, and commercial programs such as MacroMedia Director and Lingo, Adobe AfterEffects and PhotoShop and all other Developer Tools.

Rights to the Background Technology are usually, but not always, retained by the developer, with a license to the client which can look like this:

Background Technology. Notwithstanding anything contained herein to the contrary, Client agrees that Developer shall retain any and all rights Developer may have in the Background Technology. Developer hereby grants Client a perpetual, non exclusive, worldwide, royalty-free license to use the Background Technology in the Web Site or any related Internet application.

Developer Tools -

A common definition of Developer Tools which appears in developer contracts looks like this:

Developer Tools means the software tools of general application, not originally created by Developer, its predecessors or affiliates, whether now owned by or licensed to Developer or directly to Client, which are used to develop the Web Site, including, without limitation, commercial programs such as MacroMedia Director and Lingo, Adobe AfterEffects and PhotoShop.

With regard to the Developer Tools, the Developer obtains the license it needs from the software company and passes it along to the client.

I’ve seen this one over the last several years:

Generic Components -

Generic Components usually refers to technical solutions developed by the developer during the project. A common definition of Generic Components which appears in developer contracts looks like this:

Generic Components means the software/programming tools developed generally to support Developer products and/or service offerings and which (i) can be used in Web sites and systems other than the Web Site developed hereunder, and (ii) can be used completely free of the Client Content and (iii) do not embody or convey the look and feel of the Web Site developed hereunder.

There is still lots of resistance by the Client to releasing ownership of something it’s paid Developer to create. But the principle is still the same. The Developer needs it – the Client doesn’t.

The negotiations and the solution usually looks like one of the following.

1. “You created it with our money; we own it!” Work For Hire; owned entirely by the client;
   
   
2. Work for hire, owned by the client, but with a license back to the Developer for its future use. That language can look like this: Notwithstanding the foregoing, Client hereby grants Developer an irrevocable, non-exclusive, worldwide, perpetual license to reproduce and modify the Generic Components. This license back is often accompanied by a non-compete preventing the developer from using the same Generic Components in the client’s industry.
   
   
3. The developer retains ownership of the Generic Components, but grants Client a non-exclusive license, with the following language: Developer hereby grants Client a perpetual, non exclusive, worldwide, royalty-free license to use the Generic Components in the Web Site or any related Internet application.; The same non-compete as above will often be granted to the Client.