The author seems to base his argument on: 1) assuming the reasons a project owner might want to mandate an agreement; and then 2) demonstrating why those assu

The author seems to base his argument on: 1) assuming the reasons a project owner might want to mandate an agreement; and then 2) demonstrating why those assumed reasons are not fulfilled by an agreement. However there exist other good reasons a project may want to mandate a contributor agreement or assignment. If I can demonstrate just one, then his entire claim is moot. Here is one reason. A project owner may want to relicense the project in the future. This would require them to either contact every copyright holder (some of whom may be unreachable in the future), or to require a copyright assignment for all contributions, or to require an agreement permitting such relicensing in the future. I'm sure some contributors explicitly do not want such relicensing to be possible in the future. That's fine - but the author has not argued that this makes such agreements or assignments a bad thing. Here's a legitimate example: what if your project is licensed under the GPL but later you want to add SSL functionality by linking with OpenSSL? You'll need an "OpenSSL linking exception" from all copyright holders which can be extremely difficult to obtain. If you had a contributor agreement or assignment in place, then you wouldn't. What about other things like this that would generally be accepted by the community in the future, but you haven't thought of today? A copyright assignment or suitable contributor agreement derisks you from these. On his "work for hire" point, the same argument applies to any contribution whatsoever, since if the contributor doesn't have permission to assign copyright, that contributor may also not have the permission to license their work. I'm not trying to argue for or against these agreements here; I'm just saying that it seems like the author's arguments are moot because of the very narrow scope of the assumptions that he's made.