By: Janet Langjahr

March 28th, 2003

Reader Rating: 8.5

Of what stuff is a Website made? Or, more to the point, of what stuff is it not made? To me, that was the real legal question when a colleague consulted me about a dispute involving his client, a Web host-turned-developer.

The client had recently expanded and upgraded its in-house technical resources. However, it had neglected to refocus its legal mindset to reflect the technical shift it had made from building simple Websites, to developing powerful, software-driven sites and Web-based software. That oversight resulted in ill-suited contracts, and eventually jeopardized the company's copyright to a valuable source code library that it leveraged in projects for many different clients.

Fortunately, if you allow your technical insights to guide you in drafting contracts, you should be able to avoid this company's mistakes.

Whose Site Is It? What’s a Site Anyway?

Very often a customer will demand ownership of the intellectual property rights to a Website it orders. A customer can well argue that it would be tethered to the developing host if it didn’t own the site. This is a deceptively powerful argument that, in fairness, is difficult for many developer-hosts to refute. But therein lies a trap.

What does the customer bargain for when it orders a Website? What does the developer-host offer? With changes in Web development technology, the answers to these questions may not be as clear these days as they once were.

Before: Website = Look and Feel = Customer’s Brand

In the past, Websites contained only pure hypertext mark-up language (HTML). A Web page was a static display of visual elements: logos, graphics, layout, color themes, and, of course, text. HTML alone implemented the design and arrangement, the "look and feel" of a Website.

Custom-designed visual elements of a Website go to the heart of a customer's unique branding. Of course, a customer makes a compelling business argument for the ownership of these elements of a Website. And it’s fairly clear that the customer's interest in these elements of its site may be legally protected (though ironically, much of that “look and feel” protection may come from trade dress law more than copyright law).

So Web developers often enter contracts that grant the customer ownership of the customer’s “Website”. But what exactly does that mean today?

Now: Website = Logic = Developer’s Toolkit

Pure static HTML Websites are increasingly rare. Today, we have client-side scripted interactivity. We also have numerous platforms for server-side database handling and other server-based logic manipulations, or, in other words, full-blown programming.

Whether on the server-side or on the client-side, the logic powering a Website does not visually brand the Website.

Sorry, Logic Sold Separately ...Maybe

So, how compelling is the customer’s argument for ownership of the back-end logic that powers its Website? In my view, the customer is not fairly entitled to own the logic that powers the site -- unless the customer clearly bargained, and paid a premium, specifically for the ownership rights to the code (though of course, the customer is entitled to license, non-exclusively, the use of the logic).

What does the law say about the software behind the site? In my view, the answer is often unclear. If there is no contract, a non-employee developer generally owns the copyright to software they write and other intellectual property they create.

Note, however, that there are some important exceptions to this rule, and courts sometimes define "employee" differently to the way we might as regular people.

Make the Contract Say What You Mean

In practice, usually there’s a contract between the developer and the customer. Unfortunately, that contract typically refers to “The Customer’s Website”, without defining that term. The contract then purports to transfer to the customer ownership of that undefined “Website”. To me, this begs the question of whether site-enabling software is included in “The Website”.

Transfer of the ownership of software-powered Websites should raise some concerns in developers. If you don’t get your contract right, you may jeopardize ownership of your valuable source code.

The good news is that, with proper care, you should be able to give your customer the desired and deserved ownership of the branding features of its Website, and still retain rights to your software. That's a win-win scenario.

To achieve it, all you have to do is clearly distinguish the software powering the Website from “The Website” itself. As is usually the case, that is a manageable task if addressed head-on in the contract.

It's Never Too Late...

What if you already signed away a “Website” in a contract that doesn’t properly draw this distinction, and your customer makes a claim to the software you wrote to run behind the site? In this case, I believe you face the more expensive and challenging tasks of proving (to a non-technical judge or jury) that the distinction between the enabling software, and the rest of the Website:

1. cuts to the heart of whether there really was an agreement at all (the proverbial “meeting of the minds”), and

2. merits great weight in deciding the outcome under the specific facts of your case (since there is no contractual definition).

Programming 101 for Judges and Juries

How do you persuade a lay judge or jury how this distinction had to have underpinned the whole deal? I would argue that visual elements are basically one-shot deals. When a developer designs a logo for a customer, it must extract the full value or price from that customer - because it can never leverage (i.e., re-use) that logo for another customer. Similarly, HTML code cannot truly be leveraged.

Not so for true logical elements, whether script or programming language. Typically, efficient and sophisticated developers work harder and smarter to develop modular code that they can widely re-use, and repeatedly extract value from.

Therefore, parting with the copyright to code will, in effect, “cost” the developer time and time again. Tech-savvy common sense, fairness and business dynamics all compel the developer to give up code ownership only knowingly, and for an appropriate price.

Website Architecture for the Server Rack - and the Courtroom

How do you persuasively distinguish software from a Website for a judge or jury? Your software should be as different and as separate from the rest of the Website as possible. Ideally, your software should exist in wholly separate files (DLLs, EXEs or the like) and reside on a separate server from that which hosts the site. The beauty of that architecture is that it’s equally desirable from both legal and technical standpoints.

Conclusion

Based on Web-related contracts in wide circulation, the distinction between a Website and site-powering software is an obscure one. But, in the right circumstances -- if skillfully drawn, either in court or in contract – that distinction just might make the difference between profits and losses.

What happened with the client of my colleague, discussed at the beginning of this article? It decided to negotiate to avoid the uncertainty of the outcome of anticipated litigation. You see, that developer-host had a couple of strikes against it.

First, its off-the-cuff contract made no attempt to draw any distinction at all between the Website and the powering software. On the contrary, by its own reckless terms, the developer-host transferred to its customer intellectual property rights to "all property developed".

Second, that developer-host made no attempt technically to separate the Web user interface from the considerable amount of logic that powered the Website. Instead, it embedded all the logic in server-side scripts that resided entirely within the rendering Web pages. Sure, you and I know that it's still software, but try explaining that to a non-technical judge and jury.

Any way you cut it, it just makes plain good sense to separate your Web user interface from your logic -- both legally, preferably in a clear and thorough contract, and technically, in implementation architecture.

NOTE: The preceding article contains general information only. It does not contain legal advice. For legal advice, you should consult an attorney about your specific situation.