xemacs, yeh

Perhaps it is not the policy itself, but the fact that people trust the FSF.

The exact same policy might not work as well for other organizations.

FSF is a non-profit and whatever one can say about RMS, noone is going to ever accuse him of trying to take advantage of the code in a proprietary way and besides there is a explicit counter promise in the legal contract. None of that applies to commercial organizations.

> xemacs development stopped _years_ ago and their mailing list archives have just been accumulating spam.

While xemacs is certainly not a very active project, and it seems questionable whether the next release will ever actually be finished, it's not *completely* dead, and the mailing lists have actual content. Maybe you looked at the wrong list?

http://list-archive.xemacs.org/pipermail/xemacs-beta/

> If the success of xemacs is the only evidence for his criticism of FSF's assignment policy, then FSF's assignment policy must be pretty excellent.

OK, so the reasons why I think copyright assignment is bad for the ecosystem essentially boils down to

1. It creates an unequal balance of power between the assignee and the contributors, since the assignee gets more rights in the code than the rest of the ecosystem.
2. It's unsafe because, however much you might trust the assignee now, it may be bought by some evil company or its board may change composition.
3. It creates anaemic communities and bureaucracy. A good example of this is evolution: when Novell gave up requiring copyright assignment, the number of external contributors jumped massively (plus Red Hat contributions went from near zero to being quite substantial).
4. It's jurisdiction based. I know people who've failed for years to contribute patches to the FSF simply because they don't live in the USA and they refuse to sign an assignment which would be invalid in their home jurisdiction.

Conversely, it's very hard to get out of the FSF why they think copyright assignment (at least to them) is a good thing. The basic reasons seem to be

1. We have to own all the code to enforce the licence. Well, this one's been debunked by the SLFC with busybox and gplviolations.org with the kernel.
2. We need the ability to relicense. This is a bit blunted by the FSF promise only to relicense to something substantially in the spirit of GPL. As long as they only accept code under GPLv2 or later *and* the new licence can be called GPLvN (because it's in the spirit), then there's no issue.
3. We need to be the controlling entity deciding on enforcement (by the way, this means that by signing the FSF assignment, the developer gives up any interest they had in enforcing the licence to their own code). This is fine and dandy in a big brother knows best kind of way, but I rather prefer a world where control is decentralised and individuals are empowered to call corporations on the use of their code (this is what gplviolations.org does; in the FSF we own it all world view, they wouldn't be able to function).

So I still don't have a convincing argument for why the FSF should continue to insist on assignments. If there's no good reason to do it, perhaps it's time to stop?

I do have a good one for why they shouldn't: Every company I go to to persuade them to eliminate their assignment policy always whines "but the FSF does it". Bradley's blog post (http://www.ebb.org/bkuhn/blog/2010/02/01/copyright-not-al...) while true, essentially amounts to telling the company that the FSF isn't evil and they are, which isn't exactly helpful. It would be far more powerful to be able to turn up with the unified message from the entire Free and Open Source ecosystems that copyright assignments are wrong. While the FSF fails to be on board with this, and worse still appears to condone it, the damage to the ecosystem done by corporations seeking to make balance sheet assets of community code gets more and more substantial.