><i>A highly recommended practice is to institute a clause which covers a variety of scenarios of assignment of the copyright for all work produced.</i><p>This is what I've done for years with my Service Agreement. IP transfer officially occurs on full payment, and rights are assigned to Client if Product would not be considered a work made for hire under applicable law. Though if I'm not paid, I send a written warning after N past due. If still don't get paid N days past said notice, I reserve the right to equitable relief, send a cease to desist, and if I still don't get paid I can go to court and get an injunction to stop Client from using it. There is some language that clearly provides a grace period to the Client to use it while awaiting invoices, etc.<p>IP transfer is the most leverage you have as a freelance software consultant. It's the one thing you should have clearly defined in a Services Agreement, and you shouldn't waffle on.
There are at least four US District court decisions that stand for the proposition that software qualifies as a work for hire as either a "contribution to a collective work" or a "compilation": iXL Inc. v. Adoutlet (N.D. Ill. March 29, 2001); Logicom Inclusive, Inc. v. W.P. Stewart & Co. (S.D.N.Y. August 9, 2004); Siniouguine v. Mediachase Ltd. (C.D. Cal. June 11, 2012); and Stanacard, LLC v. Rubard, LLC (S.D.N.Y. February 3, 2016). So far no appellate court has ruled on the issue AFAIK.
My old law partner liked to harp on this point as well, and it is a valid one. However, as a matter of practice most well-drafted work-for-hire agreements also contain a backup assignment clause something like "to the extent the work is not a work-for-hire, I hereby assign the copyright". "Work-for-hire" is one of the many misnomers you find in commercial contracts, along with "intellectual property".
Joel Spolsky recently wrote on this topic, with focus on full time employment<p><a href="https://www.joelonsoftware.com/2016/12/09/developers-side-projects/" rel="nofollow">https://www.joelonsoftware.com/2016/12/09/developers-side-pr...</a><p>"... If you hire a photographer to take pictures for your wedding, you own the copies of the pictures that you get, but the photographer still owns the copyright and has the legal monopoly on making more copies of those pictures. Surprise! Same applies to code."
Ok, wait. I am somewhat confused by this article. It is from my (non-lawyer) understanding that intellectual property ownership generally default to the creator. This happens even in "independent contractor" type of relationships, from my understanding. In the case of an employee/employer relationship, on the other hand, IP generally lies on the employer.<p>So if it's a work-for-hire relationship, IP automatically goes to the potential employer?
Has anyone seen any clauses within an independent contractor agreement, which would allow the retention of certain pieces of the finished work? For instance, I write a class/component/plugin/etc. that I want to use in several projects to increase productivity. Is there a standard way to carve out and retain those pieces of code?
While it may not fall under the precise definitions, I like to think that the source code I produce is both a translation (from an abstract concept language into a machine-executable/-readable language) AND an instructional text (for the machine to parse and execute).<p>From the perspective of a machine, that makes a surprising amount of sense.
DRY (Don't Repeat Yourself) is one of the prime commandments of software development.<p>The problem I see with transferring IP/copyright on a 'work for hire' basis, is that certainly in my case
a substantial portion of the codebase is often code that is being reused for good reason.<p>Losing control of that code now effectively prevents the same code from being reused this elsewhere without getting into further messy contractual details.<p>Personally I refuse to do work for hire - instead the client gets unrestricted right to use code as desired but does not own copyright.<p>Thoughts?
You could certainly argue that writing software as part of a team is "a contribution to a collective work".<p>What surprises me is how many startups are not even aware of at least including a "work for hire" clause when bring on software developers.