Dave Neary writes about the potential ills of copyright assignments. I agree with Dave that if you require a copyright assignment as a pre-condition to contribution that you will inevitably limit the amount of participation you have. It becomes just one more barrier to entry that one has to jump over.
The answer, however, is not to have no copyright assignment program in place. Having no such program can actually be quite detrimental for the reasons succinctly outlined by the FSF: you can't defend rights or make decisions on licensing on behalf of others. Limiting the number and types of individuals involved in defense and maintenance of licensing is a good reason to have copyright assignment, as it allows both more agile response and to put risk in response to things like licensing disagreements off of the individual hacker in the middle of some hamlet in the pastoral Canadian countryside (or whatever pastoral countryside they may live in).
Having some sort of copyright assignment option in place also prevents problems that can arise whenever someone disappears from the project. It's hardly fair for the future community of your project to forever be tied to licensing decisions taken by predecessors who can no longer be reached.
So how does a project avoid getting stuck in this "rock and a hard place" type decision between "keeping your community open" and "protecting the technology and rights of others"? Simple: have an optional copyright program that your contributors can engage in. This isn't "perfect" from a purists point of view, but it can make things a lot simpler down the line if it's something the bulk of the community gets on board with.
In KDE we have the Fiduciary License Agreement (FLA) which does a neat little bit of legal polka in which the signatories (the contributor and KDE e.V. in this case) swap about rights to the copyrights. After signing, both now have the ability to continue to make decisions on the copyrights and KDE e.V. can defend the code in our shared repository and make licensing decisions if needed.
"Oh no!" some will say, including apparently Dave, "But what happens if KDE e.V. goes evil?! Now they can do bad things!" Well, all I can say is that if you've signed your rights away with no understanding in place as to what the other party can do with those rights then, yes, you made a silly move and deserve everything you get.
With KDE's FLA, we have another document that goes with it: the FRP, which is pronounced "eff are pee" if you are a lawyerish type or "frap!" with a good amount of emphasis on the 'ap' if you are a bit more light hearted. The frap, er... FRP lays down specific guidelines as to what KDE e.V. can do today and in the future. It's a separate document to keep that part out of the courts should we ever need to defend your rights, since it's only really useful between the signatories and could give a GPL violating defendant enough rope to play out a case for a long time playing "let's define this other term first" with the court. The important part is that it protects the rights of the individual without requiring us to enter into some mistrustful standoff based on "I own my property, and I'm not going to share any rights with you so you can't screw me later! Bwuahaha!"
So the FLA is a socially responsible relationship that displays respect for both the individuals and the community simultaneously. It lives in balance between a proper level of trust between parties (e.g. not too much) and respect for the current and future legal health of the project.
When it comes to corporate entities holding all the rights, something Dave also notes can be dangerous, my recommendation is the same: get an agreement with them first before signing over anything. We did this with the Free Qt foundation and it helped preserve the future of Qt quite nicely even though there was a single copyright holder. This made the decision to relicense Qt under the LGPL very easy while preventing the proprietization of Qt.
In my experience when people talk about the danger of assigning copyrights to a company, the reaction to the suggestion that they get something signed first that lays out the rules by which the agreement should be maintained and dealt with the in the future is usually met with "That's a good idea ..." and a bunch of silence. Then usually a few days/weeks/months later they'll repeat the same argument as if there was no good answer.
Oh, and if you're reading this, Dave: Trolltech is now Qt Software, the commercial version of Qt is only different in licensing terms from the open one, Qt was never "community code [they] forked commercial versions off of" (when they did use community code such as Phonon or Webkit, they stuck with LGPL and multiple-copyright holder licensing) and since then Qt Software has announced that they are opening their repositories for public involvement (something I wish was already completed, but these things take time to arrange organizationally and legally). :)
Finally, to everyone who has contributed copyrightable materials to KDE in any meaningful manner (source code, artwork, documentation, etc), please consider signing an FLA. I have. Why? Because I feel it's the most responsible way of handling my relationship with the KDE community in terms of sharing governance of my contributions at no cost or risk to me.
KDE e.V. is currently having some legally sound boilerplate language for signers to pick from for the "what contributions this covers" created for us (for my personal KDE FLA I used a broad "all copyrightable works produced by me in the kde.org repositories now or in the future" phrase, but we want to get a gradient of legally accurate phrases you can pick from to paste in there). We will also be hosting a FLA signing area at this year's Akademy so you can do this in person. It takes all of 5 minutes. You might even get a cookie or a hug or both from Adriaan for doing so. We're still working out those details. ;)
Also, depending on regional law and employee agreements in place, companies that contribute to KDE can also sign an FLA on behalf of their company's contributions rather than have each of your employees do so. It's a great way to show your support for the community you are helping to make better and getting so much from in return.
p.s. This is yet another one of those topics where I see a lot of either/or argumentation ("assign copyrights for the good of the project!" vs "assigning copyrights is bad") when the reality is a lot less black and white. There are balanced, middle-path answers to be had if sought out. The opt-in FLA/FRA is one such answer. It's interesting how often the best of intentions (in this case "protecting our creations") can so easily devolve into either/or thinking that produces no truly good results in any direction.