>
Interesting. Thanks for the write-up. However, I take a different stance than you on the following point (IOW, I agree more with how the law stands).
>

As a software developer, I can't fault you for agreeing with were things stand.


>
I guess you're referring to situations similar to the one that John H brought up, in which you implied that the company got screwed.
>

Not really. I think the rationale is illogical. Lets say I am a carpenter and I build furniture for a company. They use the furniture in their business. Surely, they are free to sell the furniture if they so desire. Why should software get different treatment? Of course the issue can be argued both ways very effectively.


What I find intriguing is the spin on the employee vs. indendent contractor. I bet there are a lot of folks who are technically independent contractors - but for purposes of this subject matter may fall into the cateogy of employee. I know a lot of folks would disagree. However, this was the subject of much debate with MS some years ago with respect to benefits. It was a whole substance over form argument. And, the IRS has cracked down big time.

I just finished reading an article from the 7/19/1994 issue of the Connecticut Law Tribune. One of the paragraphs goes as far to say that because computer programs are not in the categories listed of 17 USCA 101 - computer programs cannot be the basis of work for hire. There, this issue turns on your status as employee or independent contractor.

How slippery is the slope?

In the NY Law Journal - dated 3/10/1992, there is an interesting article that discusses two cases: The Aymes and MacLean Cases. In Aymes, it was the classic contracter writing code for a client. The court in that case determined based on the structure of the relationship, he was actually an employee. FWIW, I thought the scenario sounded more like a contractor issue. However, the court did not see it that way and thus held the program as work for hire.

In the MacLean case, you had a guy who worked for a company that developed software for NYSE. MacLean, without telling NYSE, started his own firm but continued to do work for NYSE. In the eyes of the NYSE, he was an employee - working for the old company. From MacLean's standpoint, he was an independent contractor - working for another company. The court held that in fact, the guy from NYSE's perspective was an employee - and therefore - was bound to the agreement between NYSE and the old company. Hence, the work was work for hire.

The courts seem to feel that if you spend signficant time at the client site, you are like an employee. This is what the court held in the Aymes case.


So what is the deal here??? Quite simply, the correct analysis is not whether it is work for hire or not. Rather, the analysis is whether you would legally be considered an employee or an independent contractor. And absent a written agreement specifying the terms, who owns the code will depend on that ruling.

Therefore, it would be most incorrect to say that indepdent software developers have some absolute right to code absent an agreement. You can still be an independent software developer - but legally be classified an employee for purposes of the statute - and hence - the computer program becomes work for hire.

It is all a question of fact. It will boil down to which side can write the more persuasive brief. Personally, I don't think the argument should come down to employee vs. contractor. Rather, they should add a new category to the work for hire definition in the copyright statute.

So there you go...case law that goes both ways. And, a supreme court decision that gave us the Reid Test that courts use to determine if you are to be considered an employee or an indendent contract - absent a written agreement.

This has been an invaluable excersise for me...

< JVP >