User: Password:
Subscribe / Log in / New account and contributor agreements and contributor agreements

Posted May 22, 2011 21:27 UTC (Sun) by pphaneuf (subscriber, #23480)
In reply to: and contributor agreements by iabervon
Parent article: and contributor agreements

So, if I understand this correctly, a contributor agreement is not really necessary with copyleft, because the simple act of contributing (which is distributing) would mean that it's at the very least contributed back under a compatible license, or at least, not under some more restrictive one. And for a project using a BSD-style license, an agreement can help clarify what is going on. That's also why you have to make the license of your contribution perpetual and permanent, so that someone can't go and rescind the license to the project later, saying that everyone using that project's software owes him money for a license.

I agree with your assessment, and while a a copyleft proponent might say that this is a clear sign that one should always go with a copyleft license, but for someone who just wants to get code out there with a BSD-style license, does it make sense to use a CLA? Is there some trap, for either party? If so, can they be fixed?

After that, maybe the OO.o or Canonical CLAs aren't good, but I'd like this to be constructive, and see what we can learn.

(Log in to post comments) and contributor agreements

Posted May 22, 2011 22:46 UTC (Sun) by iabervon (subscriber, #722) [Link]

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.

Standard agreements

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 Linux’s Documentation/SubmittingPatches is pretty good. It’s 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 gnulib’s 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.

Copyright © 2018, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds