OpenOffice.org and contributor agreements

Posted May 22, 2011 8:41 UTC (Sun) by iabervon (subscriber, #722)
In reply to: OpenOffice.org and contributor agreements by pphaneuf
Parent article: OpenOffice.org and contributor agreements

There's the fundamental issue that, if you send a patch to a mailing list, it's hard to tell whether the project has a right to distribute it under the project's usual license. This is somewhat less of an issue if the project uses a strong copyleft license, which you'd be violating if you distributed your patch without licensing it to the recipients. But someone could legally take a BSD-licensed project, change it, and distribute the result under a "only redistribute verbatim" license. And when someone's diffs as posted never include anything about licensing (since they're patches to the middles of files, with all of the license stuff outside of the context), it becomes hard to legally justify redistributing the work without some sort of additional statement. (It's even plausible that someone might want to make a post like "Please don't change free function X like you propose, because that breaks my all-rights-reserved use of the function, which I will reveal to illustrate my argument, but which I'm not contributing.") So it makes sense to ask for an agreement with contributors about licensing their work, even if it is a minimal "I license my contributions to the project under the terms the project licenses their versions to me under."

OpenOffice.org and contributor agreements

Posted May 22, 2011 21:27 UTC (Sun) by pphaneuf (guest, #23480) [Link] (2 responses)

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.

OpenOffice.org and contributor agreements

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

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 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.

Agreeing with Project terms

Posted May 23, 2011 16:37 UTC (Mon) by southey (guest, #9466) [Link] (5 responses)

I find your argument rather moot because sending code means that you already agree to the project's terms including licensing. Otherwise the Project would not (or should not) accept it because it would change the terms of the project.

Of course, if you do not agree with the Project's terms then you should only contribute what you can afford to lose. As was very evident in this article, if you want the code back then reassigning copyrights is one indication that you are less likely to get the code back under favorable terms.

Agreeing with Project terms

Posted May 23, 2011 18:15 UTC (Mon) by iabervon (subscriber, #722) [Link] (4 responses)

Sending code only generally means that you must have agreed to whatever license grants you the right to prepare and distribute that code. The assumption that someone distributing a modification to a BSD-licensed work agrees to distribute the modification under the BSD license is no more safe that the assumption that the person distributing the modification agrees to buy the maintainers beer. As such, projects probably shouldn't accept contributions without some sort of actual agreement, because they can't tell whether that would change the terms of the project or not.

FWIW, I think that copyright assignments are a bad idea in general, which is part of why the only contribution I've made to a GNU project is one where I convinced the maintainer that my change wasn't copyrightable (IIRC, I removed a bogus clause from an expression in make 3.79). But I would happily agree to allow a project to sublicense whatever I send them under the licenses they apply to the releases they make, particularly if the wording of this agreement has gone through public review by community lawyers.

Note that Fedora is actually planning to require contributors to sign an agreement to let Fedora use contributions in the obvious way. They feel that, even though they aren't asking for anything special (like copyright assignment), it's worth having the agreement in place.

Agreeing with Project terms

Posted May 24, 2011 0:04 UTC (Tue) by pphaneuf (guest, #23480) [Link] (2 responses)

What I find confusing is that the author of the article, in a comment stated that whether a CLA required copyright assignment or not. I want to understand whether the Apache CLA is one of the "evil CLAs", or what Mr Phipps calls a "participation agreement". It doesn't look to me like the Apache CLA is granting the Apache Foundation special powers, but then, I'm not a legal expert. What it looks like is that they get the power to sublicense (not relicense) under the same license they use for the rest of the project, which kinds of make sense to me (someone will download and use Apache software, hopefully!).

Of course, Mr Phipps goal of protecting against a company just turning around and selling your code as part of a proprietary product might be a bit moot with a license such as Apache 2.0, because with that license, right from the start, one could just repackage it, and sell it without providing code. So if you're using a BSD-style license in the first place, clearly you're fine with some odd losses of "control".

Agreeing with Project terms

Posted May 25, 2011 19:39 UTC (Wed) by webmink (guest, #47180) [Link] (1 responses)

Apache's agreement is a CLA but appears (to my eyes at least) redundant as it delivers no more than the Apache license itself. As such I would regard it as unhelpful since it legitimises the use of CLAs without delivering a significant community benefit.

Agreeing with Project terms

Posted May 25, 2011 22:08 UTC (Wed) by pphaneuf (guest, #23480) [Link]

Ok, so if I understand this correctly, it confuses the issue (it certainly confused me!), which is harmful in a broader sense, but if I sign it, it shouldn't be harmful to myself personally.

At least, it is no worse than putting out my contributions under the non-copyleft, BSD-style Apache 2.0 license...

Thanks!

Agreeing with Project terms

Posted May 27, 2011 20:45 UTC (Fri) by giraffedata (guest, #1954) [Link]

Sending code only generally means that you must have agreed to whatever license grants you the right to prepare and distribute that code.

A copyright license isn't something one agrees to -- it's a unilateral thing: the author grants a license; the copier uses it to copy (prepare and distribute).

And it's certainly possible to prepare and distribute without complying with conditions of any license, i.e. not having a license at all. It's a copyright infringement, but it can happen.

So it's even more important than you say for projects accepting code to get an explicit license from the author to distribute it. Plus whatever assurance they can get that nobody else has copyright without licensing the code to the project.

As such, projects probably shouldn't accept contributions without some sort of actual agreement

But an agreement isn't really necessary.