I don't think that using a copyleft license really avoids the need for a CLA. It's rather that a copyleft license *is* a CLA that the developer has already agreed to, by virtue of the features it happens to have. And it's only really sufficient if the project uses exactly one copyleft license: if the project were to dual-license the code under two copyleft licenses, a developer could pick just one, but the project needs both. This is actually a potential issue for any project that moved from GPLv2+ to GPLv3+, since a developer who got the GPLv2+ version could pick GPLv2 exactly to accept, make a modified version under those terms, and prepare a patch that is not compatible with the GPLv3. It also doesn't work for LGPL, which allows recipients to prepare GPL-only derivative works.
I think it's worthwhile for the community to agree on a particular legal wording for the ad hoc expectation that developers and projects generally have (contributor grants any recipient the right to sublicense the contribution under all of the project licenses, whatever they happen to be). Since a number of projects across the spectrum (including OO.o and GNU) require copyright assignments, I think it's worthwhile to standardize the legal language for that as well.
Posted May 22, 2011 23:10 UTC (Sun) by jrn (subscriber, #64214)
[Link]
For the former, the Developer's Certificate of Origin 1.1 in Linuxs Documentation/SubmittingPatches is pretty good. Its less permissive than what you described --- it indicates submission under the open source license indicated in the patched file.
For the latter, the language in gnulibs doc/Copyright/assign.future.manual is fairly clear. It allows the FSF to choose a license in the future and imposes some requirements about the nature of such a license. Other projects might not find the text easy to reuse as is, but it seems worth coming up with terms that are equally clear and thoughtful.