Agreed. Always make contracted work a work for hire. A friend of mine did not and he ending up paying $20,000 additional to ransom his software back. That was 20 years ago when $20,000 was real money.
You also want to avoid having the employee become a Statutory Employee. See footnote 3 in the article. If that happens, you can be hit with all sorts of nasties like disability claims to IRS claims for withholding taxes.
It looks like there may be a CA minefield in there also if you DO make it a work for hire.
> Agreed. Always make contracted work a work for hire.
How? Per the article, you can only do this if the person making the work is an employee, or the kind of work is in that list (which does not include software).
...hmm. I wonder if, say, the Unix shellutils could be considered a "collective work" if each individual program was written by a different person.
The point, as I understand it, is that you don't get to determine what constitutes a work for hire - that is determined by law, and only 9 categories of things (or work done by an employee) count. Your contract may need to be written more carefully to ensure that you own the copyright when all is said and done.
Not quite. The law enumerates the things that are automatically work for hire. Works outside those must be explicitly declared works for hire in the contract. If you have done any contracting you will find the phrase in your contract "work for hire".
Literary works are not automatically works for hire. I believe that software is considered a literary work, strange as it seems. (IANAL)
> Not quite. The law enumerates the things that are automatically work for hire. Works outside those must be explicitly declared works for hire in the contract.
The article specifically says that this is not correct: "A work made for hire is not any work that you pay someone to create for you. Nor is it any work that you and a developer agree is a work made for hire.".
Per TFA (quoting the law) it has to be (1) done by an employee, or (2) both in the list of 9 kinds of things (which does not include software) and specifically declared to be a work for hire. Things that are not in the list and are not done by employees cannot be works for hire regardless of what the contract tries to claim.
You should always be clear who gets what when you freelance or when you hire freelancers. Any legal "default" would fail to capture the subtleties. For example, who owns the copyright to my "library code" when I use it in your project?
I always prefer to specify something like a BSD license to the code. That means that it doesn't matter who owns the copyright - we both get to do anything we want with the code. If the client wants exclusivity, then we explicitly agree that he gets 100% ownership of the code that was written just for him, and the remainder is BSD licensed.
None of this is hard, and none of it requires a lawyer.
I disagree about none of it being hard; there are a lot of potential pitfalls, and disputes may arise not just between client and provider, but between either of them and the labor or taxation authorities.
For example, A hires B to develop software tools for A's business, which takes 3 months of full-time work, during which B does not service any other clients. B gets paid and assigns all his interest in the code to A and both walk away happy. A year later B goes bankrupt or is involved in a messy divorce, and a court takes control of his assets. In the course of assessing B's financial position, they find the transaction with A was equivalent to employment, and that B's financial position would be better if it had been treated as such for the 3 months, which would in turn have made more funds available for B's alimony or creditors. A may be asked to make good on additional obligations that would have been payable to or on behalf of B, if B had been classified as an employee (social security payments or suchlike). Even if both parties agreed that B was an independent contractor, a court could invalidate that agreement on the basis that statutory obligations of employers took precedence and hold A liable for failing to meet those obligations. Or that A's payment to B was far below reasonable market rates, and the administrator of B's trust/estate/whatever may seek equitable relief from A. Or...
This is hypothetical of course, but not so far away from some real cases. And as far as copyright is concerned, disputes can and do arise after the fact, and an agreement that looked beautifully simple during friendship is interpreted differently under acrimonious circumstances. I was involved in a case like that last year as a witness, where a dispute arose between client and vendor relating to payment and delivery, the client sued the vendor and was counter-sued in turn, and the paperwork between them turned out to have holes big enough to drive a truck through. After a second visit to court yielded no result other than the parties threatening further legal action against each other (though mainly out of bravado rather than serious intent), I documented, copied, and quickly severed my relationship with both of them, feeling that no good could come of it. Not fun.
Perhaps, but this is probably the single most important bit of unique to software development legal advice there is.
(Can anyone think of something else that's more important? Not counting the usual stuff that applies to all companies.)
And you're right, it's neither hard nor requires a lawyer, but you must know about it and do the right thing, otherwise the person you hire owns the code he writes.
It's way more complicated than that. It also depends on how much control a contractor has over his task, hours, and tools. Even if you have a work for hire agreement, micromanagement can turn the contractor into a Statutory Employee. If you treat them as employees they may well turn out to be employees if anything goes to court. Microsoft learned that the hard way.
EDIT: Clarification: The IRS and Labor department dont really like independent contractors; it allows you all sorts of tax write-offs. They have a list of tests to see if you qualify: available to work for anyone, advertising, the list above, and a few other things. If you work at their site, using their equipment, and are micromanaged, you may be declared a statuary employee. A business license should be a simple remedy.
Micromanaging someone, dictating their tools, etc, are telling them how to spend their time. Which I would take to mean that they clearly must have sold you that time (regardless of what's on paper) rather than whatever they're producing with it.
That would be a "joint work", which is not in the list. What is in the list is "a contribution to a collective work", which has to be distinct from the whole.
http://www.copyright.gov/title17/92chap1.html#101 : <<A “collective work” is a work, such as a periodical issue, anthology, or encyclopedia, in which a number of contributions, constituting separate and independent works in themselves, are assembled into a collective whole.>> <<A “joint work” is a work prepared by two or more authors with the intention that their contributions be merged into inseparable or interdependent parts of a unitary whole.>>
