Stance on projects that require a CLA (Contributor License Agreement)

Dave Reid wrote in #3:

If we switched to GPLv3 to all projects, which contains much stronger patent clauses, it would basically eliminate the concerns of needing a CLA.

The only part of this that is relevant to the LWG is the comment above. I'll address this here (and then comment on the issue summary seperately).

In 15 years of Drupal, I an not aware of a single incident involving patents. IMHO: If it ain't broken, don't fix it.

The license we require all contributors to Drupal.org to adopt is GPLv2+. For the record: the meaning of the "+" is that the code is made available under GPLv2 with an option to downstream recipient to re-license the code to GPLv3. This means that the GPLv3 patent clause:

Each contributor grants you a non-exclusive, worldwide, royalty-free patent license under the contributor's essential patent claims, to make, use, sell, offer for sale, import and otherwise run, modify and propagate the contents of its contributor version.

has already been agreed to by all contributors on Drupal.org. If somebody thinks they need a CLA to make the contributor agree to this, they should think again, since they already have it. The contributor has not only agreed to make the code available under GPLv2, he/she has also agreed to the re-licensing clause implied by the "+" and by the phrase "and/or later".

IMHO, the license we currently use (i.e. GPLv2+) is far superior to GPLv3 if one care about freedom. The only downside is that the "+"-bit is sometimes misunderstood - but the disadvantages of switching to GPLv3 are much greater (but the GPLv2+ vs. GPLv3 discussion belongs in a different issue, i.e. #1449452: Give installation profiles/distributions GPLv3+ license as option for packaged downloads).

Can an organization or individual require users on Drupal.org to sign a CLA before contributing to a project?

Obviously not. The existence of a CLA does not suspend free will.

However, to be allowed to push to the Drupal.org repo, you must agree to our CLA - the Drupal Git Repository Usage policy. People that for some reason does not agree with our CLA can still contribute - but elsewhere (such as GitHub).

Likewise, a project owner can ignore contributions from people who hasn't signed the CLA, but he/she cannot bar people from posting patches in the project's issue queue on Drupal.org, or from creating forks containing those patches.

Does this go against our existing Git repository usage policy in any way?

That depends on the CLA. An owner imposed CLA as such does not necessarily go against our Git repository usage policy, but one that contains terms that are in conflict with our Git repository usage policy obviously does.

All code on Drupal.org is made available under GPLv2+. So any owner imposed CLA that invalidates the GPLv2+ license would be null and void.

Provided the owner CLA is not in conflict with our Git Repo Policy, a project owner can refuse to promote your contribution (patch) to the repo unless you sign a CLA. But he/she cannot stop you from posting patches, and he/she can not stop you from taking all the code in their repo, including all the code contributed by people stupid enough to sign the owner CLA, and forking it. This is the beauty of free software.

Should it be allowed?

This is related to #2650610: Can projects declare their own code of conduct requirements?. So far, the practice here has been that: 1) project owners can accept and reject patches and co-maintainers at will; but 2) a project owner that refuses to commit RTBC patches to an important project will have his/her project forked by people who want to see those patches committed; or even 3) losing ownership of the project for being an unresponsive owner.

Personally, I don't think we should regulate what project owners do or say directly. Going there is a slippery slope, and the community can take care of it (by forking or refusing to contribute to projects where the project owner imposes stupid terms as a condition for contributions being accepted).

Does the CLA have to be maintained in code on Drupal.org, or is it allowed to be a form on an external site?

As pointed out already, our Drupal Git Repository Usage policy is a CLA, and it is maintained on Drupal.org. Having additional owner imposed CLAs attached to individual projects is confusing and should be discouraged. In other words: They should not be part of the Drupal.org ecosystem. We can not regulate what people put up elsewhere, but if this happens, our policy should be that this is free speech (and must be tolerated as such), but that agreeing to the CLA is not a condition for contributing to the project on Drupal.org.

If you (or anyone else) believe that there is something lacking from our existing CLA, you should propose that it is amended.

Why couldn't I declare I won't accept any patches to Pathauto unless you've posted a photo of you trying to touch your ear with your tongue?

Of course you can declare that. And as a staunch supporter of free speech, I'll support your first amendment rights to do so.

But I am also pretty sure you wouldn't receive many patches - at least not with photo attached - after making such a declaration (and if you really did this, some people may even think you're a kind of a jackass).

Do we classify these types of barriers to contributions as fair or unfair?

I think "stupid" is the word you're looking for: It is stupid to put up barriers to contribution to a free software project. If you replace "stupid" with either "fair" or "unfair" in that sentence, it stops making sense.

Can't I just fork the module instead?

Of course you can!

Won't that piss off the organizations we are trying to attract to Drupal.org?

If an organization is pissed off by somebody forking their project because they impose barriers to contribution to their branch, maybe they need to get a better understanding of the free software ecosystem?

Anyway, I do not think that this is the type of organizations we want to attract to Drupal.org.

I just wanted to say: thank you, @gisle, for your excellent, excellent answers.

Harvard's Berkman Center is taking over CLAHub.com. That gives this approach of limiting which improvements to code will be even be considered some level of legitimacy, so I expect we'll be seeing more of this in the future.

https://github.com/clahub/clahub/issues/111#issuecomment-196120047

but he/she cannot bar people from posting patches in the project's issue queue on Drupal.org, or from creating forks containing those patches.

Where I think this becomes problematic are statements like...

http://cgit.drupalcode.org/metatag/tree/CODE_OF_CONDUCT.txt

Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful.

On Drupal.org, individual project maintainers do NOT have the right to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions or ban users that are not aligned to with a customized project CLA.

No new input for three months. I think this currently works as designed, so I am closing.

Feel free to reopen if you still think this question needs more clarification from the LWG.