Shared publicly  - 
For something that creates so much discussion and confusion, it's surprising how it really boils down to just one sentence.
The Open Source and Free Software communities work on the principle that when I contribute patches to a project, I'm donating my time, expertise and resources. In return for that donation, I receive the time, expertise and resources of the rest of the community on equal terms to that with which they receive mine.

I benefit and the community as a whole benefits.

Certain projects make you sign agreements when you contribute that instead make the terms unequal, usually benefiting just one party. When you contribute under one of these agreements, the community may benefit, but one individual or company benefits more. They receive all your time, expertise and resources but reserve the right not to return the favor.

I'm a coder in my day job, and I give my time, expertise and resources to that company - and they aren't under any obligation to return that favor. In return they pay me.

A CLA is just an employment without a wage.
Kristian Høgsberg's profile photoNicolay Doytchev's profile photoJe Saist's profile photoMichael Hasselmann's profile photo
A project, let's call it Rim, is using a Canonical-like CLA and is licensed under GPL. Say the last released version is 1.2. Now the company behind it decides that it wants to deprive the community from it and releases version 1.3 under EULA, without sharing the source. Is there anything stopping the community to fork version 1.2 into project FreeRim and continue the development under GPL, without the help of the company?
You can fork it, but why contribute at all while there is such a CLA?
+Nicolay Doytchev Philosophically, no. Realistically yes.  

In order for many coding  projects to continue under a forked version the project requires  a coder capable of actually writing the code in the first place.  

We've seen one aspect of this happen with #MySql  and #MariaDB . MariaDB would not be the huge success that it is if it were not being programmed by the same exact engineers who originally wrote MySql to begin with.   We've also seen this aspect of key original coders working on a fork to produce a new superior software version with #LibreOffice  against  #OpenOffice  as well as #CalligraSuite  against  #Koffice

We've seen another aspect with #Firefox  and #IceWeasel  under Debian. The Debian developers took umbrage against the Mozilla Trademarks and artwork licensing; which many downstream users considered a trivial non-issue. So Debian fork(s) the Mozilla source code and builds their own version. This aspect is also mirrored in #CentOS  versus #RHEL . CentOS strips  /  *stripped*  out the RHEL branding and artwork and published their own version.  However, these types for forks are largely bound to the upstream source; IceWeasel and CentOS never could really differentiate themselves from simply being source code rebuilds as many of the key engineers and developers capable of driving those projects were invested elsewhere.  Granted, that's now changing with CentOS; so that example is mostly historical.

These examples may highlight just WHY  the whole +Debian _debate_  on systemd versus Upstart leaves many downstream users tilting their head.  Upstart should have never even been presented as an option in the first place Because  of that CLA; especially given Debian's history of being overly anal on Free-Software positioning. 

So people like Ian Jackson are claiming that Debian can just fork  the code from Upstart and maintain their own version; like Debian already does with Mozilla projects.  Slight problem; those Debian versions of Mozilla software are entirely reliant upon Mozilla to actually do all of the heavy lifting of development and writing the code. 

In the same way, a fork of Upstart would still be entirely reliant on the Upstart code-base. It's not that Debian does not have the developer base that could write their own init system, write their own answer to kdbus, or so on and so forth.  It's that a significant number of developers capable of doing that kind of work to begin with have already stated flat out that the Canonical CLA was WHY THEY WORKED ON SYSTEMD TO BEGIN WITH.,  

Let me repeat that different words in case Ian Jackson or +Jono Bacon or +Mark Shuttleworth or anybody else from Canonical or who works with Canonical like +Colin Watson   actually reads this. That CLA of Canonical's already directly cost them the exact developers who could have made Upstart a success across all distributions. That CLA already fueled an answer to Upstart that is under a clear Free-Software licensing format. 

Now, honestly, I've been biting my tongue to keep from posting this type of whiskey tango foxtrot doods: how is this even an issue in the first place  posting on Canonical staff members to the Debian mailing list. There are cooler heads involved there like +Bdale Garbee, Intel's +Keith Packard, and Russ Allbery. 

But hopefully even a cursory glance at history gives you an idea over why simply forking Upstart out of the CLA is not a reasonable option for Debian to pursue. 
+Nicolay Doytchev also, often the concern isn't about the copyright holder taking the project closed source, but that the project isn't usable under its GPL license.  Whether you have to link it into a commercial product, use it with binary drivers or run on a device that only runs signed binaries, this is a option that's only open to the copyright holder.  While the project remains open source, only the company holding the copyrights can realistically use it.  You're giving away your work to another company to profit from without you or your company never being able to do that.
+Kristian Høgsberg , right. So let me correct myself - let's say the project is under the saner LGPL. Then linking and running binary blobs should be fine. If going closed source isn't a concern, isn't that the same as the no-CLA case? In such a case the only benefit that the copyright holder has over the no-CLA case is that it can dual-license the software under proprietary terms to SAMSUNG and profit from that. That said, a in a no-CLA project, as far as I understand, noone can do such dual licensing, because noone has all the copyright. So if this is indeed the case the CLA/no-CLA difference (with LGPL) comes down to - one company can profit by dual-licensing vs. no company can profit by dual-licensing. I think the second case is clearly more beneficial, because it's no worse for everyone, but better for some than the first case. Also it could have the benefit of some of those profits being poured back into the community of the project. So GPL+CLA==BAD, LGPL+CLA==NOWORSE or BETTER than LGPL-CLA. Please debunk my logic if incorrect.
+Je Saist lot's of what you say is clear. I'm trying to get some specific idea about the legal bounds of the CLA and whether it really is introducing unhealthy licensing distortion. What +Kristian Høgsberg said about GPL and using proprietary pieces with it is really true and in such a case, I can see why contributing to a GPL+CLA project would be more of a charity work than contributing to GPL-CLA project. I'm trying to figure out whether that's still the case for LGPL+CLA. My logic seems to point to no being the case, but I could be wrong.
+Kristian Høgsberg you don't have to explain that to me as I'm not entitled to that. It'd just be nice and you don't have to go in great detail if you decide to. I know it takes time.
+Nicolay Doytchev I'm not a lawyer. Yes, I have taken some legal classes, but a few semester's credit does not grant expertise. I can not say with any degree of authority that Contributor License Agreements  in general distort Free-Software or Open-Source Software licenses. 

I can, however, try to evaluate individual an CLA over what those specific CLA's grant or promise.  A direct case in point that matters to me, and involves the LGPL, is the CLA that covers #QT .  The owner of QT, which is #Digia , essentially uses the CLA to take downstream patches from contributors in the #KDE  space and "resell"  those changes under a commercial license to entities that have no intention of ever contributing their QT changes back-upstream.

However, the same CLA that grants Digia the authority to re-license contributions under a proprietary license... is the same CLA that grants the #KDEFreeQTFoundation  the authority to re-license the QT code-base under a MIT style license in the event that Digia, or any other potential owner, stops updating the project:

That, "trigger"  if you will has been considered in the past as one of the few reasons that the QT CLA is acceptable to Free-Software and Open-Source Software proponents.  In the case of the QT CLA then, the CLA itself does not warp the LGPL licensing intentions; but instead ensures that Digia or other potential owners are motivated to continue supporting the Free-Software release. 

However, that's just one case in point... and as I think +Aaron Seigo pointed out... when KDE e.v. and Trolltech struck the KDE Free QT Agreement, it was being looked at by lawyers who were looking after the interests of both parties involved.  Many other CLA's are not drafted with the interests of both parties in mind... so making a generalized assumption on CLA=Bad is not... entirely useful.
Add a comment...