Under US law, copyright originates with the author. If you write something, you hold the copyright until it expires or until you transfer it to another party. This transfer can happen in two ways, either through an explicit transfer agreement or through a "work for hire" agreement.
The explicit transfer is easy to understand, but can suffer complications. Suppose you are an independent contractor who writes software for a living. A client hires you for a project. You have a consulting contract that states that all copyrights for the commissioned work are transferred to the client. Done. Right? Maybe, maybe not.
For example, what if the software you deliver includes a library that you wrote several years ago for which you hold copyrights? You can save yourself a lot of grief if you make it clear to your client, in the agreement and in copyright notices on the code itself, that the client will not receive copyrights to that previous work. Sure, if there's a lawsuit, you can present evidence that the prior work existed before the agreement and therefore was not commissioned by the client. That will take several months and cost several tens of thousands of dollars and even then you risk a bad outcome, even if you are in the right, since the legal process has a lot more to do with how fast you can write checks than where the facts actually fall. It is much better to make the history and status of that prior work clear before you even start. And that's just one example of the kind of thing that can go wrong.
The work-for-hire transfer is a little trickier. It really has no place in the software world. The work-for-hire concept is based on the idea that work performed as part of a master-servant relationship belongs to the master, so copyrights to works produced in such a relationship transfer automatically. In the situation of the independent software contractor there are two problems with the work-for-hire concept.
First, in today's world a master-servant relationship is usually interpreted to mean regular employment, not contracting. If you are an independent contractor or consultant, then you are probably not performing work for hire, regardless of what any contract might say. Just calling something "work for hire" in a contract does not automatically make it so.
Second, the automatic copyright assignment of a work for hire relationship does not apply to software. US copyright law transfers copyrights for certain specific classes of works if they are commission as part of a work for hire agreement. The important point, though, is that computer software is not in that list of specific classes of work. Therefore, even under a work for hire agreement, copyrights to computer software remain with the author in the absence of an explicit copyright transfer. Let's pause for a minute while all the software developers (and their managers) go look at their employment agreements.
The chances are very good that any client who is asking you to sign a consulting agreement will just assume that paying you money automatically creates a work-for-hire relationship and that such a relationship automatically applies to software. Neither of these assumptions is true and the facts of the matter, as seen by a court, may include a number of factors, such as your degree of independence in your work, how you bill the client, etc. You will probably prevail, but it would be far better to avoid the inhumane machinery of the legal process by starting with clear contract language defining the copyright status of your work.
Kestrel's standing rule for work on cellular projects is that we will hold all copyrights to all source code that we produce. That is not negotiable; either the client agrees or we refuse the job. We make this clear in our communications with clients, put it in every statement of work and print it on our quotes and invoices. Much of that code goes into OpenBTS and those copyrights are reassigned to the Free Software Foundation, which offers a whole raft of advantages that will be fodder for a future post.