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

Posted May 21, 2011 0:56 UTC (Sat) by pphaneuf (subscriber, #23480)
Parent article: and contributor agreements

In the arguments over whether licensing agreements are good or bad, I wish the case of Apache would be commented on. Clearly (to me, anyway), Apache is a successful project that seems to be quite open to the community, and yet, they use a CLA for everything they do.

Is it harming them? If so, how?

(Log in to post comments) and contributor agreements

Posted May 21, 2011 3:17 UTC (Sat) by josh (subscriber, #17465) [Link]

And to flip that around: does it help them? How? It seems entirely unclear why the Apache Software Foundation benefits from requiring contributors to sign over their contributions. and contributor agreements

Posted May 21, 2011 18:15 UTC (Sat) by pphaneuf (subscriber, #23480) [Link]

What do we mean by "signing over their contributions"? The Apache CLA mainly says that you own your contribution and are allowed to make it (similar to the Linux Certificate of Origin), and if you have patents covering this, you agree to give the project a royalty-free license, things like that.

In the case of the Apache CLA, you do not assign copyright, you keep it. You just agree to license it under the same license.

It's pretty clear how it can help them, by covering their ass (you can't contribute code that you have a patent on, then ask for money from everyone, SCO-style, or them getting sued if you contribute code you're not allowed to), but not in a "we can relicense your work and charge money for it" invasive way, anyway, not that I can see?

It's that latter part that I'm trying to understand better. If you sign an Apache-style CLA with someone, can you get screwed over? and contributor agreements

Posted May 23, 2011 14:15 UTC (Mon) by blitzkrieg3 (guest, #57873) [Link]

> In the case of the Apache CLA, you do not assign copyright, you keep it. You just agree to license it under the same license.

I think Jake was specifically talking about CLAs that make you sign away your copyright. and contributor agreements

Posted May 21, 2011 3:18 UTC (Sat) by vonbrand (guest, #4458) [Link]

The point is that asking to give copyright to a commercial entity (who can turn around and sell what you give them) does tend to discourage hobbyist developers, and essentially shuts other commercial entities (who are competitors, or they wouldn't be able to contribute significantly) right out. and contributor agreements

Posted May 21, 2011 18:18 UTC (Sat) by pphaneuf (subscriber, #23480) [Link]

The Apache Contributor License Agreement does not assign copyright.

Now, I understand the Canonical and the OO.o agreements are not the same (I think they do assign the copyright), but I want to understand better whether this is "all CLAs are bad", or "these specific CLAs are bad", and in both cases, why. and contributor agreements

Posted May 21, 2011 6:24 UTC (Sat) by Escubar (guest, #39034) [Link]

Assigning copyright to a foundation which has some openness and you can participate in is certainly different from assigning it to a commercial entity which might or might not decide to close out others at a later point of time. and contributor agreements

Posted May 21, 2011 18:02 UTC (Sat) by pphaneuf (subscriber, #23480) [Link]

Let's be clear, the Apache CLA is not a copyright assignment, the original contributor keeps the copyright. The CLA says that you grant them a perpetual, non-exclusive license to the contributions, that you give a royalty-free license to any patents that cover the contribution (in the context of that contribution/project only), that you own the contribution and are allowed to contribute it (a bit like the Linux kernel Certificate of Origin process).

None of this really seems crazy to me, whether it is to a foundation or a commercial entity. The patent license thing is basically just saying you can't contribute code they can't use unless everyone gives you money (duh). Licensing your contributions is what you do when you give a GPL project a contribution under the same license, it's just saying it explicitly. The rest doesn't really give them special powers, but just cover their asses in case you're contributing "stolen code" or something. and contributor agreements

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

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." and contributor agreements

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

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

Agreeing with Project terms

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

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]

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 (subscriber, #23480) [Link]

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]

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 (subscriber, #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...


Agreeing with Project terms

Posted May 27, 2011 20:45 UTC (Fri) by giraffedata (subscriber, #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.

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